So, you should only start the bundles you need to start...the Paremus
guys just had a nice blog about this... :-)
Quite naively, I was originally hoping i wouldn't have to know..
But even with the suggestion to start only service dependencies, we're
still very sensitive to packaging: 2 bundles could provide the same
service and one may also start another service that I don't want...
I guess in my ideal little world, we'd have inoffensive APIs and library
bundles packaged independently of "active implementations" and the later
wouldn't export any package but only register a single implementation or
service per bundle (with some service properties so we can choose which
one we want!)
But the world can't be ideal since we all have our own idea of what that
ideal would be :)
So the bottom line is that I'll have to know exactly which bundles
should be started... I shall meditate on this over the week end.
Thanks for the feedback.
/arjun
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.
