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