Using Custom Class Loaders In Spring Dm -OSGi

One has to be careful while using custom class loaders in any of the bundles.This is beacuse in the context of osgi each bundle will have a classloader whose parent will be the bootclassloader.
And the hierarchy of the classes searched will be delegated from child to the parent classloader. Hence when a class is not found in a bundle, the responsibility will be delegated to the parent classloader.
When we define a custom classloader as follows
CustomClassLoader = new CustomClassaloader() - > its parent is set to the boot classloader. Hence though its inside the bundle it canot see any classes inside the bundle .
The easy way to get away from this is to set the custom class laoders parent as the bundle classloader.Now any request to the classes in the custom class loader will be delegated to its parent that is the bundle classloader and the clases will be found.

Classloader hierachy in Spring Dm - OSGi

When a bundle is deployed into the spring dm the follwing will be the classloader structure
In the case of bundle

Current classlaoder ->LoaderServerBundleClassLoader: (Bundle calssloader)

Parent1 ->sun.misc.Launcher$AppClassLoader@1754ad2

Parent2 ->sun.misc.Launcher$ExtClassLoader@1833955
In the case os a class put in the boot delegation path

Current Class Loader->sun.misc.Launcher$AppClassLoader@1754ad2

Parent1 ->sun.misc.Launcher$ExtClassLoader@1833955

Parent2 ->null

Ref :http://blog.bjhargrave.com/2007/07/why-do-classforname-and.html

OSGi - Putting classes into Boot delegation path

To put any classes into the the boot delegation path in Osgi the follwoing needs to be done
add the entry into org.osgi.framework.bootdelegation
in the follwing file --> springsource-dm-server-ee-1.0.1.RELEASE\lib\java6-server.profile
Once classes are added into the this boot path there is no need to import this in any of the bundle manifests.
But the disadvantage here is that these classe are loaded by the Boot Class loader , and hence we loose the independent runtime deployments of these classes.
But this trick can be used while integrating with teraacotta or other cases , where we can give away independent deploymenta dvantage , but get flexibilty of loading these classes using boot class laoder and also have these classes directly without any imports.

The other way of getting classes under boot class path is to make it system package or extender bundle of a system package.

Osgi - Package Imports to Shared Services Benefits

Whenever a bundle gets updated in a OSgi environments the direct affect is that all bundles which have any import will also get bounced . This information is not displayed in the dm server console.
I have observed this change only by putting sysouts in the bundle activator. I feel this should not be hidden in the console.
This will also happen in the service model if the interfaces are bundled along with the implementation.
Bundle a -> Implementation & interface and provides Osgi service
Bundle c -> osgi service importer,has import for intercface packages from a
Now if we bounce the bundle a to change the implementaion bundle c also gets refreshed though we dont change the interface.
The only way to avoid this is to have a seperate bundle b with interface
Bundle b - > has interface
and now bundle c imports from bundle b , also bundle a imports from bundle b . Thus any changes in bundle a, thats the implementaion will not have any refresh of other bundles.

Modifying the web pages inside OSGi web bundle

The imapct of packaging into a web module in OSgi was that we lost the ability to modify JSp pages on the fly. This was a drawback since our teams used to modify the JSps in production environment very often.
Spring Dm has promised to avoid this change by providing a flexibilty to allow breaking of web bundles into multiple parts and allow for thier independent deployments in the future releases.
Untill then the hack could be to commit the jsp pages into the work directory and it gets reflected.
Location for change
.\SpringServer\work\com.springsource.server.deployer\Module\Bundle-A.jar-0\Bundle-A.jar\MODULE-INF\jsp\data.jsp

Spring Dm(OSGi) integration with terracota

I have tried integrating terracotta with spring DM and it works fine. My use case included a instance a stand alone java,jetty web server,apache tomcat and Spring Dm connected to the same instance of terracotta sharing a custom class as the root.
The changes i had to make were
Added the Terracotta lib and shared classes under boot delegation path of Spring DM –
1. In springsource-dm-server-ee-1.0.1.RELEASE\lib\java6-server.profile org.osgi.framework.bootdelegation = \ com.tc.*,\--> àddedd this is to avoid errors from Spring DM which tries to load these classes from Bundle class loader share.* --> Classes which are shared
2 .Copied shared jar under springsource-dm-server-ee-1.0.1.RELEASE\lib\
The above changes are doen to ensure that teh shared classes are loaded by the boot classloader which will enable terracotta toidentify this class and share with other processes()stadalobe,jetty.tomcat).In teh above case since the shared jar is added intothe bootdelegation , any chage in the teracotta shared classes will need restart of the spring dm server.

The other staratergy to achive the same is by changing the classloader names in all the other processes which are connected to terracotta, but i found this more complicated and cumbersome.

Searching for a class in Multiple jars using shell script

#!/bin/sh

LOOK_FOR="funn/class/name"

for i in `find . -name "*jar"`
do
 echo "Searching in jar $i ..."
 jar tvf $i | grep $LOOK_FOR > /dev/null
 if [ $? == 0 ]
 then
   echo "==> Class Available in  \"$LOOK_FOR\" in $i"
 fi
done