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 13:57:30 GMT
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 

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 of
>>>            "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 think
>>>> 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 a
>>>> 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