On 3/16/11 6:01, Daniele Dellafiore wrote:
Hi.
Thanks for you extended explanation. I did not had the chance to work
with that till today.
And another similar problem occurr, I think is simpler than the old
one but I can't really understand what's going on. Status:
[ 33] [Active ] [ ] [ ] [ 60] Spring Core
(3.0.5.RELEASE)
[467] [Active ] [ ] [ ] [ 70] Pipelean Storage
(1.0.0.SNAPSHOT)
[468] [Installed ] [ ] [ ] [ 70] Lazin
Authentication (1.0.0.SNAPSHOT)
start 468
Error executing command:
Constraint violation for package 'org.springframework.util' when
resolving module 468.0 between existing import
33.0.org.springframework.util
BLAMED ON [[468.0] package;
(&(package=org.springframework.util)(version>=3.0.0)(!(version>=4.0.0)))]
and uses constraint 33.2.org.springframework.util
BLAMED ON [[468.0] package; (package=in.laz.storage.mongo), [467.0]
package;
(&(package=org.springframework.util)(version>=3.0.0)(!(version>=4.0.0)))]
what I can't understand is the difference between
33.2.org.springframework.util and 33.0.org.springframework.util.
33 is the spring-core bundle that exports the relevan
org.springframework.util package. But what's the difference between
33.0 and 33.2?
I don't understand that either. It looks as if it was a fragment
attached to the different bundles that was updated somehow. Seems odd.
What are the steps to reproduce?
-> richard
Thanks.
On Fri, Feb 11, 2011 at 10:47 PM, Richard S. Hall<[email protected]> wrote:
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]
---------------------------------------------------------------------
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]
