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 ...
On Fri, Mar 5, 2010 at 14:57, Richard S. Hall <[email protected]> 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 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. >>>>> >>>>> >>>> >>> >>> >> > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
