Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Virgo » Completeness of scoped plans(Bundle gets pulled in scoped and unscoped)
Completeness of scoped plans [message #957502] Thu, 25 October 2012 09:17 Go to next message
Thorsten Schlathölter is currently offline Thorsten SchlathölterFriend
Messages: 312
Registered: February 2012
Location: Düsseldorf
Senior Member
Hi,
I would like to share my experience with scoped plans. I am new to virgo and I created a plan that used scoping more or less unintentionally. I stumbled accross the following problem:

The plan was incomplete. So some of the required bundles were not specified in the plan. But they were available in the usr repository. The situation was as follows:

Bundle A is in plan and references B
Bundle B is in plan
Bundle C is not in plan but it is refrenced by some bundles which are in the plan
Bundle C also refrences Bundle B

What happend on startup is that Bundle C was pulled in from the usr repository (non scoped). In succession Bundle B got pulled in twice. Once scoped by the plan and once as unscoped bundle from usr repository (I assume this happens via Bundle C). I am using some aop scoped spring beans and in the course of program execution I suddenly got a ClassCastException while casting the proxy target (name it BundleBClass) to a certain class from BundleB - BundleBClass. So I wasn't able to cast an instance of BundleBClass to BundleBClass. I checked that BundleBClass was really loaded twice by differend class loaders, scoped and unscoped. Therefore the ClassCastException. I removed Bundle B from the plan (leaving it even more uncomplete). Now Bundle B got only pulled in once - unscoped. This solved the problem and proved that this is a classloader issue.

Now I wonder if it is really a good idea to resolve the plan against the repository and pull in nonscoped bundles although a scoped version is already available. I am far away from being an expert but wouldn't it make sense to enforce that the plan is complete by resolving it only against bundles which are specified in the plan itself?

Regards,
Thorsten
Re: Completeness of scoped plans [message #963091 is a reply to message #957502] Mon, 29 October 2012 15:15 Go to previous messageGo to next message
Glyn Normington is currently offline Glyn NormingtonFriend
Messages: 1222
Registered: July 2009
Senior Member
This scenario should fail to deploy if all the package exports had the correct uses constraints included. You see there should be a uses constraint in bundle C upon bundle B and this will blow up when C is wired to a different instance of B to the bundles in the plan which reference C.

How are you creating bundle manifests? Tools like bundlor or bnd should calculate uses constraints correctly.
Re: Completeness of scoped plans [message #963475 is a reply to message #963091] Mon, 29 October 2012 21:13 Go to previous message
Thorsten Schlathölter is currently offline Thorsten SchlathölterFriend
Messages: 312
Registered: February 2012
Location: Düsseldorf
Senior Member
Thanks for the answer Glyn,
to be honest I am creating the bundles myself. I develop them using a target platform that contains gemini blueprint, gemini web and some other stuff pretty close to what is used in virgo. Reason for not using virgo tooling and other stuff in development is that I had a lot of problems in the past in using plain old eclipse bundles together with virgo (in development). So I have a setup that runs smoothly in my target platform and I wanted to deploy this now into a virgo server using a plan. I think I will have to have a look into the uses constraints stuff.

Regards,
Thorsten
Previous Topic:Hibernate SessionFactory as osgi:service
Next Topic:can virgo runs as single region(without kernel/user isolation) mode?
Goto Forum:
  


Current Time: Wed Apr 24 20:44:58 GMT 2024

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

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

Back to the top