On 2/1/10 11:25, Chris Custine wrote:
I just wanted to also confirm that the Hibernate bundles all seem to resolve
and work properly now with this fix. We have several issues logged against
Karaf as well as ServiceMix regarding this and I have confirmed with several
of those users that the fix resolves all of their remaining issues. I think
we will finally be able to close the Hibernate fragment saga! Thanks a lot
Richard for getting this in for the next release.
I would like to get this framework release into the next Karaf release
(pending this fix), so I would be quite happy to cut this release ASAP if
everyone else is busy. Let me know...
We are planning a release this week.
-> richard
Thanks,
Chris
--
Chris Custine
FUSESource :: http://fusesource.com
My Blog :: http://blog.organicelement.com
Apache ServiceMix :: http://servicemix.apache.org
Apache Felix :: http://felix.apache.org
Apache Directory Server :: http://directory.apache.org
On Wed, Jan 27, 2010 at 1:01 PM, Richard S. Hall<he...@ungoverned.org>wrote:
On 1/27/10 14:25, andreas.schlos...@sybase.com wrote:
Great, thanks Richard. The Hibernate Annotations stuff is wired properly
now for me!
Good to hear. We're planning a Felix 2.0.3 release shortly which will
include this fix for the short term. Long term, I am trying to completely
re-implement Felix' resolver to address some performance issues (and some
other items on my agenda), so I expect fragment merging to happen completely
differently in Felix 3.0, but hopefully even more leniently.
-> richard
Thanks again,
Andreas
"Richard S. Hall"<he...@ungoverned.org>
01/22/2010 12:19 PM
Please respond to
dev@felix.apache.org
To
dev@felix.apache.org
cc
Subject
Re: Less restrictive conflict resolution for fragment imports
I just committed a patch to try to make fragment merging less
restrictive by calculating version range intersections for merged
requirements. It still requires that everything else be the same pretty
much, only versions are allowed to vary.
Could someone please test to see if this works for them. I deployed new
snapshots or you can build from trunk.
Thanks.
-> richard
On 12/17/09 9:44, Richard S. Hall wrote:
On 12/17/09 9:42, Richard S. Hall wrote:
On 12/17/09 8:27, Stuart McCulloch wrote:
2009/12/17 Guo Du<mrdu...@gmail.com>
On Wed, Dec 16, 2009 at 5:37 PM, Stuart McCulloch<mccu...@gmail.com>
wrote:
So +1 to trying the intersection approach.
Intersection ONLY is not safe for the case:
Host version [2.0.0,3.0.0)
[2.5.0,2.9.0)
Fails, when host is importing 2.1.0 this would cause fragment to
fail.
depends when the intersection was made - if it was done before the
host
resolved
then the host's import range would shrink to the intersection:
[2.5.0,2.9.0)
and the
host plus fragment would not be in conflict.
now if you're attaching the fragment to an already resolved host then
I
believe the
resolver would look at the existing wires, not the original range -
so if
the host was
already wired to 2.1.0 then the fragment wouldn't be able to attach
dynamically
but then this is still correct (afaik) in that you can't dynamically
attach
a fragment
that conflicts with the resolved host (btw, do we support dynamic
attachment?)
No, we don't.
We may have following condition to enable fragment:
1. exact version match or
2. host version range inside all fragments version or
3. all fragments and host share intersection + dynamic verify the
actual imported version is inside intersection
(p.s. I am not sure "dynamic verify the actual imported version is
inside intersection" is viable or not. If not, we could do at least
step 2 which will help both Andreas's and FELIX-1919 case )
these still fall under 'intersection' imho (ie. the intersection
should
apply to the
host and fragment) but let's see what Richard's algorithm actually
looks
like :)
The intersection approach will create a new version range each time a
fragment is added and the next fragment will be compared against that
range in bundle ID order. I don't think this will allow for any valid
cases since we are always making the allowed version range more narror.
Should say "any invalid cases"..."more narrow"...
-> richard
-> richard
-Guo
