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.
