You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by jo...@exceter.com on 2011/07/14 19:33:57 UTC
Managing Dynamism
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.
-John
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Managing Dynamism
Posted by Marcel Offermans <ma...@luminis.nl>.
Hello John,
Probably makes sense to follow up on the ACE mailing list. We don't yet have "users" list so feel free to use the ace-dev list for that (I cc'ed this mail to it as well).
Greetings, Marcel
On 15 Jul 2011, at 15:36 , <jo...@exceter.com> <jo...@exceter.com> wrote:
> That sounds perfect for what I'm trying to do!
>
> Quoting Marcel Offermans <ma...@luminis.nl>:
>
>> On 14 Jul 2011, at 23:00 , <jo...@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.
>>
>> You're pretty much describing the way Apache ACE handles the deployment of bundles (and configuration). They are distributed in a deployment package. Deployment packages are versioned sets of artifacts. Every time you change something in the set of bundles (for that client) its version number is bumped.
>>
>>> I'd also like to be able to give the client a menu for falling back to a previous version.
>>
>> The management agent on the client can make that decision (to go back to any previous version in fact). Hooking that up to the UI isn't hard.
>>
>> Greetings, Marcel
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Managing Dynamism
Posted by Marcel Offermans <ma...@luminis.nl>.
Hello John,
Probably makes sense to follow up on the ACE mailing list. We don't yet have "users" list so feel free to use the ace-dev list for that (I cc'ed this mail to it as well).
Greetings, Marcel
On 15 Jul 2011, at 15:36 , <jo...@exceter.com> <jo...@exceter.com> wrote:
> That sounds perfect for what I'm trying to do!
>
> Quoting Marcel Offermans <ma...@luminis.nl>:
>
>> On 14 Jul 2011, at 23:00 , <jo...@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.
>>
>> You're pretty much describing the way Apache ACE handles the deployment of bundles (and configuration). They are distributed in a deployment package. Deployment packages are versioned sets of artifacts. Every time you change something in the set of bundles (for that client) its version number is bumped.
>>
>>> I'd also like to be able to give the client a menu for falling back to a previous version.
>>
>> The management agent on the client can make that decision (to go back to any previous version in fact). Hooking that up to the UI isn't hard.
>>
>> Greetings, Marcel
Re: Managing Dynamism
Posted by jo...@exceter.com.
That sounds perfect for what I'm trying to do!
Quoting Marcel Offermans <ma...@luminis.nl>:
> On 14 Jul 2011, at 23:00 , <jo...@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.
>
> You're pretty much describing the way Apache ACE handles the
> deployment of bundles (and configuration). They are distributed in a
> deployment package. Deployment packages are versioned sets of
> artifacts. Every time you change something in the set of bundles
> (for that client) its version number is bumped.
>
>> I'd also like to be able to give the client a menu for falling back
>> to a previous version.
>
> The management agent on the client can make that decision (to go
> back to any previous version in fact). Hooking that up to the UI
> isn't hard.
>
> Greetings, Marcel
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Managing Dynamism
Posted by Marcel Offermans <ma...@luminis.nl>.
On 14 Jul 2011, at 23:00 , <jo...@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.
You're pretty much describing the way Apache ACE handles the deployment of bundles (and configuration). They are distributed in a deployment package. Deployment packages are versioned sets of artifacts. Every time you change something in the set of bundles (for that client) its version number is bumped.
> I'd also like to be able to give the client a menu for falling back to a previous version.
The management agent on the client can make that decision (to go back to any previous version in fact). Hooking that up to the UI isn't hard.
Greetings, Marcel
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Managing Dynamism
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 7/14/11 17:00, john.dunlap@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.dunlap@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-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Managing Dynamism
Posted by Christopher BROWN <br...@reflexe.fr>.
Hello,
This is the use case I'm implementing... My first "real" OSGi project is a
web front end for a lightweight ERP platform that bundles a AJAX/JS GUI
framework (the "back office", no OSGi), where the front end (OSGi) runs in a
separate process with an embedded Jetty web server. The front end uses a
templating engine for rendering ad-hoc user interfaces with the ERP platform
used as a data source (with rules, ACL, etc). Templates can be modified in
real time... and code too, hence the choice of OSGi. That's the context of
what I'm doing.
The application is delivered as an executable JAR with Felix in the
classpath and the OSGi bundles are embedded in the JAR (but not in the
default classpath). The executable JAR unpacks the embedded bundles onto
the filesystem, configures Felix in embedded mode, then installs the bundles
(including fragments), starts them (excluding fragments), and sets up a
filewatcher so that changes to the directory are detected and bundles
started as needed (if the client drops in a new custom bundle, it
auto-starts, the client can also drop in hotfix upgrades).
These design goals, which seem similar to yours, work well with Felix. The
aim is to have everything (code & UI) fully dynamic, i.e.: the application
shouldn't ever need to be fully stopped, including patches, minor upgrades,
and possibly major ones too, as well as adding/updating/replacing plugins.
A bit more detail which may be helpful: all installed bundles are INSTALLED
in the framework sense, but then a little extra logic is applied: only the
most recent version of a bundle is explicitly STARTED (the others may be
started implicity if required, but this can create class space divisions).
Also, the filewatcher notifies removal of bundles, triggering stopping of
the bundles within the framework. As soon as a bundle is added again, the
host application tries to start any "required" bundles that were knocked
offline by a previous change (because deleting then replacing a bundle -- as
opposed to a one-step upgrade -- can take others offline, and there's no
automatic restart logic in this case). The host application requests
PackageAdmin->refresh as required to re-wire stuff.
For info, about filewatching, I use a little abstraction layer, which (when
possible) uses JXFileWatcher, falling back to a polling technique, and
capable of delegating to Java 7 filewatching at some point. The
filewatching/update logic is in the host application because JXFileWatcher
binds to a native library using JNI (so loadLibrary doesn't play nice with
bundle restarts if I implement in a bundle) and because we'd get stuck if
the "system update watcher" bundle got stopped unintentionally.
This works for me. I have a suspicion OSGi start levels could be of some
use here too, I haven't looked into that much however. Hope the details
(without naming products!) are helpful.
Just for the bonus: the container is also useful in unit testing: each
bundle gets tested in the framework in isolation, using another mock bundle
and a test fragment that attaches to the bundle being tested, in the same
package. Getting JUnit to play nice was a bit tricky though, especially
creating test instances with access to the bundle context. It's doable
though, without hacking JUnit...
--
Christopher
On 14 July 2011 23:00, <jo...@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.
Re: Managing Dynamism
Posted by jo...@exceter.com.
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.
Quoting "Richard S. Hall" <he...@ungoverned.org>:
> On 7/14/11 13:33, john.dunlap@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-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Managing Dynamism
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 7/14/11 13:33, john.dunlap@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-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org