ace-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcel Offermans <>
Subject Re: Using the Sling OSGi Installer?
Date Sun, 27 Nov 2011 18:30:22 GMT
On Nov 27, 2011, at 11:50 AM, Carsten Ziegeler wrote:
> 2011/11/24 Marcel Offermans <>:
>> Let me start by explaining this in a bit more detail (while I'm trying to understand
exactly how the Sling installer works):
>> At a high level, ACE consists of a server and a management agent running within the
target OSGi container. The management agent first asks the server about available versions
of the software, and if there's something new, the next request it sends is to actually get
this new version.
>> The response from the server now by default is a Deployment Package that either contains
the delta of artifacts between two versions, or a full set of artifacts. Within that deployment
package, artifacts have a type, and for all non-bundle types, a resource processor is also
shipped as part of the package.
>> On the server side we have a mechanism now that allows us to literally "post process"
that deployment package and transform it into something else. Like Karl says, we've used that
to create PojoSR JAR files (just as a proof of concept for now) but that shows we can do all
kinds of transformations on them.
>> I can see a couple of ways to integrate the Sling installer into ACE:
>> 1) You state that the Sling installer already supports Deployment Packages. That
actually means that it could just fetch one from the ACE server and install it. That sounds
like the easiest solution and would probably require only very little modifications to the
> Yes

Cool, writing a small extension to the Sling installer so it fetches a deployment package
from an ACE server is fairly trivial. Summarizing what the management agent does, assuming
it has the unique ID called "target-id" it will query the server for a list of versions available
for itself:


This will return a list of versions like this:


The default strategy is to always get the latest version:


This will return a deployment package which can be installed. That's all there is to it. :)

>> 2) Create a post processor that transforms a deployment package into something else
that is more suitable for the Sling installer, and have that installer "fetch" that something
and install it. We now fetch everything in one go, so I'm not sure how that would map.
>> 3) Create a post procesor that transforms a deployment package into a fully self-contained
installer that contains both the installer itself and the actual set of artifacts (this would
be similar to our PojoSR experiment). It does not necessarily cater for updates this way,
but it would be a very convenient way to bootstrap using a single, executable jar file.
> I'm not sure if I can follow you for the last two points :)  I haven't
> looked at latest ACE yet, but my understanding was that it's possible
> to deploy other artifacts than deployment packages (at least in theory
> maybe). So are you saying, these are always transferred as deployment
> packages and then transformed into the "correct" artifact on the
> client installing this stuff?

No, I'm saying that can be done on the server side.

A bit of background. Actually you could also, on the server, directly talk to the "deployment
repository" and transmit the artifacts yourself. As it turns out, writing a piece of concurrent
code that allows many concurrent clients to poll for such data is not trivial, which is why
I added a mechanism to post-process the results of that code.

> This would be possible with the Sling
> installer as well as we have the concept of transformers. If something
> else is than a deployment package is transferred this can be directly
> installed by a plugin.

It can be transformed into something else, as long as it remains one single stream for all
artifacts (well, in theory, even that could be changed, but not easily).

>> Conceptually, this is very close to what the ACE management agent does, with perhaps
the difference that we use Deployment Admin as the basis and that that spec defines a single
package that contains both the artifacts and the handlers. On the target side, we send artifacts
to handlers as well to physically install them, and this is done in the context of a session
or transaction that also supports rollback.
>> Having the Sling installer as an "alternative" management agent sounds like something
we should look at supporting.
>> We could even look at if we can bridge the Sling handlers to/from Resource Processors
to/from File Install plugins. However, I know that at least File Install does not know how
to deal with sessions/transactions and rollback changes if something went wrong. How is that
for the Sling handlers?
> We don't have a rollback mechanism but a retry - so the basic idea is
> - if something is about to be installed, it really should be tried as
> hard as possible. So if an install fails, the installer retries it,
> after something else has been installed. So for example, if a bundle
> is missing during the first try, and this one gets installed later,
> the installer retries and everything is fine.
> On the other hand, the Sling installer is able to do a rollback if the
> artifact disappears from the provider.

I guess this is a difference between ACE (or rather deployment packages) and the Sling installer.
If you have an application installed and there is an update for bundles A, B and C (and we
assume there is a bug in B) then ACE will:

Start a transaction, install A, install B, discover that that fails and rollback B and A to
end up in the original situation again.

And from what I understand, Sling will:

Install A, install B, discover that that fails, install C, and then keeps retrying B.

My concern is that probably, with only A and C installed, the overall application will not
work that well, whereas if you roll all changes back, the chances of ending up with an application
that works are a lot better.

>> Interesting. Does that mean that manual changes are always preserved, and override
automatic updates?
> Yes.
>> Does this also mean that, like with deployment packages, you can only install one
single version of a bundle A at a time?
> Yes.
>> In the context of ACE and Karaf features, we ran into an issue that for example,
if you have an installation that includes bundles:
>>  * A 1.0
>>  * A 1.1
>> and you then create a new version that contains:
>> * A 2.0
>> * A 2.1
>> that you cannot detemine which is an update of which. OSGi simply does not provide
enough metadata for that. For now we have no solution for that yet (Karaf simply does not
support updates at all, but to me that is not acceptable since that means loosing your bundle
data area).
> These are packages containing the same bundle in different versions?

Yes. As soon as you allow more than one version of a bundle to be installed at the same time,
you end up with problems because you cannot identify in the case of an update, which is an
update of which. This, in my opinion, is a "bug" in the OSGi specification, especially now
that the 4.3 spec will even allow you to install the same version multiple times. Luckily,
in real life, this situation rarely occurs (appearantly).

>> Are those plugins for File Install part of Sling? I am wondering where we should
collect them (in the context of Bram's mail about his contribution to Felix).
> Right now we have everything in the Sling SVN. Like Bertrand said, I
> see no problem in giving others commit for Sling to work on this. We
> could also move the installer to Felix or somewhere else.

Ok. Let's see if anybody at Felix reacts to the plugin Bram donated. If not, it might make
sense to add it to Sling's collection, even though ultimately, Felix sounds like the appropriate
location for this collection.

Greetings, Marcel

View raw message