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: [DISCUSS] Review / release OBR 2.0.0
Date Fri, 05 Mar 2010 15:06:19 GMT
On 3/5/10 9:08, Guillaume Nodet wrote:
> About services ... How does the resolver in trunk deals with those
> requirements ?  Those are not part of the core spec, but are needed in
> OBR ...

Currently, it doesn't do anything with them at all, but since its model 
is generic, they can be fed in and resolved like OBR currently does.

-> richard

> On Fri, Mar 5, 2010 at 14:57, Richard S. Hall<heavy@ungoverned.org>  wrote:
>> On 3/5/10 8:25, Arjun Panday wrote:
>>> For info, what call the "previous version" was revision r886162 of the
>>> trunk on which I had applied the patch i had suggested for JIRA-692.
>>> As a matter of fact, this little change of behaviour in the resolver could
>>> have easily gone unnoticed, but -that's my luck- the extra bundle brought by
>>> the new resolver happens to be org.apache.felix.http.jetty-2.0.2.jar: an
>>> active bundle which, when started, opens a web server on port 8080!
>>> So now, independently of the change in the resolver implem, i'm starting
>>> to think it's a general issue with the OBR itself: as i add resources to my
>>> OBR, i have the risk of bringing new active resources which in addition to
>>> satisfy some package dependency will start doing all kinds of things and
>>> open connexions behind my back...
>>> I wanted to use the OBR to have better control over what runs in my JVM,
>>> but i'm starting to realize that it may do the exact opposite..
>>> (I shouldn't be that surprised, it's quite obvious when you think about
>>> it.. only I it had not occured to me before!)
>> Yes, if you resolve and start bundles somewhat blindly, then you don't know
>> what is going to happen.
>> I think the real issue here, though, is the starting of these bundles, not
>> the resolving. If you need package foo, then getting from anyone is fine
>> because we know what that will do (assuming no lazy activation). If you
>> start bundles, then you have no idea.
>> So, you should only start the bundles you need to start...the Paremus guys
>> just had a nice blog about this... :-)
>> Originally, when I first wrote OBR, I didn't even have an option to start
>> all deployed bundles, it only deployed them...the start was added as a
>> feature request, but it never really made that much sense to me since it
>> wasn't clear you wanted to start the transitive set of dependencies.
>> We could likely make OBR's deployer smarter. It could look at the types of
>> dependencies on a particular resource to determine whether or not they
>> should be started. For example, if all dependencies are of namespace
>> "package", then there is no reason to start it. However, if there is a
>> dependency of namespace "service", then it could start it.
>> I was thinking about this lately, since I've been having some discussion
>> with the Paremus guys. I think namespace might actually be sufficient for
>> this. We could actually make the action OBR takes for a particular namespace
>> configurable, so for example, by default it may start the "service"
>> namespace, but you could configure it not to.
>> Ok, I'm rambling...at any rate, to some degree you are correct, you don't
>> know what you are getting, but it can still be improved doing something like
>> what I suggest. However, if you need complete control, then you should just
>> define your own repository that only contains approved bundles.
>> ->  richard
>>> ....what do you think?
>>> thanks,
>>> /arjun
>>>>>    * more importantly, the output of the new implementation is
>>>>>      different from the previous one; namely, in my use case, it pulls
>>>>>      one additional resource that i do not need (nor want).. I haven't
>>>>>      yet managed to pinpoint the exact problem but here's what happens:
>>>>>          o i'm trying to resolve one single resource wich has a list
>>>>>            "Require-Bundle" dependencies
>>>>>          o one of these required bundles provides packages required by
>>>>>            the other ones
>>>>>          o my OBR happens to contain another resource which also
>>>>>            exports the same packages (same version!)
>>>>>          o the new implementation now pulls that other resource while
>>>>>            the old implementation did not, so i guess the resolution
>>>>>            order has changed and it impacts the result
>>>> The algorithm has not changed.  After having a look at the repository
>>>> you sent me, I do understand the problem but I don't see why the
>>>> resolution output has changed or what we can do about it.
>>>> The problem is that the first resource has lots of requirements on
>>>> bundles.  So the resolver tries to resolve them one by one.  While
>>>> resolving the first ones, it needs an import on javax.servlet, so the
>>>> best resource for that one is selected.  Later, the servlet api is
>>>> resolved, so we end up with two bundles exporting the javax.servlet
>>>> api.
>>>> I'm not really sure how to solve the problem.  My guess is that we'd
>>>> need some backtracking for that, but the current algorithm does not
>>>> uses backtracking because the current heuristic can't lead to
>>>> conflicts.   Resolving all the bundles requirements first can't really
>>>> be done either, because we may have multiple candidate bundles for the
>>>> same requirement, so we need to fully test one before going to the
>>>> second.
>>>> Richard may have more thoughts on that, as he is the resolution
>>>> expert.  I don't even know how the current OSGi resolver deals with
>>>> that.
>>>>> /arjun
>>>>> Le 03/01/2010 11:41 AM, Guillaume Nodet a écrit :
>>>>>> I've done a fait amount of changes to OBR those last weeks and I
>>>>>> it could deserve a release asap.
>>>>>> However, i'd like to have a few people reviewing the new API so that
>>>>>> we all agree on it before starting the release process.
>>>>>> For those who haven't followed the stream of JIRA issues, here is
>>>>>> short summary:
>>>>>>     * a new API named org.apache.felix.bundlerepository is available,
>>>>>> it's mostly based on the org.osgi.service.obr one
>>>>>>        but include a lot of small improvements
>>>>>>     * the org.osgi.service.obr isn't shipped anymore, but the if
>>>>>> present, a wrapper service will be exposed to offer compatibility
>>>>>>        with previous versions of OBR
>>>>>>     * the speed has been improved by a factor x10 or more (both parsing
>>>>>> and resolution)
>>>>>>     * ability to not resolve / install optional resources
>>>>>>     * support for requirements as an input for the resolution
>>>>>>     * support global constraints and capabilities
>>>>>> Feedback welcomed.   If there aren't any, I plan to start a release
>>>>>> early next week.

View raw message