On 7/14/11 17:00, john.dun...@exceter.com wrote:
I would like to hide the update mechanism from the end user. As far as
the client is be concerned, the application should be versioned as a
whole. For example, I would like the client to see that an update from
version 1.2.3.4 to 1.2.3.5 is available. Behind the scenes the update
would be a collection of bundles. The bundles would be versioned
separately but the update(collection of bundles) would be tested as a
unit in my test environment before being made available to the client.
I'd also like to be able to give the client a menu for falling back to
a previous version.
Well, in that case, you control everything, so it should be do-able.
Regarding the "fall back" mechanism, OSGi doesn't give you a way to
access the bundle JAR files, so you'd likely need to make some sort of
installer bundle that actually deploys the bundles and keeps a copy of
what it deploys so it is able to rollback if desired.
-> richard
Quoting "Richard S. Hall" <he...@ungoverned.org>:
On 7/14/11 13:33, john.dun...@exceter.com 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: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
