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!)
....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.
