You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Felix Meschberger <fm...@gmail.com> on 2008/10/13 17:27:22 UTC
Re: Fragment support 1.0.4 to 1.2 doesn't Import classes
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
Posted by 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
Posted by "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.
>>>>>
>>>>>
>>>>