You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Chris Custine <ch...@gmail.com> on 2010/02/01 17:25:17 UTC
Re: Less restrictive conflict resolution for fragment imports
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...
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.Schlosser@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<mr...@gmail.com>
>>>>>
>>>>>
>>>>>
>>>>>> On Wed, Dec 16, 2009 at 5:37 PM, Stuart McCulloch<mc...@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
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>
>>
>>
>
Re: Less restrictive conflict resolution for fragment imports
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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.Schlosser@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<mr...@gmail.com>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> On Wed, Dec 16, 2009 at 5:37 PM, Stuart McCulloch<mc...@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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>
>>>
>>>
>>
>