Re: Failing Installer test (was Re: ConfigAdmin support in Launchpad...)
Justin Edelson wrote
On Wed, Aug 18, 2010 at 1:38 PM, Justin Edelson justinedel...@gmail.com
wrote:
I fixed the ConfigInstallTest failure in the osgi.it module. Not sure if
this is the one which has been failing for a long time.
Great! Thanks Justin.
The problem is in the waitForConfiguration method of OsgiInstallerTestBase.
The logic was:
if (result != null ||!shouldBePresent) {
break;
}
but this fails to take into account when we want result to be null. As
such, the sleep was never happening.
After this fix, I did get another test failure due to an
IllegalStateException. It seems that this happens if a Configuration is
deleted between the time ConfigurationAdmin.listConfigurations(null) and
cfg.getPid() are called (in the findConfiguration method). I think the
only way to avoid this is to increase the sleep time between
configuration checks from 25 ms to 250 ms.
I went another way and am catching the IllegalStateException.
Carsten - what's the other IT you see fail consistently?
Still, the ConfigInstallTest.testDeferredConfigInstall is failing for
me: Expected ConfigurationAdmin to be absent expected:false but was:true
Everything else passes now.
Is it RemovedResourceDetectionTest? I saw that fail twice now, but
haven't been able to reproduce it either while debugging or with
pax.exam.log.level=DEBUG.
Yes, this failed for me once but then never again. Maybe this is a
timing problem.
Regards
Carsten
--
Carsten Ziegeler
cziege...@apache.org
Re: Failing Installer test (was Re: ConfigAdmin support in Launchpad...)
Justin Edelson wrote I think I identified the JCRInstall problem. See https://issues.apache.org/jira/browse/JCR-2720 Ah, yes, this could be the problem. Working around this in the test shouldn't be hard, but it's a nasty bug. We could also revert back to the older sling testing module with jackrabbit 1.x as a workaround. It would just require to readd the events helper class. Carsten -- Carsten Ziegeler cziege...@apache.org
Re: ConfigAdmin support in Launchpad...
Hi,
On 17.08.2010 21:51, Justin Edelson wrote:
On 8/17/10 4:20 PM, Felix Meschberger wrote:
Hi,
Sounds like an interesting approach, too.
I would really like to include the OSGi Install stuff together with
this ResourceProvider and the new File Installer to be included with
Sling 6. If we go the route as Justin proposed, we would probably have
to include File Installer configured to the ${sling.home}/startup
location to support existing use cases depending on the startup folder
being used to install bundles.
What is this new File Installer of which you speak? Is this Felix's
FileInstall or extracting BootstrapInstaller from launchpad.base and
into this new launchpad.installer bundle (or something else).
This is a new functionality built by Carsten in his efforts to support
configurations in the launchpad. The idea is to scan one or more
directories handing over found data to OSGi Install. As such it is the
Filesystem based counter-part to the JCR Install bundle and your
Launchpad Resource support.
I was thinking about this some more, and if getting osgi.installer ready
for Sling 6 is really a problem, perhaps launchpad.installer can simply
include a limited subset of functionality. So much of osgi.installer
seems to be about keeping resource lists and monitoring them whereas all
launchpad.installer needs is to do this for configs (plus some extra
code for handling factory pids):
String pid = createPid(path)
Dictionary dict = parseDictionary(stream);
if (!configExists(pid)) {
createConfig(pid, dict)
}
And for bundles, we already have all the code we need in
BootstrapInstaller, so moving that logic into a separate bundle should
be straight forward enough.
I am not particularly keen on putting too much effort into something
which will be thrown almost immediately.
Rather I would suggest for Carsten to indicate whether he will succeed
in-time for Sling 6 or whether we can be of any help to him getting this
ready for Sling 6.
But before we can do this, I apparently need to convince everyone of two
things:
1) There is no harm in doing all of our should I install/upgrade this
bundle checks on every startup of launchpad.
I can live with that. In fact, IIRC JCR Install already does this on
every bundle reastart.
2) There is no harm in installing/upgrading bundles directly from
(Launchpad) ResourceProvider.
We had this before we started copying bundles into the startup folder.
So this is perfectly ok for me -- provided we still support the startup
folder for extra deployment (as used by Sakai IIRC).
If we can agree on these, the implementation of bundle installation
within launchpad.installer will be a lot simpler.
Regarding the name: Yes, the ResourceProvider in the launchpad/base is
older than the ResourceProvider in the Resource API. But, this older
ResourceProvider has always been an internal API of the launchpad/base
module thus renaming it to prevent the name collision is a good idea.
Maybe something intelligent as LaunchpadResourceAccessor ;-)
Honestly, I am not sooo good at finding good names
My initial suggestion was going to be LaunchpadContentProvider, which
I dismissed because I didn't think Launchpad belonged in the name...
On the other hand, the content or resources is/are really provided form
inside the launchpad package (either the standalone jar or the web
application or even the launchpad plugin).
I could live well with LaunchpadContentProvider.
Regards
Felix
Justin
Regards
Felix
On 8/17/10, Justin Edelson justinedel...@gmail.com wrote:
As I mentioned last week, I had some concerns about using FileInstall
for ConfigAdmin support and, more than concerns about FileInstall in
particular, I didn't like the whole approach within Launchpad of
copying some files out of the JAR/WAR and didn't want to see us
continue this pattern.
I worked out a solution to this today and I'm pretty happy with it.
In short... Launchpad exposes a service which allows bundles/services
within the framework to access the contents of the launchpad archive (or
project, in the case of the maven-launchpad-plugin) as a virtual file
system.
It is then trivial to create a component which uses this service to
access configuration files and install them via osgi.installer.
The specific steps involved were:
1) Creating a new launchpad.api bundle which contains the
ResourceProvider interface [1]
2) Modifying launchpad.base to use the new ResourceProvider interface,
add it to the list of system packages, and register the service.
3) Modifying maven-launchpad-plugin to use the new ResourceProvider
interface.
4) Creating a new launchpad.installer bundle which contains a Component
referring to the ResourceProvider service and osgi.installer.
The patch can be viewed here: [2]. It looks much bigger than it is due
to all of the internal changes within launchpad.base. There are also two
minor changes in osgi.installer
Re: ConfigAdmin support in Launchpad...
Felix Meschberger wrote I am not particularly keen on putting too much effort into something which will be thrown almost immediately. Rather I would suggest for Carsten to indicate whether he will succeed in-time for Sling 6 or whether we can be of any help to him getting this ready for Sling 6. I think I changed/removed/refactored quiet a lot now and I'm nearly at the point of starting to add missing features and looking for long outstanding bugs/problems. We now have a cleaner api which is nearly ready for a new release. At the moment some test cases are failing in the jcrinstaller (this seems to be caused by upgrading to the latest sling testing module with JCR 2.0 included) and two test cases in the IT module (one of them is failing for a long time, even before my changes, the other one is new). In addition as I refactored the IT tests, there are now some things untested like if the installer is idle after it has done the tasks it should do. This should be done as junit tests inside the installer module. So in short, any help in getting the tests fixed and new tests is really appreciated. I hope to start on the new stuff soon. Regards Carsten But before we can do this, I apparently need to convince everyone of two things: 1) There is no harm in doing all of our should I install/upgrade this bundle checks on every startup of launchpad. I can live with that. In fact, IIRC JCR Install already does this on every bundle reastart. 2) There is no harm in installing/upgrading bundles directly from (Launchpad) ResourceProvider. We had this before we started copying bundles into the startup folder. So this is perfectly ok for me -- provided we still support the startup folder for extra deployment (as used by Sakai IIRC). If we can agree on these, the implementation of bundle installation within launchpad.installer will be a lot simpler. Regarding the name: Yes, the ResourceProvider in the launchpad/base is older than the ResourceProvider in the Resource API. But, this older ResourceProvider has always been an internal API of the launchpad/base module thus renaming it to prevent the name collision is a good idea. Maybe something intelligent as LaunchpadResourceAccessor ;-) Honestly, I am not sooo good at finding good names My initial suggestion was going to be LaunchpadContentProvider, which I dismissed because I didn't think Launchpad belonged in the name... On the other hand, the content or resources is/are really provided form inside the launchpad package (either the standalone jar or the web application or even the launchpad plugin). I could live well with LaunchpadContentProvider. Regards Felix Justin Regards Felix On 8/17/10, Justin Edelson justinedel...@gmail.com wrote: As I mentioned last week, I had some concerns about using FileInstall for ConfigAdmin support and, more than concerns about FileInstall in particular, I didn't like the whole approach within Launchpad of copying some files out of the JAR/WAR and didn't want to see us continue this pattern. I worked out a solution to this today and I'm pretty happy with it. In short... Launchpad exposes a service which allows bundles/services within the framework to access the contents of the launchpad archive (or project, in the case of the maven-launchpad-plugin) as a virtual file system. It is then trivial to create a component which uses this service to access configuration files and install them via osgi.installer. The specific steps involved were: 1) Creating a new launchpad.api bundle which contains the ResourceProvider interface [1] 2) Modifying launchpad.base to use the new ResourceProvider interface, add it to the list of system packages, and register the service. 3) Modifying maven-launchpad-plugin to use the new ResourceProvider interface. 4) Creating a new launchpad.installer bundle which contains a Component referring to the ResourceProvider service and osgi.installer. The patch can be viewed here: [2]. It looks much bigger than it is due to all of the internal changes within launchpad.base. There are also two minor changes in osgi.installer which I think should probably be made regardless. This patch includes a sample cfg file in both launchpad/builder and launchpad/testing. This was done so I could ensure that it worked in war, jar, and launchpad:run scenarios. There needs to be some kind of automated test. Note that in order for this to work properly [3], I had to introduce osgi.installer into the main pom. I'd like to get rid of the separate reactor for installer entirely, but there are still some integration test failures in osgi/it and it looks like Carsten is still working on this module. In any case, going down this path means that osgi.installer will need to be part of Sling 6 (if we want ConfigAdmin to be part of Sling 6, of course). Justin [1] Because ResourceProvider was already used within
Failing Installer test (was Re: ConfigAdmin support in Launchpad...)
I fixed the ConfigInstallTest failure in the osgi.it module. Not sure if
this is the one which has been failing for a long time.
The problem is in the waitForConfiguration method of OsgiInstallerTestBase.
The logic was:
if (result != null ||!shouldBePresent) {
break;
}
but this fails to take into account when we want result to be null. As
such, the sleep was never happening.
After this fix, I did get another test failure due to an
IllegalStateException. It seems that this happens if a Configuration is
deleted between the time ConfigurationAdmin.listConfigurations(null) and
cfg.getPid() are called (in the findConfiguration method). I think the
only way to avoid this is to increase the sleep time between
configuration checks from 25 ms to 250 ms.
Carsten - what's the other IT you see fail consistently?
Justin
On 8/18/10 8:34 AM, Carsten Ziegeler wrote:
Felix Meschberger wrote
I am not particularly keen on putting too much effort into something
which will be thrown almost immediately.
Rather I would suggest for Carsten to indicate whether he will succeed
in-time for Sling 6 or whether we can be of any help to him getting this
ready for Sling 6.
I think I changed/removed/refactored quiet a lot now and I'm nearly at
the point of starting to add missing features and looking for long
outstanding bugs/problems.
We now have a cleaner api which is nearly ready for a new release.
At the moment some test cases are failing in the jcrinstaller (this
seems to be caused by upgrading to the latest sling testing module with
JCR 2.0 included) and two test cases in the IT module (one of them is
failing for a long time, even before my changes, the other one is new).
In addition as I refactored the IT tests, there are now some things
untested like if the installer is idle after it has done the tasks it
should do. This should be done as junit tests inside the installer module.
So in short, any help in getting the tests fixed and new tests is really
appreciated. I hope to start on the new stuff soon.
Regards
Carsten
But before we can do this, I apparently need to convince everyone of two
things:
1) There is no harm in doing all of our should I install/upgrade this
bundle checks on every startup of launchpad.
I can live with that. In fact, IIRC JCR Install already does this on
every bundle reastart.
2) There is no harm in installing/upgrading bundles directly from
(Launchpad) ResourceProvider.
We had this before we started copying bundles into the startup folder.
So this is perfectly ok for me -- provided we still support the startup
folder for extra deployment (as used by Sakai IIRC).
If we can agree on these, the implementation of bundle installation
within launchpad.installer will be a lot simpler.
Regarding the name: Yes, the ResourceProvider in the launchpad/base is
older than the ResourceProvider in the Resource API. But, this older
ResourceProvider has always been an internal API of the launchpad/base
module thus renaming it to prevent the name collision is a good idea.
Maybe something intelligent as LaunchpadResourceAccessor ;-)
Honestly, I am not sooo good at finding good names
My initial suggestion was going to be LaunchpadContentProvider, which
I dismissed because I didn't think Launchpad belonged in the name...
On the other hand, the content or resources is/are really provided form
inside the launchpad package (either the standalone jar or the web
application or even the launchpad plugin).
I could live well with LaunchpadContentProvider.
Regards
Felix
Justin
Regards
Felix
On 8/17/10, Justin Edelson justinedel...@gmail.com wrote:
As I mentioned last week, I had some concerns about using FileInstall
for ConfigAdmin support and, more than concerns about FileInstall in
particular, I didn't like the whole approach within Launchpad of
copying some files out of the JAR/WAR and didn't want to see us
continue this pattern.
I worked out a solution to this today and I'm pretty happy with it.
In short... Launchpad exposes a service which allows bundles/services
within the framework to access the contents of the launchpad archive (or
project, in the case of the maven-launchpad-plugin) as a virtual file
system.
It is then trivial to create a component which uses this service to
access configuration files and install them via osgi.installer.
The specific steps involved were:
1) Creating a new launchpad.api bundle which contains the
ResourceProvider interface [1]
2) Modifying launchpad.base to use the new ResourceProvider interface,
add it to the list of system packages, and register the service.
3) Modifying maven-launchpad-plugin to use the new ResourceProvider
interface.
4) Creating a new launchpad.installer bundle which contains a Component
referring to the ResourceProvider service and osgi.installer.
The patch can be viewed here: [2]. It looks much bigger than it is due
to all of the internal changes
Re: Failing Installer test (was Re: ConfigAdmin support in Launchpad...)
On Wed, Aug 18, 2010 at 1:38 PM, Justin Edelson justinedel...@gmail.com wrote:
I fixed the ConfigInstallTest failure in the osgi.it module. Not sure if
this is the one which has been failing for a long time.
The problem is in the waitForConfiguration method of OsgiInstallerTestBase.
The logic was:
if (result != null ||!shouldBePresent) {
break;
}
but this fails to take into account when we want result to be null. As
such, the sleep was never happening.
After this fix, I did get another test failure due to an
IllegalStateException. It seems that this happens if a Configuration is
deleted between the time ConfigurationAdmin.listConfigurations(null) and
cfg.getPid() are called (in the findConfiguration method). I think the
only way to avoid this is to increase the sleep time between
configuration checks from 25 ms to 250 ms.
I went another way and am catching the IllegalStateException.
Carsten - what's the other IT you see fail consistently?
Is it RemovedResourceDetectionTest? I saw that fail twice now, but
haven't been able to reproduce it either while debugging or with
pax.exam.log.level=DEBUG.
Still, I added some more logging into the even waiting code to see if
this might help trap the problem.
Justin
Justin
On 8/18/10 8:34 AM, Carsten Ziegeler wrote:
Felix Meschberger wrote
I am not particularly keen on putting too much effort into something
which will be thrown almost immediately.
Rather I would suggest for Carsten to indicate whether he will succeed
in-time for Sling 6 or whether we can be of any help to him getting this
ready for Sling 6.
I think I changed/removed/refactored quiet a lot now and I'm nearly at
the point of starting to add missing features and looking for long
outstanding bugs/problems.
We now have a cleaner api which is nearly ready for a new release.
At the moment some test cases are failing in the jcrinstaller (this
seems to be caused by upgrading to the latest sling testing module with
JCR 2.0 included) and two test cases in the IT module (one of them is
failing for a long time, even before my changes, the other one is new).
In addition as I refactored the IT tests, there are now some things
untested like if the installer is idle after it has done the tasks it
should do. This should be done as junit tests inside the installer module.
So in short, any help in getting the tests fixed and new tests is really
appreciated. I hope to start on the new stuff soon.
Regards
Carsten
But before we can do this, I apparently need to convince everyone of two
things:
1) There is no harm in doing all of our should I install/upgrade this
bundle checks on every startup of launchpad.
I can live with that. In fact, IIRC JCR Install already does this on
every bundle reastart.
2) There is no harm in installing/upgrading bundles directly from
(Launchpad) ResourceProvider.
We had this before we started copying bundles into the startup folder.
So this is perfectly ok for me -- provided we still support the startup
folder for extra deployment (as used by Sakai IIRC).
If we can agree on these, the implementation of bundle installation
within launchpad.installer will be a lot simpler.
Regarding the name: Yes, the ResourceProvider in the launchpad/base is
older than the ResourceProvider in the Resource API. But, this older
ResourceProvider has always been an internal API of the launchpad/base
module thus renaming it to prevent the name collision is a good idea.
Maybe something intelligent as LaunchpadResourceAccessor ;-)
Honestly, I am not sooo good at finding good names
My initial suggestion was going to be LaunchpadContentProvider, which
I dismissed because I didn't think Launchpad belonged in the name...
On the other hand, the content or resources is/are really provided form
inside the launchpad package (either the standalone jar or the web
application or even the launchpad plugin).
I could live well with LaunchpadContentProvider.
Regards
Felix
Justin
Regards
Felix
On 8/17/10, Justin Edelson justinedel...@gmail.com wrote:
As I mentioned last week, I had some concerns about using FileInstall
for ConfigAdmin support and, more than concerns about FileInstall in
particular, I didn't like the whole approach within Launchpad of
copying some files out of the JAR/WAR and didn't want to see us
continue this pattern.
I worked out a solution to this today and I'm pretty happy with it.
In short... Launchpad exposes a service which allows bundles/services
within the framework to access the contents of the launchpad archive (or
project, in the case of the maven-launchpad-plugin) as a virtual file
system.
It is then trivial to create a component which uses this service to
access configuration files and install them via osgi.installer.
The specific steps involved were:
1) Creating a new launchpad.api bundle which contains the
ResourceProvider interface [1]
2) Modifying launchpad.base to use
Re: ConfigAdmin support in Launchpad...
updated patchset to remove modifications to osgi.installer: http://codereview.appspot.com/1997042 On Mon, Aug 16, 2010 at 8:44 PM, Justin Edelson justinedel...@gmail.com wrote: As I mentioned last week, I had some concerns about using FileInstall for ConfigAdmin support and, more than concerns about FileInstall in particular, I didn't like the whole approach within Launchpad of copying some files out of the JAR/WAR and didn't want to see us continue this pattern. I worked out a solution to this today and I'm pretty happy with it. In short... Launchpad exposes a service which allows bundles/services within the framework to access the contents of the launchpad archive (or project, in the case of the maven-launchpad-plugin) as a virtual file system. It is then trivial to create a component which uses this service to access configuration files and install them via osgi.installer. The specific steps involved were: 1) Creating a new launchpad.api bundle which contains the ResourceProvider interface [1] 2) Modifying launchpad.base to use the new ResourceProvider interface, add it to the list of system packages, and register the service. 3) Modifying maven-launchpad-plugin to use the new ResourceProvider interface. 4) Creating a new launchpad.installer bundle which contains a Component referring to the ResourceProvider service and osgi.installer. The patch can be viewed here: [2]. It looks much bigger than it is due to all of the internal changes within launchpad.base. There are also two minor changes in osgi.installer which I think should probably be made regardless. This patch includes a sample cfg file in both launchpad/builder and launchpad/testing. This was done so I could ensure that it worked in war, jar, and launchpad:run scenarios. There needs to be some kind of automated test. Note that in order for this to work properly [3], I had to introduce osgi.installer into the main pom. I'd like to get rid of the separate reactor for installer entirely, but there are still some integration test failures in osgi/it and it looks like Carsten is still working on this module. In any case, going down this path means that osgi.installer will need to be part of Sling 6 (if we want ConfigAdmin to be part of Sling 6, of course). Justin [1] Because ResourceProvider was already used within launchpad.base for this purpose, I used that name, although it's a bit odd that we have two different service interfaces named ResourceProvider. Suggestions for alternate names welcome :) [2] http://codereview.appspot.com/1953045/ [3] This is only 50% true.
Re: ConfigAdmin support in Launchpad...
Hi, Justin Edelson wrote As I mentioned last week, I had some concerns about using FileInstall for ConfigAdmin support and, more than concerns about FileInstall in particular, I didn't like the whole approach within Launchpad of copying some files out of the JAR/WAR and didn't want to see us continue this pattern. yepp, though I don't think that copying is a huge problem, it would be nicer to go without copying. I worked out a solution to this today and I'm pretty happy with it. In short... Launchpad exposes a service which allows bundles/services within the framework to access the contents of the launchpad archive (or project, in the case of the maven-launchpad-plugin) as a virtual file system. It is then trivial to create a component which uses this service to access configuration files and install them via osgi.installer. Yes, I was thinking about something like this as well - if possible, i would like to have a solution which does not require new interfaces or services in launchpad; but so far I couldn't come up with something useful (url handlers or something similar comes to my mind) Note that in order for this to work properly [3], I had to introduce osgi.installer into the main pom. I'd like to get rid of the separate reactor for installer entirely, but there are still some integration test failures in osgi/it and it looks like Carsten is still working on this module. In any case, going down this path means that osgi.installer will need to be part of Sling 6 (if we want ConfigAdmin to be part of Sling 6, of course). Yes, I'm currently rewriting the whole integration tests as they rely on internals of the implementation which makes changing the implementation really hard. If Sling 6 is near - and I really hope it is - I don't see osgi install be ready for this - so we have to go without osgi install. Though I really would love to have config support in launchpad it is not a must and should not block Sling 6. If we can't get it for Sling 6 we will have it for Sling 7. Carsten -- Carsten Ziegeler cziege...@apache.org
Re: ConfigAdmin support in Launchpad...
Hi,
Sounds like an interesting approach, too.
I would really like to include the OSGi Install stuff together with
this ResourceProvider and the new File Installer to be included with
Sling 6. If we go the route as Justin proposed, we would probably have
to include File Installer configured to the ${sling.home}/startup
location to support existing use cases depending on the startup folder
being used to install bundles.
Regarding the name: Yes, the ResourceProvider in the launchpad/base is
older than the ResourceProvider in the Resource API. But, this older
ResourceProvider has always been an internal API of the launchpad/base
module thus renaming it to prevent the name collision is a good idea.
Maybe something intelligent as LaunchpadResourceAccessor ;-)
Honestly, I am not sooo good at finding good names
Regards
Felix
On 8/17/10, Justin Edelson justinedel...@gmail.com wrote:
As I mentioned last week, I had some concerns about using FileInstall
for ConfigAdmin support and, more than concerns about FileInstall in
particular, I didn't like the whole approach within Launchpad of
copying some files out of the JAR/WAR and didn't want to see us
continue this pattern.
I worked out a solution to this today and I'm pretty happy with it.
In short... Launchpad exposes a service which allows bundles/services
within the framework to access the contents of the launchpad archive (or
project, in the case of the maven-launchpad-plugin) as a virtual file
system.
It is then trivial to create a component which uses this service to
access configuration files and install them via osgi.installer.
The specific steps involved were:
1) Creating a new launchpad.api bundle which contains the
ResourceProvider interface [1]
2) Modifying launchpad.base to use the new ResourceProvider interface,
add it to the list of system packages, and register the service.
3) Modifying maven-launchpad-plugin to use the new ResourceProvider
interface.
4) Creating a new launchpad.installer bundle which contains a Component
referring to the ResourceProvider service and osgi.installer.
The patch can be viewed here: [2]. It looks much bigger than it is due
to all of the internal changes within launchpad.base. There are also two
minor changes in osgi.installer which I think should probably be made
regardless.
This patch includes a sample cfg file in both launchpad/builder and
launchpad/testing. This was done so I could ensure that it worked in
war, jar, and launchpad:run scenarios. There needs to be some kind of
automated test.
Note that in order for this to work properly [3], I had to introduce
osgi.installer into the main pom. I'd like to get rid of the separate
reactor for installer entirely, but there are still some integration
test failures in osgi/it and it looks like Carsten is still working on
this module. In any case, going down this path means that osgi.installer
will need to be part of Sling 6 (if we want ConfigAdmin to be part of
Sling 6, of course).
Justin
[1] Because ResourceProvider was already used within launchpad.base for
this purpose, I used that name, although it's a bit odd that we have two
different service interfaces named ResourceProvider. Suggestions for
alternate names welcome :)
[2] http://codereview.appspot.com/1953045/
[3] This is only 50% true.
Re: ConfigAdmin support in Launchpad...
On 8/17/10 4:20 PM, Felix Meschberger wrote:
Hi,
Sounds like an interesting approach, too.
I would really like to include the OSGi Install stuff together with
this ResourceProvider and the new File Installer to be included with
Sling 6. If we go the route as Justin proposed, we would probably have
to include File Installer configured to the ${sling.home}/startup
location to support existing use cases depending on the startup folder
being used to install bundles.
What is this new File Installer of which you speak? Is this Felix's
FileInstall or extracting BootstrapInstaller from launchpad.base and
into this new launchpad.installer bundle (or something else).
I was thinking about this some more, and if getting osgi.installer ready
for Sling 6 is really a problem, perhaps launchpad.installer can simply
include a limited subset of functionality. So much of osgi.installer
seems to be about keeping resource lists and monitoring them whereas all
launchpad.installer needs is to do this for configs (plus some extra
code for handling factory pids):
String pid = createPid(path)
Dictionary dict = parseDictionary(stream);
if (!configExists(pid)) {
createConfig(pid, dict)
}
And for bundles, we already have all the code we need in
BootstrapInstaller, so moving that logic into a separate bundle should
be straight forward enough.
But before we can do this, I apparently need to convince everyone of two
things:
1) There is no harm in doing all of our should I install/upgrade this
bundle checks on every startup of launchpad.
2) There is no harm in installing/upgrading bundles directly from
(Launchpad) ResourceProvider.
If we can agree on these, the implementation of bundle installation
within launchpad.installer will be a lot simpler.
Regarding the name: Yes, the ResourceProvider in the launchpad/base is
older than the ResourceProvider in the Resource API. But, this older
ResourceProvider has always been an internal API of the launchpad/base
module thus renaming it to prevent the name collision is a good idea.
Maybe something intelligent as LaunchpadResourceAccessor ;-)
Honestly, I am not sooo good at finding good names
My initial suggestion was going to be LaunchpadContentProvider, which
I dismissed because I didn't think Launchpad belonged in the name...
Justin
Regards
Felix
On 8/17/10, Justin Edelson justinedel...@gmail.com wrote:
As I mentioned last week, I had some concerns about using FileInstall
for ConfigAdmin support and, more than concerns about FileInstall in
particular, I didn't like the whole approach within Launchpad of
copying some files out of the JAR/WAR and didn't want to see us
continue this pattern.
I worked out a solution to this today and I'm pretty happy with it.
In short... Launchpad exposes a service which allows bundles/services
within the framework to access the contents of the launchpad archive (or
project, in the case of the maven-launchpad-plugin) as a virtual file
system.
It is then trivial to create a component which uses this service to
access configuration files and install them via osgi.installer.
The specific steps involved were:
1) Creating a new launchpad.api bundle which contains the
ResourceProvider interface [1]
2) Modifying launchpad.base to use the new ResourceProvider interface,
add it to the list of system packages, and register the service.
3) Modifying maven-launchpad-plugin to use the new ResourceProvider
interface.
4) Creating a new launchpad.installer bundle which contains a Component
referring to the ResourceProvider service and osgi.installer.
The patch can be viewed here: [2]. It looks much bigger than it is due
to all of the internal changes within launchpad.base. There are also two
minor changes in osgi.installer which I think should probably be made
regardless.
This patch includes a sample cfg file in both launchpad/builder and
launchpad/testing. This was done so I could ensure that it worked in
war, jar, and launchpad:run scenarios. There needs to be some kind of
automated test.
Note that in order for this to work properly [3], I had to introduce
osgi.installer into the main pom. I'd like to get rid of the separate
reactor for installer entirely, but there are still some integration
test failures in osgi/it and it looks like Carsten is still working on
this module. In any case, going down this path means that osgi.installer
will need to be part of Sling 6 (if we want ConfigAdmin to be part of
Sling 6, of course).
Justin
[1] Because ResourceProvider was already used within launchpad.base for
this purpose, I used that name, although it's a bit odd that we have two
different service interfaces named ResourceProvider. Suggestions for
alternate names welcome :)
[2] http://codereview.appspot.com/1953045/
[3] This is only 50% true.
