Wednesday, July 9, 2008

Partial solution to TCCL problem in OSGi

One of perennial problem that OSGi uses asked from mailing lists is to resolved the problem of TCCL. As I have mentioned in the blog post "OSGi and TCCL dilemma", there is no proper definition is available in OSGi R4.1 specification for TCCL.

On the other hand Eclipse Equinox OSGi implementation has taken steps to prevent this problem with the invent of ContextFinder (CF). When the framework starts, Equinox sets the framework TCCL to CF. Hence, all the bundles spawn from this framework will set its TCCL to CF. CF finds classes and resources from the classloader associate with the current method of the execution stack. (java.lang.SecurityManager#getClassContext). This is not the complete answer to the problem, but it will solve most of the common scenarios. Thus, it's very easy to use this concept and apply to other OSGi implementations as well, such as Apache Felix.

WSO2 is align with producing products that are OSGi enabled. The underline infrastructure of these products uses a product called "Carbon", which is an OSGi wrapper powered with either Eclipse Equinox or Apache Felix and provide a
Web Services infrastructure powered by Apache Axis2. Carbon uses the "servletbridge" design principle to bridge OSGi and Servlet container. Hence, Carbon is one such infrastructure that harness the benefits of server-side OSGi. Though Carbon defaults to Equinox and Felix OSGi implementations, it has give a very powerful API to integrate other OSGi implementations as well.

You will be able to find the source code from "svn co".

Nice thing about Carbon is that it can switch between Equinox or Felix based on users preference. It can switched to any other OSGi implementations that is registered with too. Carbon uses the prior mentioned ContextFinder principle to solve the TCCL problem and I think it's a very fair assumption until OSGi specification mandate on the TCCL.

One of the very first product that is scheduled to be released on this month on top of the prior mentioned infrastructure is "Data Services Solution", which is a complete solution for data services via web services.


Mirko said...

Well, I am with you, saying that TCCL are a problem in the context of OSGi. However, I don't think it is an issue of the OSGi spec. The spec tries to define a component model and in its nature, it doesn't know anything about the context, each bundle is used. The approach Carbon and actually more Equinox is promoting is a good solution for adopting OSGi as a first step, but I think it is more important to rethink the design of the libraries to get rid of the need for TCCLs or at least have a mechanism to set them in a meaningful way. Neither the component, nor the container should know about it. Only the application, but that's just my opinion of course ;-)

Saminda Abeyruwan said...

You are right. OSGi spec doesn't mandate on TCCL and it's a grey area. When we try to convert the existing jars as bundles to be used in an OSGi environment, we face the problem of not being able to change the code to obtain classes and resources from that classes classloader. Most probably this is due to licences and it's quite error prone to change an production code. So IMHO in order to OSGi to be dominant in server side, it first needs to interoperate with existing stuff. So having notion of a context to a bundle will be handy in a long term scenario.

Rajesh Girish said...

Hi, I'm facing few problems when i followed the OSGI pdf documents for check out the source codes and build using maven,when i build " i'm getting few errors

"The bundle could not be resolved. Reason: Missing Constraint: Import-Package: org.apache.axiom.attachments; version="0.0.0"

how to resolve this.. please inform me ASAP .Advanced thanks for any help.

Ice said...

Hey, really nice post! Wish u a nice day!
best and newest cheap shoes online at a fraction of the cost.

Nargis Satti said...

Cool article, that is interesting that columns have been around us in every day life and we put them in our designs thinking we are creative.