You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Carsten Ziegeler <cz...@apache.org> on 2010/06/14 17:06:16 UTC
Adding support to handle configurations to launchpad
Hi,
I'm currently investigating how to add support for configurations to the
launchpad. Currently it is only possible to provision bundles, but I
have the need for configurations as well.
My first approach was to replace our code with FileInstall from the
Felix project. But it seems that we would hit several problems with that
(it really only supports the file system, has no start level support etc.)
So, my basic idea is to search for "*.cfg" files in the same dirs as we
are searching for bundles in, and then add the found configs to the
config admin. The question is how/if to update. I think adding the
configs on the first start only and then forget about them is fine for
my use cases (maybe we could add a force install option) This would not
cover the case of updating a config or even removing a config through
this way.
WDYT?
Regards
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: Adding support to handle configurations to launchpad
Posted by Justin Edelson <ju...@gmail.com>.
One other thought - perhaps launchpad should expose the
ResourceProvider as a service (using what interface I am not sure).
This would allow a config file processing component to get access to
the files and also potentially help with the JR config file problem as
well - without adding a bunch of logic to Launchpad (which I think we
all want to keep light).
WDYT?
Justin
On Jun 15, 2010, at 1:45 AM, Carsten Ziegeler <cz...@apache.org>
wrote:
> Hi,
>
> Justin Edelson wrote
>>
>> Other than configuring the embedded Jackrabbit server, couldn't you
>> use
>> jcrinstall for this?
> jcrinstall is nice if you have a somehow running system and a
> repository. In my use cases I don't even have a repository but I'm
> using
> launchpad to start my OSGi app :)
>
>
>> I agree that updating is tricky, but there might be a way of handling
>> this with a ConfigurationListener, i.e. if you could remember which
>> configuration had been modified/removed by something else, you could
>> modify how to handle the embedded files.
>>
>> <boot>
>> 1) load com.foo.cfg from launchpad archive and create a Configuration
>> object based upon it.
>> 2) someone modifies PID com.foo via webconsole
>> 3) ConfigurationEvent fired with type = CM_UPDATED, PID=com.foo
>> 4) Launchpad stores this PID in a list somewhere
>>
>> <boot>
>> 4) when com.foo.cfg is loaded, its PID is compared against the list
>> of
>> updated PIDs. It is contained in that list, so it is ignored.
>>
>> In other words, once someone else modifies/removes the configuration,
>> the "launchpad configuration loader" will ignore that file going
>> forward.
> Yes, something along those lines would work - but I'm not sure if one
> really needs this :)
>
>> I have no idea on how you could support removing a configuration.
>> Then
>> again, it isn't like launchpad supports removing bundles :)
> :)
>
> Carsten
>
> --
> Carsten Ziegeler
> cziegeler@apache.org
Re: Adding support to handle configurations to launchpad
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,
On Tue, Jun 15, 2010 at 7:45 AM, Carsten Ziegeler <cz...@apache.org> wrote:
>> ...Other than configuring the embedded Jackrabbit server, couldn't you use
>> jcrinstall for this?
> jcrinstall is nice if you have a somehow running system and a
> repository. In my use cases I don't even have a repository but I'm using
> launchpad to start my OSGi app :)...
You should be able to use the osgi controller part of jcrinstall only,
that doesn't require a repository (it has very minimal dependencies
actually) and the API is very simple.
The interface and class found in the o.a.s.osgi.installer package [1]
are the API to that module.
To create configs, you'd just need to use the
InstallableResource(String url, Dictionary<String, Object> d)
constructor to define a config, and OsgiInstaller.registerResources or
OsgiInstaller. addResource to inject them.
The OSGi controller uses digests computed on the supplied Dictionary
objects to find out if a config has changed and must be updated. There
might be conflicts if you modify the config later via other means, but
solving that would solve it for jcrinstall as well, instead of being a
separate solution.
-Bertrand
[1] http://svn.apache.org/repos/asf/sling/trunk/installer/osgi/installer/src/main/java/org/apache/sling/osgi/installer/
Re: Adding support to handle configurations to launchpad
Posted by Carsten Ziegeler <cz...@apache.org>.
Hi,
Justin Edelson wrote
>
> Other than configuring the embedded Jackrabbit server, couldn't you use
> jcrinstall for this?
jcrinstall is nice if you have a somehow running system and a
repository. In my use cases I don't even have a repository but I'm using
launchpad to start my OSGi app :)
> I agree that updating is tricky, but there might be a way of handling
> this with a ConfigurationListener, i.e. if you could remember which
> configuration had been modified/removed by something else, you could
> modify how to handle the embedded files.
>
> <boot>
> 1) load com.foo.cfg from launchpad archive and create a Configuration
> object based upon it.
> 2) someone modifies PID com.foo via webconsole
> 3) ConfigurationEvent fired with type = CM_UPDATED, PID=com.foo
> 4) Launchpad stores this PID in a list somewhere
>
> <boot>
> 4) when com.foo.cfg is loaded, its PID is compared against the list of
> updated PIDs. It is contained in that list, so it is ignored.
>
> In other words, once someone else modifies/removes the configuration,
> the "launchpad configuration loader" will ignore that file going forward.
Yes, something along those lines would work - but I'm not sure if one
really needs this :)
> I have no idea on how you could support removing a configuration. Then
> again, it isn't like launchpad supports removing bundles :)
:)
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: Adding support to handle configurations to launchpad
Posted by Mike Moulton <mi...@meltmedia.com>.
Another use for configuration support in launchpad is in the generation of the Karaf / ServiceMix feature file. This could allow custom <config /> blocks to be inserted into the feature file.
-- Mike
On Jun 14, 2010, at 8:24 AM, Justin Edelson wrote:
> On 6/14/10 11:06 AM, Carsten Ziegeler wrote:
>> Hi,
>>
>> I'm currently investigating how to add support for configurations to the
>> launchpad. Currently it is only possible to provision bundles, but I
>> have the need for configurations as well.
>>
>> My first approach was to replace our code with FileInstall from the
>> Felix project. But it seems that we would hit several problems with that
>> (it really only supports the file system, has no start level support etc.)
>>
>> So, my basic idea is to search for "*.cfg" files in the same dirs as we
>> are searching for bundles in, and then add the found configs to the
>> config admin. The question is how/if to update. I think adding the
>> configs on the first start only and then forget about them is fine for
>> my use cases (maybe we could add a force install option) This would not
>> cover the case of updating a config or even removing a config through
>> this way.
>>
>> WDYT?
>>
>> Regards
>> Carsten
>
> Other than configuring the embedded Jackrabbit server, couldn't you use
> jcrinstall for this?
>
> I agree that updating is tricky, but there might be a way of handling
> this with a ConfigurationListener, i.e. if you could remember which
> configuration had been modified/removed by something else, you could
> modify how to handle the embedded files.
>
> <boot>
> 1) load com.foo.cfg from launchpad archive and create a Configuration
> object based upon it.
> 2) someone modifies PID com.foo via webconsole
> 3) ConfigurationEvent fired with type = CM_UPDATED, PID=com.foo
> 4) Launchpad stores this PID in a list somewhere
>
> <boot>
> 4) when com.foo.cfg is loaded, its PID is compared against the list of
> updated PIDs. It is contained in that list, so it is ignored.
>
> In other words, once someone else modifies/removes the configuration,
> the "launchpad configuration loader" will ignore that file going forward.
>
> I have no idea on how you could support removing a configuration. Then
> again, it isn't like launchpad supports removing bundles :)
>
> Justin
Re: Adding support to handle configurations to launchpad
Posted by Justin Edelson <ju...@gmail.com>.
On 6/14/10 11:06 AM, Carsten Ziegeler wrote:
> Hi,
>
> I'm currently investigating how to add support for configurations to the
> launchpad. Currently it is only possible to provision bundles, but I
> have the need for configurations as well.
>
> My first approach was to replace our code with FileInstall from the
> Felix project. But it seems that we would hit several problems with that
> (it really only supports the file system, has no start level support etc.)
>
> So, my basic idea is to search for "*.cfg" files in the same dirs as we
> are searching for bundles in, and then add the found configs to the
> config admin. The question is how/if to update. I think adding the
> configs on the first start only and then forget about them is fine for
> my use cases (maybe we could add a force install option) This would not
> cover the case of updating a config or even removing a config through
> this way.
>
> WDYT?
>
> Regards
> Carsten
Other than configuring the embedded Jackrabbit server, couldn't you use
jcrinstall for this?
I agree that updating is tricky, but there might be a way of handling
this with a ConfigurationListener, i.e. if you could remember which
configuration had been modified/removed by something else, you could
modify how to handle the embedded files.
<boot>
1) load com.foo.cfg from launchpad archive and create a Configuration
object based upon it.
2) someone modifies PID com.foo via webconsole
3) ConfigurationEvent fired with type = CM_UPDATED, PID=com.foo
4) Launchpad stores this PID in a list somewhere
<boot>
4) when com.foo.cfg is loaded, its PID is compared against the list of
updated PIDs. It is contained in that list, so it is ignored.
In other words, once someone else modifies/removes the configuration,
the "launchpad configuration loader" will ignore that file going forward.
I have no idea on how you could support removing a configuration. Then
again, it isn't like launchpad supports removing bundles :)
Justin