On 3/5/10 12:46, Arjun Panday wrote:
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!)
Yeah, I'm not sure this would be an ideal world, since related services
couldn't share an implementation bundle, which would likely lead to
inefficiencies. I think one service per bundle is too strict.
I am not saying this is a good idea, but it sounds like you want to add
additional constraints on the candidate selected to resolver your
dependency. For example, you want to say "I want a bundle that provides
FooService, but no other services". This will start to make things even
more difficult to resolve.
-> richard
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.
