Bamboo

Bamboo is another available tool for setting Continuous Integration in your environment. Its one of the simplest tools i have come across for building a continuous integration system.

http://www.atlassian.com/software/bamboo/

The website shows a 10 minute tutorial which helps in setting up and starting the continuous integration server. The configuration options with this tool are very simple and helps in setting up the environment through the user interface available in this tool.

It has easy integration with build tools like Maven, Ant etc.

Maven

I have been using ant for a pretty long time and i was very comfortable with the flexibility it gives , until i started using Maven. Its almost been a month since i have started using maven , and i feel i will never go back to ant.

Maven works on the principle on "Convention over Configuration" .

Basic convention is each module builds a single artifact and there is a pom file associated with each module which describes all the dependencies required by the module and the properties of the module. The pom file when run can help you do a lot of things like

Compile the code.
Build the Jar
Run the test cases.
Build Java Docs ...etc and many more

Each of the above tasks belong to a particular phase in the Maven build cycle. The best things to use Maven is with a IDE like Eclipse or STS which has complete support for maven.

After i thought about writing the basics of Maven , i came across this blog from spring source which in details explains about the basics of Maven which should be a good starting point.

http://blog.springsource.com/2011/01/17/green-beans-getting-started-with-maven-and-spring/

Maven comes in with easy integration for build tools like Bamboo, Hudson and Cruisecontrol.

Once you start using Maven managing the modules. its version and its dependencies becomes a very simple task.

Spring Bean Life Cycle Phases

I want to demonstrate the bean Life Cycle with a help of a simple Example.

Phase 1. BeanPostProcessor: Bean definitions are changes here.

[Example : Property file replacement as property values.]

Phase 2: Object Creation Phase

Phase 3 :Setting Required Dependencies

Phase 4: Initialization Phase


There is a separate phase called BeanPostProcessor phase in which there the bean itself can be changes.

The org.springframework.beans.factory.config.BeanPostProcessor interface consists of exactly two callback methods. When such a class is registered as a post-processor with the container (see below for how this registration is effected), for each bean instance that is created by the container, the post-processor will get a callback from the container both before any container initialization methods (such as afterPropertiesSet and any declared init method) are called, and also afterwards. The post-processor is free to do what it wishes with the bean instance, including ignoring the callback completely.

Spring uses runtime AOP and hence creates proxy based implementation using this phase.
Since AOP auto-proxying is implemented as a BeanPostProcessor itself, no BeanPostProcessors
or directly referenced beans are eligible for auto-proxying (and thus will not have aspects 'woven' into them.

In my sample example i will not be talking about BeanFactoryPostProcessorPhase or BeanPostProcessor instaed will be concentrating on the phases.

Consider teh following three simple classes.

public class Bean1{

private Bean2 bean2;

private Bean3 bean3;

public void setBean3(Bean3 bean3) {
    this.bean3 = bean3;
    System.out.println("Setter Called For bean3");
}


public Bean1(Bean2 bean2) {
    super();
    this.bean2 = bean2;
    System.out.println("Bean 1 constructor called");
}

public void init() {
    System.out.println("Init of bean1 method called");
}

}

public class Bean2 {

private Bean1 bean1;

public Bean2() {
    super();
    System.out.println("Bean2 constructior Called");
}

public void setBean1(Bean1 bean1) {
    this.bean1 = bean1;
    System.out.println("Setter Called");
}

public void init() {
    System.out.println("Init of bean2 method called");
}

}

public class Bean3 {

public Bean3() {
    super();
    System.out.println("Construictor Called for Bean3");
}

private Bean1 bean1;

public void setBean1(Bean1 bean1) {
    this.bean1 = bean1;
    System.out.println("Setter for Bean1 Called in Bean3");
}

public void init() {
    System.out.println("Init Called For Bean3");
}

}

The spring xml will be as follows

    <bean id="bean1" class="com.test.Bean1" init-method="init">
    <constructor-arg ref="bean2"></constructor-arg>
    <property name="bean3" ref="bean3"></property>
</bean>

<bean id="bean2" class="com.test.Bean2" init-method="init">
</bean>

<bean id="bean3" class="com.test.Bean3" init-method="init">
    <property name="bean1" ref="bean1"></property>
</bean>

OutPut :

Bean2 constructior Called
Init of bean2 method called
Bean 1 constructor called
Construictor Called for Bean3
Setter for Bean1 Called in Bean3
Init Called For Bean3
Setter Called For bean3
Init of bean1 method called

Let me explain how this workz

Phase 2: Object Creation Phase
Phase 3: Initialization Phase
Phase 4: Setting Required Dependencies


bean1 : Phase2(started) - Tries to create object.Since the constructor requires bean2 goes to beans 2

bean2 : Phase2(started->completed) - Creates teh object(Hence sysout from constructor)
bean2 : Phase3(started->completed) - Nothing to be done as no property setters are present
bean2 : Phase4(started->completed) - Calls init method(As there are no property values to be Set)

bean1 : Phase2(completed) - Since beans 2 is ready this phase will complete(constructor sysout printed)
bean2 : Phase3(started) - Checks for dependency and finds bean3

bean3 : Phase2(started->completed) - Creates teh object(Hence sysout from constructor)
bean3 : Phase3(started->completed) - Sets the dependencies. [******** beans 3's init is called b4 bean1's init]
bean3 : Phase4(started->completed) - Init method called.

bean1 : Phase3(started->completed) - Setters called
bean1 : Phase4(started->completed) - Init Method called.


Hence all the beans go through these individual life cycle methods.

The following is the ordering for initialization methods based on the approach followed for initializing:
[All these are part of Phase4 above]
• Methods annotated with @PostConstruct
• afterPropertiesSet() as defined by the InitializingBean callback interface
• A custom configured init() method


In all the cases spring tries to ensure that before dependencies(beans) are set , the dependency(bean) is properly initialized.(dependency set and init called). {**** -Not always true for simple property injection - i. e before bean is injected its(injected bean) init may not have been called }

This is strict for Constructor injection.[In the above case if we try to modify the bean definition for bean 3 as follows]

<bean id="bean2" class="com.test.Bean2" init-method="init">
<property name="bean1" ref="bean1"></property>
</bean>


We get the following Exception

Caused by: org.springframework.beans.factory.BeanCurrentlyInCreationException: Error creating bean with name 'bean1': Requested bean is currently in creation: Is there an unresolvable circular reference?


This is because bean1's constructor depends on bean2. and bean2 has a setter which is bean1. Bean2 just after completing phase 2(object creation will not be injected into constructor , will wait for all phases to complete)

***** - But this is not the case with simple property injected.

Ex : Bean1 and Bean 2 injected visa versa will work fine.

Design Patterns

OO principles

1. Encapsulate what varies.

Take what varies and "encapsulate" it so it wont affect the rest of your code.

2 . Program to interface not an implementation. [ program to super type can be abstract class also]

Ex : Animal d = new Dog();

Animal g = getAnimal() - better { could be injected at run time even better , can plug new implementation without change of code}


3. Favour composition(HAS-A) over inheritance(IS-A)


Advantages of Composition over Inheritance


1. Refactoring becomes very easy [No need to change super class]
In an inheritance relationship, super classes are often said to be "fragile," because one little change to a super class can ripple out and require changes in many other places in the application's code.

back-end class - Super class

front end class - Sub class


It is easier to change the interface of a back-end class (composition) than a super class (inheritance). [Only subclass functionalities which directly depends on super class can be changed , other implementation classes using teh sub class need not change.]


It is easier to change the interface of a front-end class (composition) than a subclass (inheritance). We can't add to a subclass a method with the same signature but a different return type as a method inherited from a superclass. Composition, on the other hand, allows you to change the interface of a front-end class without affecting back-end classes.


2. Composition gives high flexibility.[Change behavior at run time]

Composition allows you to delay the creation of back-end objects until (and unless) they are needed, as well as changing the back-end objects dynamically throughout the lifetime of the front-end object.

With inheritance, you get the image of the superclass in your subclass object image as soon as the subclass is created, and it remains part of the subclass object throughout the lifetime of the subclass.


3. The explicit method-invocation forwarding (or delegation) approach of composition will often have a performance cost as compared to inheritance's single invocation of an inherited super class method implementation [but very negligible]

• Don't use inheritance just to get code reuse If all you really want is to reuse code and there is no is-a relationship in sight, use composition.

• Don't use inheritance just to get at polymorphism If all you really want is polymorphism, but there is no natural is-a relationship, use composition with interfaces.

Ref : http://www.artima.com/designtechniques/compoinh.html

JavaScript/Css Basics- Presentation

Linking a java script/ css presentation prepared by one of my friend . It covers right from basics.

https://dl.dropbox.com/u/4970006/blog/static/presentations/webapps.html

Issues during migration of platform to OSGi

1. Certain framework classes had to be part of boot delegation like Terracotta.

Added com.tc.* to org.osgi.framework.bootdelegation = \ in

/home/pg/thirdparty/springsource-dm-kernel-2.0.0.RELEASE/lib/java6-server.profile

2.Certain jboss imports were not getting part of package imports when jars were run through bundlor

So had to explicitly add these to bundles which required JMS(JBoss MQ) functionalities.

org.jboss.logging,
org.jboss.mq.referenceable,
org.jnp.interfaces,
org.jboss.util,


3. If there is any Custom Class Loader created in the code ,special care has to be taken to ensure that you set the custom class loaders parent to Bundle Classloader.


4. Special care needs to be taken that classes loaded through custom class loader should see all its imports and exports through its parent Bundles manifest.


5. Where ever class was loaded using Class.forname() we had to change it to ensure these where done through Thread Context Classloader where classes were laoded from other bundle.

6. Since we use jbossallclient.jar for JMS(Jboss MQ) we had issues as this was conflicting with packages in bootdelegation.

We could either solve this using explicit imports from system bundle(bundle 0).

a.

BootClasspath was exporting javax.management

Removed javax.management from jboss all client jar - Using bundlor excluded exports manifest

b.

Because jboss-allclient.jar also exports javax.jms which is also exported by javax.jms_1.1.0 bundle

Ensured jbossallclient.jar imports this and doesnt export it by changing manifest.


7.Since there were multiple bundles exporting org.apache.log4j , i had to explicitly mention bundle
symbolic names for the imports.

There were certain cases of cyclic dependency since it was legacy code.

Code in one bundle was initialized(spring application context) by code in another bundle. This cyclic dependency was solved by
explicitly marking this imports as optional(resolution="optional").


8. Wherever Application Context was read using regular expression had to change classpath: to classpath*: to ensure that all classpath resources are read.

BootStrap Initialization GuideLines (For same code base to work in both OSGi and Non-OSGi environment)

During the migration of the platform into OSGi we had use cases where we needed the platform to work in both OSGi and non OSGi cases until the OSGi platform had stabilized.But our mail goal was we needed the same code based and packaging to work in both OSGi and non OSGi use cases.

We had come up with list of guidelines and conventions to achieve the same.

One major assumption was that in a non OSGi case there has to be a single application Context as against OSGi where there is application context
per bundle.


1. Separate xml files for OSGi service definitions and bean definitions.

2. Naming convention for spring xml files are as follows

<MODULE_NAME>-osgi-context.xml
<MODULE_NAME>-bean-context.xml
3.Naming convention for beans to be exported as services

Service Exposing side
<bean id="<MODULE_NAME>service" class="XXX.YYY.ZZZ"/>
<osgi:service ref=""<MODULE_NAME>service"" interface="bla.bla.IService"/>

Service Reference side
<osgi:ref interface=" bla.bla.IService" id="<MODULE_NAME>service"/>
Now this <MODULE_NAME>service can be used as regular bean.
This convention will help us run the same code base both in OSGi and non OSGi cases without changing these xmls. Note that in non OSgi cases we will initialize META-INF/spring/*-bean-context.xml. This will help in unit testing so that only required xmls can be initialized.

4. All spring bean definition files have to be in the following location - META-INF/spring/*

5. Ensure that in NON-OSGI cases individual products/services/modules do not independently initialize the application Context.There should be a independent initialization moduel which initilialises the app context across all products(jars) in the Vm based on some naming convention followed by the products.This will help easy wiring of beans across products which in other cases are done through OSGi services.Also the common module will expose a method in for accessing the beans present in the context.

6. Conventions have to be followed so that there are no same named beans across products as there is a single application context and objects will get overridden.

7.Boot Strap initialized xmls with this regular expression - [*-bean-context.xml]

[** Ensure that if any module in not following all these conventions the spring xml file has to be in any other folder than META-INF/spring ***[so that DM server doesnt initialize it ]* . *Ensure that in any case the spring xmls** are not initialized twice *[all the above guidelines are just to ensure that ] ***]

8. Property File initialization

Property placeholder config definitions containing files should be seperated from bean and osgi definition files and should be present in META-INF/spring folder.

Naming convention pgconfig-<MODULE_NAME>.properties

This will be initialized in bootstrap based on this expression in teh bootstrap propertyPlaceHolconfigurator : "classpath*:pgconfig*.properties"

{"classpath*:META-INF/spring/bootstrapconfig.xml","classpath*:/META-INF/spring/*-bean-context.xml"};

bootstrapconfig.xml contains --> <context:property-placeholder location="classpath*:pgconfig*.properties"/>

9.Avoid using Bundle Activator and instead use spring config (init method) for initialization as this will give us a common approach in both OSGi and Non OSGi cases.