Richard: In my case the resolver just fails without being able to resolve so it would probably not make a very good test scenario. Could you elaborate on how the uses constraint could be involved in the symptoms I am seeing? Thanks,
David -----Original Message----- From: Richard S. Hall [mailto:[email protected]] Sent: Wednesday, January 27, 2010 11:48 AM To: [email protected] Subject: Re: constraint violation problem On 1/27/10 10:36, Lawson, David wrote: > When running my application bundles under Felix 2.0.1 I am experiencing the > following constraint violation: > > DEBUG: Constraint violation for 34.0 detected; module can see > org.w3c.dom from [27.0] and org.w3c.dom from [0] > DEBUG: Constraint violation for 34.0 detected; module can see > org.w3c.dom from [27.0] and org.w3c.dom from [0] > > Looking at the import definition for bundle 34 (my application bundle) I can > see that it references: > > org.w3c.dom;version="3.0" > > The export definition from bundle 27 (Xerces 2.9.1): > > org.w3c.dom;version="3.0" > > The export definition from bundle 0 (Felix System Bundle) > > org.w3c.dom;version="0.0.0" > > In this scenario I would expect the resolver to select the package from the > Xerces bundle but from the constraint > violation this seems not to be the case. Is there a way to force the resolver > to use the Xerces package or to remove > the org.w3c.dom export from the System Bundle? Thanks, > The spec says the resolver should favor already resolved packages over unresolved packages (i.e., resolved packages have higher. However, in this case, if your bundle imports version 3, then it should not be looking at version 0 at all. I would guess that there is a uses constraint causing the issue and it is not related to choosing the wrong version. You can modify the org.osgi.framework.system.packages property to not include org.w3c.dom. It is a little bit of a pain, but if you look inside the felix.jar you will see a default.properties file. If you copy that file and put it into the conf/config.properties file, then you can modify the default values to exclude the offending package. Does your above scenario end up resolving or does it end up detecting constraint violations for a long time or just error and not resolve? If it does take a long time, I'd be interested in being able to re-create it, since I am working on a new resolver which is intended to address such issues and it would be nice to have another test scenario. -> richard > David > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
