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.
>>>>>>
>>>>>>
>>>>>
>
