On 8/28/15 15:05 , Benson Margulies wrote:
On Fri, Aug 28, 2015 at 2:59 PM, Richard S. Hall <[email protected]> wrote:
On 8/28/15 14:36 , Benson Margulies wrote:
Consider three bundles, A, B, and C. A has imports from B and C. All
three import Guava.
A and B import with a constraint of [18, 19), C takes [15, 16).
The container obediently wires A and B to one bundle, and C to the other.
Now, no Guava objects flow _directly_ from C to A. However, A calls C
with some Json, and asks C to turn it onto Java objects, and passes a
class (X) from B as the target of the conversion. X has a field of
type ImmutableList.
The code in C looked at that field, and does not recognize it, because
it has a Class<ImmutableList> for Guava 15, while the Class object
seen reflectively is for 18.
If I understand the scenario correctly: C gives an object to A that has an
instance of something from Guava 15 inside of it somewhere.
Never actually happens, but close enough.
A gives C a Class object for X. C doesn't recognize C as a class it
knows what to do with, so it throws.
It simply sounds like the export from C is missing a "uses" constraint on
Guava. It doesn't matter how you expose classes, even if it deeply nested
(i.e., not only directly), if the classes are visible to others (barring
weird stuff like using reflection) then it has to be listed as a "uses"
constraint on your export. In that were the case in your scenario, the
bundles would not resolve.
To be concrete: The package is 'com.google.collect', and I think that
bundle B is pretty much beside the point.
It may be significant that A is a pax-exam test probe. So,
A has no imports, just a Dynamic-Import of *.
B has an import of com.google.collect;version="[18.0,19)"
C has an import of com.google.collect;version="[15.0,15.1)"
Is the dynamic import the root of the evil?
Very well could be.
-> richard
There is no easy way to diagnose such issues. When bundles have faulty
metadata, weird stuff can happen.
-> richard
This raises two questions: is there some diagnostic technique I'm
missing here that would have made this more evident? And, is there any
legitimate way to tell the OSGi container "I know that C works with 18
even if that fails the version constraint."
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
