Friday, June 27, 2008

OSGi and TCCL dilemma

OSGi in server side is still in its infant stage, though the technology is prominent in embedded and mobile devices space. Most of the time use will try to wrap the non-OSGi libraries to bundles including proper import, export etc OSGi headers. There are so many tools available for this conversion in web, and one of the most popular tool is maven-bundle-plugin that associate with Maven2.

In order to OSGi import/export paradigm to work, bundle must use the bundle classloader. But many of the wrapped non-OSGi bundles might have used system classloader or thread context class loader (TCCL). Problem arise when TCCL is used and which is not fully explained in current OSGi specification.

Luckily, Eclipse Equinox OSGi implementation has addressed this problem by setting a "ContextFinder" in systems bundles TCCL, which is capable of traversing the bundle classloader cache and obtaining the relevant resources and classes. But other OSGi implementations such as Knopflerfish uses, what they called "byte code injection". Apache Felix has not covered this dilemma yet.

So IMO, in order to OSGi to be dominant in server side, TCCL problem should be addressed and it should be addressed quite soon.

1 comment:

Shriniwas Joshi said...

Good point and I agree.

In felix you are forced to change the TCCL to bundle classloader. Most common way is by getting the classloader of activator class.

But I wonder why OSGi is not very clear about it? Why not provide ability to explicitly mention the preference in Manifest file?

But in the mean time, felix can enhance their config setup to provide this choice. By doing this, felix will move one step ahead of other implementation since it provides flexibility to users in a space left vacant by OSGi

Thanks for your blog entry