On 2/11/11 11:49, [email protected] wrote:
On Fri, Feb 11, 2011 at 3:36 PM, Richard S. Hall<[email protected]> wrote:
On 2/11/11 4:33, [email protected] wrote:
On Thu, Feb 10, 2011 at 3:55 PM, Richard S. Hall<[email protected]>
wrote:
On 2/10/11 6:56, [email protected] wrote:
Hi.
I've deployed a couple of Restlet 2.x bundles, one being
restlet.xstream extension.
To activate restlet.xstream I've added xstream 1.3.1 via:
obr:deploy com.springsource.com.thoughtworks.xstream
That installed a lot of required and optional extensions.
Now, the existing activemq-core bundels stop working due to:
Error executing command: Constraint violation for package
'javax.xml.stream' when resolving module 154.0 between existing import
0.javax.xml.stream BLAMED ON [[154.0] package;
(package=javax.xml.stream)] and uses constraint 200.0.javax.xml.stream
BLAMED ON [[154.0] package; (package=com.thoughtworks.xstream.io.xml),
[196.0] package;
(&(package=javax.xml.stream)(version>=1.0.1)(!(version>=2.0.0)))]
being
154 activemq-core
200 Java XML Stream API (StAX) (1.0.1)
196 Thoughtworks XStream (1.3.1)
What this is telling you is that 154 imports javax.xml.stream and the
candidate chosen for that is the system bundle, but 154 is also exposed
to
javax.xml.stream from bundle 200 from 154's import of
com.thoughtworks.xstream.io.xml which it satisfied by 196 and uses its
import of javax.xml.stream which is satisfied by 200.
The confusing part to me, though, is that this doesn't seem like it
should
be the final error, rather this seems like an intermediate error. Because
154's import of javax.xml.stream should also be satisfiable by 200 since
154's import doesn't include a version range. So, the resolver should
attempt this combination too, which given this limited information should
succeed.
If you can give me a simple way to reproduce this situation, I can check
it
out; e.g., you could provide me a link to download your bundle cache and
give me the steps to cause the error.
on Karaf 2.1.2
features:install obr
features:install activemq-spring
A step must be missing, because the above command fails to execute, it says
there is no such feature.
here it is, sorry:
features:addUrl mvn:org.apache.activemq/activemq-karaf/5.4.0/xml/features
That did the trick. So, this is what I see with debug logging enabled
for the Felix framework (and ignoring some duplicate exception messages):
DEBUG: Conflict between imports
(org.apache.felix.framework.resolver.ResolveException: Constraint
violation for package 'javax.xml.stream' when resolving module 57.0
between existing import 78.0.javax.xml.stream BLAMED ON [[57.0] package;
(package=javax.xml.stream)] and uses constraint 0.javax.xml.stream
BLAMED ON [[57.0] package; (package=org.apache.xbean.spring.context.v2),
[65.0] package;
(&(package=org.springframework.util.xml)(version>=2.5.0)), [36.0]
package; (&(package=javax.xml.stream)(version>=0.0.0))])
DEBUG: Conflict between imports
(org.apache.felix.framework.resolver.ResolveException: Constraint
violation for package 'javax.xml.stream' when resolving module 57.0
between existing import 0.javax.xml.stream BLAMED ON [[57.0] package;
(package=javax.xml.stream)] and uses constraint 78.0.javax.xml.stream
BLAMED ON [[57.0] package; (package=com.thoughtworks.xstream.io.xml),
[73.0] package;
(&(package=javax.xml.stream)(version>=1.0.1)(!(version>=2.0.0)))])
Error executing command: Constraint violation for package
'javax.xml.stream' when resolving module 57.0 between existing import
0.javax.xml.stream BLAMED ON [[57.0] package;
(package=javax.xml.stream)] and uses constraint 78.0.javax.xml.stream
BLAMED ON [[57.0] package; (package=com.thoughtworks.xstream.io.xml),
[73.0] package;
(&(package=javax.xml.stream)(version>=1.0.1)(!(version>=2.0.0)))]
As you can see, the final ERROR is just the exception from the last
resolve attempt, but there are other resolve attempts that failed too.
By setting the framework log level to DEBUG, you can see these other
failures.
So, module 57 is:
000057 INS org.apache.activemq.activemq-core-5.4.0
You can see in the above output that 57 has an import for
javax.xml.stream and has two candidates to resolve it: module 78 and
module 0. In the first DEBUG above it tries to use 78 to satisfy the
requirement, but this fails because module 36 is already resolved and
wired to javax.xml.stream from bundle 0:
000036 ACT org.springframework.core-3.0.4.RELEASE
Thus it tries again to resolve 57, but using module 0 as the provider of
javax.xml.stream. This case fails because module 73 exposes
javax.xml.stream and 73 can only be satisfied by provider 78.
Module 36 requires this: (&(package=javax.xml.stream)(version>=0.0.0))
<== This matches 0 and 78.
Module 73 requires this:
(&(package=javax.xml.stream)(version>=1.0.1)(!(version>=2.0.0))) <==
This matches only 78.
This is the root of the issue and the fact that the bundles are
incrementally resolved makes it so the early decision of 0 for 36 makes
it impossible to resolve 73.
The reason 0 is chosen for 36 is because when Karaf starts up, 36 ends
up being resolved before 78, which means that 36 takes the highest
priority matching provider at that point in time, which will be 0 since
the system bundle is already resolved giving it higher priority.
Once Karaf is done starting up, 78 ends also being resolved which raises
its priority. So after this, I am able to refresh 36 and have the
framework re-wire it to the highest version of javax.xml.stream from 78,
then I was able to start 57 without issue. Unforunately, I don't have a
general solution to this issue. Since the Felix framework resolver is
incremental, it is not possible to prevent this sort of situation
completely.
If bundle 36's version range requirement is correct (version>=0.0.0)
then there is no easy fix, but if it should actually be like 78's
(1.0.1<=version<2.0.0), then if it is edited it will work because it
will not select 0. The other approach is to configure the framework to
not export javax.xml.stream from the system bundle.
-> richard
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
