Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Gemini » Blueprint TCCL usage and OSGi
Blueprint TCCL usage and OSGi [message #761666] Tue, 06 December 2011 20:54 Go to next message
Frederic Esnault is currently offline Frederic EsnaultFriend
Messages: 10
Registered: October 2010
Junior Member
HI all,
I've just saw that SpringDM/gemini blueprint make use of TCCL to allow class visibility between bundles, even if no export/import package would allow this visibiliy. My question is why this choice was made? Isn't it completely against OSGi philosophy? Doesn't it break all OSGi implementation encapsulation?

I'm really baffled by this context-class-loader attribute of the service/refence tags. Can someone explain to me why this TCCL thing has been used?

Thx in advance Smile
Re: Blueprint TCCL usage and OSGi [message #761918 is a reply to message #761666] Wed, 07 December 2011 09:38 Go to previous messageGo to next message
Glyn Normington is currently offline Glyn NormingtonFriend
Messages: 1222
Registered: July 2009
Senior Member
Without TCCL support, bundles are not able to use the bundle form of common 3rd party libraries such as hibernate which rely on the TCCL for loading application types.
Re: Blueprint TCCL usage and OSGi [message #762016 is a reply to message #761918] Wed, 07 December 2011 12:42 Go to previous messageGo to next message
Frederic Esnault is currently offline Frederic EsnaultFriend
Messages: 10
Registered: October 2010
Junior Member
Thanks for your answer.
I'm aware of the nasty classloading problem when using hibernate with OSGi.
But modifying the TCCL just to allow Hibernate to perform its classloading still goes against OSGi encapsulation goal.
There are ways to get around this problem, like requiring bundles, dynamic import packages (both are bad, but allowed by OSGi, even if they also create problems), or even inverse the process, by letting the entities provider bundle call itself the session factory (using a proxified session factory, as we can see in an example on the net) to reload its configuration with new entities.

Anyway, i'm surprised that Eclipse Gemini Blueprint uses such an 'ugly' (sorry) turnaround to fix this kind of classloading problem.

Is the hibernate concern the only reason of the TCCL usage? Because allowing bundle referencing services from another bundle see all the classes of the service-providing bundle is just ugly.

Peter Kriens himself flamed the solutions based on dynamic imports, buddy system, or required bundles (even if the latter is the solution he chose to use hibernate in an OSGi app).

Any comments on this point? Is this TCCL trick part of the blueprint specification (didn't read it yet) ?

Thx for comments and answers Smile
Re: Blueprint TCCL usage and OSGi [message #762024 is a reply to message #762016] Wed, 07 December 2011 12:55 Go to previous messageGo to next message
Frederic Esnault is currently offline Frederic EsnaultFriend
Messages: 10
Registered: October 2010
Junior Member
Just checked to answer my own question, the context-class-loader attribute is not in the blueprint specification XSD.
<xsd:complexType name="Tservice">
    <xsd:complexContent>
        <xsd:extension base="Tcomponent">
            <xsd:sequence>
                <xsd:group ref="GserviceElements"/>
            </xsd:sequence>
            <xsd:attribute name="interface" type="Tclass"/>
            <xsd:attribute name="ref" type="Tidref"/>
            <xsd:attribute name="auto-export" type="TautoExportModes" default="disabled"/>
            <xsd:attribute name="ranking" type="xsd:int" default="0"/>
            <xsd:anyAttribute namespace="##other" processContents="strict"/>
        </xsd:extension>
    </xsd:complexContent>
</xsd:complexType>


Sorry if I seem quite strict on this point, but in my opinion it really breaks OSGi encapsulation concept.
Re: Blueprint TCCL usage and OSGi [message #762105 is a reply to message #762024] Wed, 07 December 2011 14:58 Go to previous messageGo to next message
Costin Leau is currently offline Costin LeauFriend
Messages: 45
Registered: February 2010
Member
Then don't use it - you can enable or disable it, it's a configurable setting.
In an ideal world, there would be no need for TCCL fixes however we're not in one. When writing new code you can make or not use of it however when you're integrating existing libraries or "foreign code" you are restricted. As Glyn pointed out, the TCCL option was added since a big number of libraries rely on it and use it to load their classes - w/o such a setting you're in a world of hurt and have to "patch" the service yourself.
That's why the TCCL setting has been added (as explained in the docs) - if you don't want to use it then simply ignore it or turn it off.
Re: Blueprint TCCL usage and OSGi [message #762182 is a reply to message #762105] Wed, 07 December 2011 16:57 Go to previous messageGo to next message
Frederic Esnault is currently offline Frederic EsnaultFriend
Messages: 10
Registered: October 2010
Junior Member
Hi Costin (so excited to get an answer from you Very Happy - great work on spring-OSGi btw ! )
I think i'll try not using it, even if it seems so tempting to use it and solve this hibernate classloading issue.
May be making my model extension bundles fragments targeting my hibernate bundle, so that their class spaces are merged, and refreshing the SessionFactory on install/uninstall of the fragment bundle.

Re: Blueprint TCCL usage and OSGi [message #763175 is a reply to message #762182] Fri, 09 December 2011 09:45 Go to previous messageGo to next message
Frederic Esnault is currently offline Frederic EsnaultFriend
Messages: 10
Registered: October 2010
Junior Member
After giving it a second thought, i think the TCCL approach, even if i still think it's against OSGi rules - but you must be aware of that also - ), is a better solution to the classloading issue than Require-Bundle or DynamicImport-Package.
The required bundle method is bad because it ties the bundle to one specific bundle, instead of just asking for a package, whoever provides it. And of course it imports all the bundle packages, which is too much.
And it prevents the bundle from starting if the specified bundle is not present, even if anothr bundle could provide the needed package.
The Dynamic import package is bad also, because it looses all tracking of bundle dependencies, prevents the on-start checking of dependencies and may lead to runtime errors we just can't predict, and more...
But the TCCL approach is better in the way that it is done on a bundle providing a package/service explicitly required in the spring osgi context, and because it's a one shot (TCCL is adjusted at service call and put back normal after).
Of course any loaded class stays in the classspace, but it's the goal (mainly for hibernate problem described before). In my (new) opinion, it's an extension of the OSGi class loading system, allowing to avoid some nasty issues due to third party libs (as Costin and Glyn stated).

As I said before, i still think it's wrong (in a pure OSGi point of view), but i also think it's a better approach than the dynamic imports/required bundle possibilities offered by OSGi, which are offered only because you cannot always use pure import/export schema (As Peter Kriens said, hey are here because sometime they are the last (but sad) solution).

I'd like to have some more input from people about this specific point. And if my view is correct (ie. it's better thatn dynamic imports/required bundle, why not including this possibility in the OSGi spec, or in Blueprint spec)?
Costin, did you have some discussion with people from the OSGi alliance about this ? If yes, what was the outcome of this talk ?
Re: Blueprint TCCL usage and OSGi [message #792255 is a reply to message #763175] Mon, 06 February 2012 20:03 Go to previous message
Costin Leau is currently offline Costin LeauFriend
Messages: 45
Registered: February 2010
Member
Hi. I don't recall the status of the discussion or whether it took place - I believe there was a suggestion to make an RFP for this but I'm not sure what that actually led to.
Previous Topic:Gemini blueprint: Spring NamespaceHandler management
Next Topic:Problems using cm-properties in Gemini blueprint
Goto Forum:
  


Current Time: Tue Mar 19 04:25:29 GMT 2024

Powered by FUDForum. Page generated in 0.02268 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top