You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ace.apache.org by Carsten Ziegeler <cz...@apache.org> on 2011/11/24 08:54:58 UTC
Using the Sling OSGi Installer?
Hi,
I'm wondering what the general opinion about using the Sling OSGi
installer in ACE is?
The installer is not tied to Sling it just happens that we have
developed it as part of the project. It's a general purpose installer
which ootb is able to handle bundles and configurations like
FileInstall. The main difference is that we separated the actual
handling of the artifacts from the providers. So the installer itself
is handling installation, update, and removal of artifacts and there
are different plugins providing those artifacts.
One of these plugins is a file provider (which basically works like
FileInstall), another one (different bundle) reads artifacts from a
JCR repository and so on.
In addition, the installer handles retries, keeps state of what it did
install and detects if a user did some manual changes. For example,
you install bundle A in version 1.0 through the installer, the user
updates this bundle to version 1.1 through the web console. Now you
remove the 1.0 artifact from the directory. In this case, the 1.1
version should still be active and not be uninstalled. And so on.
Oh, and like with FileInstall it's possible to add support for other
artifact types. For example we have support for deployment packages
etc.
Just a rough description :)
So, in general, WDYT?
Regards
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: Using the Sling OSGi Installer?
Posted by Bram de Kruijff <bd...@gmail.com>.
Hi Carsten,
On Thu, Nov 24, 2011 at 11:11 AM, Carsten Ziegeler <cz...@apache.org> wrote:
> Hi Bram,
>
> no it doesn't support that ootb - actually I saw your bug and that
> reminded me of proposing the Sling Installer here (I wanted to do this
> for a long time)....
>
> Implementing such an handler for the Sling installer should be easy,
> though it requires to implement two service interfaces: the first one
> detects the artifact type, the second one does the actual action. We
> split this up to be able to add special handling of a certain artifact
> type without requiring to reimplement the detection logic.
Cool, I'll look into that when I have some time to spare. Taking that
of this thread to keep it on your topic :)
Thanks,
Bram
> Regards
> Carsten
>
> 2011/11/24 Bram de Kruijff <bd...@gmail.com>:
>> Hi Carsten,
>>
>>> I'm wondering what the general opinion about using the Sling OSGi
>>> installer in ACE is?
>>
>> does it support metatype (out of the box)? If so, I'll have a look at
>> it for amdatu as well :) We just created an artifacthandler for
>> fileinstall and submitted it to felix, but no sure if it will make it
>> there.. (https://issues.apache.org/jira/browse/FELIX-3241)
>>
>> grz
>> Bram
>>
>> On Thu, Nov 24, 2011 at 8:54 AM, Carsten Ziegeler <cz...@apache.org> wrote:
>>> Hi,
>>>
>>> I'm wondering what the general opinion about using the Sling OSGi
>>> installer in ACE is?
>>>
>>> The installer is not tied to Sling it just happens that we have
>>> developed it as part of the project. It's a general purpose installer
>>> which ootb is able to handle bundles and configurations like
>>> FileInstall. The main difference is that we separated the actual
>>> handling of the artifacts from the providers. So the installer itself
>>> is handling installation, update, and removal of artifacts and there
>>> are different plugins providing those artifacts.
>>> One of these plugins is a file provider (which basically works like
>>> FileInstall), another one (different bundle) reads artifacts from a
>>> JCR repository and so on.
>>>
>>> In addition, the installer handles retries, keeps state of what it did
>>> install and detects if a user did some manual changes. For example,
>>> you install bundle A in version 1.0 through the installer, the user
>>> updates this bundle to version 1.1 through the web console. Now you
>>> remove the 1.0 artifact from the directory. In this case, the 1.1
>>> version should still be active and not be uninstalled. And so on.
>>>
>>> Oh, and like with FileInstall it's possible to add support for other
>>> artifact types. For example we have support for deployment packages
>>> etc.
>>>
>>> Just a rough description :)
>>>
>>> So, in general, WDYT?
>>>
>>> Regards
>>> Carsten
>>> --
>>> Carsten Ziegeler
>>> cziegeler@apache.org
>>>
>>
>
>
>
> --
> Carsten Ziegeler
> cziegeler@apache.org
>
Re: Using the Sling OSGi Installer?
Posted by Carsten Ziegeler <cz...@apache.org>.
Hi Bram,
no it doesn't support that ootb - actually I saw your bug and that
reminded me of proposing the Sling Installer here (I wanted to do this
for a long time)....
Implementing such an handler for the Sling installer should be easy,
though it requires to implement two service interfaces: the first one
detects the artifact type, the second one does the actual action. We
split this up to be able to add special handling of a certain artifact
type without requiring to reimplement the detection logic.
Regards
Carsten
2011/11/24 Bram de Kruijff <bd...@gmail.com>:
> Hi Carsten,
>
>> I'm wondering what the general opinion about using the Sling OSGi
>> installer in ACE is?
>
> does it support metatype (out of the box)? If so, I'll have a look at
> it for amdatu as well :) We just created an artifacthandler for
> fileinstall and submitted it to felix, but no sure if it will make it
> there.. (https://issues.apache.org/jira/browse/FELIX-3241)
>
> grz
> Bram
>
> On Thu, Nov 24, 2011 at 8:54 AM, Carsten Ziegeler <cz...@apache.org> wrote:
>> Hi,
>>
>> I'm wondering what the general opinion about using the Sling OSGi
>> installer in ACE is?
>>
>> The installer is not tied to Sling it just happens that we have
>> developed it as part of the project. It's a general purpose installer
>> which ootb is able to handle bundles and configurations like
>> FileInstall. The main difference is that we separated the actual
>> handling of the artifacts from the providers. So the installer itself
>> is handling installation, update, and removal of artifacts and there
>> are different plugins providing those artifacts.
>> One of these plugins is a file provider (which basically works like
>> FileInstall), another one (different bundle) reads artifacts from a
>> JCR repository and so on.
>>
>> In addition, the installer handles retries, keeps state of what it did
>> install and detects if a user did some manual changes. For example,
>> you install bundle A in version 1.0 through the installer, the user
>> updates this bundle to version 1.1 through the web console. Now you
>> remove the 1.0 artifact from the directory. In this case, the 1.1
>> version should still be active and not be uninstalled. And so on.
>>
>> Oh, and like with FileInstall it's possible to add support for other
>> artifact types. For example we have support for deployment packages
>> etc.
>>
>> Just a rough description :)
>>
>> So, in general, WDYT?
>>
>> Regards
>> Carsten
>> --
>> Carsten Ziegeler
>> cziegeler@apache.org
>>
>
--
Carsten Ziegeler
cziegeler@apache.org
Re: Using the Sling OSGi Installer?
Posted by Bram de Kruijff <bd...@gmail.com>.
Hi Carsten,
> I'm wondering what the general opinion about using the Sling OSGi
> installer in ACE is?
does it support metatype (out of the box)? If so, I'll have a look at
it for amdatu as well :) We just created an artifacthandler for
fileinstall and submitted it to felix, but no sure if it will make it
there.. (https://issues.apache.org/jira/browse/FELIX-3241)
grz
Bram
On Thu, Nov 24, 2011 at 8:54 AM, Carsten Ziegeler <cz...@apache.org> wrote:
> Hi,
>
> I'm wondering what the general opinion about using the Sling OSGi
> installer in ACE is?
>
> The installer is not tied to Sling it just happens that we have
> developed it as part of the project. It's a general purpose installer
> which ootb is able to handle bundles and configurations like
> FileInstall. The main difference is that we separated the actual
> handling of the artifacts from the providers. So the installer itself
> is handling installation, update, and removal of artifacts and there
> are different plugins providing those artifacts.
> One of these plugins is a file provider (which basically works like
> FileInstall), another one (different bundle) reads artifacts from a
> JCR repository and so on.
>
> In addition, the installer handles retries, keeps state of what it did
> install and detects if a user did some manual changes. For example,
> you install bundle A in version 1.0 through the installer, the user
> updates this bundle to version 1.1 through the web console. Now you
> remove the 1.0 artifact from the directory. In this case, the 1.1
> version should still be active and not be uninstalled. And so on.
>
> Oh, and like with FileInstall it's possible to add support for other
> artifact types. For example we have support for deployment packages
> etc.
>
> Just a rough description :)
>
> So, in general, WDYT?
>
> Regards
> Carsten
> --
> Carsten Ziegeler
> cziegeler@apache.org
>
Re: Using the Sling OSGi Installer?
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Thu, Nov 24, 2011 at 12:17 PM, Marcel Offermans
<ma...@luminis.nl> wrote:
>> On Thu, Nov 24, 2011 at 8:54 AM, Carsten Ziegeler <cz...@apache.org> wrote:
>>> ...Oh, and like with FileInstall it's possible to add support for other
>>> artifact types. For example we have support for deployment packages
>>> etc.
>
> 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)...
Yes they are under
http://svn.apache.org/repos/asf/sling/trunk/installer/ in "providers".
As a Sling committer, I would support giving committers from other
OSGi-related ASF projects commit access to that tree, with a "please
ask before breaking stuff" policy, so that we could contribute on
improving the installer there (or move that code to Felix and make
that happen there with the same policy).
-Bertrand
Re: Using the Sling OSGi Installer?
Posted by Carsten Ziegeler <cz...@apache.org>.
2011/11/28 Marcel Offermans <ma...@luminis.nl>:
>>> 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).
>> Yepp, when it comes to bundles, the Sling installer does not allow to
>> install the same bundle in different versions (based on the symbolic
>> name of the bundle)
>
> Out of interest, did you ever run into issues with this in practice?
>
We had one problem recently with commons lang version 2.x and 3.x
which both use the same symbolic name but export completely different
packages - so this is one of the rare cases where it makes sense to
have them both available at the same time. However, we more had the
feeling that the 3.x version should use a different symbolic name :)
We ended up re-packaging one of them.
Apart from that we never really had the need to have different
versions runnin in parallel.
Regards
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: Using the Sling OSGi Installer?
Posted by Marcel Offermans <ma...@luminis.nl>.
On Nov 28, 2011, at 16:35 PM, Carsten Ziegeler wrote:
> 2011/11/27 Marcel Offermans <ma...@luminis.nl>:
>>
>> 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.
>
> Yes, that's a basic difference - but as long as you're using
> deployment packages with the Sling installer, you're fine. So your
> deployment package contains bundles A, B and C and if installation of
> B fails, the deployment package installation is stopped/rolled back.
True!
> The only difference is, Sling tries to reinstall the deployment
> package.
Actually, I forgot to explicitly mention that, but the default behavior of the ACE management agent is the same, it will periodically keep retrying.
> If you're using single bundles which are installed directly, you're right.
>
>> 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).
> Yepp, when it comes to bundles, the Sling installer does not allow to
> install the same bundle in different versions (based on the symbolic
> name of the bundle)
Out of interest, did you ever run into issues with this in practice?
Greetings, Marcel
Re: Using the Sling OSGi Installer?
Posted by Carsten Ziegeler <cz...@apache.org>.
Hi,
2011/11/27 Marcel Offermans <ma...@luminis.nl>:
>
> 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.
>
Yes, that's a basic difference - but as long as you're using
deployment packages with the Sling installer, you're fine. So your
deployment package contains bundles A, B and C and if installation of
B fails, the deployment package installation is stopped/rolled back.
The only difference is, Sling tries to reinstall the deployment
package.
If you're using single bundles which are installed directly, you're right.
> 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).
Yepp, when it comes to bundles, the Sling installer does not allow to
install the same bundle in different versions (based on the symbolic
name of the bundle)
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: Using the Sling OSGi Installer?
Posted by Marcel Offermans <ma...@luminis.nl>.
On Nov 27, 2011, at 11:50 AM, Carsten Ziegeler wrote:
> 2011/11/24 Marcel Offermans <ma...@luminis.nl>:
>> 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 installer.
> 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:
http://server:8080/deployment/target-id/versions
This will return a list of versions like this:
1.0.0
2.0.0
3.0.0
The default strategy is to always get the latest version:
http://server:8080/deployment/target-id/versions/3.0.0
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
Re: Using the Sling OSGi Installer?
Posted by Carsten Ziegeler <cz...@apache.org>.
2011/11/24 Marcel Offermans <ma...@luminis.nl>:
> 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 installer.
Yes
>
> 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? 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.
>
> 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.
>
> 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?
>
> 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.
Regards
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: Using the Sling OSGi Installer?
Posted by Marcel Offermans <ma...@luminis.nl>.
On Nov 24, 2011, at 10:05 AM, Karl Pauls wrote:
> I like the idea. I think Marcel added a new endpoint anyways which
> allows to hook other kind of provisioning mechanisms (we use it to
> create pojosr jars - a single jar that runs a bunch of bundles and
> configurations without the need to create any files on disc and
> skipping classloader magic). That might be already what is needed to
> use the sling osgi installer .... Marrs?
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 installer.
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.
Some further comments and questions in-line below:
> On Thu, Nov 24, 2011 at 8:54 AM, Carsten Ziegeler <cz...@apache.org> wrote:
>> I'm wondering what the general opinion about using the Sling OSGi
>> installer in ACE is?
In general, let's explore this!
>> The installer is not tied to Sling it just happens that we have
>> developed it as part of the project. It's a general purpose installer
>> which ootb is able to handle bundles and configurations like
>> FileInstall. The main difference is that we separated the actual
>> handling of the artifacts from the providers. So the installer itself
>> is handling installation, update, and removal of artifacts and there
>> are different plugins providing those artifacts.
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?
>> One of these plugins is a file provider (which basically works like
>> FileInstall), another one (different bundle) reads artifacts from a
>> JCR repository and so on.
Ok.
>> In addition, the installer handles retries, keeps state of what it did
>> install and detects if a user did some manual changes. For example,
>> you install bundle A in version 1.0 through the installer, the user
>> updates this bundle to version 1.1 through the web console. Now you
>> remove the 1.0 artifact from the directory. In this case, the 1.1
>> version should still be active and not be uninstalled. And so on.
Interesting. Does that mean that manual changes are always preserved, and override automatic updates? Does this also mean that, like with deployment packages, you can only install one single version of a bundle A at a time?
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).
>> Oh, and like with FileInstall it's possible to add support for other
>> artifact types. For example we have support for deployment packages
>> etc.
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).
Greetings, Marcel
Re: Using the Sling OSGi Installer?
Posted by Karl Pauls <ka...@gmail.com>.
I like the idea. I think Marcel added a new endpoint anyways which
allows to hook other kind of provisioning mechanisms (we use it to
create pojosr jars - a single jar that runs a bunch of bundles and
configurations without the need to create any files on disc and
skipping classloader magic). That might be already what is needed to
use the sling osgi installer .... Marrs?
regards,
Karl
On Thu, Nov 24, 2011 at 8:54 AM, Carsten Ziegeler <cz...@apache.org> wrote:
> Hi,
>
> I'm wondering what the general opinion about using the Sling OSGi
> installer in ACE is?
>
> The installer is not tied to Sling it just happens that we have
> developed it as part of the project. It's a general purpose installer
> which ootb is able to handle bundles and configurations like
> FileInstall. The main difference is that we separated the actual
> handling of the artifacts from the providers. So the installer itself
> is handling installation, update, and removal of artifacts and there
> are different plugins providing those artifacts.
> One of these plugins is a file provider (which basically works like
> FileInstall), another one (different bundle) reads artifacts from a
> JCR repository and so on.
>
> In addition, the installer handles retries, keeps state of what it did
> install and detects if a user did some manual changes. For example,
> you install bundle A in version 1.0 through the installer, the user
> updates this bundle to version 1.1 through the web console. Now you
> remove the 1.0 artifact from the directory. In this case, the 1.1
> version should still be active and not be uninstalled. And so on.
>
> Oh, and like with FileInstall it's possible to add support for other
> artifact types. For example we have support for deployment packages
> etc.
>
> Just a rough description :)
>
> So, in general, WDYT?
>
> Regards
> Carsten
> --
> Carsten Ziegeler
> cziegeler@apache.org
>
--
Karl Pauls
karlpauls@gmail.com
http://twitter.com/karlpauls
http://www.linkedin.com/in/karlpauls
https://profiles.google.com/karlpauls