|
|
Re: Blueprint TCCL usage and OSGi [message #762016 is a reply to message #761918] |
Wed, 07 December 2011 12:42 |
Frederic Esnault 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
|
|
|
|
|
|
Re: Blueprint TCCL usage and OSGi [message #763175 is a reply to message #762182] |
Fri, 09 December 2011 09:45 |
Frederic Esnault 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 ?
|
|
|
|
Powered by
FUDForum. Page generated in 0.04997 seconds