You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by jspeton <je...@speton.com> on 2010/04/07 22:41:51 UTC
Fragment-Host's bundle-version not being honored in 2.0.4
According to this bug https://cwiki.apache.org/jira/browse/FELIX-1795
bundle-version support in Fragment-Host header should work as of 2.0.2, yet
it is not being honored for me.
Here is my situation:
1. Two bundle hosts, with the same symbolic name, but with different
versions 1.6.1 and 1.6.2.
2. Two bundle fragments, with the same symbolic name, and with the same
symbolic name fragment host from (1). The bundle-version of the two
fragments is 1.6.1 and 1.6.2 (they are kept in sync to avoid confusion).
In other words, I am expecting that version 1.6.1 of the host will resolve
the 1.6.1 fragment, and the 1.6.2 host will resolve the 1.6.2 fragment.
What I am finding is that the 1.6.2 fragment is resolving to both the 1.6.1
and 1.6.2 hosts. I know the 1.6.1 class loader is correct, as is the 1.6.2,
but using getResourceAsStream from either host always gets me the 1.6.2
version. Both bundle-version parameters are expressed as single versions,
e.g. bundle-version="1.6.2", although I have tried "[1.6.2,1.6.2]" as well
to no avail.
Am I doing something wrong or is this feature still bugged? Why is the
1.6.2 fragment in the classpath of the 1.6.1 classloader?
Many thanks!
Jean-Guy Speton
--
View this message in context: http://old.nabble.com/Fragment-Host%27s-bundle-version-not-being-honored-in-2.0.4-tp28170716p28170716.html
Sent from the Apache Felix - Dev mailing list archive at Nabble.com.
Re: Fragment-Host's bundle-version not being honored in 2.0.4
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 4/8/10 12:40, jspeton wrote:
> Hi Richard,
>
> There is no range, just the single version.
A single version is a range: from the specified version to infinity.
If you want a single version, you must specify: "[x.y.z,x.y.z]"
> More succinctly, this bundle:
>
> Bundle-SymbolicName: com.mypackage
> Bundle-Version: 1.6.1
>
> is resolving this fragment
>
> Bundle-SymbolicName: com.mypackage.frag
> Bundle-Version: 1.6.2
> Fragment-Host: com.mypackage; bundle-version="1.6.2"
>
> Your description is in line with how I would expect fragment bundle version
> specifiers to work, but it is not.
>
If this is true, then it would be a bug. Verify and, if so, please open
a JIRA issue to track this. Thanks.
-> richard
> Thanks!
> Jean-Guy
>
>
> Richard S. Hall wrote:
>
>> On 4/7/10 16:41, jspeton wrote:
>>
>>> According to this bug https://cwiki.apache.org/jira/browse/FELIX-1795
>>> bundle-version support in Fragment-Host header should work as of 2.0.2,
>>> yet
>>> it is not being honored for me.
>>>
>>> Here is my situation:
>>> 1. Two bundle hosts, with the same symbolic name, but with different
>>> versions 1.6.1 and 1.6.2.
>>> 2. Two bundle fragments, with the same symbolic name, and with the same
>>> symbolic name fragment host from (1). The bundle-version of the two
>>> fragments is 1.6.1 and 1.6.2 (they are kept in sync to avoid confusion).
>>>
>>> In other words, I am expecting that version 1.6.1 of the host will
>>> resolve
>>> the 1.6.1 fragment, and the 1.6.2 host will resolve the 1.6.2 fragment.
>>>
>>> What I am finding is that the 1.6.2 fragment is resolving to both the
>>> 1.6.1
>>> and 1.6.2 hosts. I know the 1.6.1 class loader is correct, as is the
>>> 1.6.2,
>>> but using getResourceAsStream from either host always gets me the 1.6.2
>>> version. Both bundle-version parameters are expressed as single
>>> versions,
>>> e.g. bundle-version="1.6.2", although I have tried "[1.6.2,1.6.2]" as
>>> well
>>> to no avail.
>>>
>>> Am I doing something wrong or is this feature still bugged? Why is the
>>> 1.6.2 fragment in the classpath of the 1.6.1 classloader?
>>>
>>>
>> What is the version range in your Fragment-Host header? If your
>> fragments match both hosts, then the resolver will try to attach the
>> highest version fragment to each host. This is correct. If you only want
>> your fragments to attach to a specific host version, then your
>> Fragment-Host header should only match that version.
>>
>> -> richard
>>
>>
>>> Many thanks!
>>> Jean-Guy Speton
>>>
>>>
>>>
>>
>>
>
Re: Fragment-Host's bundle-version not being honored in 2.0.4
Posted by jspeton <je...@speton.com>.
Hi Richard,
There is no range, just the single version. More succinctly, this bundle:
Bundle-SymbolicName: com.mypackage
Bundle-Version: 1.6.1
is resolving this fragment
Bundle-SymbolicName: com.mypackage.frag
Bundle-Version: 1.6.2
Fragment-Host: com.mypackage; bundle-version="1.6.2"
Your description is in line with how I would expect fragment bundle version
specifiers to work, but it is not.
Thanks!
Jean-Guy
Richard S. Hall wrote:
>
> On 4/7/10 16:41, jspeton wrote:
>> According to this bug https://cwiki.apache.org/jira/browse/FELIX-1795
>> bundle-version support in Fragment-Host header should work as of 2.0.2,
>> yet
>> it is not being honored for me.
>>
>> Here is my situation:
>> 1. Two bundle hosts, with the same symbolic name, but with different
>> versions 1.6.1 and 1.6.2.
>> 2. Two bundle fragments, with the same symbolic name, and with the same
>> symbolic name fragment host from (1). The bundle-version of the two
>> fragments is 1.6.1 and 1.6.2 (they are kept in sync to avoid confusion).
>>
>> In other words, I am expecting that version 1.6.1 of the host will
>> resolve
>> the 1.6.1 fragment, and the 1.6.2 host will resolve the 1.6.2 fragment.
>>
>> What I am finding is that the 1.6.2 fragment is resolving to both the
>> 1.6.1
>> and 1.6.2 hosts. I know the 1.6.1 class loader is correct, as is the
>> 1.6.2,
>> but using getResourceAsStream from either host always gets me the 1.6.2
>> version. Both bundle-version parameters are expressed as single
>> versions,
>> e.g. bundle-version="1.6.2", although I have tried "[1.6.2,1.6.2]" as
>> well
>> to no avail.
>>
>> Am I doing something wrong or is this feature still bugged? Why is the
>> 1.6.2 fragment in the classpath of the 1.6.1 classloader?
>>
>
> What is the version range in your Fragment-Host header? If your
> fragments match both hosts, then the resolver will try to attach the
> highest version fragment to each host. This is correct. If you only want
> your fragments to attach to a specific host version, then your
> Fragment-Host header should only match that version.
>
> -> richard
>
>> Many thanks!
>> Jean-Guy Speton
>>
>>
>
>
--
View this message in context: http://old.nabble.com/Fragment-Host%27s-bundle-version-not-being-honored-in-2.0.4-tp28170716p28181111.html
Sent from the Apache Felix - Dev mailing list archive at Nabble.com.
Re: Fragment-Host's bundle-version not being honored in 2.0.4
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 4/7/10 16:41, jspeton wrote:
> According to this bug https://cwiki.apache.org/jira/browse/FELIX-1795
> bundle-version support in Fragment-Host header should work as of 2.0.2, yet
> it is not being honored for me.
>
> Here is my situation:
> 1. Two bundle hosts, with the same symbolic name, but with different
> versions 1.6.1 and 1.6.2.
> 2. Two bundle fragments, with the same symbolic name, and with the same
> symbolic name fragment host from (1). The bundle-version of the two
> fragments is 1.6.1 and 1.6.2 (they are kept in sync to avoid confusion).
>
> In other words, I am expecting that version 1.6.1 of the host will resolve
> the 1.6.1 fragment, and the 1.6.2 host will resolve the 1.6.2 fragment.
>
> What I am finding is that the 1.6.2 fragment is resolving to both the 1.6.1
> and 1.6.2 hosts. I know the 1.6.1 class loader is correct, as is the 1.6.2,
> but using getResourceAsStream from either host always gets me the 1.6.2
> version. Both bundle-version parameters are expressed as single versions,
> e.g. bundle-version="1.6.2", although I have tried "[1.6.2,1.6.2]" as well
> to no avail.
>
> Am I doing something wrong or is this feature still bugged? Why is the
> 1.6.2 fragment in the classpath of the 1.6.1 classloader?
>
What is the version range in your Fragment-Host header? If your
fragments match both hosts, then the resolver will try to attach the
highest version fragment to each host. This is correct. If you only want
your fragments to attach to a specific host version, then your
Fragment-Host header should only match that version.
-> richard
> Many thanks!
> Jean-Guy Speton
>
>