On 7/14/11 13:33, [email protected] wrote:
I'm interested in using OSGI as an update mechanism in a swing based
app. However, I'm concerned that managing the extremely dynamic nature
of OSGI is too difficult.
How can guarantee that the client's OSGI container will remain in a
known state which is identical to the state of the OSGI container that
I'm testing against? How can I guarantee that updates will be
installed, resolved, and wired in exactly the same sequence in the
client OSGI container and as they are in the OSGI container that I'm
testing against? If I cannot guarantee these things then I do not
understand how I can guarantee that my updates will succeed.
It depends. If you are completely hiding the underlying dynamic OSGi
layer underneath and completely controlling what gets installed into the
framework, then you should be able to control it. However, if you are
exposing it to the end user (e.g., allowing the user to dynamic deploy
arbitrary bundles or plugins), then it becomes more complicated.
If you are exposing the ability to deploy arbitrary bundles, then you
can always try to make your bundles' dependencies very rigid so you only
get them from where you expect (e.g., using Import-Package with the
explicit attributes or even Require-Bundle). Doing so, however, might
not always give you optimum results.
For example, if the user deployed some newer version of a common library
and other bundles that depend on it. If your bundles can only wire to
the older version (even if the newer one would be compatible), then
you'll create a class space division in the system and your bundles will
potentially not be able to interoperate with the new bundles. It can
also create situations where things fail to resolve at all, since rigid
dependencies, by definition, do not give the OSGi resolver much
flexibility in selecting candidates.
So, in short, if you cannot and do not want to cope with any dynamism in
your system, don't introduce any other than what is controlled by yourself.
-> richard
-John
---------------------------------------------------------------------
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]
