Richard S. Hall wrote:
OBR does not really support run-time dependency resolution. I would be
fairly easy to create resources at run time that you could ask OBR to
resolve, but that is not really the hard part.
Should say, "It would be fairly easy..."
OBR is not really geared toward run-time service dependency
resolution, since it is hard to know which to choose. Typically you'd
want to make a selection based on some non-functional characteristics.
But even if you just want it based on service interface type, OBR
doesn't really have a way to know how it should treat optional service
dependencies (e.g., should they always be resolved if possible?) or
aggregate service dependencies (e.g., should it all available or some
subset?).
Should say, "(e.g., should it get all available...)"
Tired, I guess.
-> richard
Only simple policies are possible in these cases. Coming up with a
"best fit" policy is difficult, unless we have some way of describing
what a "best fit" is.
I think this is an interesting area, but it needs more exploration.
-> richard
Krishanu wrote:
I have 4 bundles. B2 has interface I1. B3 and B4 provide different
implementations of I1. So both B3 and B4 depends on B2. B1 uses I1
interface
and hence also depends on B2.
So for B1 to work properly; B1, B2 and either or both of B3 and B4
needs to
be in OSGi runtime. When we use OBR service and deploy B1, its
compile time
dependency: B2 gets installed in runtime, automatically. This is because
these dependencies are represented in the repository.xml file.
However, what
about the runtime dependencies of B1?
Is there a way to depoly B1 so that the best fit among B3 and B4 will
automatically get installed in runtime. Or do the developer has to
independently deploy either B3 or B4 or both along with B1. What is
the best
practice?
Note: I understand that if both B1 and B2 are in runtime, OSGi knows
how to
choose the proper one using constraints(if at all required). I also
understand, that if B1 has B3 or B4 as its required bundle, it will
resolve
the dependency, but then the whole purpose of making the impl
dynamically
available is lost.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
