[jira] Updated: (SLING-604) Multi value properties not properly supported by ScriptableNode.get(String) method
[
https://issues.apache.org/jira/browse/SLING-604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Felix Meschberger updated SLING-604:
Fix Version/s: (was: Scripting JavaScript 2.1.0)
Descheduling. Will be fixed in a future release.
> Multi value properties not properly supported by ScriptableNode.get(String)
> method
> --
>
> Key: SLING-604
> URL: https://issues.apache.org/jira/browse/SLING-604
> Project: Sling
> Issue Type: Bug
> Components: Scripting JavaScript (Rhino)
>Affects Versions: Scripting JavaScript 2.0.2
>Reporter: Felix Meschberger
>Assignee: Felix Meschberger
>
> It seems that mutlivalue properties are not properly supported by the
> ScriptableNode.get(String) method. The construct
>someNode.prop
> should return an array of values if the property is multi-valued even in the
> case of the array only containing a single value.
> Paul Davis reported in [1] that the construct
><% for(var i=0; i
><%= currentNode.trackId[i] %>
><% } %>
> listed the single characters of the single value of the trackid property in
> case the trackid is a multi-valued property with just a single value. The
> actual property seems to be a proper multivalue property because
>var items = currentNode.getProperty("trackId").values;
>for( var i=0; i < items.length; i++ ) {
>...
>}
> works correctly.
> [1] http://markmail.org/message/rbnsfolm3yq6thfv
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (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:all-tabpanel ] Felix Meschberger closed SLING-939. --- Resolution: Fixed Fix Version/s: Extensions httpauth 2.0.4 Works fine, therefore closing. > 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 > Fix For: Extensions httpauth 2.0.4 > > > 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] Closed: (SLING-938) Refine initiaition of the authentication process
[ https://issues.apache.org/jira/browse/SLING-938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger closed SLING-938. --- Resolution: Fixed This looks good now and seems to work fine. Therefore closing this issue. > Refine initiaition of the authentication process > > > Key: SLING-938 > URL: https://issues.apache.org/jira/browse/SLING-938 > Project: Sling > Issue Type: Improvement > Components: Engine >Affects Versions: Engine 2.0.2 >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: Engine 2.0.4 > > > Currently the authentication process can only be initiated by explicitly > calling a login page provided by some AuthenticationHandler implementation > bundle. There is no way to initiate the authentication process from within a > servlet or script (e.g. to have the user log in a 404/NOT FOUND error > handler). > To support this kind of functionality the existing > SlingAuthenticator.requestAuthentcation method should be publicly accessible > through Service interface. Servlets or scripts which want to request > authentication from the client for the current request may then call this > service method. > This method applies the same authentication handler selection algorithm for > the given HttpServletRequest object as it does for finding the authentication > handler in the authenticate process. This ensures, that for a given request, > the appropriate authentication handler is called which is then able to > initiate authentication appropriately, for example by drawing a form. > For full details refer to > http://cwiki.apache.org/SLING/authentication-initiation.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-841) Set thread context class loader on behalf of script engines
[ https://issues.apache.org/jira/browse/SLING-841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated SLING-841: Fix Version/s: (was: Scripting Core 2.0.4) Descheduling from the release. This needs to be considered very carefully. In addition, we might even create a common parent class loader for all script engines which includes support for Resource tree based classes. > Set thread context class loader on behalf of script engines > --- > > Key: SLING-841 > URL: https://issues.apache.org/jira/browse/SLING-841 > Project: Sling > Issue Type: Improvement > Components: Scripting >Affects Versions: Scripting Core 2.0.2 >Reporter: Felix Meschberger >Assignee: Felix Meschberger > > Often times script engines might expect the thread class loader to be set to > the correct instance. Most notably if any scripts are using JAXP, setting the > thread context class loader correctly is crucial to executing the script > correctly. > One solution would be to delegate setting the contetx class loader to the > script engine. Since this is a common task, I would argue, that the thread > context class loader should be set by the scripting core module, which calls > into the script engines. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-926) Do not render directory on included request
[ https://issues.apache.org/jira/browse/SLING-926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated SLING-926: Needs more brainjuice but don't want to block the release with this right now. Therefore descheduling. > Do not render directory on included request > --- > > Key: SLING-926 > URL: https://issues.apache.org/jira/browse/SLING-926 > Project: Sling > Issue Type: Bug > Components: Servlets Get >Affects Versions: Servlets Get 2.0.4 >Reporter: Felix Meschberger >Assignee: Felix Meschberger > > As of SLING-723, the StreamRendererServlet contains functionality to render > an index (directory listing) or send 403/FORBIDDEN if rendering the index is > disabled by configuration. > This works like this: >* If request has trailing slash -> render directory or send 403 >* Else If resource adapts to a stream -> spool the stream >* Else redirect to the same URL with a trailing slash > This all perfectly works if this mechanism handles the request directly. If > this mechanism is triggered in an included resource, where a directly > addressed resource includes another resource, which is then handled by the > StreamRendererServlet, this should probably be different: >* If the resource adapts to a stream -> spool the stream >* Else do nothing (but log this situation and add an entry in the > RequestProgressTracker -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-926) Do not render directory on included request
[ https://issues.apache.org/jira/browse/SLING-926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated SLING-926: Fix Version/s: (was: Servlets Post 2.0.4) > Do not render directory on included request > --- > > Key: SLING-926 > URL: https://issues.apache.org/jira/browse/SLING-926 > Project: Sling > Issue Type: Bug > Components: Servlets Get >Affects Versions: Servlets Get 2.0.4 >Reporter: Felix Meschberger >Assignee: Felix Meschberger > > As of SLING-723, the StreamRendererServlet contains functionality to render > an index (directory listing) or send 403/FORBIDDEN if rendering the index is > disabled by configuration. > This works like this: >* If request has trailing slash -> render directory or send 403 >* Else If resource adapts to a stream -> spool the stream >* Else redirect to the same URL with a trailing slash > This all perfectly works if this mechanism handles the request directly. If > this mechanism is triggered in an included resource, where a directly > addressed resource includes another resource, which is then handled by the > StreamRendererServlet, this should probably be different: >* If the resource adapts to a stream -> spool the stream >* Else do nothing (but log this situation and add an entry in the > RequestProgressTracker -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: JCR2 upgrade plans ?
hi guys, > I think that Sling should be able to run on JCR 1.0 for a long time; we > shouldn't tie us to a new version; however, of course we might have some > optional functionality requiring JCR 2.0. i think we should naturally embrace jcr 2.0, i don't really think that we will have backwards compatibility issues since i would not expect that there are other repositories than jackrabbit that are currently used with sling. so in my opinion we should probably use jcr 2.0 where it makes sense particularly over proprietary jackrabbit apis as soon as they are available in jackrabbit... thoughts? regards, david
Re: JCR2 upgrade plans ?
Hi, On Mon, May 4, 2009 at 8:29 AM, Carsten Ziegeler wrote: > I think that Sling should be able to run on JCR 1.0 for a long time; we > shouldn't tie us to a new version; however, of course we might have some > optional functionality requiring JCR 2.0. >From a functionality perspective JCR 1.0 already covers mostly everything Sling needs, though there are a few things in JCR 2.0 like the more flexible node type handling (setPrimaryType!) and improved query features that may be of interest to Sling. And regardless of the JCR API version, it probably makes sense for Sling to upgrade to Jackrabbit 2.x once it's available. BR, Jukka Zitting
[jira] Updated: (SLING-950) Remove old ResourceResolver implementation
[ https://issues.apache.org/jira/browse/SLING-950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated SLING-950: Component/s: JCR Resource > Remove old ResourceResolver implementation > -- > > Key: SLING-950 > URL: https://issues.apache.org/jira/browse/SLING-950 > Project: Sling > Issue Type: Task > Components: JCR Resource >Affects Versions: JCR Resource 2.0.4 >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: JCR Resource 2.0.4 > > > As of SLING- a new ResourceResolver implementation -- JcrResourceResovler2 > -- has been implemented and put into use. The old implementation -- > JcrResourceResolver -- still exists and may still be used setting a > configuration switch. > After having the new resolver in use for some time now, the old one should be > removed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-951) Namespace Mangling inaccurate due to namespace registrations
Namespace Mangling inaccurate due to namespace registrations Key: SLING-951 URL: https://issues.apache.org/jira/browse/SLING-951 Project: Sling Issue Type: Bug Components: JCR Resource Affects Versions: JCR Resource 2.0.4 Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: JCR Resource 2.0.4 Namespace mangling internally uses a cache of mapped name spaces. This cache is not updated if new namespaces are registered or registered namespaces are unregistered because there is no update notification mechanism. This may cause name space mangling to fail (false positives or false negatives) of the namespace mapping is changed during the lifetime of the namespace prefix cache. The fix to this problem is to not cache the namespace prefixes anymore and ask the session's namespace provider any time a potential namespace prefix is encountered. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (SLING-951) Namespace Mangling inaccurate due to namespace registrations
[ https://issues.apache.org/jira/browse/SLING-951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger closed SLING-951. --- Resolution: Fixed Removed namespace prefix cache in Rev. 771223. > Namespace Mangling inaccurate due to namespace registrations > > > Key: SLING-951 > URL: https://issues.apache.org/jira/browse/SLING-951 > Project: Sling > Issue Type: Bug > Components: JCR Resource >Affects Versions: JCR Resource 2.0.4 >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: JCR Resource 2.0.4 > > > Namespace mangling internally uses a cache of mapped name spaces. This cache > is not updated if new namespaces are registered or registered namespaces are > unregistered because there is no update notification mechanism. > This may cause name space mangling to fail (false positives or false > negatives) of the namespace mapping is changed during the lifetime of the > namespace prefix cache. > The fix to this problem is to not cache the namespace prefixes anymore and > ask the session's namespace provider any time a potential namespace prefix is > encountered. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Hudson build is still unstable: sling-contrib-1. 5 » Apache Sling Launchpad Contrib Testing #13
Hi, On Mon, May 4, 2009 at 8:27 AM, Carsten Ziegeler wrote: > Is it possible to configure Hudson to only send mails if the status changed? Yes, there's a "Send e-mail for every unstable build" option that's enabled by default. I've disabled it for now, but it would still be good to fix the build breakage. BR, Jukka Zitting
Re: JCR2 upgrade plans ?
Hi, On Sun, May 3, 2009 at 7:10 AM, Felix Meschberger wrote: > In fact, many Jackrabbit libraries already come as bundles > (jackrabbit-api, jackrabbit-jcr-commons, jackrabbit-jcr-rmi), why not > the rest also ? Good question. Patches/commits are welcome. :-) There's already an issue reported for this (https://issues.apache.org/jira/browse/JCR-1991), but so far nobody has had the time or know-how to make this happen. I'd love to have OSGi metadata included already in Jackrabbit 1.6. BR, Jukka Zitting
Updated Hudson settings
Hi, I've changed the Hudson settings a bit: * Changed the svn poll interval from 15 minutes to 1 hour based on infra recommendation * Removed the timed nightly build option, as the build jobs are already executed whenever there are code or dependency changes. Extra nightly builds serve little purpose and only produce the "still broken" notifications that people find annoying. * Disabled the "Send e-mail for every unstable build" option for sling-contrib-1.5, though in light of the above changes I think it could (should?) be re-enabled. A "still broken" notification is IMHO quite useful when it's bound to actual changes that people commit. BR, Jukka Zitting
[jira] Closed: (SLING-950) Remove old ResourceResolver implementation
[ https://issues.apache.org/jira/browse/SLING-950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger closed SLING-950. --- Resolution: Fixed Removed the old resource resolver implementation JcrResourceResolver together with its test class and configuration options in Rev. 771230. > Remove old ResourceResolver implementation > -- > > Key: SLING-950 > URL: https://issues.apache.org/jira/browse/SLING-950 > Project: Sling > Issue Type: Task > Components: JCR Resource >Affects Versions: JCR Resource 2.0.4 >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: JCR Resource 2.0.4 > > > As of SLING- a new ResourceResolver implementation -- JcrResourceResovler2 > -- has been implemented and put into use. The old implementation -- > JcrResourceResolver -- still exists and may still be used setting a > configuration switch. > After having the new resolver in use for some time now, the old one should be > removed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Hudson build is still unstable: sling-contrib-1. 5 » Apache Sling Launchpad Contrib Testing #13
On Mon, May 4, 2009 at 9:50 AM, Jukka Zitting wrote: > Hi, > > On Mon, May 4, 2009 at 8:27 AM, Carsten Ziegeler wrote: >> Is it possible to configure Hudson to only send mails if the status changed? > > Yes, there's a "Send e-mail for every unstable build" option that's > enabled by default. > > I've disabled it for now, but it would still be good to fix the build > breakage. Thanks! The breakage is SLING-946, and that problem doesn't happen on my (macosx) box, so I'll have to investigate further - a java call to the bnd library is failing in the Hudson environment but works fine here, I'll try on a Linux box to see if I can reproduce the problem. -Bertrand
Re: Updated Hudson settings
Hi, One more change: * The sling-trunk-1.6 job is now only build after a successful sling-trunk-1.5. This way we won't get duplicate warnings (separately for 1.5 and 1.6) about broken builds. BR, Jukka Zitting
Re: Updated Hudson settings
On Mon, May 4, 2009 at 9:58 AM, Jukka Zitting wrote: > I've changed the Hudson settings a bit: Thanks! We're using https://issues.apache.org/jira/browse/SLING-920 to keep track of the Hudson setup, I have added your comments there. -Bertrand
[jira] Commented: (SLING-920) Hudson continuous integration setup
[ https://issues.apache.org/jira/browse/SLING-920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12705519#action_12705519 ] Bertrand Delacretaz commented on SLING-920: --- Jukka says, on sling-dev: I've changed the Hudson settings a bit: * Changed the svn poll interval from 15 minutes to 1 hour based on infra recommendation * Removed the timed nightly build option, as the build jobs are already executed whenever there are code or dependency changes. Extra nightly builds serve little purpose and only produce the "still broken" notifications that people find annoying. * Disabled the "Send e-mail for every unstable build" option for sling-contrib-1.5, though in light of the above changes I think it could (should?) be re-enabled. A "still broken" notification is IMHO quite useful when it's bound to actual changes that people commit. > Hudson continuous integration setup > --- > > Key: SLING-920 > URL: https://issues.apache.org/jira/browse/SLING-920 > Project: Sling > Issue Type: Task > Components: Testing >Reporter: Bertrand Delacretaz > > Use this issue to record changes to the Hudson continuous environment setup > at http://hudson.zones.apache.org/hudson/view/Sling/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-920) Hudson continuous integration setup
[ https://issues.apache.org/jira/browse/SLING-920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12705520#action_12705520 ] Jukka Zitting commented on SLING-920: - One more change * The sling-trunk-1.6 job is now only build after a successful sling-trunk-1.5. This way we won't get duplicate warnings (separately for 1.5 and 1.6) about broken builds. > Hudson continuous integration setup > --- > > Key: SLING-920 > URL: https://issues.apache.org/jira/browse/SLING-920 > Project: Sling > Issue Type: Task > Components: Testing >Reporter: Bertrand Delacretaz > > Use this issue to record changes to the Hudson continuous environment setup > at http://hudson.zones.apache.org/hudson/view/Sling/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: JCR2 upgrade plans ?
2009/5/3 Ian Boston > I think this may be a question of what is exported from the bundle. At the > moment the jackrabbit-server bundle doesn't expose much more than the real > API's which IMHO is correct, however it does mean that customizations have to > live inside the server bundle. As you say, this has been done to make the > access manager pluggable in trunk Sling. But this was done because of the way DefaultAccessManager is linked to the rest of the Jackrabbit stuff. If DefaultAccessManager could be separated out in a bundle of its own, we would have a pluggable accessmanager by definition. -- Vidar S. Ramdal - http://www.idium.no Akersgata 16, N-0158 Oslo, Norway +47 21 531941, ext 2070
Re: Welcome Mike Mueller as Documentation Committer
2009/4/30 Felix Meschberger : > Based on his sustained contributions to the Sling documentation in the > last months, the Sling PPMC has decided to give Mike Müller write access > to the Sling website content wiki. > > Thanks again, Mike, for your contributions and keep up the good work. Great! Welcome on board, Mike! -- Vidar S. Ramdal - http://www.idium.no Akersgata 16, N-0158 Oslo, Norway +47 21 531941, ext 2070
Re: [VOTE] Update to Community Roles and Processes
2009/5/1 Felix Meschberger : > We can leave the vote open for more time, no problem with me. And we can > continue to discuss. +1 -- Vidar S. Ramdal - http://www.idium.no Akersgata 16, N-0158 Oslo, Norway +47 21 531941, ext 2070
[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=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 repla
[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
]
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] Created: (SLING-952) ant task in dojo build does not use Maven proxy settings for downloading
ant task in dojo build does not use Maven proxy settings for downloading Key: SLING-952 URL: https://issues.apache.org/jira/browse/SLING-952 Project: Sling Issue Type: Bug Components: Extensions Reporter: Bertrand Delacretaz Priority: Minor The ant task used in /contrib/extensions/dojo/pom.xml does not seem to use the current Maven proxy settings. Workaround is to download the dojo release file manually and place it in the download-cache folder. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Updated Hudson settings
Hi, Bertrand Delacretaz schrieb: > On Mon, May 4, 2009 at 9:58 AM, Jukka Zitting wrote: >> I've changed the Hudson settings a bit: > > Thanks! +1 > > We're using https://issues.apache.org/jira/browse/SLING-920 to keep > track of the Hudson setup, I have added your comments there. Shoudn't we document this on the Wiki or the Site ? Regards Felix
[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=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.
Build failed in Hudson: sling-contrib-1.5 » Apache Sling JCR OSGi Installer Service #15
See
http://hudson.zones.apache.org/hudson/job/sling-contrib-1.5/org.apache.sling$org.apache.sling.jcr.jcrinstall/15/
--
[INFO]
[INFO] Building Apache Sling JCR OSGi Installer Service
[INFO]task-segment: [clean, install]
[INFO]
[INFO] [clean:clean]
[INFO] Deleting directory
http://hudson.zones.apache.org/hudson/job/sling-contrib-1.5/org.apache.sling$org.apache.sling.jcr.jcrinstall/ws/target
[INFO] [enforcer:enforce {execution: enforce-java}]
[INFO] [resources:resources]
[WARNING] Using platform encoding (UTF-8 actually) to copy filtered resources,
i.e. build is platform dependent!
[INFO] Copying 2 resources
[INFO] [antrun:run {execution: default}]
[INFO] Executing tasks
[echo] ** WARNING (SLING-443)
**
[echo] On most platforms, building Sling currently requires setting
[echo] MAVEN_OPTS="-Xmx256M", see
https://issues.apache.org/jira/browse/SLING-443
[echo] You might get a "java.lang.OutOfMemoryError: Java heap space" if
that
[echo] setting is not correct.
[echo]
*
[INFO] Executed tasks
[INFO] [compiler:compile]
[INFO] Compiling 32 source files to
http://hudson.zones.apache.org/hudson/job/sling-contrib-1.5/org.apache.sling$org.apache.sling.jcr.jcrinstall/ws/target/classes
[INFO] [scr:scr {execution: generate-scr-scrdescriptor}]
[INFO] Generating 2 MetaType Descriptors to
http://hudson.zones.apache.org/hudson/job/sling-contrib-1.5/org.apache.sling$org.apache.sling.jcr.jcrinstall/ws/target/scr-plugin-generated/OSGI-INF/metatype/metatype.xml
[INFO] Writing abstract service descriptor
http://hudson.zones.apache.org/hudson/job/sling-contrib-1.5/org.apache.sling$org.apache.sling.jcr.jcrinstall/ws/target/scr-plugin-generated/OSGI-INF/scr-plugin/scrinfo.xml
with 2 entries.
[INFO] Generating 2 Service Component Descriptors to
http://hudson.zones.apache.org/hudson/job/sling-contrib-1.5/org.apache.sling$org.apache.sling.jcr.jcrinstall/ws/target/scr-plugin-generated/OSGI-INF/serviceComponents.xml
[INFO] [resources:testResources]
[WARNING] Using platform encoding (UTF-8 actually) to copy filtered resources,
i.e. build is platform dependent!
[INFO] skip non existing resourceDirectory
http://hudson.zones.apache.org/hudson/job/sling-contrib-1.5/org.apache.sling$org.apache.sling.jcr.jcrinstall/ws/src/test/resources
[INFO] [compiler:testCompile]
[INFO] Compiling 19 source files to
http://hudson.zones.apache.org/hudson/job/sling-contrib-1.5/org.apache.sling$org.apache.sling.jcr.jcrinstall/ws/target/test-classes
[HUDSON] Archiving
http://hudson.zones.apache.org/hudson/job/sling-contrib-1.5/org.apache.sling$org.apache.sling.jcr.jcrinstall/ws/pom.xml
to
/export/home/hudson/hudson/jobs/sling-contrib-1.5/modules/org.apache.sling$org.apache.sling.jcr.jcrinstall/builds/2009-05-04_09-44-28/archive/org.apache.sling/org.apache.sling.jcr.jcrinstall/2.0.3-incubator-SNAPSHOT/pom.xml
May 4, 2009 3:11:54 AM hudson.remoting.Channel$ReaderThread run
SEVERE: Unable to read a command
java.lang.ClassNotFoundException: hudson.remoting.ProxyOutputStream$Unexport
at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at
org.codehaus.classworlds.RealmClassLoader.loadClassDirect(RealmClassLoader.java:195)
at
org.codehaus.classworlds.DefaultClassRealm.loadClass(DefaultClassRealm.java:255)
at
org.codehaus.classworlds.DefaultClassRealm.loadClass(DefaultClassRealm.java:274)
at
org.codehaus.classworlds.DefaultClassRealm.loadClass(DefaultClassRealm.java:274)
at
org.codehaus.classworlds.RealmClassLoader.loadClass(RealmClassLoader.java:214)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:242)
at java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:585)
at
java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1544)
at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1466)
at
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1699)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348)
at hudson.remoting.Channel$ReaderThread.run(Channel.java:637)
[INFO]
[ERROR] BUILD FAILURE
[INFO]
Re: Updated Hudson settings
Hi, Bertrand Delacretaz schrieb: > On Mon, May 4, 2009 at 11:41 AM, Felix Meschberger wrote: >>> We're using https://issues.apache.org/jira/browse/SLING-920 to keep >>> track of the Hudson setup, I have added your comments there. >> Shoudn't we document this on the Wiki or the Site ? > > We could, but a JIRA issue is a nice way to keep track of the history > of our Hudson configurations. > > For now, Hudson is mentioned at > http://incubator.apache.org/sling/site/project-information.html#ProjectInformation-ci > with a link to that issue. Ok, this should do it, I think. Thanks for the reminder. Regards Felix
Re: Build failed in Hudson: sling-contrib-1.5 » Apa che Sling JCR OSGi Installer Service #15
On Mon, May 4, 2009 at 11:52 AM, Apache Hudson Server wrote: > See > http://hudson.zones.apache.org/hudson/job/sling-contrib-1.5/org.apache.sling$org.apache.sling.jcr.jcrinstall/15/ My bad...just broke the tests ;-) -Bertrand
Re: Updated Hudson settings
On Mon, May 4, 2009 at 11:41 AM, Felix Meschberger wrote: >> We're using https://issues.apache.org/jira/browse/SLING-920 to keep >> track of the Hudson setup, I have added your comments there. > > Shoudn't we document this on the Wiki or the Site ? We could, but a JIRA issue is a nice way to keep track of the history of our Hudson configurations. For now, Hudson is mentioned at http://incubator.apache.org/sling/site/project-information.html#ProjectInformation-ci with a link to that issue. -Bertrand
Re: Sling Release
Hi Carsten, There is currently a single issue (SLING-933 [1]) open. We have a request by Aaron Zeckoski to also include SLING-933 [2] in the release. For SLING-933 I will have to wait a few hours for the Apache Felix SCR bundle 1.0.8 to hit the central maven repository, at which time I will then fix this issue. For SLING-933: Aaron provided a pretty good patch, to which I had some comments. I am not sure, whether we should stop the release to wait for this (valuable) addition. I would rather like to go with the release and take our time to cleanly implement this new feature and release the launchpad/base module as soon as we are done. Apart from these issues, there are none left [3]. The others mentioned in an earlier posts have either been closed (SLING-793, SLING-938) or I descheduled (SLING-926, SLING-604, SLING-841) them for a later release. Regards Felix [1] https://issues.apache.org/jira/browse/SLING-933 [2] https://issues.apache.org/jira/browse/SLING-922 [3] https://issues.apache.org/jira/secure/IssueNavigator.jspa?requestId=12312970 Carsten Ziegeler schrieb: > Hello everyone, > > I'm planning to do the release next monday or tuesday. > We have two missing pieces atm, one is the Felix framework 1.6.1 release > (which should be available now) and the Felix SCR 1.0.8 implementation > (which should be available by monday). > > So if you think that we need to anything in svn before the release, this > is the time to step up :) > > I'll release the modules in bundles, launchpad and maven plugins and > will create a single release download like we did for our first release > for convenience. > > After this big release we can think about releasing samples etc. separately. > > Regards > Carsten
Build failed in Hudson: sling-contrib-1.5 » Apache Sling JCR OSGi Installer Service #16
See
http://hudson.zones.apache.org/hudson/job/sling-contrib-1.5/org.apache.sling$org.apache.sling.jcr.jcrinstall/16/
--
[INFO]
[INFO] Building Apache Sling JCR OSGi Installer Service
[INFO]task-segment: [clean, install]
[INFO]
[INFO] [clean:clean]
[INFO] Deleting directory
http://hudson.zones.apache.org/hudson/job/sling-contrib-1.5/org.apache.sling$org.apache.sling.jcr.jcrinstall/ws/target
[INFO] [enforcer:enforce {execution: enforce-java}]
[INFO] [resources:resources]
[WARNING] Using platform encoding (UTF-8 actually) to copy filtered resources,
i.e. build is platform dependent!
[INFO] Copying 2 resources
[INFO] [antrun:run {execution: default}]
[INFO] Executing tasks
[echo] ** WARNING (SLING-443)
**
[echo] On most platforms, building Sling currently requires setting
[echo] MAVEN_OPTS="-Xmx256M", see
https://issues.apache.org/jira/browse/SLING-443
[echo] You might get a "java.lang.OutOfMemoryError: Java heap space" if
that
[echo] setting is not correct.
[echo]
*
[INFO] Executed tasks
[INFO] [compiler:compile]
[INFO] Compiling 32 source files to
http://hudson.zones.apache.org/hudson/job/sling-contrib-1.5/org.apache.sling$org.apache.sling.jcr.jcrinstall/ws/target/classes
[INFO] [scr:scr {execution: generate-scr-scrdescriptor}]
[INFO] Generating 2 MetaType Descriptors to
http://hudson.zones.apache.org/hudson/job/sling-contrib-1.5/org.apache.sling$org.apache.sling.jcr.jcrinstall/ws/target/scr-plugin-generated/OSGI-INF/metatype/metatype.xml
[INFO] Writing abstract service descriptor
http://hudson.zones.apache.org/hudson/job/sling-contrib-1.5/org.apache.sling$org.apache.sling.jcr.jcrinstall/ws/target/scr-plugin-generated/OSGI-INF/scr-plugin/scrinfo.xml
with 2 entries.
[INFO] Generating 2 Service Component Descriptors to
http://hudson.zones.apache.org/hudson/job/sling-contrib-1.5/org.apache.sling$org.apache.sling.jcr.jcrinstall/ws/target/scr-plugin-generated/OSGI-INF/serviceComponents.xml
[INFO] [resources:testResources]
[WARNING] Using platform encoding (UTF-8 actually) to copy filtered resources,
i.e. build is platform dependent!
[INFO] skip non existing resourceDirectory
http://hudson.zones.apache.org/hudson/job/sling-contrib-1.5/org.apache.sling$org.apache.sling.jcr.jcrinstall/ws/src/test/resources
[INFO] [compiler:testCompile]
[INFO] Compiling 19 source files to
http://hudson.zones.apache.org/hudson/job/sling-contrib-1.5/org.apache.sling$org.apache.sling.jcr.jcrinstall/ws/target/test-classes
[HUDSON] Archiving
http://hudson.zones.apache.org/hudson/job/sling-contrib-1.5/org.apache.sling$org.apache.sling.jcr.jcrinstall/ws/pom.xml
to
/export/home/hudson/hudson/jobs/sling-contrib-1.5/modules/org.apache.sling$org.apache.sling.jcr.jcrinstall/builds/2009-05-04_11-33-16/archive/org.apache.sling/org.apache.sling.jcr.jcrinstall/2.0.3-incubator-SNAPSHOT/pom.xml
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] Compilation failure
http://hudson.zones.apache.org/hudson/job/sling-contrib-1.5/org.apache.sling$org.apache.sling.jcr.jcrinstall/ws/src/test/java/org/apache/sling/jcr/jcrinstall/osgi/impl/BundleResourceProcessorTest.java
:[113,92] 'void' type not allowed here
http://hudson.zones.apache.org/hudson/job/sling-contrib-1.5/org.apache.sling$org.apache.sling.jcr.jcrinstall/ws/src/test/java/org/apache/sling/jcr/jcrinstall/osgi/impl/BundleResourceProcessorTest.java
:[119,89] 'void' type not allowed here
http://hudson.zones.apache.org/hudson/job/sling-contrib-1.5/org.apache.sling$org.apache.sling.jcr.jcrinstall/ws/src/test/java/org/apache/sling/jcr/jcrinstall/osgi/impl/BundleResourceProcessorTest.java
:[131,78] 'void' type not allowed here
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
[INFO] Total time: 8 minutes 25 seconds
[INFO] Finished at: Mon May 04 05:01:05 PDT 2009
[INFO] Final Memory: 27M/62M
[INFO]
Build failed in Hudson: sling-contrib-1.5 » Apache Sling JCR OSGi Installer Service #17
See
http://hudson.zones.apache.org/hudson/job/sling-contrib-1.5/org.apache.sling$org.apache.sling.jcr.jcrinstall/17/
--
[INFO]
[INFO] Building Apache Sling JCR OSGi Installer Service
[INFO]task-segment: [clean, install]
[INFO]
[INFO] [clean:clean]
[INFO] Deleting directory
http://hudson.zones.apache.org/hudson/job/sling-contrib-1.5/org.apache.sling$org.apache.sling.jcr.jcrinstall/ws/target
[INFO] [enforcer:enforce {execution: enforce-java}]
[INFO] [resources:resources]
[WARNING] Using platform encoding (UTF-8 actually) to copy filtered resources,
i.e. build is platform dependent!
[INFO] Copying 2 resources
[INFO] [antrun:run {execution: default}]
[INFO] Executing tasks
[echo] ** WARNING (SLING-443)
**
[echo] On most platforms, building Sling currently requires setting
[echo] MAVEN_OPTS="-Xmx256M", see
https://issues.apache.org/jira/browse/SLING-443
[echo] You might get a "java.lang.OutOfMemoryError: Java heap space" if
that
[echo] setting is not correct.
[echo]
*
[INFO] Executed tasks
[INFO] [compiler:compile]
[INFO] Compiling 32 source files to
http://hudson.zones.apache.org/hudson/job/sling-contrib-1.5/org.apache.sling$org.apache.sling.jcr.jcrinstall/ws/target/classes
[INFO] [scr:scr {execution: generate-scr-scrdescriptor}]
[INFO] Generating 2 MetaType Descriptors to
http://hudson.zones.apache.org/hudson/job/sling-contrib-1.5/org.apache.sling$org.apache.sling.jcr.jcrinstall/ws/target/scr-plugin-generated/OSGI-INF/metatype/metatype.xml
[INFO] Writing abstract service descriptor
http://hudson.zones.apache.org/hudson/job/sling-contrib-1.5/org.apache.sling$org.apache.sling.jcr.jcrinstall/ws/target/scr-plugin-generated/OSGI-INF/scr-plugin/scrinfo.xml
with 2 entries.
[INFO] Generating 2 Service Component Descriptors to
http://hudson.zones.apache.org/hudson/job/sling-contrib-1.5/org.apache.sling$org.apache.sling.jcr.jcrinstall/ws/target/scr-plugin-generated/OSGI-INF/serviceComponents.xml
[INFO] [resources:testResources]
[WARNING] Using platform encoding (UTF-8 actually) to copy filtered resources,
i.e. build is platform dependent!
[INFO] skip non existing resourceDirectory
http://hudson.zones.apache.org/hudson/job/sling-contrib-1.5/org.apache.sling$org.apache.sling.jcr.jcrinstall/ws/src/test/resources
[INFO] [compiler:testCompile]
[INFO] Compiling 19 source files to
http://hudson.zones.apache.org/hudson/job/sling-contrib-1.5/org.apache.sling$org.apache.sling.jcr.jcrinstall/ws/target/test-classes
[HUDSON] Archiving
http://hudson.zones.apache.org/hudson/job/sling-contrib-1.5/org.apache.sling$org.apache.sling.jcr.jcrinstall/ws/pom.xml
to
/export/home/hudson/hudson/jobs/sling-contrib-1.5/modules/org.apache.sling$org.apache.sling.jcr.jcrinstall/builds/2009-05-04_11-42-07/archive/org.apache.sling/org.apache.sling.jcr.jcrinstall/2.0.3-incubator-SNAPSHOT/pom.xml
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] Compilation failure
http://hudson.zones.apache.org/hudson/job/sling-contrib-1.5/org.apache.sling$org.apache.sling.jcr.jcrinstall/ws/src/test/java/org/apache/sling/jcr/jcrinstall/osgi/impl/BundleResourceProcessorTest.java
:[113,92] 'void' type not allowed here
http://hudson.zones.apache.org/hudson/job/sling-contrib-1.5/org.apache.sling$org.apache.sling.jcr.jcrinstall/ws/src/test/java/org/apache/sling/jcr/jcrinstall/osgi/impl/BundleResourceProcessorTest.java
:[119,89] 'void' type not allowed here
http://hudson.zones.apache.org/hudson/job/sling-contrib-1.5/org.apache.sling$org.apache.sling.jcr.jcrinstall/ws/src/test/java/org/apache/sling/jcr/jcrinstall/osgi/impl/BundleResourceProcessorTest.java
:[131,78] 'void' type not allowed here
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
[INFO] Total time: 8 minutes 6 seconds
[INFO] Finished at: Mon May 04 05:09:32 PDT 2009
[INFO] Final Memory: 27M/60M
[INFO]
Re: Build failed in Hudson: sling-c ontrib-1.5 » Apache Sling JCR OSGi Instal ler Service #17
Hi,
Apache Hudson Server schrieb:
> [INFO] Compilation failure
>
> http://hudson.zones.apache.org/hudson/job/sling-contrib-1.5/org.apache.sling$org.apache.sling.jcr.jcrinstall/ws/src/test/java/org/apache/sling/jcr/jcrinstall/osgi/impl/BundleResourceProcessorTest.java
> :[113,92] 'void' type not allowed here
>
> http://hudson.zones.apache.org/hudson/job/sling-contrib-1.5/org.apache.sling$org.apache.sling.jcr.jcrinstall/ws/src/test/java/org/apache/sling/jcr/jcrinstall/osgi/impl/BundleResourceProcessorTest.java
> :[119,89] 'void' type not allowed here
>
> http://hudson.zones.apache.org/hudson/job/sling-contrib-1.5/org.apache.sling$org.apache.sling.jcr.jcrinstall/ws/src/test/java/org/apache/sling/jcr/jcrinstall/osgi/impl/BundleResourceProcessorTest.java
> :[131,78] 'void' type not allowed here
These are statements like:
assertEquals("First install returns INSTALLED", INSTALLED,
c.scheduleInstallOrUpdate(uri, data));
where the return value of scheduleInstallOrUpdate is being checked,
which hopefully is flagged by the compiler because this method does not
return anything since it is defined as "public void".
Regards
Felix
>
>
> [INFO]
>
> [INFO] For more information, run Maven with the -e switch
> [INFO]
>
> [INFO] Total time: 8 minutes 6 seconds
> [INFO] Finished at: Mon May 04 05:09:32 PDT 2009
> [INFO] Final Memory: 27M/60M
> [INFO]
>
>
>
Re: Build failed in Hudson: sling-contrib-1.5 » Apa che Sling JCR OSGi Installer Service #17
On Mon, May 4, 2009 at 2:23 PM, Felix Meschberger wrote:
> ...These are statements like:
>
> assertEquals("First install returns INSTALLED", INSTALLED,
> c.scheduleInstallOrUpdate(uri, data));
>
> where the return value of scheduleInstallOrUpdate is being checked,
> which hopefully is flagged by the compiler because this method does not
> return anything since it is defined as "public void"
Sure...I changed the return type this morning and did't change the
tests. Shame on me ;-)
-Bertrand
Re: Build failed in Hudson: sling-contrib-1.5 » Apa che Sling JCR OSGi Installer Service #17
Hi,
Bertrand Delacretaz schrieb:
> On Mon, May 4, 2009 at 2:23 PM, Felix Meschberger wrote:
>> ...These are statements like:
>>
>> assertEquals("First install returns INSTALLED", INSTALLED,
>> c.scheduleInstallOrUpdate(uri, data));
>>
>> where the return value of scheduleInstallOrUpdate is being checked,
>> which hopefully is flagged by the compiler because this method does not
>> return anything since it is defined as "public void"
>
> Sure...I changed the return type this morning and did't change the
> tests. Shame on me ;-)
I see , sorry, then ;-)
Regards
Felix
>
> -Bertrand
>
Re: storing repo content in svn
2009/5/3 Dominik Süß : > This initial-content can be deployed via the maven-sling-plugin. > JCR-Properties can be uploaded as JSON or XML File having the same name > (extended by .json or .xml) parallel to your targetnode. The structure you > have to use is the same as the default xml or json renderer. You may also use other XML formats, if you should need that, by using an XSLT stylesheet with your XML. This thread might be of interest: http://markmail.org/thread/qxi6qw77vgymrdim -- Vidar S. Ramdal - http://www.idium.no Akersgata 16, N-0158 Oslo, Norway +47 21 531941, ext 2070
Hudson build is back to normal: sling-contrib-1 .5 » Apache Sling JCR OSGi Installer Service #18
See http://hudson.zones.apache.org/hudson/job/sling-contrib-1.5/org.apache.sling$org.apache.sling.jcr.jcrinstall/18/
[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
Re: JCR2 upgrade plans ?
On 4 May 2009, at 09:37, Vidar Ramdal wrote: 2009/5/3 Ian Boston I think this may be a question of what is exported from the bundle. At the moment the jackrabbit-server bundle doesn't expose much more than the real API's which IMHO is correct, however it does mean that customizations have to live inside the server bundle. As you say, this has been done to make the access manager pluggable in trunk Sling. But this was done because of the way DefaultAccessManager is linked to the rest of the Jackrabbit stuff. If DefaultAccessManager could be separated out in a bundle of its own, we would have a pluggable accessmanager by definition. agreed. Is this likely to happen, as it would also make it much easier to extend the existing implementation? Ian -- Vidar S. Ramdal - http://www.idium.no Akersgata 16, N-0158 Oslo, Norway +47 21 531941, ext 2070
[jira] Closed: (SLING-933) Upgrade to latest SCR release
[ https://issues.apache.org/jira/browse/SLING-933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger closed SLING-933. --- Resolution: Fixed Upgraded in Rev. 771575 > Upgrade to latest SCR release > - > > Key: SLING-933 > URL: https://issues.apache.org/jira/browse/SLING-933 > Project: Sling > Issue Type: Sub-task > Components: Launchpad >Reporter: Felix Meschberger > Fix For: Launchpad Bundles 4 > > > Upgrade 1.0.7-SNAPSHOT with next SCR release once available from the Apache > Felix project. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
