felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lukasz Dywicki <luk...@dywicki.pl>
Subject Re: Karaf features improvements
Date Mon, 24 May 2010 08:53:24 GMT

Ok,
I will write code similar to feature state management (verify
blueprint/spring context state) and bundle monitoring based od feature sets.
I can provide patch for these things.

Regards,
Lukasz


gnodet wrote:
> 
> On Fri, May 21, 2010 at 11:42, Lukasz Dywicki <lukasz@dywicki.pl> wrote:
>>
>> Hello Guillaume,
>>
>> gnodet wrote:
>>>
>>> There is some work going on in the OSGi Alliance about multiple
>>> frameworks in one JVM (see
>>> http://www.osgi.org/Download/File?url=/download/osgi-core-4.3-early-draft1.pdf
>>> for more informations).  This would enable to have a tree of OSGi
>>> frameworks instead of a single instance and would enable controlled
>>> sharing between a framework and its parent.      This would enable a
>>> controlled level of isolation and could be used to make sure some
>>> features don't interfere with each other.  That's one of the reason
>>> i'm not totally convinced about your proposal.  If we'd were to use
>>> nested frameworks, each feature would have its own framework, so that
>>> would not map well to your proposal.
>>>
>> I didn't know that OSGi alliance published new draft so fast.
>>
>> I am not familar with current draft - but I found that bundle listeners
>> will
>> be also scoped per framework - so when you'll install feature (and
>> budnles)
>> in one other instances will don't know anything about this operation.
>>
> 
> Well, the idea would be that a feature would create a new nested
> framework, so all features would be visible from the top level.
> 
>>
>>
>> gnodet wrote:
>>>
>>> The two other things i have in mind for features are:
>>>   * give a lifecycle to a feature (start / stop)
>>>   * allow more control on the bundles when installed (started level,
>>> start state)
>>>
>>>
>> I agree with you in your proposals:
>> +1 for feature lifecycle
>> +1 allow more control on the bundles when installed
>>
>>
>> gnodet wrote:
>>>
>>>   * leverage obr to compute a transitive closure of the feature before
>>> installation
>>> The last one would allow a more loose definition of a feature but just
>>> specifying the list of key bundles and let the features service
>>> determine all the required dependencies and download / install them.
> 
>> I don't know OBR and other stuff so I can't help and vote on this. I can
>> help in first two cases.
> 
> OBR is a repository containing OSGi metadata.  It would be used to
> compute the required dependencies.
> 
>>
>>
>> gnodet wrote:
>>>
>>> FWIW, nested frameworks are not available yet in felix (there's only a
>>> prototype in an equinox branch), so we can't really use those now, but
>>> the other things should be possible to implement now.  In particular,
>>> the use of OBR should now be possible since the new release as some
>>> acceptable performances.
>>
>> I think we can leave 4.3 and it's features and make Karaf good base to
>> work
>> with OSGi 4.2.
>> From my side groving osgi complexity it's bad idea - I love KISS
>> principle
>> and in my idea OSGi 4.2 is good example of simple and powerful
>> environment.
>> We should wait until 4.3 will be in final stage to get them into Karaf.
>>
>> Best regards,
>> Lukasz Dywicki
>> --
>> View this message in context:
>> http://old.nabble.com/Karaf-features-improvements-tp28622180p28631675.html
>> Sent from the Apache Felix - Dev mailing list archive at Nabble.com.
>>
>>
> 
> 
> 
> -- 
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
> 
> 

-- 
View this message in context: http://old.nabble.com/Karaf-features-improvements-tp28622180p28654869.html
Sent from the Apache Felix - Dev mailing list archive at Nabble.com.


Mime
View raw message