[jira] Commented: (SLING-835) Python: python.home must be set
[
https://issues.apache.org/jira/browse/SLING-835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12712484#action_12712484
]
Aaron Zeckoski commented on SLING-835:
--
If the issue is cache files related to python then the "python.cachedir"
setting might be more important here (though this should get set right if the
python.home is set correctly). Since python.home is not always the same on
every machine I assume we probably want something like this in the constructor
for PythonScriptEngineFactory:
Properties props = new Properties();
props.put("python.home", configuredPythonHome);
PythonInterpreter.initialize(System.getProperties(),
props, new String[0]);
I would think it would be ideal to get the configuredPythonHome value from the
OSGi configuration.
If you give me a tip about how to do that I will be happy to submit a patch for
this.
> Python: python.home must be set
> ---
>
> Key: SLING-835
> URL: https://issues.apache.org/jira/browse/SLING-835
> Project: Sling
> Issue Type: Improvement
> Components: Scripting
>Reporter: Felix Meschberger
>
> It seems that currently the python.home property is not set for the
> PythonInterpreter, which causes the cachedir containing some Java Library
> stuff caches to be created in the current working directory.
> I think, the PythonScriptEngineFactory should setup the PythonInterpreter
> with correct setup information by calling the static
> PythonInterpreter.initialize method before creating the first
> PythonScriptEngine instance.
--
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
[
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] Commented: (SLING-922) Load modules on startup from an external directory
[
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 r
[jira] Updated: (SLING-922) Load modules on startup from an external directory
[
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
[
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
[
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
[
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-939) Adapt the Http Authenticator to the refined authentication process
[ https://issues.apache.org/jira/browse/SLING-939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12701888#action_12701888 ] Aaron Zeckoski commented on SLING-939: -- That makes sense. I was thinking something like checking for "overrideTemplate" before getting the default one but storing in the repo would be good. My only possible issue with that is setting up a new one the first time sling starts up would be annoying (unless there is some way to push things into the repo on startup?). If there is no way to push things into the repo on startup I would recommend doing something like allowing a bundle fragment to control this. > Adapt the Http Authenticator to the refined authentication process > -- > > Key: SLING-939 > URL: https://issues.apache.org/jira/browse/SLING-939 > Project: Sling > Issue Type: Sub-task > Components: Extensions >Affects Versions: Extensions httpauth 2.0.2 >Reporter: Felix Meschberger >Assignee: Felix Meschberger > > Adapt the HTTP Header authentication handler to the new refined > authenticaiton initiation processing implemented by SLING-938. > Tasks: > * The LoginServlet calls the new requestAuthentication service method > * requestAuthentication method will now draw the login form -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-939) Adapt the Http Authenticator to the refined authentication process
[ https://issues.apache.org/jira/browse/SLING-939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12701859#action_12701859 ] Aaron Zeckoski commented on SLING-939: -- Should be possible to update it via a bundle fragment though right? > Adapt the Http Authenticator to the refined authentication process > -- > > Key: SLING-939 > URL: https://issues.apache.org/jira/browse/SLING-939 > Project: Sling > Issue Type: Sub-task > Components: Extensions >Affects Versions: Extensions httpauth 2.0.2 >Reporter: Felix Meschberger >Assignee: Felix Meschberger > > Adapt the HTTP Header authentication handler to the new refined > authenticaiton initiation processing implemented by SLING-938. > Tasks: > * The LoginServlet calls the new requestAuthentication service method > * requestAuthentication method will now draw the login form -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[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
[
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] Updated: (SLING-919) Cannot configure the Jetty in Sling because of the old version of pax-web
[ https://issues.apache.org/jira/browse/SLING-919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Zeckoski updated SLING-919: - Attachment: sling-pax-0.6.0.patch > Cannot configure the Jetty in Sling because of the old version of pax-web > - > > Key: SLING-919 > URL: https://issues.apache.org/jira/browse/SLING-919 > Project: Sling > Issue Type: Improvement > Components: General, Launchpad, Launchpad Launcher >Reporter: Aaron Zeckoski >Priority: Critical > Attachments: sling-pax-0.5.3.patch, sling-pax-0.6.0.patch > > Original Estimate: 0.25h > Remaining Estimate: 0.25h > > The old versions of pax-web make it impossible to configure Jetty since the > ability to configure was added to version 0.5.2 and version 0.2.3 was used > (0.5.1 in the newest trunk maybe). Apparently 0.5.3 is needed because of > weird escaping issue in pax-web 0.5.2 (SLING-918) so the version should be > updated to 0.5.3. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-919) Cannot configure the Jetty in Sling because of the old version of pax-web
[ https://issues.apache.org/jira/browse/SLING-919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Zeckoski updated SLING-919: - Component/s: General Priority: Critical (was: Major) The new version of pax-web is availableat 0.6.0. I am attaching a new patch. http://repository.ops4j.org/maven2/org/ops4j/pax/web/pax-web-service/0.6.0/pax-web-service-0.6.0.jar > Cannot configure the Jetty in Sling because of the old version of pax-web > - > > Key: SLING-919 > URL: https://issues.apache.org/jira/browse/SLING-919 > Project: Sling > Issue Type: Improvement > Components: General, Launchpad, Launchpad Launcher >Reporter: Aaron Zeckoski >Priority: Critical > Attachments: sling-pax-0.5.3.patch > > Original Estimate: 0.25h > Remaining Estimate: 0.25h > > The old versions of pax-web make it impossible to configure Jetty since the > ability to configure was added to version 0.5.2 and version 0.2.3 was used > (0.5.1 in the newest trunk maybe). Apparently 0.5.3 is needed because of > weird escaping issue in pax-web 0.5.2 (SLING-918) so the version should be > updated to 0.5.3. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-919) Cannot configure the Jetty in Sling because of the old version of pax-web
[ https://issues.apache.org/jira/browse/SLING-919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12697461#action_12697461 ] Aaron Zeckoski commented on SLING-919: -- Created a request in the paxweb jira so we can (maybe) more easily track when the 0.5.3 release is ready. http://issues.ops4j.org/browse/PAXWEB-132 > Cannot configure the Jetty in Sling because of the old version of pax-web > - > > Key: SLING-919 > URL: https://issues.apache.org/jira/browse/SLING-919 > Project: Sling > Issue Type: Improvement > Components: Launchpad, Launchpad Launcher >Reporter: Aaron Zeckoski > Attachments: sling-pax-0.5.3.patch > > Original Estimate: 0.25h > Remaining Estimate: 0.25h > > The old versions of pax-web make it impossible to configure Jetty since the > ability to configure was added to version 0.5.2 and version 0.2.3 was used > (0.5.1 in the newest trunk maybe). Apparently 0.5.3 is needed because of > weird escaping issue in pax-web 0.5.2 (SLING-918) so the version should be > updated to 0.5.3. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-919) Cannot configure the Jetty in Sling because of the old version of pax-web
[ https://issues.apache.org/jira/browse/SLING-919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Zeckoski updated SLING-919: - Attachment: sling-pax-0.5.3.patch This patch should work once the 0.5.3 version is out, though it is a patch from 0.2.3 to 0.5.3 so it would need to be slightly tweaked if applied to the newest trunk. > Cannot configure the Jetty in Sling because of the old version of pax-web > - > > Key: SLING-919 > URL: https://issues.apache.org/jira/browse/SLING-919 > Project: Sling > Issue Type: Improvement > Components: Launchpad, Launchpad Launcher >Reporter: Aaron Zeckoski > Attachments: sling-pax-0.5.3.patch > > Original Estimate: 0.25h > Remaining Estimate: 0.25h > > The old versions of pax-web make it impossible to configure Jetty since the > ability to configure was added to version 0.5.2 and version 0.2.3 was used > (0.5.1 in the newest trunk maybe). Apparently 0.5.3 is needed because of > weird escaping issue in pax-web 0.5.2 (SLING-918) so the version should be > updated to 0.5.3. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-919) Cannot configure the Jetty in Sling because of the old version of pax-web
Cannot configure the Jetty in Sling because of the old version of pax-web - Key: SLING-919 URL: https://issues.apache.org/jira/browse/SLING-919 Project: Sling Issue Type: Improvement Components: Launchpad, Launchpad Launcher Reporter: Aaron Zeckoski The old versions of pax-web make it impossible to configure Jetty since the ability to configure was added to version 0.5.2 and version 0.2.3 was used (0.5.1 in the newest trunk maybe). Apparently 0.5.3 is needed because of weird escaping issue in pax-web 0.5.2 (SLING-918) so the version should be updated to 0.5.3. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
