You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by "Aaron Zeckoski (JIRA)" <ji...@apache.org> on 2009/04/15 12:48:14 UTC
[jira] Created: (SLING-922) Load modules on startup from an
external directory
Load modules on startup from an external directory
--------------------------------------------------
Key: SLING-922
URL: https://issues.apache.org/jira/browse/SLING-922
Project: Sling
Issue Type: New Feature
Components: Launchpad, Launchpad Launcher
Reporter: Aaron Zeckoski
Need a way to install and start bundles automatically from an external directory (sling home) on startup. The ideas below are from the list.
----------
> I would like to be able to setup sling to start with a bunch of
> installed bundles when it first is started. It seems like there are a
> couple way to do this that I have found but neither is ideal:
> 1) Rebuild sling from source with the extra bundles in the launcher
> pom (this seems to create a bunch of resources/# folders with bundles
> in them)
> 2) Configure all bundles in the sling.properties file (this requires
> the bundles to be in an accessible obr)
> http://incubator.apache.org/sling/site/provisioning-and-startup.html
>
> I would like to ideally do something in between like so:
> Get a binary copy of the sling jar
> Create a folder with sub-folders like /1 /10 /15
> Put my bundles in the various subfolders
> Configure sling.properties to point to the folder
> Start sling and have all bundles in the sub-folders installed and started
- Aaron Zeckoski
===============
Currently, as you say in (1), the BootstrapInstaller of the Sling
launchpad looks into its own resources enclosed in the JAR or WAR file
for bundles to install on startup.
How about extending this mechanism like this:
- Copy all bundles from enclosed resources to
${sling.home}/startup. This gives something like
${sling.home}/startup/0, /1, /10, /15, ...
Existing files are only replaced if the files
enclosed in the Sling launchpad jar/war file are
newer.
- Scan ${sling.home}/startup for bundles to install
in the same way as today the enclosed resources
are scanned directly.
So you could place your bundles in that structure and get them installed
at the requested start level (0 being "default bundle start level").
A nice side effect of this is, that you can quickly see, which bundles
have been installed at all.
- Felix
=================
I like this, and agree that this should replace the current mechanism.
How about adding a sling.properties option to completely ignore the
bundles that come from the Sling jar/war file? Might make it easier to
have precise control on what's installed.
-Bertrand
=================
Maybe worth it to make this optional or controllable via a property in the sling properties.
- Aaron Zeckoski
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-922) Load modules on startup from an
external directory
Posted by "Aaron Zeckoski (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12702314#action_12702314 ]
Aaron Zeckoski commented on SLING-922:
--------------------------------------
A few notes as I am going through this:
1) It is possible to check the bundles which are being copied from the war/jar against the installed bundles but I am not sure if this is what we want. If I check them as they are being copied then I can avoid copying over any bundles which are already installed (maybe good?) so the startup will contain a more accurate set of installed bundles. If I wait and check them later then the startup could contain bundles that were not installed. Currently I am checking before copying and not copying if the bundle is installed already.
2) the if (!isAlreadyInstalled(context)) check keeps any new bundles which are added to the jar/war or in the new case, to the startup directory from being installed normally. I would prefer this allow any new bundles in the startup to be installed after the initial startup so I am making it so the check only keeps the DeploymentPackageInstaller from running more than once (for now). Maybe this could be a sling property.
3) Invalid or duplicate bundles in the startup are currently just causing warnings in the logs. I think this is consistent with current behavior but perhaps there should be a strict mode that dies when bundles are invalid or duplicated? Thoughts?
> Load modules on startup from an external directory
> --------------------------------------------------
>
> Key: SLING-922
> URL: https://issues.apache.org/jira/browse/SLING-922
> Project: Sling
> Issue Type: New Feature
> Components: Launchpad, Launchpad Launcher
> Reporter: Aaron Zeckoski
> Assignee: Felix Meschberger
> Original Estimate: 72h
> Remaining Estimate: 72h
>
> Need a way to install and start bundles automatically from an external directory (sling home) on startup. The ideas below are from the list.
> ----------
> > I would like to be able to setup sling to start with a bunch of
> > installed bundles when it first is started. It seems like there are a
> > couple way to do this that I have found but neither is ideal:
> > 1) Rebuild sling from source with the extra bundles in the launcher
> > pom (this seems to create a bunch of resources/# folders with bundles
> > in them)
> > 2) Configure all bundles in the sling.properties file (this requires
> > the bundles to be in an accessible obr)
> > http://incubator.apache.org/sling/site/provisioning-and-startup.html
> >
> > I would like to ideally do something in between like so:
> > Get a binary copy of the sling jar
> > Create a folder with sub-folders like /1 /10 /15
> > Put my bundles in the various subfolders
> > Configure sling.properties to point to the folder
> > Start sling and have all bundles in the sub-folders installed and started
> - Aaron Zeckoski
> ===============
> Currently, as you say in (1), the BootstrapInstaller of the Sling
> launchpad looks into its own resources enclosed in the JAR or WAR file
> for bundles to install on startup.
> How about extending this mechanism like this:
> - Copy all bundles from enclosed resources to
> ${sling.home}/startup. This gives something like
> ${sling.home}/startup/0, /1, /10, /15, ...
> Existing files are only replaced if the files
> enclosed in the Sling launchpad jar/war file are
> newer.
> - Scan ${sling.home}/startup for bundles to install
> in the same way as today the enclosed resources
> are scanned directly.
> So you could place your bundles in that structure and get them installed
> at the requested start level (0 being "default bundle start level").
> A nice side effect of this is, that you can quickly see, which bundles
> have been installed at all.
> - Felix
> =================
> I like this, and agree that this should replace the current mechanism.
> How about adding a sling.properties option to completely ignore the
> bundles that come from the Sling jar/war file? Might make it easier to
> have precise control on what's installed.
> -Bertrand
> =================
> Maybe worth it to make this optional or controllable via a property in the sling properties.
> - Aaron Zeckoski
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-922) Load modules on startup from an
external directory
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12705077#action_12705077 ]
Felix Meschberger commented on SLING-922:
-----------------------------------------
Thanks for the patch, I try to look at it shortly.
> Load modules on startup from an external directory
> --------------------------------------------------
>
> Key: SLING-922
> URL: https://issues.apache.org/jira/browse/SLING-922
> Project: Sling
> Issue Type: New Feature
> Components: Launchpad, Launchpad Launcher
> Reporter: Aaron Zeckoski
> Assignee: Felix Meschberger
> Attachments: binary-test-resources.zip, SLING-922.patch
>
> Original Estimate: 72h
> Remaining Estimate: 72h
>
> Need a way to install and start bundles automatically from an external directory (sling home) on startup. The ideas below are from the list.
> ----------
> > I would like to be able to setup sling to start with a bunch of
> > installed bundles when it first is started. It seems like there are a
> > couple way to do this that I have found but neither is ideal:
> > 1) Rebuild sling from source with the extra bundles in the launcher
> > pom (this seems to create a bunch of resources/# folders with bundles
> > in them)
> > 2) Configure all bundles in the sling.properties file (this requires
> > the bundles to be in an accessible obr)
> > http://incubator.apache.org/sling/site/provisioning-and-startup.html
> >
> > I would like to ideally do something in between like so:
> > Get a binary copy of the sling jar
> > Create a folder with sub-folders like /1 /10 /15
> > Put my bundles in the various subfolders
> > Configure sling.properties to point to the folder
> > Start sling and have all bundles in the sub-folders installed and started
> - Aaron Zeckoski
> ===============
> Currently, as you say in (1), the BootstrapInstaller of the Sling
> launchpad looks into its own resources enclosed in the JAR or WAR file
> for bundles to install on startup.
> How about extending this mechanism like this:
> - Copy all bundles from enclosed resources to
> ${sling.home}/startup. This gives something like
> ${sling.home}/startup/0, /1, /10, /15, ...
> Existing files are only replaced if the files
> enclosed in the Sling launchpad jar/war file are
> newer.
> - Scan ${sling.home}/startup for bundles to install
> in the same way as today the enclosed resources
> are scanned directly.
> So you could place your bundles in that structure and get them installed
> at the requested start level (0 being "default bundle start level").
> A nice side effect of this is, that you can quickly see, which bundles
> have been installed at all.
> - Felix
> =================
> I like this, and agree that this should replace the current mechanism.
> How about adding a sling.properties option to completely ignore the
> bundles that come from the Sling jar/war file? Might make it easier to
> have precise control on what's installed.
> -Bertrand
> =================
> Maybe worth it to make this optional or controllable via a property in the sling properties.
> - Aaron Zeckoski
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-922) Load modules on startup from an
external directory
Posted by "Aaron Zeckoski (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12705038#action_12705038 ]
Aaron Zeckoski commented on SLING-922:
--------------------------------------
OK, I had some trouble generating this patch file so my apologies if it ends up being a little tricky to apply the patch. I have attached a zip which has the binary pieces used in the test. The remaining stuff should be visible in the patch file. So apply the patch and then extract the binary-test-resources into the sling trunk and then the build should be fine.
> Load modules on startup from an external directory
> --------------------------------------------------
>
> Key: SLING-922
> URL: https://issues.apache.org/jira/browse/SLING-922
> Project: Sling
> Issue Type: New Feature
> Components: Launchpad, Launchpad Launcher
> Reporter: Aaron Zeckoski
> Assignee: Felix Meschberger
> Original Estimate: 72h
> Remaining Estimate: 72h
>
> Need a way to install and start bundles automatically from an external directory (sling home) on startup. The ideas below are from the list.
> ----------
> > I would like to be able to setup sling to start with a bunch of
> > installed bundles when it first is started. It seems like there are a
> > couple way to do this that I have found but neither is ideal:
> > 1) Rebuild sling from source with the extra bundles in the launcher
> > pom (this seems to create a bunch of resources/# folders with bundles
> > in them)
> > 2) Configure all bundles in the sling.properties file (this requires
> > the bundles to be in an accessible obr)
> > http://incubator.apache.org/sling/site/provisioning-and-startup.html
> >
> > I would like to ideally do something in between like so:
> > Get a binary copy of the sling jar
> > Create a folder with sub-folders like /1 /10 /15
> > Put my bundles in the various subfolders
> > Configure sling.properties to point to the folder
> > Start sling and have all bundles in the sub-folders installed and started
> - Aaron Zeckoski
> ===============
> Currently, as you say in (1), the BootstrapInstaller of the Sling
> launchpad looks into its own resources enclosed in the JAR or WAR file
> for bundles to install on startup.
> How about extending this mechanism like this:
> - Copy all bundles from enclosed resources to
> ${sling.home}/startup. This gives something like
> ${sling.home}/startup/0, /1, /10, /15, ...
> Existing files are only replaced if the files
> enclosed in the Sling launchpad jar/war file are
> newer.
> - Scan ${sling.home}/startup for bundles to install
> in the same way as today the enclosed resources
> are scanned directly.
> So you could place your bundles in that structure and get them installed
> at the requested start level (0 being "default bundle start level").
> A nice side effect of this is, that you can quickly see, which bundles
> have been installed at all.
> - Felix
> =================
> I like this, and agree that this should replace the current mechanism.
> How about adding a sling.properties option to completely ignore the
> bundles that come from the Sling jar/war file? Might make it easier to
> have precise control on what's installed.
> -Bertrand
> =================
> Maybe worth it to make this optional or controllable via a property in the sling properties.
> - Aaron Zeckoski
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-922) Load modules on startup from an
external directory
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12705539#action_12705539 ]
Felix Meschberger commented on SLING-922:
-----------------------------------------
Thanks for providing the patch and testcase. All in all, this looks very promising and a really nice feature.
Yet I have some comments:
(1) Protected Methods: Many methods are protected. I prefer to default methods to private and only if they prove to be required outside of the clase, I make them default visibility, protected or public, but very reluctant. So I would like to have visibility reduced on all protected methods to private. If some methods are used for testcases, we should make them have default visibility. Reason: A protected method becomes part of the API of a class. As such, it must be thought about, whether it really constitutes API or is just a helper method. Also removing or changning API is a relatively expensive task.
If you agree, I would just "downgrade" all methods to private (or package if required by the test case).
(2) The BootstrapInstallerTest class has an unusual file header, which makes it hard to include it as is. Generally we have the default license header (see the BootstrapInstaller class for example).
If you agree, I will just "fix" this whille committing the class.
(3) The helper bundles are only provided as binaries. I am somewhat reluctant to addding binaries to the SVN without their accompanying source. I would probably be more comfortable with the source in SVN and creating the binaries during the test run (using the bnd tool and ant script for example).
(4) The BootstrapInstaller.start method now always checks the bundles in the startup folder on each startup. This is a potentially expensive operation. Therefore, I would think it would be better to enhance the isAlreadyInstalled test to see, whether there are files in the startup folder, which are more recent that the flag. If so the installation may take place.
(5) You add a dependency to Junit 4.5. Is this required or can we live with Sling's current setup of JUnit 4.3 ?
If 4.3 does it (it does on my system), I will just remove th version, scope and type elements from the pom while checking in.
I will attach a patch with the BundleInstaller class slightly modified from your patch.
> Load modules on startup from an external directory
> --------------------------------------------------
>
> Key: SLING-922
> URL: https://issues.apache.org/jira/browse/SLING-922
> Project: Sling
> Issue Type: New Feature
> Components: Launchpad, Launchpad Launcher
> Reporter: Aaron Zeckoski
> Assignee: Felix Meschberger
> Attachments: binary-test-resources.zip, SLING-922.patch
>
> Original Estimate: 72h
> Remaining Estimate: 72h
>
> Need a way to install and start bundles automatically from an external directory (sling home) on startup. The ideas below are from the list.
> ----------
> > I would like to be able to setup sling to start with a bunch of
> > installed bundles when it first is started. It seems like there are a
> > couple way to do this that I have found but neither is ideal:
> > 1) Rebuild sling from source with the extra bundles in the launcher
> > pom (this seems to create a bunch of resources/# folders with bundles
> > in them)
> > 2) Configure all bundles in the sling.properties file (this requires
> > the bundles to be in an accessible obr)
> > http://incubator.apache.org/sling/site/provisioning-and-startup.html
> >
> > I would like to ideally do something in between like so:
> > Get a binary copy of the sling jar
> > Create a folder with sub-folders like /1 /10 /15
> > Put my bundles in the various subfolders
> > Configure sling.properties to point to the folder
> > Start sling and have all bundles in the sub-folders installed and started
> - Aaron Zeckoski
> ===============
> Currently, as you say in (1), the BootstrapInstaller of the Sling
> launchpad looks into its own resources enclosed in the JAR or WAR file
> for bundles to install on startup.
> How about extending this mechanism like this:
> - Copy all bundles from enclosed resources to
> ${sling.home}/startup. This gives something like
> ${sling.home}/startup/0, /1, /10, /15, ...
> Existing files are only replaced if the files
> enclosed in the Sling launchpad jar/war file are
> newer.
> - Scan ${sling.home}/startup for bundles to install
> in the same way as today the enclosed resources
> are scanned directly.
> So you could place your bundles in that structure and get them installed
> at the requested start level (0 being "default bundle start level").
> A nice side effect of this is, that you can quickly see, which bundles
> have been installed at all.
> - Felix
> =================
> I like this, and agree that this should replace the current mechanism.
> How about adding a sling.properties option to completely ignore the
> bundles that come from the Sling jar/war file? Might make it easier to
> have precise control on what's installed.
> -Bertrand
> =================
> Maybe worth it to make this optional or controllable via a property in the sling properties.
> - Aaron Zeckoski
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-922) Load modules on startup from an
external directory
Posted by "Aaron Zeckoski (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12705730#action_12705730 ]
Aaron Zeckoski commented on SLING-922:
--------------------------------------
(1) Protected Methods: Many methods are protected. I prefer to default methods to private and only if they prove to be required outside of the clase, I make them default visibility, protected or public, but very reluctant. So I would like to have visibility reduced on all protected methods to private. If some methods are used for testcases, we should make them have default visibility. Reason: A protected method becomes part of the API of a class. As such, it must be thought about, whether it really constitutes API or is just a helper method. Also removing or changning API is a relatively expensive task.
If you agree, I would just "downgrade" all methods to private (or package if required by the test case).
- Sounds fine. Default is most appropriate anyway for the methods which are being tested. I should probably have left them as default anyway.
(2) The BootstrapInstallerTest class has an unusual file header, which makes it hard to include it as is. Generally we have the default license header (see the BootstrapInstaller class for example).
If you agree, I will just "fix" this whille committing the class.
- Please change the headers however you like. These are probably just some default ones I use.
(3) The helper bundles are only provided as binaries. I am somewhat reluctant to addding binaries to the SVN without their accompanying source. I would probably be more comfortable with the source in SVN and creating the binaries during the test run (using the bnd tool and ant script for example).
- You mean the test bundles here I assume. That's fine with me. I just wanted something that would serve as good static test data and it proved impossible for me to get bnd to generate invalid bundles but if you can do this then definitely do it.
(4) The BootstrapInstaller.start method now always checks the bundles in the startup folder on each startup. This is a potentially expensive operation. Therefore, I would think it would be better to enhance the isAlreadyInstalled test to see, whether there are files in the startup folder, which are more recent that the flag. If so the installation may take place.
- The modification to getSelfTimestamp looks good to me.
(5) You add a dependency to Junit 4.5. Is this required or can we live with Sling's current setup of JUnit 4.3 ?
- 4.3 should work fine.
> Load modules on startup from an external directory
> --------------------------------------------------
>
> Key: SLING-922
> URL: https://issues.apache.org/jira/browse/SLING-922
> Project: Sling
> Issue Type: New Feature
> Components: Launchpad, Launchpad Launcher
> Reporter: Aaron Zeckoski
> Assignee: Felix Meschberger
> Attachments: binary-test-resources.zip, SLING-922.patch, SLING922_fmeschbe.patch
>
> Original Estimate: 72h
> Remaining Estimate: 72h
>
> Need a way to install and start bundles automatically from an external directory (sling home) on startup. The ideas below are from the list.
> ----------
> > I would like to be able to setup sling to start with a bunch of
> > installed bundles when it first is started. It seems like there are a
> > couple way to do this that I have found but neither is ideal:
> > 1) Rebuild sling from source with the extra bundles in the launcher
> > pom (this seems to create a bunch of resources/# folders with bundles
> > in them)
> > 2) Configure all bundles in the sling.properties file (this requires
> > the bundles to be in an accessible obr)
> > http://incubator.apache.org/sling/site/provisioning-and-startup.html
> >
> > I would like to ideally do something in between like so:
> > Get a binary copy of the sling jar
> > Create a folder with sub-folders like /1 /10 /15
> > Put my bundles in the various subfolders
> > Configure sling.properties to point to the folder
> > Start sling and have all bundles in the sub-folders installed and started
> - Aaron Zeckoski
> ===============
> Currently, as you say in (1), the BootstrapInstaller of the Sling
> launchpad looks into its own resources enclosed in the JAR or WAR file
> for bundles to install on startup.
> How about extending this mechanism like this:
> - Copy all bundles from enclosed resources to
> ${sling.home}/startup. This gives something like
> ${sling.home}/startup/0, /1, /10, /15, ...
> Existing files are only replaced if the files
> enclosed in the Sling launchpad jar/war file are
> newer.
> - Scan ${sling.home}/startup for bundles to install
> in the same way as today the enclosed resources
> are scanned directly.
> So you could place your bundles in that structure and get them installed
> at the requested start level (0 being "default bundle start level").
> A nice side effect of this is, that you can quickly see, which bundles
> have been installed at all.
> - Felix
> =================
> I like this, and agree that this should replace the current mechanism.
> How about adding a sling.properties option to completely ignore the
> bundles that come from the Sling jar/war file? Might make it easier to
> have precise control on what's installed.
> -Bertrand
> =================
> Maybe worth it to make this optional or controllable via a property in the sling properties.
> - Aaron Zeckoski
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-922) Load modules on startup from an
external directory
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12702317#action_12702317 ]
Felix Meschberger commented on SLING-922:
-----------------------------------------
ad 1): With respect to copying bundles out of the enclosing into the startup folder, I would check the bundle contents before actually copying it. The problem of having out-of-sync situation with the actually installed bundles is acceptable and actually even an expected situation frm the POV of OSGi: You may install, update or remove bundles at any time.
ad 2): IIRC the isAlreadyInstalled method compares a timestamp stored in the filesystem with the timestamp of the launchpad jar file. So whenever this file is updated that modification time is changed (it changes when you modify embedded bundles), the isAlreadyInstalled method returns false. So changing embedded bundles has the "side-effect" of causing the BootstrapInstaller to inspect all enclosed bundles.
ad 3): I am not sure, what warn message you mean. There is a info logged when a bundle is enclosed whose version is lower than (or equal to) the version of a bundle of the same symbolic name which is already installed. I think, this is a valid situation, since someone might already have updated the bundle through other means. Other than that I cannot remember any duplicity checks in the BootstrapInstaller
> Load modules on startup from an external directory
> --------------------------------------------------
>
> Key: SLING-922
> URL: https://issues.apache.org/jira/browse/SLING-922
> Project: Sling
> Issue Type: New Feature
> Components: Launchpad, Launchpad Launcher
> Reporter: Aaron Zeckoski
> Assignee: Felix Meschberger
> Original Estimate: 72h
> Remaining Estimate: 72h
>
> Need a way to install and start bundles automatically from an external directory (sling home) on startup. The ideas below are from the list.
> ----------
> > I would like to be able to setup sling to start with a bunch of
> > installed bundles when it first is started. It seems like there are a
> > couple way to do this that I have found but neither is ideal:
> > 1) Rebuild sling from source with the extra bundles in the launcher
> > pom (this seems to create a bunch of resources/# folders with bundles
> > in them)
> > 2) Configure all bundles in the sling.properties file (this requires
> > the bundles to be in an accessible obr)
> > http://incubator.apache.org/sling/site/provisioning-and-startup.html
> >
> > I would like to ideally do something in between like so:
> > Get a binary copy of the sling jar
> > Create a folder with sub-folders like /1 /10 /15
> > Put my bundles in the various subfolders
> > Configure sling.properties to point to the folder
> > Start sling and have all bundles in the sub-folders installed and started
> - Aaron Zeckoski
> ===============
> Currently, as you say in (1), the BootstrapInstaller of the Sling
> launchpad looks into its own resources enclosed in the JAR or WAR file
> for bundles to install on startup.
> How about extending this mechanism like this:
> - Copy all bundles from enclosed resources to
> ${sling.home}/startup. This gives something like
> ${sling.home}/startup/0, /1, /10, /15, ...
> Existing files are only replaced if the files
> enclosed in the Sling launchpad jar/war file are
> newer.
> - Scan ${sling.home}/startup for bundles to install
> in the same way as today the enclosed resources
> are scanned directly.
> So you could place your bundles in that structure and get them installed
> at the requested start level (0 being "default bundle start level").
> A nice side effect of this is, that you can quickly see, which bundles
> have been installed at all.
> - Felix
> =================
> I like this, and agree that this should replace the current mechanism.
> How about adding a sling.properties option to completely ignore the
> bundles that come from the Sling jar/war file? Might make it easier to
> have precise control on what's installed.
> -Bertrand
> =================
> Maybe worth it to make this optional or controllable via a property in the sling properties.
> - Aaron Zeckoski
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-922) Load modules on startup from an
external directory
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Felix Meschberger updated SLING-922:
------------------------------------
Attachment: SLING922_fmeschbe.patch
Modifications to the BundleInstaller patch proposal:
* some method reordering
* all protected methods are now private or package
* extending getSelfTimeStamp to include the bundles from startup folder
* only install/update if there is something to do
* copying bundles from the launcher does not check them any more (done on install/update)
* use default JUnit version /change in pom.xml)
WDYT ?
> Load modules on startup from an external directory
> --------------------------------------------------
>
> Key: SLING-922
> URL: https://issues.apache.org/jira/browse/SLING-922
> Project: Sling
> Issue Type: New Feature
> Components: Launchpad, Launchpad Launcher
> Reporter: Aaron Zeckoski
> Assignee: Felix Meschberger
> Attachments: binary-test-resources.zip, SLING-922.patch, SLING922_fmeschbe.patch
>
> Original Estimate: 72h
> Remaining Estimate: 72h
>
> Need a way to install and start bundles automatically from an external directory (sling home) on startup. The ideas below are from the list.
> ----------
> > I would like to be able to setup sling to start with a bunch of
> > installed bundles when it first is started. It seems like there are a
> > couple way to do this that I have found but neither is ideal:
> > 1) Rebuild sling from source with the extra bundles in the launcher
> > pom (this seems to create a bunch of resources/# folders with bundles
> > in them)
> > 2) Configure all bundles in the sling.properties file (this requires
> > the bundles to be in an accessible obr)
> > http://incubator.apache.org/sling/site/provisioning-and-startup.html
> >
> > I would like to ideally do something in between like so:
> > Get a binary copy of the sling jar
> > Create a folder with sub-folders like /1 /10 /15
> > Put my bundles in the various subfolders
> > Configure sling.properties to point to the folder
> > Start sling and have all bundles in the sub-folders installed and started
> - Aaron Zeckoski
> ===============
> Currently, as you say in (1), the BootstrapInstaller of the Sling
> launchpad looks into its own resources enclosed in the JAR or WAR file
> for bundles to install on startup.
> How about extending this mechanism like this:
> - Copy all bundles from enclosed resources to
> ${sling.home}/startup. This gives something like
> ${sling.home}/startup/0, /1, /10, /15, ...
> Existing files are only replaced if the files
> enclosed in the Sling launchpad jar/war file are
> newer.
> - Scan ${sling.home}/startup for bundles to install
> in the same way as today the enclosed resources
> are scanned directly.
> So you could place your bundles in that structure and get them installed
> at the requested start level (0 being "default bundle start level").
> A nice side effect of this is, that you can quickly see, which bundles
> have been installed at all.
> - Felix
> =================
> I like this, and agree that this should replace the current mechanism.
> How about adding a sling.properties option to completely ignore the
> bundles that come from the Sling jar/war file? Might make it easier to
> have precise control on what's installed.
> -Bertrand
> =================
> Maybe worth it to make this optional or controllable via a property in the sling properties.
> - Aaron Zeckoski
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-922) Load modules on startup from an
external directory
Posted by "Aaron Zeckoski (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12699147#action_12699147 ]
Aaron Zeckoski commented on SLING-922:
--------------------------------------
Just so it is clear, I am working on a patch for this so please please let me know if someone else (like you) are thinking about writing this so I don't waste my time. :-)
> Load modules on startup from an external directory
> --------------------------------------------------
>
> Key: SLING-922
> URL: https://issues.apache.org/jira/browse/SLING-922
> Project: Sling
> Issue Type: New Feature
> Components: Launchpad, Launchpad Launcher
> Reporter: Aaron Zeckoski
> Original Estimate: 72h
> Remaining Estimate: 72h
>
> Need a way to install and start bundles automatically from an external directory (sling home) on startup. The ideas below are from the list.
> ----------
> > I would like to be able to setup sling to start with a bunch of
> > installed bundles when it first is started. It seems like there are a
> > couple way to do this that I have found but neither is ideal:
> > 1) Rebuild sling from source with the extra bundles in the launcher
> > pom (this seems to create a bunch of resources/# folders with bundles
> > in them)
> > 2) Configure all bundles in the sling.properties file (this requires
> > the bundles to be in an accessible obr)
> > http://incubator.apache.org/sling/site/provisioning-and-startup.html
> >
> > I would like to ideally do something in between like so:
> > Get a binary copy of the sling jar
> > Create a folder with sub-folders like /1 /10 /15
> > Put my bundles in the various subfolders
> > Configure sling.properties to point to the folder
> > Start sling and have all bundles in the sub-folders installed and started
> - Aaron Zeckoski
> ===============
> Currently, as you say in (1), the BootstrapInstaller of the Sling
> launchpad looks into its own resources enclosed in the JAR or WAR file
> for bundles to install on startup.
> How about extending this mechanism like this:
> - Copy all bundles from enclosed resources to
> ${sling.home}/startup. This gives something like
> ${sling.home}/startup/0, /1, /10, /15, ...
> Existing files are only replaced if the files
> enclosed in the Sling launchpad jar/war file are
> newer.
> - Scan ${sling.home}/startup for bundles to install
> in the same way as today the enclosed resources
> are scanned directly.
> So you could place your bundles in that structure and get them installed
> at the requested start level (0 being "default bundle start level").
> A nice side effect of this is, that you can quickly see, which bundles
> have been installed at all.
> - Felix
> =================
> I like this, and agree that this should replace the current mechanism.
> How about adding a sling.properties option to completely ignore the
> bundles that come from the Sling jar/war file? Might make it easier to
> have precise control on what's installed.
> -Bertrand
> =================
> Maybe worth it to make this optional or controllable via a property in the sling properties.
> - Aaron Zeckoski
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-922) Load modules on startup from an
external directory
Posted by "Bertrand Delacretaz (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12705544#action_12705544 ]
Bertrand Delacretaz commented on SLING-922:
-------------------------------------------
> ...(3) The helper bundles are only provided as binaries.,,,I would probably be more comfortable with the
> source in SVN and creating the binaries during the test run (using the bnd tool and ant script
> for example). ..
FWIW, I'm doing something like this in the installClonedBundle() method of the JcrinstallTestBase class [1]. The BundleCloner class uses bnd to create several copies of test bundles with different symbolic names. See also SLING-946, for some reason the bnd call currently fails on our Hudson build server.
[1] http://svn.eu.apache.org/repos/asf/incubator/sling/trunk/contrib/launchpad/testing/src/test/java/org/apache/sling/launchpad/webapp/integrationtest/jcrinstall/JcrinstallTestBase.java
> Load modules on startup from an external directory
> --------------------------------------------------
>
> Key: SLING-922
> URL: https://issues.apache.org/jira/browse/SLING-922
> Project: Sling
> Issue Type: New Feature
> Components: Launchpad, Launchpad Launcher
> Reporter: Aaron Zeckoski
> Assignee: Felix Meschberger
> Attachments: binary-test-resources.zip, SLING-922.patch, SLING922_fmeschbe.patch
>
> Original Estimate: 72h
> Remaining Estimate: 72h
>
> Need a way to install and start bundles automatically from an external directory (sling home) on startup. The ideas below are from the list.
> ----------
> > I would like to be able to setup sling to start with a bunch of
> > installed bundles when it first is started. It seems like there are a
> > couple way to do this that I have found but neither is ideal:
> > 1) Rebuild sling from source with the extra bundles in the launcher
> > pom (this seems to create a bunch of resources/# folders with bundles
> > in them)
> > 2) Configure all bundles in the sling.properties file (this requires
> > the bundles to be in an accessible obr)
> > http://incubator.apache.org/sling/site/provisioning-and-startup.html
> >
> > I would like to ideally do something in between like so:
> > Get a binary copy of the sling jar
> > Create a folder with sub-folders like /1 /10 /15
> > Put my bundles in the various subfolders
> > Configure sling.properties to point to the folder
> > Start sling and have all bundles in the sub-folders installed and started
> - Aaron Zeckoski
> ===============
> Currently, as you say in (1), the BootstrapInstaller of the Sling
> launchpad looks into its own resources enclosed in the JAR or WAR file
> for bundles to install on startup.
> How about extending this mechanism like this:
> - Copy all bundles from enclosed resources to
> ${sling.home}/startup. This gives something like
> ${sling.home}/startup/0, /1, /10, /15, ...
> Existing files are only replaced if the files
> enclosed in the Sling launchpad jar/war file are
> newer.
> - Scan ${sling.home}/startup for bundles to install
> in the same way as today the enclosed resources
> are scanned directly.
> So you could place your bundles in that structure and get them installed
> at the requested start level (0 being "default bundle start level").
> A nice side effect of this is, that you can quickly see, which bundles
> have been installed at all.
> - Felix
> =================
> I like this, and agree that this should replace the current mechanism.
> How about adding a sling.properties option to completely ignore the
> bundles that come from the Sling jar/war file? Might make it easier to
> have precise control on what's installed.
> -Bertrand
> =================
> Maybe worth it to make this optional or controllable via a property in the sling properties.
> - Aaron Zeckoski
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-922) Load modules on startup from an
external directory
Posted by "Aaron Zeckoski (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Aaron Zeckoski updated SLING-922:
---------------------------------
Attachment: SLING-922.patch
binary-test-resources.zip
Everything seems to be working on my machine so I think this is ready to go. Please let me know if there are any issues and I will generate a new patch.
> Load modules on startup from an external directory
> --------------------------------------------------
>
> Key: SLING-922
> URL: https://issues.apache.org/jira/browse/SLING-922
> Project: Sling
> Issue Type: New Feature
> Components: Launchpad, Launchpad Launcher
> Reporter: Aaron Zeckoski
> Assignee: Felix Meschberger
> Attachments: binary-test-resources.zip, SLING-922.patch
>
> Original Estimate: 72h
> Remaining Estimate: 72h
>
> Need a way to install and start bundles automatically from an external directory (sling home) on startup. The ideas below are from the list.
> ----------
> > I would like to be able to setup sling to start with a bunch of
> > installed bundles when it first is started. It seems like there are a
> > couple way to do this that I have found but neither is ideal:
> > 1) Rebuild sling from source with the extra bundles in the launcher
> > pom (this seems to create a bunch of resources/# folders with bundles
> > in them)
> > 2) Configure all bundles in the sling.properties file (this requires
> > the bundles to be in an accessible obr)
> > http://incubator.apache.org/sling/site/provisioning-and-startup.html
> >
> > I would like to ideally do something in between like so:
> > Get a binary copy of the sling jar
> > Create a folder with sub-folders like /1 /10 /15
> > Put my bundles in the various subfolders
> > Configure sling.properties to point to the folder
> > Start sling and have all bundles in the sub-folders installed and started
> - Aaron Zeckoski
> ===============
> Currently, as you say in (1), the BootstrapInstaller of the Sling
> launchpad looks into its own resources enclosed in the JAR or WAR file
> for bundles to install on startup.
> How about extending this mechanism like this:
> - Copy all bundles from enclosed resources to
> ${sling.home}/startup. This gives something like
> ${sling.home}/startup/0, /1, /10, /15, ...
> Existing files are only replaced if the files
> enclosed in the Sling launchpad jar/war file are
> newer.
> - Scan ${sling.home}/startup for bundles to install
> in the same way as today the enclosed resources
> are scanned directly.
> So you could place your bundles in that structure and get them installed
> at the requested start level (0 being "default bundle start level").
> A nice side effect of this is, that you can quickly see, which bundles
> have been installed at all.
> - Felix
> =================
> I like this, and agree that this should replace the current mechanism.
> How about adding a sling.properties option to completely ignore the
> bundles that come from the Sling jar/war file? Might make it easier to
> have precise control on what's installed.
> -Bertrand
> =================
> Maybe worth it to make this optional or controllable via a property in the sling properties.
> - Aaron Zeckoski
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-922) Load modules on startup from an
external directory
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12702324#action_12702324 ]
Felix Meschberger commented on SLING-922:
-----------------------------------------
ad 1) To the contrary: I would check before actually copying
ad 3) I see. That would be a new check, since currently this is not checked. But it might make sense to check this (if easly feasible) and at least WARN or ERROR about it. Whether we should die ? I am not so sure, really.
> Load modules on startup from an external directory
> --------------------------------------------------
>
> Key: SLING-922
> URL: https://issues.apache.org/jira/browse/SLING-922
> Project: Sling
> Issue Type: New Feature
> Components: Launchpad, Launchpad Launcher
> Reporter: Aaron Zeckoski
> Assignee: Felix Meschberger
> Original Estimate: 72h
> Remaining Estimate: 72h
>
> Need a way to install and start bundles automatically from an external directory (sling home) on startup. The ideas below are from the list.
> ----------
> > I would like to be able to setup sling to start with a bunch of
> > installed bundles when it first is started. It seems like there are a
> > couple way to do this that I have found but neither is ideal:
> > 1) Rebuild sling from source with the extra bundles in the launcher
> > pom (this seems to create a bunch of resources/# folders with bundles
> > in them)
> > 2) Configure all bundles in the sling.properties file (this requires
> > the bundles to be in an accessible obr)
> > http://incubator.apache.org/sling/site/provisioning-and-startup.html
> >
> > I would like to ideally do something in between like so:
> > Get a binary copy of the sling jar
> > Create a folder with sub-folders like /1 /10 /15
> > Put my bundles in the various subfolders
> > Configure sling.properties to point to the folder
> > Start sling and have all bundles in the sub-folders installed and started
> - Aaron Zeckoski
> ===============
> Currently, as you say in (1), the BootstrapInstaller of the Sling
> launchpad looks into its own resources enclosed in the JAR or WAR file
> for bundles to install on startup.
> How about extending this mechanism like this:
> - Copy all bundles from enclosed resources to
> ${sling.home}/startup. This gives something like
> ${sling.home}/startup/0, /1, /10, /15, ...
> Existing files are only replaced if the files
> enclosed in the Sling launchpad jar/war file are
> newer.
> - Scan ${sling.home}/startup for bundles to install
> in the same way as today the enclosed resources
> are scanned directly.
> So you could place your bundles in that structure and get them installed
> at the requested start level (0 being "default bundle start level").
> A nice side effect of this is, that you can quickly see, which bundles
> have been installed at all.
> - Felix
> =================
> I like this, and agree that this should replace the current mechanism.
> How about adding a sling.properties option to completely ignore the
> bundles that come from the Sling jar/war file? Might make it easier to
> have precise control on what's installed.
> -Bertrand
> =================
> Maybe worth it to make this optional or controllable via a property in the sling properties.
> - Aaron Zeckoski
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-922) Load modules on startup from an
external directory
Posted by "Aaron Zeckoski (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12702321#action_12702321 ]
Aaron Zeckoski commented on SLING-922:
--------------------------------------
1) OK, so no checking before copying then?
2) So only copy if this trips then (that makes sense to me)
3) Sorry, poor choice of words. I mean currently in the code I am working on, not in the sling trunk.
They are info level like below (this is one from trunk which checks to see if the bundle is already installed and newer and skips it if so). That is similar to a duplicate check in my mind:
logger.log(Logger.LOG_INFO, "Ignoring " + path
+ ": More recent version already installed");
I was mosting thinking of the situation where there is a bundle in startup/0 and startup/1 which are the same. I could just have the first loaded or last loaded win but I am not sure what the best way to handle it is. I was thinking I would just use the ignore(installedBundle, manifest) check in this case. Am I making sense? :-)
> Load modules on startup from an external directory
> --------------------------------------------------
>
> Key: SLING-922
> URL: https://issues.apache.org/jira/browse/SLING-922
> Project: Sling
> Issue Type: New Feature
> Components: Launchpad, Launchpad Launcher
> Reporter: Aaron Zeckoski
> Assignee: Felix Meschberger
> Original Estimate: 72h
> Remaining Estimate: 72h
>
> Need a way to install and start bundles automatically from an external directory (sling home) on startup. The ideas below are from the list.
> ----------
> > I would like to be able to setup sling to start with a bunch of
> > installed bundles when it first is started. It seems like there are a
> > couple way to do this that I have found but neither is ideal:
> > 1) Rebuild sling from source with the extra bundles in the launcher
> > pom (this seems to create a bunch of resources/# folders with bundles
> > in them)
> > 2) Configure all bundles in the sling.properties file (this requires
> > the bundles to be in an accessible obr)
> > http://incubator.apache.org/sling/site/provisioning-and-startup.html
> >
> > I would like to ideally do something in between like so:
> > Get a binary copy of the sling jar
> > Create a folder with sub-folders like /1 /10 /15
> > Put my bundles in the various subfolders
> > Configure sling.properties to point to the folder
> > Start sling and have all bundles in the sub-folders installed and started
> - Aaron Zeckoski
> ===============
> Currently, as you say in (1), the BootstrapInstaller of the Sling
> launchpad looks into its own resources enclosed in the JAR or WAR file
> for bundles to install on startup.
> How about extending this mechanism like this:
> - Copy all bundles from enclosed resources to
> ${sling.home}/startup. This gives something like
> ${sling.home}/startup/0, /1, /10, /15, ...
> Existing files are only replaced if the files
> enclosed in the Sling launchpad jar/war file are
> newer.
> - Scan ${sling.home}/startup for bundles to install
> in the same way as today the enclosed resources
> are scanned directly.
> So you could place your bundles in that structure and get them installed
> at the requested start level (0 being "default bundle start level").
> A nice side effect of this is, that you can quickly see, which bundles
> have been installed at all.
> - Felix
> =================
> I like this, and agree that this should replace the current mechanism.
> How about adding a sling.properties option to completely ignore the
> bundles that come from the Sling jar/war file? Might make it easier to
> have precise control on what's installed.
> -Bertrand
> =================
> Maybe worth it to make this optional or controllable via a property in the sling properties.
> - Aaron Zeckoski
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-922) Load modules on startup from an
external directory
Posted by "Aaron Zeckoski (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12707767#action_12707767 ]
Aaron Zeckoski commented on SLING-922:
--------------------------------------
Is this waiting on some action from me? Just let me know if there is something you would like me to do.
it might be easiest for now to just remove the tests which use the binary files if there is an issue around those. I would not want that to be the reason why this is held up.
> Load modules on startup from an external directory
> --------------------------------------------------
>
> Key: SLING-922
> URL: https://issues.apache.org/jira/browse/SLING-922
> Project: Sling
> Issue Type: New Feature
> Components: Launchpad, Launchpad Launcher
> Reporter: Aaron Zeckoski
> Assignee: Felix Meschberger
> Attachments: binary-test-resources.zip, SLING-922.patch, SLING922_fmeschbe.patch
>
> Original Estimate: 72h
> Remaining Estimate: 72h
>
> Need a way to install and start bundles automatically from an external directory (sling home) on startup. The ideas below are from the list.
> ----------
> > I would like to be able to setup sling to start with a bunch of
> > installed bundles when it first is started. It seems like there are a
> > couple way to do this that I have found but neither is ideal:
> > 1) Rebuild sling from source with the extra bundles in the launcher
> > pom (this seems to create a bunch of resources/# folders with bundles
> > in them)
> > 2) Configure all bundles in the sling.properties file (this requires
> > the bundles to be in an accessible obr)
> > http://incubator.apache.org/sling/site/provisioning-and-startup.html
> >
> > I would like to ideally do something in between like so:
> > Get a binary copy of the sling jar
> > Create a folder with sub-folders like /1 /10 /15
> > Put my bundles in the various subfolders
> > Configure sling.properties to point to the folder
> > Start sling and have all bundles in the sub-folders installed and started
> - Aaron Zeckoski
> ===============
> Currently, as you say in (1), the BootstrapInstaller of the Sling
> launchpad looks into its own resources enclosed in the JAR or WAR file
> for bundles to install on startup.
> How about extending this mechanism like this:
> - Copy all bundles from enclosed resources to
> ${sling.home}/startup. This gives something like
> ${sling.home}/startup/0, /1, /10, /15, ...
> Existing files are only replaced if the files
> enclosed in the Sling launchpad jar/war file are
> newer.
> - Scan ${sling.home}/startup for bundles to install
> in the same way as today the enclosed resources
> are scanned directly.
> So you could place your bundles in that structure and get them installed
> at the requested start level (0 being "default bundle start level").
> A nice side effect of this is, that you can quickly see, which bundles
> have been installed at all.
> - Felix
> =================
> I like this, and agree that this should replace the current mechanism.
> How about adding a sling.properties option to completely ignore the
> bundles that come from the Sling jar/war file? Might make it easier to
> have precise control on what's installed.
> -Bertrand
> =================
> Maybe worth it to make this optional or controllable via a property in the sling properties.
> - Aaron Zeckoski
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (SLING-922) Load modules on startup from an
external directory
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Felix Meschberger reassigned SLING-922:
---------------------------------------
Assignee: Felix Meschberger
Provisionally assigning to me. I know that you Aaron are working on it so I will surely just be sitting and waiting for the patch to arrive.
Thanks alot.
> Load modules on startup from an external directory
> --------------------------------------------------
>
> Key: SLING-922
> URL: https://issues.apache.org/jira/browse/SLING-922
> Project: Sling
> Issue Type: New Feature
> Components: Launchpad, Launchpad Launcher
> Reporter: Aaron Zeckoski
> Assignee: Felix Meschberger
> Original Estimate: 72h
> Remaining Estimate: 72h
>
> Need a way to install and start bundles automatically from an external directory (sling home) on startup. The ideas below are from the list.
> ----------
> > I would like to be able to setup sling to start with a bunch of
> > installed bundles when it first is started. It seems like there are a
> > couple way to do this that I have found but neither is ideal:
> > 1) Rebuild sling from source with the extra bundles in the launcher
> > pom (this seems to create a bunch of resources/# folders with bundles
> > in them)
> > 2) Configure all bundles in the sling.properties file (this requires
> > the bundles to be in an accessible obr)
> > http://incubator.apache.org/sling/site/provisioning-and-startup.html
> >
> > I would like to ideally do something in between like so:
> > Get a binary copy of the sling jar
> > Create a folder with sub-folders like /1 /10 /15
> > Put my bundles in the various subfolders
> > Configure sling.properties to point to the folder
> > Start sling and have all bundles in the sub-folders installed and started
> - Aaron Zeckoski
> ===============
> Currently, as you say in (1), the BootstrapInstaller of the Sling
> launchpad looks into its own resources enclosed in the JAR or WAR file
> for bundles to install on startup.
> How about extending this mechanism like this:
> - Copy all bundles from enclosed resources to
> ${sling.home}/startup. This gives something like
> ${sling.home}/startup/0, /1, /10, /15, ...
> Existing files are only replaced if the files
> enclosed in the Sling launchpad jar/war file are
> newer.
> - Scan ${sling.home}/startup for bundles to install
> in the same way as today the enclosed resources
> are scanned directly.
> So you could place your bundles in that structure and get them installed
> at the requested start level (0 being "default bundle start level").
> A nice side effect of this is, that you can quickly see, which bundles
> have been installed at all.
> - Felix
> =================
> I like this, and agree that this should replace the current mechanism.
> How about adding a sling.properties option to completely ignore the
> bundles that come from the Sling jar/war file? Might make it easier to
> have precise control on what's installed.
> -Bertrand
> =================
> Maybe worth it to make this optional or controllable via a property in the sling properties.
> - Aaron Zeckoski
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.