felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard S. Hall" <he...@ungoverned.org>
Subject Re: Less restrictive conflict resolution for fragment imports
Date Mon, 01 Feb 2010 16:35:49 GMT
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<heavy@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"<heavy@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<mrduguo@gmail.com>
>>>>>>
>>>>>>
>>>>>>
>>>>>>              
>>>>>>> On Wed, Dec 16, 2009 at 5:37 PM, Stuart McCulloch<mcculls@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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>                
>>>>>>              
>>>
>>>
>>>        
>>      
>    

Mime
View raw message