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]

Reply via email to