In the mean time, I had tried to reproduce
it also and failed to in my environment. Keep us posted, if you do
find something that reproduces then it would help to open an Equinox bug
report for investigation.
Andreas Sewe <andreas.sewe@xxxxxxxxxxxxxx>
10/08/2014 08:18 AM
Question about uses constraints in a constellation involving fragments
> What you describe should not be allowed. The uses directive
> export of org.slf4j.impl from ch.qos.logback.slf4j should not allow
> bundle slf4j.api (id=927) from wiring to the logback version. Running
> the osgi> command 'bundle 927' should give you the packages that
> 927 is wired to. That should tell us if it really is wired to
> from logback which is being hosted by orbit slf4j bundle. Your
> sounds correct for the IncombatibleClassChangeError, but I don't
> understand how it is getting wired to the logback version of the impl
Unfortunately, I have not yet been able to reproduce this problem on my
machine, which is where the OSGi console outputs are from. I am just
trying to make sense of , which is an error report that has been sent
automatically by an anonymous user.
To be clear: I have *not* been able to observe the wiring I described in
my earlier mail on my machine but it is the only wiring I can think of
that explains why we received the IncombatibleClassChangeError error report.
Maybe there is another wiring that also has the same symptoms, but if
the uses constraints of the ch.qos.logback.slf4j fragment (5) from Orbit
are honored by Equinox then I have no idea what the wiring would look like.
Sorry if this sounds a bit vague, but in this situation a statement like
"what you describe should not be allowed" already helps a lot,
it just assures me that my understanding of uses constraints is correct
and I need to dig deeper.
Managing Director: Dr. Marcel Bruch
Handelsregister: Darmstadt HRB 91940
equinox-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit https://dev.eclipse.org/mailman/listinfo/equinox-dev