On 07.05.2009, at 18:36, Marcel Offermans
<marcel.offerm...@luminis.nl> wrote:
On May 7, 2009, at 18:14 , Guillaume Nodet wrote:
So you quite end up with a single deployment package for a given
container which is updated when you want to deploy something else.
Though it works, I don't really see the benefit of the deployment
admin (it kinda becomes an implementation detail) ...
There are a couple of benefits:
a) It gives you transactional updates, ensuring that if bundle 3 out
of 5 fails, all bundles that had already been installed are rolled
back.
b) It's extensible, so you can update not only bundles, but also
configuration data and just about anything else you and have that be
included in the same transaction.
c) It's an OSGi standard.
There are a couple of other features that might be of use, such as
the ability to sign the whole package to ensure nobody tampers with
it.
The other
problem is that you need to exactly control the state of the
framework
in order to make any deployment, so that the same "application" can
not be easily deployed onto multiple containers.
Exactly controlling the state of each framework is precisely what
you want when centrally managing and provisioning targets. You can
even turn your argument around and state that not exactly knowing
the state of a framework when deploying is the problem.
You could also say that ace on the target device is what best is known
as management agent provisioned by the initial provisioning service.
So its not best in being an "opt-in" service you install occasionally.
Thats just what i saw from ace so far while waiting for the asl
licensed code drop.. ;)
Toni
Ace has other ways of "grouping" bundles into features and assigning
those to targets, so for the user, there are simple ways to deploy
an "application" or "feature" to multiple containers. It's only
internally that this gets converted to a single deployment package.
In that sense you could indeed argue that this is just an
implementation detail, but one that comes with the benefits that
deployment admin brings (which would otherwise have to be developed
in some non-standard way).
Greetings, Marcel
---------------------------------------------------------------------
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
