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.
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.
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]
