Sunday, October 5, 2014

How to register a custom deployer in Carbon

Deployers in Axis2 are used to track the new file additions, file updates and file deletes. Writing an custom deployer is not a difficult task. A deployer is an implementation of org.apache.axis2.deployment.Deployer interface. You can find more details on how to write a deployer on : http://wso2.com/library/3708/

Once you write your custom deployer, you have to register it. Following  is how to register a custom deployer.

Add the deployer details to the component.xml file

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
<component xmlns="http://products.wso2.org/carbon">
   <deployers>
       <deployer>
           <directory>sample</directory>
           <extension>xml</extension>
           <class>
               org.wso2.carbon.samples.deployer.CustomDeployer
           </class>
       </deployer>
   </deployers>
</component>

As the information given in the above configuration, a directory named ‘sample’ in the location ‘repository/deployment/server’ will be monitored. Whenever file with extension ‘xml’  is added, modified or removed deployed() method will be called.

Add the following entry to the <configuration> <instructions> list of the maven-bundle-plugin in your pox.xml file.

<Axis2Deployer>CustomDeployer</Axis2Deployer>

To be responsive for real time file additions, updates and deletions configuration ‘hotupdate’ in Axis2.xml has to be set to true.

<parameter name="hotupdate" locked="false">true</parameter>

You can find a sample code in : https://github.com/jsdjayanga/How-to-register-a-custom-deployer-in-Carbon

Friday, October 3, 2014

Internal synchronization of carbon kernel (Holding transports until the kernel get ready)

Starting up sequence of internal components of the carbon kernel is crucial for the kernel to operate  properly. Most importantly kernel should not start accepting external messages until it is ready to process messages. So it is needed to delay the activation of transports until the kernel is ready. Carbon kernel is made up of OSGi based components. According to the OSGi  standards there is no definite order in which the bundles get activated.


To overcome the this sequencing problem, In carbon kernel there is special component which handles this synchronization. ‘StartupFinalizerServiceComponent’ an OSGi component, which delays the activation of transports.


If all the required services are ready by the bundle activation time, then the ‘StartupFinalizerServiceComponent’ call the ‘completeInitialization()’ method which performs the initialization of transports. But if the required services are not available at the bundle activation time, transports will not get activated. And it will wait until the required services are available.


‘StartupFinalizerServiceComponent’ is a ServiceListener. Each time a service change happens serviceChanged() method is called, and this will check for the required service list. Once all the required services are available, it calls the ‘completeInitialization()’ and activate the transports.