You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by "Richard S. Hall" <he...@ungoverned.org> on 2009/05/03 03:31:16 UTC
Fragment support
I recently checked in a first pass at providing support for fragments to
do exports, imports, and requires. (Native libraries are not yet
supported since that requires some work on the bundle cache.)
I am sure there are some bugs lurking in the fragment support, but I
have created some fragment tests of my own and have been running it
against the TCK and it at least looks like it is doing something.
Please try out some fragments and give feedback.
I will likely need to push a release of this soon, since GF has some
requirements I need to address with it. So any feedback is welcome.
Thanks.
-> richard
Re: Fragment support
Posted by "Richard S. Hall" <he...@ungoverned.org>.
p.s. I have deployed new snapshot of framework and main...
On 5/2/09 9:31 PM, Richard S. Hall wrote:
> I recently checked in a first pass at providing support for fragments
> to do exports, imports, and requires. (Native libraries are not yet
> supported since that requires some work on the bundle cache.)
>
> I am sure there are some bugs lurking in the fragment support, but I
> have created some fragment tests of my own and have been running it
> against the TCK and it at least looks like it is doing something.
>
> Please try out some fragments and give feedback.
>
> I will likely need to push a release of this soon, since GF has some
> requirements I need to address with it. So any feedback is welcome.
>
> Thanks.
>
> -> richard
Re: Fragment support
Posted by Clement Escoffier <cl...@gmail.com>.
By the way, this version support Spring SL4J bundles (using fragment
to contribute API implementations).
[ 27] [Active ] [ 1] SLF4J API (1.5.6)
[ 28] [Resolved ] [ 1] SLF4J Jakarta Commons Logging Binding
(1.5.6)
[ 29] [Active ] [ 1] Apache Commons Logging (1.1.1)
Regards,
Clement
On 03.05.2009, at 03:31, Richard S. Hall wrote:
> I recently checked in a first pass at providing support for
> fragments to do exports, imports, and requires. (Native libraries
> are not yet supported since that requires some work on the bundle
> cache.)
>
> I am sure there are some bugs lurking in the fragment support, but I
> have created some fragment tests of my own and have been running it
> against the TCK and it at least looks like it is doing something.
>
> Please try out some fragments and give feedback.
>
> I will likely need to push a release of this soon, since GF has some
> requirements I need to address with it. So any feedback is welcome.
>
> Thanks.
>
> -> richard
Re: Fragment support
Posted by Marcel Offermans <ma...@luminis.nl>.
On May 3, 2009, at 18:13 , Richard S. Hall wrote:
> On 5/3/09 11:58 AM, Marcel Offermans wrote:
>> So what if there was a bundle that actually exported:
>> foo;version=1.0.0 and foo;version=2.0.0. One could argue that this
>> would allow this bundle to be wired to the one above, which needs
>> version 1 and 2, both of which are exported by the same bundle.
>>
>> Now I fully agree this is a very theoretical example, I can't find
>> any
>> real world use for it, just curious. :)
>
> Yes, that sounds pretty funny and in this case it is a loophole, so
> you
> are right. But the only reason it will work in practice is because
> there
> is actually only one set of byte code that is being used for both. The
> exporting bundle in question is masquerading as both, but it is really
> only one or the other.
Effectively, version 1.0.0 is exactly equal to 2.0.0 in this case, so
there really should not be two versions in the first place.
> So, in the future if we loosen how we detect conflicts, depending on
> how
> far we go, we could end up allowing such situations. Essentially, you
> would need to resolve all dependencies for the host and fragments and
> then look for shared candidates for conflicting dependencies.
Yes, in theory we could go this far. However, I would say we need
examples that make more sense to move this up the priority list.
Greetings, Marcel
Re: Fragment support
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 5/3/09 11:58 AM, Marcel Offermans wrote:
> So what if there was a bundle that actually exported:
> foo;version=1.0.0 and foo;version=2.0.0. One could argue that this
> would allow this bundle to be wired to the one above, which needs
> version 1 and 2, both of which are exported by the same bundle.
>
> Now I fully agree this is a very theoretical example, I can't find any
> real world use for it, just curious. :)
Yes, that sounds pretty funny and in this case it is a loophole, so you
are right. But the only reason it will work in practice is because there
is actually only one set of byte code that is being used for both. The
exporting bundle in question is masquerading as both, but it is really
only one or the other.
So, in the future if we loosen how we detect conflicts, depending on how
far we go, we could end up allowing such situations. Essentially, you
would need to resolve all dependencies for the host and fragments and
then look for shared candidates for conflicting dependencies.
-> richard
Re: Fragment support
Posted by Marcel Offermans <ma...@luminis.nl>.
On May 3, 2009, at 16:45 , Richard S. Hall wrote:
> For example, the host could
> import foo;version=[1.0.0,1.0.0] and the fragment could import
> foo;version=[2.0.0,2.0.0]. This would be impossible to resolve.
> Version
> is just one attribute, but there could be conflicts with any
> attribute.
It probably does not make any sense to allow such conflicting imports,
however, your comment later in the post triggered a question:
> Exports do not pose a conflict at all, since a bundle is allowed to
> export the same package more than once with different attributes. So,
> this is only an issue for overlapping import packages and required
> bundles.
So what if there was a bundle that actually exported:
foo;version=1.0.0 and foo;version=2.0.0. One could argue that this
would allow this bundle to be wired to the one above, which needs
version 1 and 2, both of which are exported by the same bundle.
Now I fully agree this is a very theoretical example, I can't find any
real world use for it, just curious. :)
Greetings, Marcel
Re: Fragment support
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 5/3/09 10:35 AM, Filippo Diotalevi wrote:
> On Sun, May 3, 2009 at 3:41 PM, Richard S. Hall<he...@ungoverned.org> wrote:
>
>> The specification is somewhat vague on what it means for a fragment and host
>> (or other fragments) to conflict. Initially I have taken a conservative view
>> of this, so if there is any overlap at all I consider them to be in
>> conflict.
>>
>> It would be possible to loosen this up by allowing overlap if they the have
>> exact same requirement, for example. You could even go further and try to
>> see if you can find candidates that resolve overlapping requirements and
>> only consider them conflicting if you cannot.
>>
>
> I don't know the implementation details, but if the fragment imports a
> package that is already imported by the host, I would consider it just
> redundant and not a conflict (maybe a WARNING to explain that the
> import is not needed). Implementation wise, maybe you can just ignore
> the redundant import (?).
>
That is only true if there is no conflict. For example, the host could
import foo;version=[1.0.0,1.0.0] and the fragment could import
foo;version=[2.0.0,2.0.0]. This would be impossible to resolve. Version
is just one attribute, but there could be conflicts with any attribute.
However, you are correct that we can treat an overlapping requirement as
redundant if, in the most general sense, we can find a candidate that
satisfies all overlapping requirements for a given package/require bundle.
> Just noticed that the (infamous, by now ;-) hibernate bundle example
> has the same problem for exports: f.i. the "org.hibernate.cfg" package
> is exported by the host bundle and by 2 fragments. Haven't tested this
> use case yet. Do you think it's complicated to support?
>
Exports do not pose a conflict at all, since a bundle is allowed to
export the same package more than once with different attributes. So,
this is only an issue for overlapping import packages and required bundles.
-> richard
Re: Fragment support
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 5/6/09 3:24 PM, Filippo Diotalevi wrote:
> On Wed, May 6, 2009 at 1:15 AM, Richard S. Hall<he...@ungoverned.org> wrote:
>
>> No problem. I have another fix to commit once SVN is working again.
>>
>
> Had the time to do only some tests
> - host and fragment import the same package
> - host and fragment import the same versioned package
> everything is working well.
>
Thanks.
-> richard
Re: Fragment support
Posted by Filippo Diotalevi <fi...@gmail.com>.
On Wed, May 6, 2009 at 1:15 AM, Richard S. Hall <he...@ungoverned.org> wrote:
> No problem. I have another fix to commit once SVN is working again.
Had the time to do only some tests
- host and fragment import the same package
- host and fragment import the same versioned package
everything is working well.
--
Filippo Diotalevi
Re: Fragment support
Posted by "Richard S. Hall" <he...@ungoverned.org>.
No problem. I have another fix to commit once SVN is working again.
-> richard
On 5/5/09 5:19 PM, Filippo Diotalevi wrote:
> On Tue, May 5, 2009 at 6:40 PM, Richard S. Hall<he...@ungoverned.org> wrote:
>
>> Filippo,
>>
>> As it turns out, the use case I was trying to solve for GF also had
>> overlapping requirements, so I was forced to loosen up conflict
>> determination to some degree. I did as I said below, which is to check if
>> the requirements are identical, if so I allow it, otherwise it is a conflict
>> and the fragment doesn't attach.
>>
>>
>
> I saw the Jira update, but still haven't had any time to try the new build.
> Hopefully I'll give it a a go tomorrow.
>
>
Re: Fragment support
Posted by Filippo Diotalevi <fi...@gmail.com>.
On Tue, May 5, 2009 at 6:40 PM, Richard S. Hall <he...@ungoverned.org> wrote:
> Filippo,
>
> As it turns out, the use case I was trying to solve for GF also had
> overlapping requirements, so I was forced to loosen up conflict
> determination to some degree. I did as I said below, which is to check if
> the requirements are identical, if so I allow it, otherwise it is a conflict
> and the fragment doesn't attach.
>
I saw the Jira update, but still haven't had any time to try the new build.
Hopefully I'll give it a a go tomorrow.
--
Filippo Diotalevi
Re: Fragment support
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Filippo,
As it turns out, the use case I was trying to solve for GF also had
overlapping requirements, so I was forced to loosen up conflict
determination to some degree. I did as I said below, which is to check
if the requirements are identical, if so I allow it, otherwise it is a
conflict and the fragment doesn't attach.
New snapshots of framework and main have been deployed...
-> richard
On 5/3/09 4:06 PM, Richard S. Hall wrote:
> On 5/3/09 1:45 PM, Filippo Diotalevi wrote:
>> If redundant imports (same package, same version range) could be
>> simply ignored it would be great; but if it's too much work to
>> implement it now, for me it's not a big problem. The support is
>> definitely good enough (and specification-compliant, for what I can
>> understand) to start writing fragments.
>
> Well, it wouldn't be sufficient to just check version range, you need
> to check if all attributes were the same.
>
> It depends on how much time I have after doing my other testing. If I
> have time, I will look into it more. If I don't, it will have to wait
> for the next release.
>
> -> richard
Re: Fragment support
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 5/3/09 1:45 PM, Filippo Diotalevi wrote:
> If redundant imports (same package, same version range) could be
> simply ignored it would be great; but if it's too much work to
> implement it now, for me it's not a big problem. The support is
> definitely good enough (and specification-compliant, for what I can
> understand) to start writing fragments.
>
Well, it wouldn't be sufficient to just check version range, you need to
check if all attributes were the same.
It depends on how much time I have after doing my other testing. If I
have time, I will look into it more. If I don't, it will have to wait
for the next release.
-> richard
Re: Fragment support
Posted by Filippo Diotalevi <fi...@gmail.com>.
On Sun, May 3, 2009 at 4:51 PM, Richard S. Hall <he...@ungoverned.org> wrote:
> I am not so worried since I know the area we are discussing can be improved
> later. I guess the question we need to answer for now is, is this level of
> support good enough to move forward for now and we can improve it later
> (release early and often) or is it too limited to be useful?
If redundant imports (same package, same version range) could be
simply ignored it would be great; but if it's too much work to
implement it now, for me it's not a big problem. The support is
definitely good enough (and specification-compliant, for what I can
understand) to start writing fragments.
--
Filippo Diotalevi
Re: Fragment support
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Yep, you are correct...see my other response.
Thanks for really looking into this.
I am not so worried since I know the area we are discussing can be
improved later. I guess the question we need to answer for now is, is
this level of support good enough to move forward for now and we can
improve it later (release early and often) or is it too limited to be
useful?
From my point of view, I think it is definitely an improvement so I
would say move forward. If that is the case, then we need to test a
little to see if what we have is actually working. In that regard, I am
somewhat confident, since I have passed my own tests and most of the TCK
tests, but I know that this is not complete coverage.
I expect to spend some time this week trying to find more fine-grained bugs.
-> richard
On 5/3/09 10:44 AM, Filippo Diotalevi wrote:
> On Sun, May 3, 2009 at 4:35 PM, Filippo Diotalevi
> <fi...@gmail.com> wrote:
>
>> Just noticed that the (infamous, by now ;-) hibernate bundle example
>> has the same problem for exports: f.i. the "org.hibernate.cfg" package
>> is exported by the host bundle and by 2 fragments. Haven't tested this
>> use case yet. Do you think it's complicated to support?
>>
>
> Answering my own question here: the spec seems to allow that
> ("Append the export definitions of a Fragment bundle to the export
> definitions of the host bundle unless the exact definition (directives and
> attributes must match) is already present in the host."
>
> ..and I've just tested your implementation and this use case works.
>
>
Re: Fragment support
Posted by Filippo Diotalevi <fi...@gmail.com>.
On Sun, May 3, 2009 at 4:35 PM, Filippo Diotalevi
<fi...@gmail.com> wrote:
> Just noticed that the (infamous, by now ;-) hibernate bundle example
> has the same problem for exports: f.i. the "org.hibernate.cfg" package
> is exported by the host bundle and by 2 fragments. Haven't tested this
> use case yet. Do you think it's complicated to support?
Answering my own question here: the spec seems to allow that
("Append the export definitions of a Fragment bundle to the export
definitions of the host bundle unless the exact definition (directives and
attributes must match) is already present in the host."
..and I've just tested your implementation and this use case works.
--
Filippo Diotalevi
Re: Fragment support
Posted by Filippo Diotalevi <fi...@gmail.com>.
On Sun, May 3, 2009 at 3:41 PM, Richard S. Hall <he...@ungoverned.org> wrote:
> The specification is somewhat vague on what it means for a fragment and host
> (or other fragments) to conflict. Initially I have taken a conservative view
> of this, so if there is any overlap at all I consider them to be in
> conflict.
>
> It would be possible to loosen this up by allowing overlap if they the have
> exact same requirement, for example. You could even go further and try to
> see if you can find candidates that resolve overlapping requirements and
> only consider them conflicting if you cannot.
I don't know the implementation details, but if the fragment imports a
package that is already imported by the host, I would consider it just
redundant and not a conflict (maybe a WARNING to explain that the
import is not needed). Implementation wise, maybe you can just ignore
the redundant import (?).
Just noticed that the (infamous, by now ;-) hibernate bundle example
has the same problem for exports: f.i. the "org.hibernate.cfg" package
is exported by the host bundle and by 2 fragments. Haven't tested this
use case yet. Do you think it's complicated to support?
--
Filippo Diotalevi
Re: Fragment support
Posted by "Richard S. Hall" <he...@ungoverned.org>.
The specification is somewhat vague on what it means for a fragment and
host (or other fragments) to conflict. Initially I have taken a
conservative view of this, so if there is any overlap at all I consider
them to be in conflict.
It would be possible to loosen this up by allowing overlap if they the
have exact same requirement, for example. You could even go further and
try to see if you can find candidates that resolve overlapping
requirements and only consider them conflicting if you cannot.
I am aware that I chose a stricter definition at this point, since it
was easier for now and I need to try to release this soon. We can always
open up an issue to loosen it up later.
What do you think?
-> richard
On 5/3/09 6:39 AM, Filippo Diotalevi wrote:
> On Sun, May 3, 2009 at 3:31 AM, Richard S. Hall<he...@ungoverned.org> wrote:
>
>> [..]
>> Please try out some fragments and give feedback.
>>
>> I will likely need to push a release of this soon, since GF has some
>> requirements I need to address with it. So any feedback is welcome.
>>
>
> Hi Richard,
> I did a fair amount of testing on bundle fragment support yesterday
> and today, using both some home-made fragments and examples available.
> As Clement says, felix works fine with slf4j, but fails to resolve
> some "real world" fragments.
>
> Taking the usual hibernate bundle as an example, the 2 fragments are
> not resolved
> [ 7] [Active ] [ 1] JBoss Hibernate Object-Relational Mapper (3.2.6.ga)
> [ 9] [Installed ] [ 1] JBoss Hibernate Annotations (3.3.1.ga)
> [ 10] [Active ] [ 1] JBoss Hibernate Common Annotations (3.3.0.ga)
> [ 11] [Installed ] [ 1] JBoss Hibernate Entity Manager (3.3.2.GA)
> The reason is
> DEBUG: Excluding fragment com.springsource.org.hibernate.annotations
> from com.springsource.org.hibernate due to conflict with imported
> package org.apache.commons.logging from com.springsource.org.hibernate
> DEBUG: Excluding fragment com.springsource.org.hibernate.ejb from
> com.springsource.org.hibernate due to conflict with imported package
> javax.naming from com.springsource.org.hibernate
>
> In practice, when host and fragment share some imports (in the
> specific org.apache.commons.logging
> and javax.naming), fragments are not resolved.
>
> Specification wise, I think these double imports should be specified, since
> "Fragments are therefore treated as part of the host, including any
> permitted headers; they must not have their own class loader. "
>
> and
>
> " Append the import definitions for the Fragment bundle that do not con-
> flict with an import definition of the host to the import definitions of the
> host bundle. A Fragment can provide an import statement for a private
> package of the host. The private package in the host is hidden in that
> case.
> [..]
> A host and a fragment conflict when they cannot resolve to provide a consis-
> tent class space"
>
> but, as far as I see, it's quite common to find similar cases in
> already available bundles.
>
>
Re: Fragment support
Posted by Filippo Diotalevi <fi...@gmail.com>.
On Sun, May 3, 2009 at 12:39 PM, Filippo Diotalevi
<fi...@gmail.com> wrote:
> Specification wise, I think these double imports should be specified
Sorry, *should not* !
--
Filippo Diotalevi
Re: Fragment support
Posted by Filippo Diotalevi <fi...@gmail.com>.
On Sun, May 3, 2009 at 3:31 AM, Richard S. Hall <he...@ungoverned.org> wrote:
> [..]
> Please try out some fragments and give feedback.
>
> I will likely need to push a release of this soon, since GF has some
> requirements I need to address with it. So any feedback is welcome.
Hi Richard,
I did a fair amount of testing on bundle fragment support yesterday
and today, using both some home-made fragments and examples available.
As Clement says, felix works fine with slf4j, but fails to resolve
some "real world" fragments.
Taking the usual hibernate bundle as an example, the 2 fragments are
not resolved
[ 7] [Active ] [ 1] JBoss Hibernate Object-Relational Mapper (3.2.6.ga)
[ 9] [Installed ] [ 1] JBoss Hibernate Annotations (3.3.1.ga)
[ 10] [Active ] [ 1] JBoss Hibernate Common Annotations (3.3.0.ga)
[ 11] [Installed ] [ 1] JBoss Hibernate Entity Manager (3.3.2.GA)
The reason is
DEBUG: Excluding fragment com.springsource.org.hibernate.annotations
from com.springsource.org.hibernate due to conflict with imported
package org.apache.commons.logging from com.springsource.org.hibernate
DEBUG: Excluding fragment com.springsource.org.hibernate.ejb from
com.springsource.org.hibernate due to conflict with imported package
javax.naming from com.springsource.org.hibernate
In practice, when host and fragment share some imports (in the
specific org.apache.commons.logging
and javax.naming), fragments are not resolved.
Specification wise, I think these double imports should be specified, since
"Fragments are therefore treated as part of the host, including any
permitted headers; they must not have their own class loader. "
and
" Append the import definitions for the Fragment bundle that do not con-
flict with an import definition of the host to the import definitions of the
host bundle. A Fragment can provide an import statement for a private
package of the host. The private package in the host is hidden in that
case.
[..]
A host and a fragment conflict when they cannot resolve to provide a consis-
tent class space"
but, as far as I see, it's quite common to find similar cases in
already available bundles.
--
Filippo Diotalevi