You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Benson Margulies <be...@basistech.com> on 2015/08/28 20:36:03 UTC
When good version constraints go bad
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.
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: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: When good version constraints go bad
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 8/28/15 15:05 , Benson Margulies wrote:
> On Fri, Aug 28, 2015 at 2:59 PM, Richard S. Hall <he...@ungoverned.org> 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: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: When good version constraints go bad
Posted by Benson Margulies <be...@basistech.com>.
On Fri, Aug 28, 2015 at 2:59 PM, Richard S. Hall <he...@ungoverned.org> 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: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: When good version constraints go bad
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org