You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by martin liste larsson <ma...@gmail.com> on 2009/11/30 16:20:10 UTC
Loading multiple versions of the same bundle
I have a situation where bundle A and B both depends on C, but on
different versions
(A on C version 1, B on C version 2). In the actual situation, none of
these are actual
bundles, but rather plain JAR-files. They will be supplied by a third
party, so I won't be
able to recompile A to upgrade to version 2 of C (it might not even be
possible).
After a lot of wasted time, I made it work by making both versions of
C explicitly
importing it's own version. IOW:
Export-Package: com.package.some;version="1.0.0"
Import-Package: com.package.some;version="[1.0.0,1.0.0]"
(and likewise for version 2.0.0:
Export-Package: com.package.some;version="2.0.0"
Import-Package: com.package.some;version="[2.0.0,2.0.0]"
).
Is this really necessary? Why won't A and B connect to the correct
C-version with
Import-Package: com.package.some;version="[1.0.0,2.0)"
for A, and
Import-Package: com.package.some;version="2.0.0"
for B?
The error I got was:
org.osgi.framework.BundleException: Unresolved constraint in bundle A
[35]: package; (&(package=com.package.some)(version>=1.0.0)(!(version>=2.0.0)))
when both versions of C was in the 'Active' state.
If anyone has any comments, I'd be grateful.
Thanks,
M.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Loading multiple versions of the same bundle
Posted by martin liste larsson <ma...@gmail.com>.
On Tue, Dec 1, 2009 at 4:35 PM, Richard S. Hall <he...@ungoverned.org> wrote:
> I should be more precise. Assuming the package name is foo, if C1 ends up
> getting wired to C2 for package foo, then C1's version of foo will no longer
> be available for anyone to use, including C1.
Thanks. That's a somewhat non-intuitive, but very logical (yes, that would seem
a paradox) bit of information. Thanks. :*)
M.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Loading multiple versions of the same bundle
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 12/1/09 10:20, Richard S. Hall wrote:
> On 12/1/09 4:29, martin liste larsson wrote:
>> On Mon, Nov 30, 2009 at 11:46 PM, Richard S.
>> Hall<he...@ungoverned.org> wrote:
>>> Yes, BND by default generates imports for exports, but you can
>>> easily tell
>>> it not to...check the docs.
>> Looking at it again, I see that C1 actually imports C2, which is what
>> you describe. But
>> it seems a bit strange to me that that should prevent A from importing
>> C1. If both C1 and
>> C2 are available, why can't A find C1?
>
> If C1 ends up getting wired to C2, then this means C1 is no longer
> available, thus A cannot resolve.
I should be more precise. Assuming the package name is foo, if C1 ends
up getting wired to C2 for package foo, then C1's version of foo will no
longer be available for anyone to use, including C1.
-> richard
>
> -> richard
>
>> Anyways, I'll fix the imports and be on my way. Thanks for the help. :*)
>>
>> M.
>>
>> ---------------------------------------------------------------------
>> 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: Loading multiple versions of the same bundle
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 12/1/09 4:29, martin liste larsson wrote:
> On Mon, Nov 30, 2009 at 11:46 PM, Richard S. Hall<he...@ungoverned.org> wrote:
>
>> Yes, BND by default generates imports for exports, but you can easily tell
>> it not to...check the docs.
>>
> Looking at it again, I see that C1 actually imports C2, which is what
> you describe. But
> it seems a bit strange to me that that should prevent A from importing
> C1. If both C1 and
> C2 are available, why can't A find C1?
>
If C1 ends up getting wired to C2, then this means C1 is no longer
available, thus A cannot resolve.
-> richard
> Anyways, I'll fix the imports and be on my way. Thanks for the help. :*)
>
> M.
>
> ---------------------------------------------------------------------
> 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: Loading multiple versions of the same bundle
Posted by martin liste larsson <ma...@gmail.com>.
On Mon, Nov 30, 2009 at 11:46 PM, Richard S. Hall <he...@ungoverned.org> wrote:
>
> Yes, BND by default generates imports for exports, but you can easily tell
> it not to...check the docs.
Looking at it again, I see that C1 actually imports C2, which is what
you describe. But
it seems a bit strange to me that that should prevent A from importing
C1. If both C1 and
C2 are available, why can't A find C1?
Anyways, I'll fix the imports and be on my way. Thanks for the help. :*)
M.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Loading multiple versions of the same bundle
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 11/30/09 17:03, martin liste larsson wrote:
> Thanks for the input. I think maybe the bnd-tool is adding that broad import.
> Maybe I shouldn't use bnd after all, or at least learn it before I use it... :*)
>
Yes, BND by default generates imports for exports, but you can easily
tell it not to...check the docs.
-> richard
> As I said earlier, neither of these are OSGi-bundles, just plain
> jar-files without sources.
> So I can pretty much define the versions and exports and imports
> myself. I'll have to
> decide what's logical for this case.
>
> M.
>
> On Mon, Nov 30, 2009 at 4:36 PM, Richard S. Hall<he...@ungoverned.org> wrote:
>
>> On 11/30/09 10:34, Richard S. Hall wrote:
>>
>>> On 11/30/09 10:20, martin liste larsson wrote:
>>>
>>>> I have a situation where bundle A and B both depends on C, but on
>>>> different versions
>>>> (A on C version 1, B on C version 2). In the actual situation, none of
>>>> these are actual
>>>> bundles, but rather plain JAR-files. They will be supplied by a third
>>>> party, so I won't be
>>>> able to recompile A to upgrade to version 2 of C (it might not even be
>>>> possible).
>>>>
>>>> After a lot of wasted time, I made it work by making both versions of
>>>> C explicitly
>>>> importing it's own version. IOW:
>>>> Export-Package: com.package.some;version="1.0.0"
>>>> Import-Package: com.package.some;version="[1.0.0,1.0.0]"
>>>> (and likewise for version 2.0.0:
>>>> Export-Package: com.package.some;version="2.0.0"
>>>> Import-Package: com.package.some;version="[2.0.0,2.0.0]"
>>>> ).
>>>>
>>>> Is this really necessary? Why won't A and B connect to the correct
>>>> C-version with
>>>> Import-Package: com.package.some;version="[1.0.0,2.0)"
>>>> for A, and
>>>> Import-Package: com.package.some;version="2.0.0"
>>>> for B?
>>>>
>>>> The error I got was:
>>>> org.osgi.framework.BundleException: Unresolved constraint in bundle A
>>>> [35]: package;
>>>> (&(package=com.package.some)(version>=1.0.0)(!(version>=2.0.0)))
>>>> when both versions of C was in the 'Active' state.
>>>>
>>>> If anyone has any comments, I'd be grateful.
>>>>
>>> I'd assume that your old version of C is importing its own package with
>>> too broad of a version range, which causes it to get wired to the new
>>> version instead of itself. If C is just a library bundle providing some
>>> packages at a specific version, then don't have it import its own packages,
>>> just have it export only then you should be fine.
>>>
>>>
>> p.s. If C does have service interfaces or something that you want to be
>> substitutable, then make sure you limit its import range to be [1.0.0,
>> 2.0.0)...there is little point in making it [1.0.0, 1.0.0] since this is
>> nearly the same as not importing at all, so you might as well do that if you
>> don't want substitutability.
>>
>>> -> richard
>>>
>>>
>>>> Thanks,
>>>> M.
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Loading multiple versions of the same bundle
Posted by martin liste larsson <ma...@gmail.com>.
Thanks for the input. I think maybe the bnd-tool is adding that broad import.
Maybe I shouldn't use bnd after all, or at least learn it before I use it... :*)
As I said earlier, neither of these are OSGi-bundles, just plain
jar-files without sources.
So I can pretty much define the versions and exports and imports
myself. I'll have to
decide what's logical for this case.
M.
On Mon, Nov 30, 2009 at 4:36 PM, Richard S. Hall <he...@ungoverned.org> wrote:
> On 11/30/09 10:34, Richard S. Hall wrote:
>>
>> On 11/30/09 10:20, martin liste larsson wrote:
>>>
>>> I have a situation where bundle A and B both depends on C, but on
>>> different versions
>>> (A on C version 1, B on C version 2). In the actual situation, none of
>>> these are actual
>>> bundles, but rather plain JAR-files. They will be supplied by a third
>>> party, so I won't be
>>> able to recompile A to upgrade to version 2 of C (it might not even be
>>> possible).
>>>
>>> After a lot of wasted time, I made it work by making both versions of
>>> C explicitly
>>> importing it's own version. IOW:
>>> Export-Package: com.package.some;version="1.0.0"
>>> Import-Package: com.package.some;version="[1.0.0,1.0.0]"
>>> (and likewise for version 2.0.0:
>>> Export-Package: com.package.some;version="2.0.0"
>>> Import-Package: com.package.some;version="[2.0.0,2.0.0]"
>>> ).
>>>
>>> Is this really necessary? Why won't A and B connect to the correct
>>> C-version with
>>> Import-Package: com.package.some;version="[1.0.0,2.0)"
>>> for A, and
>>> Import-Package: com.package.some;version="2.0.0"
>>> for B?
>>>
>>> The error I got was:
>>> org.osgi.framework.BundleException: Unresolved constraint in bundle A
>>> [35]: package;
>>> (&(package=com.package.some)(version>=1.0.0)(!(version>=2.0.0)))
>>> when both versions of C was in the 'Active' state.
>>>
>>> If anyone has any comments, I'd be grateful.
>>
>> I'd assume that your old version of C is importing its own package with
>> too broad of a version range, which causes it to get wired to the new
>> version instead of itself. If C is just a library bundle providing some
>> packages at a specific version, then don't have it import its own packages,
>> just have it export only then you should be fine.
>>
>
> p.s. If C does have service interfaces or something that you want to be
> substitutable, then make sure you limit its import range to be [1.0.0,
> 2.0.0)...there is little point in making it [1.0.0, 1.0.0] since this is
> nearly the same as not importing at all, so you might as well do that if you
> don't want substitutability.
>>
>> -> richard
>>
>>> Thanks,
>>> M.
>>>
>>> ---------------------------------------------------------------------
>>> 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: Loading multiple versions of the same bundle
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 11/30/09 10:34, Richard S. Hall wrote:
> On 11/30/09 10:20, martin liste larsson wrote:
>> I have a situation where bundle A and B both depends on C, but on
>> different versions
>> (A on C version 1, B on C version 2). In the actual situation, none of
>> these are actual
>> bundles, but rather plain JAR-files. They will be supplied by a third
>> party, so I won't be
>> able to recompile A to upgrade to version 2 of C (it might not even be
>> possible).
>>
>> After a lot of wasted time, I made it work by making both versions of
>> C explicitly
>> importing it's own version. IOW:
>> Export-Package: com.package.some;version="1.0.0"
>> Import-Package: com.package.some;version="[1.0.0,1.0.0]"
>> (and likewise for version 2.0.0:
>> Export-Package: com.package.some;version="2.0.0"
>> Import-Package: com.package.some;version="[2.0.0,2.0.0]"
>> ).
>>
>> Is this really necessary? Why won't A and B connect to the correct
>> C-version with
>> Import-Package: com.package.some;version="[1.0.0,2.0)"
>> for A, and
>> Import-Package: com.package.some;version="2.0.0"
>> for B?
>>
>> The error I got was:
>> org.osgi.framework.BundleException: Unresolved constraint in bundle A
>> [35]: package;
>> (&(package=com.package.some)(version>=1.0.0)(!(version>=2.0.0)))
>> when both versions of C was in the 'Active' state.
>>
>> If anyone has any comments, I'd be grateful.
>
> I'd assume that your old version of C is importing its own package
> with too broad of a version range, which causes it to get wired to the
> new version instead of itself. If C is just a library bundle providing
> some packages at a specific version, then don't have it import its own
> packages, just have it export only then you should be fine.
>
p.s. If C does have service interfaces or something that you want to be
substitutable, then make sure you limit its import range to be [1.0.0,
2.0.0)...there is little point in making it [1.0.0, 1.0.0] since this is
nearly the same as not importing at all, so you might as well do that if
you don't want substitutability.
> -> richard
>
>> Thanks,
>> M.
>>
>> ---------------------------------------------------------------------
>> 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: Loading multiple versions of the same bundle
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 11/30/09 10:20, martin liste larsson wrote:
> I have a situation where bundle A and B both depends on C, but on
> different versions
> (A on C version 1, B on C version 2). In the actual situation, none of
> these are actual
> bundles, but rather plain JAR-files. They will be supplied by a third
> party, so I won't be
> able to recompile A to upgrade to version 2 of C (it might not even be
> possible).
>
> After a lot of wasted time, I made it work by making both versions of
> C explicitly
> importing it's own version. IOW:
> Export-Package: com.package.some;version="1.0.0"
> Import-Package: com.package.some;version="[1.0.0,1.0.0]"
> (and likewise for version 2.0.0:
> Export-Package: com.package.some;version="2.0.0"
> Import-Package: com.package.some;version="[2.0.0,2.0.0]"
> ).
>
> Is this really necessary? Why won't A and B connect to the correct
> C-version with
> Import-Package: com.package.some;version="[1.0.0,2.0)"
> for A, and
> Import-Package: com.package.some;version="2.0.0"
> for B?
>
> The error I got was:
> org.osgi.framework.BundleException: Unresolved constraint in bundle A
> [35]: package; (&(package=com.package.some)(version>=1.0.0)(!(version>=2.0.0)))
> when both versions of C was in the 'Active' state.
>
> If anyone has any comments, I'd be grateful.
>
I'd assume that your old version of C is importing its own package with
too broad of a version range, which causes it to get wired to the new
version instead of itself. If C is just a library bundle providing some
packages at a specific version, then don't have it import its own
packages, just have it export only then you should be fine.
-> richard
> Thanks,
> M.
>
> ---------------------------------------------------------------------
> 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