Fragment support 1.0.4 to 1.2 doesn't Import classes

["Daniel Rubio (OSGI Mailing List)" <os...@webforefront.com>]

I just upgraded to Felix 1.2+ from 1.0.4, only to realize some of my 
(library) bundles are fragments.

I'm getting a warning that in 1.2 there is partial support for 
fragments, which I of course appreciate. However, the application now 
ceases to work since it apparently doesn't import any classes in the 
fragment....
 Is there some way to get things to work as in 1.0.4 and get the warning ?
 I realize full support for fragments may be well down the road, but is 
there any plan for a release like 1.0.4 (import class from the fragment 
) and getting a warning ?

Thanks for any information on the subject.
Daniel Rubio
P.S- I realize the simple answer is keep using 1.0.4, but the reason for 
my question is because I'm in the process of writing a book (for Apress 
on Spring-OSGi) which is using Apache Felix, and some things are already 
based on the v.1.0.4 and the upgrade to the newer v.1.2 breaks a few of 
the apps.

Re: Fragment support 1.0.4 to 1.2 doesn't Import classes

[Felix Meschberger <fm...@gmail.com>]

Hi,

Richard S. Hall schrieb:
> Just to be clear, you are saying we should check to see if it is an
> extension bundle and allow that case, right?

Yes. Currently the ManifestParser constructor calls the
checkAndNormalizeR4() method, which in turn has the following code to
check Extension Bundles:

        if (parseExtensionBundleHeader((String)
            m_headerMap.get(Constants.FRAGMENT_HOST)) != null)
        {
            checkExtensionBundle();
        }

The ManifestParser constructor,  earlier on, calls the validateFragment
method to throw or log a warning. I think validateFragment method should
be enhanced to also call the parseExtensionBundleHeader method with the
Fragement-Host header and not do anything in case the bundle is an
Extension bundle; something like:

        if (fragmentHost != null
            && parseExtensionBundleHeader(fragmentHost) == null)

instead of just checking for the header existence.

Regards
Felix

> 
> -> richard
> 
> Felix Meschberger wrote:
>> Hi,
>>
>> Richard S. Hall schrieb:
>>  
>>> Daniel,
>>>
>>> I just applied a patch to trunk that makes the fragment install
>>> exception configurable. For details:
>>>
>>>    https://issues.apache.org/jira/browse/FELIX-725
>>>     
>>
>> In fact IMHO the Fragment-Host checks are to generous. Because they also
>> include Framework Extension bundles which used to be supported for a
>> while and cease to work now.
>>
>> I think the check should be modified to not do the Fragment-Host
>> verificiation stuff in case of Framework Extension bundles (as per 3.15,
>> Extension Bundles, of the core spec; identified with the extension
>> directive).
>>
>> Regards
>> Felix
>>
>>  
>>> I have deployed a new maven snapshot or you can build from trunk if you
>>> want to use it.
>>>
>>> -> richard
>>>
>>> Daniel Rubio wrote:
>>>    
>>>> I hadn't actually tried to upgrade until now, and since some of the
>>>> bundles I was using were libraries (apache tomcat, jasper
>>>> compiler,etc) I didn't realize they were fragments until I got this
>>>> message testing on 1.2!
>>>>
>>>> I believe ignoring fragments in 1.0.4 - or the Fragment-Host directive
>>>> - simply processed the Import-Package statement and made the fragments
>>>> classes available as if they were a normal bundle, so that's why it
>>>> worked....
>>>>  Inclusively I removed the Fragment-Host from the bundle and the app
>>>> works in 1.2, so I'm also realizing what is packaged as a fragment
>>>> didn't actually require being a full-fledged fragment, go figure, but
>>>> that's for the one's OSGi'fying bundles...
>>>>
>>>>   I guess we will leave 1.0.4 in place. If a new release comes out
>>>> before the last draft revision, that warns about fragments but still
>>>> loads classes 'as if it were a normal bundle' then I will use that ;)
>>>> otherwise I will just put a note.
>>>>
>>>>   Don't know what the consequence/side effects may be, in my app there
>>>> didn't seem to be trouble converting a fragment to a bundle just to
>>>> Import its classes an run the app successfully in 1.2...though there
>>>> might be trouble in some 'well-designed fragments' that do require not
>>>> just importing classes but the whole functionality required by the
>>>> fragment spec (but I guess that's where the warning comes in :-)  ).
>>>>
>>>>
>>>>
>>>> Richard S. Hall wrote:
>>>>      
>>>>> Argh!
>>>>>
>>>>> Yes, we probably should have made that configurable. Where were you
>>>>> when I was asking about throwing an exception on fragment install? ;-)
>>>>>
>>>>> I guess the short answer is "no, there is no way to change it". You
>>>>> have two options at this point:
>>>>>
>>>>>   1. Roll your own release that disables the exception (pretty easy to
>>>>>      do, I guess I might actually be able to make this configurable in
>>>>>      trunk and create a new snapshot that will eventually become 1.2.2
>>>>>      and you could use that for the time being).
>>>>>   2. Keep using 1.0.4 until we do another release that makes this
>>>>>      configurable.
>>>>>
>>>>> I don't see any reason why we couldn't make this configurable,
>>>>> perhaps someone sees something that I don't. The fact that your apps
>>>>> worked at all before I guess was just luck, since we ignored
>>>>> fragments altogether in 1.0.4.
>>>>>
>>>>> -> richard
>>>>>
>>>>> Daniel Rubio (OSGI Mailing List) wrote:
>>>>>        
>>>>>> I just upgraded to Felix 1.2+ from 1.0.4, only to realize some of my
>>>>>> (library) bundles are fragments.
>>>>>>
>>>>>> I'm getting a warning that in 1.2 there is partial support for
>>>>>> fragments, which I of course appreciate. However, the application
>>>>>> now ceases to work since it apparently doesn't import any classes in
>>>>>> the fragment....
>>>>>> Is there some way to get things to work as in 1.0.4 and get the
>>>>>> warning ?
>>>>>> I realize full support for fragments may be well down the road, but
>>>>>> is there any plan for a release like 1.0.4 (import class from the
>>>>>> fragment ) and getting a warning ?
>>>>>>
>>>>>> Thanks for any information on the subject.
>>>>>> Daniel Rubio
>>>>>> P.S- I realize the simple answer is keep using 1.0.4, but the reason
>>>>>> for my question is because I'm in the process of writing a book (for
>>>>>> Apress on Spring-OSGi) which is using Apache Felix, and some things
>>>>>> are already based on the v.1.0.4 and the upgrade to the newer v.1.2
>>>>>> breaks a few of the apps.
>>>>>>
>>>>>>           
>>>>>         
> 

Re: Fragment support 1.0.4 to 1.2 doesn't Import classes

["Richard S. Hall" <he...@ungoverned.org>]

Just to be clear, you are saying we should check to see if it is an 
extension bundle and allow that case, right?

-> richard

Felix Meschberger wrote:
> Hi,
>
> Richard S. Hall schrieb:
>   
>> Daniel,
>>
>> I just applied a patch to trunk that makes the fragment install
>> exception configurable. For details:
>>
>>    https://issues.apache.org/jira/browse/FELIX-725
>>     
>
> In fact IMHO the Fragment-Host checks are to generous. Because they also
> include Framework Extension bundles which used to be supported for a
> while and cease to work now.
>
> I think the check should be modified to not do the Fragment-Host
> verificiation stuff in case of Framework Extension bundles (as per 3.15,
> Extension Bundles, of the core spec; identified with the extension
> directive).
>
> Regards
> Felix
>
>   
>> I have deployed a new maven snapshot or you can build from trunk if you
>> want to use it.
>>
>> -> richard
>>
>> Daniel Rubio wrote:
>>     
>>> I hadn't actually tried to upgrade until now, and since some of the
>>> bundles I was using were libraries (apache tomcat, jasper
>>> compiler,etc) I didn't realize they were fragments until I got this
>>> message testing on 1.2!
>>>
>>> I believe ignoring fragments in 1.0.4 - or the Fragment-Host directive
>>> - simply processed the Import-Package statement and made the fragments
>>> classes available as if they were a normal bundle, so that's why it
>>> worked....
>>>  Inclusively I removed the Fragment-Host from the bundle and the app
>>> works in 1.2, so I'm also realizing what is packaged as a fragment
>>> didn't actually require being a full-fledged fragment, go figure, but
>>> that's for the one's OSGi'fying bundles...
>>>
>>>   I guess we will leave 1.0.4 in place. If a new release comes out
>>> before the last draft revision, that warns about fragments but still
>>> loads classes 'as if it were a normal bundle' then I will use that ;)
>>> otherwise I will just put a note.
>>>
>>>   Don't know what the consequence/side effects may be, in my app there
>>> didn't seem to be trouble converting a fragment to a bundle just to
>>> Import its classes an run the app successfully in 1.2...though there
>>> might be trouble in some 'well-designed fragments' that do require not
>>> just importing classes but the whole functionality required by the
>>> fragment spec (but I guess that's where the warning comes in :-)  ).
>>>
>>>
>>>
>>> Richard S. Hall wrote:
>>>       
>>>> Argh!
>>>>
>>>> Yes, we probably should have made that configurable. Where were you
>>>> when I was asking about throwing an exception on fragment install? ;-)
>>>>
>>>> I guess the short answer is "no, there is no way to change it". You
>>>> have two options at this point:
>>>>
>>>>   1. Roll your own release that disables the exception (pretty easy to
>>>>      do, I guess I might actually be able to make this configurable in
>>>>      trunk and create a new snapshot that will eventually become 1.2.2
>>>>      and you could use that for the time being).
>>>>   2. Keep using 1.0.4 until we do another release that makes this
>>>>      configurable.
>>>>
>>>> I don't see any reason why we couldn't make this configurable,
>>>> perhaps someone sees something that I don't. The fact that your apps
>>>> worked at all before I guess was just luck, since we ignored
>>>> fragments altogether in 1.0.4.
>>>>
>>>> -> richard
>>>>
>>>> Daniel Rubio (OSGI Mailing List) wrote:
>>>>         
>>>>> I just upgraded to Felix 1.2+ from 1.0.4, only to realize some of my
>>>>> (library) bundles are fragments.
>>>>>
>>>>> I'm getting a warning that in 1.2 there is partial support for
>>>>> fragments, which I of course appreciate. However, the application
>>>>> now ceases to work since it apparently doesn't import any classes in
>>>>> the fragment....
>>>>> Is there some way to get things to work as in 1.0.4 and get the
>>>>> warning ?
>>>>> I realize full support for fragments may be well down the road, but
>>>>> is there any plan for a release like 1.0.4 (import class from the
>>>>> fragment ) and getting a warning ?
>>>>>
>>>>> Thanks for any information on the subject.
>>>>> Daniel Rubio
>>>>> P.S- I realize the simple answer is keep using 1.0.4, but the reason
>>>>> for my question is because I'm in the process of writing a book (for
>>>>> Apress on Spring-OSGi) which is using Apache Felix, and some things
>>>>> are already based on the v.1.0.4 and the upgrade to the newer v.1.2
>>>>> breaks a few of the apps.
>>>>>
>>>>>           
>>>>         

Re: Fragment support 1.0.4 to 1.2 doesn't Import classes

[Felix Meschberger <fm...@gmail.com>]

Hi,

Richard S. Hall schrieb:
> Daniel,
> 
> I just applied a patch to trunk that makes the fragment install
> exception configurable. For details:
> 
>    https://issues.apache.org/jira/browse/FELIX-725

In fact IMHO the Fragment-Host checks are to generous. Because they also
include Framework Extension bundles which used to be supported for a
while and cease to work now.

I think the check should be modified to not do the Fragment-Host
verificiation stuff in case of Framework Extension bundles (as per 3.15,
Extension Bundles, of the core spec; identified with the extension
directive).

Regards
Felix

> 
> I have deployed a new maven snapshot or you can build from trunk if you
> want to use it.
> 
> -> richard
> 
> Daniel Rubio wrote:
>>
>> I hadn't actually tried to upgrade until now, and since some of the
>> bundles I was using were libraries (apache tomcat, jasper
>> compiler,etc) I didn't realize they were fragments until I got this
>> message testing on 1.2!
>>
>> I believe ignoring fragments in 1.0.4 - or the Fragment-Host directive
>> - simply processed the Import-Package statement and made the fragments
>> classes available as if they were a normal bundle, so that's why it
>> worked....
>>  Inclusively I removed the Fragment-Host from the bundle and the app
>> works in 1.2, so I'm also realizing what is packaged as a fragment
>> didn't actually require being a full-fledged fragment, go figure, but
>> that's for the one's OSGi'fying bundles...
>>
>>   I guess we will leave 1.0.4 in place. If a new release comes out
>> before the last draft revision, that warns about fragments but still
>> loads classes 'as if it were a normal bundle' then I will use that ;)
>> otherwise I will just put a note.
>>
>>   Don't know what the consequence/side effects may be, in my app there
>> didn't seem to be trouble converting a fragment to a bundle just to
>> Import its classes an run the app successfully in 1.2...though there
>> might be trouble in some 'well-designed fragments' that do require not
>> just importing classes but the whole functionality required by the
>> fragment spec (but I guess that's where the warning comes in :-)  ).
>>
>>
>>
>> Richard S. Hall wrote:
>>> Argh!
>>>
>>> Yes, we probably should have made that configurable. Where were you
>>> when I was asking about throwing an exception on fragment install? ;-)
>>>
>>> I guess the short answer is "no, there is no way to change it". You
>>> have two options at this point:
>>>
>>>   1. Roll your own release that disables the exception (pretty easy to
>>>      do, I guess I might actually be able to make this configurable in
>>>      trunk and create a new snapshot that will eventually become 1.2.2
>>>      and you could use that for the time being).
>>>   2. Keep using 1.0.4 until we do another release that makes this
>>>      configurable.
>>>
>>> I don't see any reason why we couldn't make this configurable,
>>> perhaps someone sees something that I don't. The fact that your apps
>>> worked at all before I guess was just luck, since we ignored
>>> fragments altogether in 1.0.4.
>>>
>>> -> richard
>>>
>>> Daniel Rubio (OSGI Mailing List) wrote:
>>>> I just upgraded to Felix 1.2+ from 1.0.4, only to realize some of my
>>>> (library) bundles are fragments.
>>>>
>>>> I'm getting a warning that in 1.2 there is partial support for
>>>> fragments, which I of course appreciate. However, the application
>>>> now ceases to work since it apparently doesn't import any classes in
>>>> the fragment....
>>>> Is there some way to get things to work as in 1.0.4 and get the
>>>> warning ?
>>>> I realize full support for fragments may be well down the road, but
>>>> is there any plan for a release like 1.0.4 (import class from the
>>>> fragment ) and getting a warning ?
>>>>
>>>> Thanks for any information on the subject.
>>>> Daniel Rubio
>>>> P.S- I realize the simple answer is keep using 1.0.4, but the reason
>>>> for my question is because I'm in the process of writing a book (for
>>>> Apress on Spring-OSGi) which is using Apache Felix, and some things
>>>> are already based on the v.1.0.4 and the upgrade to the newer v.1.2
>>>> breaks a few of the apps.
>>>>
>>>
>>>
>>
> 

Re: Fragment support 1.0.4 to 1.2 doesn't Import classes

["Richard S. Hall" <he...@ungoverned.org>]

Daniel,

I just applied a patch to trunk that makes the fragment install 
exception configurable. For details:

    https://issues.apache.org/jira/browse/FELIX-725

I have deployed a new maven snapshot or you can build from trunk if you 
want to use it.

-> richard

Daniel Rubio wrote:
>
> I hadn't actually tried to upgrade until now, and since some of the 
> bundles I was using were libraries (apache tomcat, jasper 
> compiler,etc) I didn't realize they were fragments until I got this 
> message testing on 1.2!
>
> I believe ignoring fragments in 1.0.4 - or the Fragment-Host directive 
> - simply processed the Import-Package statement and made the fragments 
> classes available as if they were a normal bundle, so that's why it 
> worked....
>  Inclusively I removed the Fragment-Host from the bundle and the app 
> works in 1.2, so I'm also realizing what is packaged as a fragment 
> didn't actually require being a full-fledged fragment, go figure, but 
> that's for the one's OSGi'fying bundles...
>
>   I guess we will leave 1.0.4 in place. If a new release comes out 
> before the last draft revision, that warns about fragments but still 
> loads classes 'as if it were a normal bundle' then I will use that ;) 
> otherwise I will just put a note.
>
>   Don't know what the consequence/side effects may be, in my app there 
> didn't seem to be trouble converting a fragment to a bundle just to 
> Import its classes an run the app successfully in 1.2...though there 
> might be trouble in some 'well-designed fragments' that do require not 
> just importing classes but the whole functionality required by the 
> fragment spec (but I guess that's where the warning comes in :-)  ).
>
>
>
> Richard S. Hall wrote:
>> Argh!
>>
>> Yes, we probably should have made that configurable. Where were you 
>> when I was asking about throwing an exception on fragment install? ;-)
>>
>> I guess the short answer is "no, there is no way to change it". You 
>> have two options at this point:
>>
>>   1. Roll your own release that disables the exception (pretty easy to
>>      do, I guess I might actually be able to make this configurable in
>>      trunk and create a new snapshot that will eventually become 1.2.2
>>      and you could use that for the time being).
>>   2. Keep using 1.0.4 until we do another release that makes this
>>      configurable.
>>
>> I don't see any reason why we couldn't make this configurable, 
>> perhaps someone sees something that I don't. The fact that your apps 
>> worked at all before I guess was just luck, since we ignored 
>> fragments altogether in 1.0.4.
>>
>> -> richard
>>
>> Daniel Rubio (OSGI Mailing List) wrote:
>>> I just upgraded to Felix 1.2+ from 1.0.4, only to realize some of my 
>>> (library) bundles are fragments.
>>>
>>> I'm getting a warning that in 1.2 there is partial support for 
>>> fragments, which I of course appreciate. However, the application 
>>> now ceases to work since it apparently doesn't import any classes in 
>>> the fragment....
>>> Is there some way to get things to work as in 1.0.4 and get the 
>>> warning ?
>>> I realize full support for fragments may be well down the road, but 
>>> is there any plan for a release like 1.0.4 (import class from the 
>>> fragment ) and getting a warning ?
>>>
>>> Thanks for any information on the subject.
>>> Daniel Rubio
>>> P.S- I realize the simple answer is keep using 1.0.4, but the reason 
>>> for my question is because I'm in the process of writing a book (for 
>>> Apress on Spring-OSGi) which is using Apache Felix, and some things 
>>> are already based on the v.1.0.4 and the upgrade to the newer v.1.2 
>>> breaks a few of the apps.
>>>
>>
>>
>

Re: Fragment support 1.0.4 to 1.2 doesn't Import classes

[Daniel Rubio <da...@webforefront.com>]

I hadn't actually tried to upgrade until now, and since some of the 
bundles I was using were libraries (apache tomcat, jasper compiler,etc) 
I didn't realize they were fragments until I got this message testing on 
1.2!

I believe ignoring fragments in 1.0.4 - or the Fragment-Host directive - 
simply processed the Import-Package statement and made the fragments 
classes available as if they were a normal bundle, so that's why it 
worked....
  Inclusively I removed the Fragment-Host from the bundle and the app 
works in 1.2, so I'm also realizing what is packaged as a fragment 
didn't actually require being a full-fledged fragment, go figure, but 
that's for the one's OSGi'fying bundles...

   I guess we will leave 1.0.4 in place. If a new release comes out 
before the last draft revision, that warns about fragments but still 
loads classes 'as if it were a normal bundle' then I will use that ;) 
otherwise I will just put a note.
 
   Don't know what the consequence/side effects may be, in my app there 
didn't seem to be trouble converting a fragment to a bundle just to 
Import its classes an run the app successfully in 1.2...though there 
might be trouble in some 'well-designed fragments' that do require not 
just importing classes but the whole functionality required by the 
fragment spec (but I guess that's where the warning comes in :-)  ).



Richard S. Hall wrote:
> Argh!
>
> Yes, we probably should have made that configurable. Where were you 
> when I was asking about throwing an exception on fragment install? ;-)
>
> I guess the short answer is "no, there is no way to change it". You 
> have two options at this point:
>
>   1. Roll your own release that disables the exception (pretty easy to
>      do, I guess I might actually be able to make this configurable in
>      trunk and create a new snapshot that will eventually become 1.2.2
>      and you could use that for the time being).
>   2. Keep using 1.0.4 until we do another release that makes this
>      configurable.
>
> I don't see any reason why we couldn't make this configurable, perhaps 
> someone sees something that I don't. The fact that your apps worked at 
> all before I guess was just luck, since we ignored fragments 
> altogether in 1.0.4.
>
> -> richard
>
> Daniel Rubio (OSGI Mailing List) wrote:
>> I just upgraded to Felix 1.2+ from 1.0.4, only to realize some of my 
>> (library) bundles are fragments.
>>
>> I'm getting a warning that in 1.2 there is partial support for 
>> fragments, which I of course appreciate. However, the application now 
>> ceases to work since it apparently doesn't import any classes in the 
>> fragment....
>> Is there some way to get things to work as in 1.0.4 and get the 
>> warning ?
>> I realize full support for fragments may be well down the road, but 
>> is there any plan for a release like 1.0.4 (import class from the 
>> fragment ) and getting a warning ?
>>
>> Thanks for any information on the subject.
>> Daniel Rubio
>> P.S- I realize the simple answer is keep using 1.0.4, but the reason 
>> for my question is because I'm in the process of writing a book (for 
>> Apress on Spring-OSGi) which is using Apache Felix, and some things 
>> are already based on the v.1.0.4 and the upgrade to the newer v.1.2 
>> breaks a few of the apps.
>>
>
>

Re: Fragment support 1.0.4 to 1.2 doesn't Import classes

["Richard S. Hall" <he...@ungoverned.org>]

Argh!

Yes, we probably should have made that configurable. Where were you when 
I was asking about throwing an exception on fragment install? ;-)

I guess the short answer is "no, there is no way to change it". You have 
two options at this point:

   1. Roll your own release that disables the exception (pretty easy to
      do, I guess I might actually be able to make this configurable in
      trunk and create a new snapshot that will eventually become 1.2.2
      and you could use that for the time being).
   2. Keep using 1.0.4 until we do another release that makes this
      configurable.

I don't see any reason why we couldn't make this configurable, perhaps 
someone sees something that I don't. The fact that your apps worked at 
all before I guess was just luck, since we ignored fragments altogether 
in 1.0.4.

-> richard

Daniel Rubio (OSGI Mailing List) wrote:
> I just upgraded to Felix 1.2+ from 1.0.4, only to realize some of my 
> (library) bundles are fragments.
>
> I'm getting a warning that in 1.2 there is partial support for 
> fragments, which I of course appreciate. However, the application now 
> ceases to work since it apparently doesn't import any classes in the 
> fragment....
> Is there some way to get things to work as in 1.0.4 and get the warning ?
> I realize full support for fragments may be well down the road, but is 
> there any plan for a release like 1.0.4 (import class from the 
> fragment ) and getting a warning ?
>
> Thanks for any information on the subject.
> Daniel Rubio
> P.S- I realize the simple answer is keep using 1.0.4, but the reason 
> for my question is because I'm in the process of writing a book (for 
> Apress on Spring-OSGi) which is using Apache Felix, and some things 
> are already based on the v.1.0.4 and the upgrade to the newer v.1.2 
> breaks a few of the apps.
>