Velocity Scripting Release 2.0.0 (was Velocity scripting support)
On Wed, Aug 25, 2010 at 4:23 PM, olaf.o...@css.ch wrote: ...I will also test the scripting support against the latest velocity release tomorrow, thereby also testing whether it integrates with the latest Day CQ5 distribution (I expect that should be interesting). The question of course is what kind of tests must be performed before one would consider a release... I'm no velocity expert...I'd suggest checking that all the velocity features that you need work as expected, and if possible run some stress tests and watch for memory leaks. ...Perhaps it would be best to create release candidates beforehand and use those within an actual project?... We'll rather create a release, and another one if problems are discovered. Release early, release often! Please let us know the results of your tests, and if things look good I can prepare a release in the next few days. -Bertrand Hi Betrand I moved the disussion about the release to the dev list, which is probably better. Betrand, if you don't mind I would like to cut the release next week (just to get used to do so...). The bundle contains very little code, so from my side I don't see any problems to release it. best regards mike
Re: Velocity Scripting Release 2.0.0 (was Velocity scripting support)
Hi Mike, On Thu, Aug 26, 2010 at 8:01 AM, Mike Müller mike...@mysign.ch wrote: ...Betrand, if you don't mind I would like to cut the release next week (just to get used to do so...). The bundle contains very little code, so from my side I don't see any problems to release it... Fine with me! -Bertrand
Re: Velocity Scripting Release 2.0.0 (was Velocity scripting support)
+1 Regards Felix On 26.08.2010 08:01, Mike Müller wrote: On Wed, Aug 25, 2010 at 4:23 PM, olaf.o...@css.ch wrote: ...I will also test the scripting support against the latest velocity release tomorrow, thereby also testing whether it integrates with the latest Day CQ5 distribution (I expect that should be interesting). The question of course is what kind of tests must be performed before one would consider a release... I'm no velocity expert...I'd suggest checking that all the velocity features that you need work as expected, and if possible run some stress tests and watch for memory leaks. ...Perhaps it would be best to create release candidates beforehand and use those within an actual project?... We'll rather create a release, and another one if problems are discovered. Release early, release often! Please let us know the results of your tests, and if things look good I can prepare a release in the next few days. -Bertrand Hi Betrand I moved the disussion about the release to the dev list, which is probably better. Betrand, if you don't mind I would like to cut the release next week (just to get used to do so...). The bundle contains very little code, so from my side I don't see any problems to release it. best regards mike
Re: [jira] Created: (SLING-1695) form auth should be able to set the auth cookie on a specific domain
Hi, Thanks for the info. This is what I assumed. I would just like to have this kind of flesh to the bones in the JIRA issues for later reference, why something has been done like is has been done - if it looks too obvious today. Thanks. Regards Felix On 25.08.2010 16:59, Justin Edelson wrote: I suspect my use case is very specific and is intertwined with a few other things, but basically... I make heavy use of workspaces in my CMS for content branches. Subdomains of a parent domain are used to identify which workspace should be used. Setting the auth cookie on the parent domain allows for users to view content in different branches (workspaces) without re-authenticating. Another use case (just thinking out loud here), would be to use Sling as an SSO provider, again by setting the cookie on a parent domain and then having a ServletFilter on each client application which check the cookie against the Sling instance. It's no SAML, but would work. Justin On 8/25/10 9:55 AM, Felix Meschberger wrote: Hi, Just for documentation and completeness sake: Can you please elaborate a bit on the use case etc. Thanks alot. (By no means questioning the request at all ;-) ). Regards Felix On 25.08.2010 15:11, Justin Edelson (JIRA) wrote: form auth should be able to set the auth cookie on a specific domain Key: SLING-1695 URL: https://issues.apache.org/jira/browse/SLING-1695 Project: Sling Issue Type: Improvement Components: Authentication Reporter: Justin Edelson
Re: sling 6 releases visualization
Hey thats excellent, makes it much easier to see what needs to be worked on. ( feeling very Guilty of not having enough time to do that work just at the moment) Thanks Ian On 25 Aug 2010, at 22:42, Justin Edelson wrote: I put this together to help visualize the releases leading up to Sling 6: https://cwiki.apache.org/confluence/download/attachments/2743/sling6-bundles-viz.pdf Red Boxes - modules with outstanding issues Green Boxes - modules with no outstanding issues Blue Boxes - modules up for vote White Boxes - released modules Black line - dependency on released module Brown line - dependency on unreleased module So... a Green Box with only brown lines is good to go. One thing that jumped out is that Servlets Post will need to be released before the JCR modules (at least some of them). That dependency feels wrong, almost like whatever it is should be in JCR Base or a new Servlets Base ? Although thats what Post Servlets is in a way. Justin
[jira] Created: (SLING-1699) New default configuration is created on each startup
New default configuration is created on each startup Key: SLING-1699 URL: https://issues.apache.org/jira/browse/SLING-1699 Project: Sling Issue Type: Bug Components: Commons Affects Versions: Commons Threads 3.0.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Commons Threads 3.0.2 On each startup a new default configuration is added -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-1697) Log the start of each test class run
[ https://issues.apache.org/jira/browse/SLING-1697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Federico Paparoni updated SLING-1697: - Attachment: HttpTestBase.java.patch I don't know if it's the behaviour you want, but using this patch you have logged every setUp() of classes that extend HttpTestBase having an output like this: Running test: class org.apache.sling.launchpad.webapp.integrationtest.userManager.CreateUserTest Running test: class org.apache.sling.launchpad.webapp.integrationtest.userManager.CreateUserTest Running test: class org.apache.sling.launchpad.webapp.integrationtest.userManager.CreateUserTest Running test: class org.apache.sling.launchpad.webapp.integrationtest.userManager.CreateUserTest Running test: class org.apache.sling.launchpad.webapp.integrationtest.HttpPingTest Running test: class org.apache.sling.launchpad.webapp.integrationtest.HttpPingTest Running test: class org.apache.sling.launchpad.webapp.integrationtest.servlets.post.PostServletAtDeleteTest Running test: class org.apache.sling.launchpad.webapp.integrationtest.servlets.post.PostServletAtDeleteTest Running test: class org.apache.sling.launchpad.webapp.integrationtest.EspLoadTest Running test: class org.apache.sling.launchpad.webapp.integrationtest.EspLoadTest Running test: class org.apache.sling.launchpad.webapp.integrationtest.JspIncludeTest Log the start of each test class run Key: SLING-1697 URL: https://issues.apache.org/jira/browse/SLING-1697 Project: Sling Issue Type: Improvement Components: Testing Reporter: Justin Edelson Fix For: Launchpad Testing 6 Attachments: HttpTestBase.java.patch -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1697) Log the start of each test class run
[ https://issues.apache.org/jira/browse/SLING-1697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12902782#action_12902782 ] Federico Paparoni commented on SLING-1697: -- It should be useful also to move the logging from the setUp() in a static method using BeforeClass annotation http://junit.sourceforge.net/javadoc/org/junit/BeforeClass.html But I don't have idea how it could be possible to print the class name in a static method Log the start of each test class run Key: SLING-1697 URL: https://issues.apache.org/jira/browse/SLING-1697 Project: Sling Issue Type: Improvement Components: Testing Reporter: Justin Edelson Fix For: Launchpad Testing 6 Attachments: HttpTestBase.java.patch -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1623) Update some third party dependencies in the launchpad builder list
[ https://issues.apache.org/jira/browse/SLING-1623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12902800#action_12902800 ] Felix Meschberger commented on SLING-1623: -- Adding to the list of external dependencies: Apache Felix Configuration Admin: 2.0.7-SNAPSHOT (see https://issues.apache.org/jira/browse/FELIX/fixforversion/12314190) Update some third party dependencies in the launchpad builder list -- Key: SLING-1623 URL: https://issues.apache.org/jira/browse/SLING-1623 Project: Sling Issue Type: Improvement Components: Launchpad Affects Versions: Launchpad Builder 6 Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: Launchpad Builder 6 As discussed on the list, some third party bundles might be updated in the launchpad builder list: commons-lang: 2.5 groovy-all: 1.7.4 org.apache.felix.webconsole: 3.0.1-SNAPSHOT (targeting upcoming 3.0.2 release) org.apache.felix.webconsole.plugins.memoryusage: 1.0.1-SNAPSHOT (targeting upcoming 1.0.2 release) org.apache.felix.bundlerepository: 1.6.0 org.apache.felix.eventadmin: 1.2.2 org.apache.felix.scr: 1.4.1-SNAPSHOT (targetting upcoming 1.4.2 release) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (SLING-1623) Update some third party dependencies in the launchpad builder list
[ https://issues.apache.org/jira/browse/SLING-1623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12902800#action_12902800 ] Felix Meschberger edited comment on SLING-1623 at 8/26/10 5:39 AM: --- Adding to the list of external dependencies: Apache Felix Configuration Admin: 1.2.7-SNAPSHOT (see https://issues.apache.org/jira/browse/FELIX/fixforversion/12314190) Upgraded Apache Felix Configuration Admin reference to 1.2.7-SNAPSHOT in Rev. 989572 was (Author: fmeschbe): Adding to the list of external dependencies: Apache Felix Configuration Admin: 2.0.7-SNAPSHOT (see https://issues.apache.org/jira/browse/FELIX/fixforversion/12314190) Update some third party dependencies in the launchpad builder list -- Key: SLING-1623 URL: https://issues.apache.org/jira/browse/SLING-1623 Project: Sling Issue Type: Improvement Components: Launchpad Affects Versions: Launchpad Builder 6 Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: Launchpad Builder 6 As discussed on the list, some third party bundles might be updated in the launchpad builder list: commons-lang: 2.5 groovy-all: 1.7.4 org.apache.felix.webconsole: 3.0.1-SNAPSHOT (targeting upcoming 3.0.2 release) org.apache.felix.webconsole.plugins.memoryusage: 1.0.1-SNAPSHOT (targeting upcoming 1.0.2 release) org.apache.felix.bundlerepository: 1.6.0 org.apache.felix.eventadmin: 1.2.2 org.apache.felix.scr: 1.4.1-SNAPSHOT (targetting upcoming 1.4.2 release) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] Release Commons ClassLoader 1.2.0 and JCR ClassLoader 3.1.2
On Wed, Aug 25, 2010 at 2:33 PM, Carsten Ziegeler cziege...@apache.org wrote: [X ] +1 Approve the release Checked signatures and checked that the contents of the following archives match the corresponding svn tags: org.apache.sling.commons.classloader-1.2.0-source-release.zip MD5 2d8fa8039af516d4cdce41757dcebd4f org.apache.sling.jcr.classloader-3.1.2-source-release.zip MD5 ad6fd3473cd467c0345ea18e90d3ef85 -Bertrand
Build failed in Hudson: sling-trunk-1.6 #539
See https://hudson.apache.org/hudson/job/sling-trunk-1.6/539/changes Changes: [cziegeler] Don't log shutdown as a warning [cziegeler] Interrupt thread on shutdown [cziegeler] Cleanup ununsed watched folders. [mykee] SLING-1696 Update Velocity scripting to Velocity 1.6.4 [cziegeler] Correct accidentally changed versions [cziegeler] Use current snapshots after release. [cziegeler] [maven-release-plugin] prepare for next development iteration [cziegeler] [maven-release-plugin] prepare release org.apache.sling.jcr.classloader-3.1.2 [cziegeler] [maven-release-plugin] prepare for next development iteration [cziegeler] Prepare for release [cziegeler] [maven-release-plugin] prepare release org.apache.sling.commons.classloader-1.2.0 [cziegeler] Update notice file [mykee] [mykee] Typo from SLING-1681 [cziegeler] SLING-1694 : Instantiate adapter factories lazy [cziegeler] Correct docs [fmeschbe] Use released versions of the webconsole branding and security provider bundles [cziegeler] SLING-1681 : Remove intermediate reactor pom -- [...truncated 14189 lines...] [INFO] Copying bundle from /home/hudson/.m2/repository/org/apache/sling/org.apache.sling.auth.openid/0.9.1-SNAPSHOT/org.apache.sling.auth.openid-0.9.1-SNAPSHOT.jar to https://hudson.apache.org/hudson/job/sling-trunk-1.6/ws/trunk/launchpad/testing/target/classes/resources/bundles/0/org.apache.sling.auth.openid-0.9.1-SNAPSHOT.jar [INFO] Copying bundle from /home/hudson/.m2/repository/org/apache/sling/org.apache.sling.auth.form/0.9-SNAPSHOT/org.apache.sling.auth.form-0.9-SNAPSHOT.jar to https://hudson.apache.org/hudson/job/sling-trunk-1.6/ws/trunk/launchpad/testing/target/classes/resources/bundles/0/org.apache.sling.auth.form-0.9-SNAPSHOT.jar [INFO] Copying bundle from /home/hudson/.m2/repository/org/apache/sling/org.apache.sling.auth.selector/0.9.0-SNAPSHOT/org.apache.sling.auth.selector-0.9.0-SNAPSHOT.jar to https://hudson.apache.org/hudson/job/sling-trunk-1.6/ws/trunk/launchpad/testing/target/classes/resources/bundles/0/org.apache.sling.auth.selector-0.9.0-SNAPSHOT.jar [INFO] Copying bundle from /home/hudson/.m2/repository/org/apache/sling/org.apache.sling.adapter/2.0.5-SNAPSHOT/org.apache.sling.adapter-2.0.5-SNAPSHOT.jar to https://hudson.apache.org/hudson/job/sling-trunk-1.6/ws/trunk/launchpad/testing/target/classes/resources/bundles/0/org.apache.sling.adapter-2.0.5-SNAPSHOT.jar [INFO] Copying bundle from /home/hudson/.m2/repository/org/apache/sling/org.apache.sling.servlets.resolver/2.0.9-SNAPSHOT/org.apache.sling.servlets.resolver-2.0.9-SNAPSHOT.jar to https://hudson.apache.org/hudson/job/sling-trunk-1.6/ws/trunk/launchpad/testing/target/classes/resources/bundles/0/org.apache.sling.servlets.resolver-2.0.9-SNAPSHOT.jar [INFO] Copying bundle from /home/hudson/.m2/repository/org/apache/sling/org.apache.sling.servlets.get/2.0.9-SNAPSHOT/org.apache.sling.servlets.get-2.0.9-SNAPSHOT.jar to https://hudson.apache.org/hudson/job/sling-trunk-1.6/ws/trunk/launchpad/testing/target/classes/resources/bundles/0/org.apache.sling.servlets.get-2.0.9-SNAPSHOT.jar [INFO] Copying bundle from /home/hudson/.m2/repository/org/apache/sling/org.apache.sling.servlets.post/2.0.5-SNAPSHOT/org.apache.sling.servlets.post-2.0.5-SNAPSHOT.jar to https://hudson.apache.org/hudson/job/sling-trunk-1.6/ws/trunk/launchpad/testing/target/classes/resources/bundles/0/org.apache.sling.servlets.post-2.0.5-SNAPSHOT.jar [INFO] Copying bundle from /home/hudson/.m2/repository/org/apache/sling/org.apache.sling.jcr.contentloader/2.0.7-SNAPSHOT/org.apache.sling.jcr.contentloader-2.0.7-SNAPSHOT.jar to https://hudson.apache.org/hudson/job/sling-trunk-1.6/ws/trunk/launchpad/testing/target/classes/resources/bundles/0/org.apache.sling.jcr.contentloader-2.0.7-SNAPSHOT.jar [INFO] Copying bundle from /home/hudson/.m2/repository/org/apache/sling/org.apache.sling.jcr.resource/2.0.7-SNAPSHOT/org.apache.sling.jcr.resource-2.0.7-SNAPSHOT.jar to https://hudson.apache.org/hudson/job/sling-trunk-1.6/ws/trunk/launchpad/testing/target/classes/resources/bundles/0/org.apache.sling.jcr.resource-2.0.7-SNAPSHOT.jar [INFO] Copying bundle from /home/hudson/.m2/repository/org/apache/sling/org.apache.sling.jcr.ocm/2.0.4-incubator/org.apache.sling.jcr.ocm-2.0.4-incubator.jar to https://hudson.apache.org/hudson/job/sling-trunk-1.6/ws/trunk/launchpad/testing/target/classes/resources/bundles/0/org.apache.sling.jcr.ocm-2.0.4-incubator.jar [INFO] Copying bundle from /home/hudson/.m2/repository/org/apache/sling/org.apache.sling.jcr.classloader/3.1.3-SNAPSHOT/org.apache.sling.jcr.classloader-3.1.3-SNAPSHOT.jar to https://hudson.apache.org/hudson/job/sling-trunk-1.6/ws/trunk/launchpad/testing/target/classes/resources/bundles/0/org.apache.sling.jcr.classloader-3.1.3-SNAPSHOT.jar [INFO] Copying bundle from
Hudson build is back to stable : sling-trun k-1.6 » Apache Sling Launchpad Testing #539
See https://hudson.apache.org/hudson/job/sling-trunk-1.6/org.apache.sling$org.apache.sling.launchpad.testing/539/
Build failed in Hudson: sling-contrib-1.5 » Apache Sling Dojo JavaScript Library #569
See
https://hudson.apache.org/hudson/job/sling-contrib-1.5/org.apache.sling$org.apache.sling.extensions.dojo/569/
--
[INFO]
[INFO] Building Apache Sling Dojo JavaScript Library
[INFO]task-segment: [clean, install]
[INFO]
[INFO] [clean:clean {execution: default-clean}]
[INFO] Deleting file set:
https://hudson.apache.org/hudson/job/sling-contrib-1.5/org.apache.sling$org.apache.sling.extensions.dojo/ws/target
(included: [**], excluded: [])
[INFO] [enforcer:enforce {execution: enforce-java}]
[INFO] [remote-resources:process {execution: default}]
[INFO] [resources:resources {execution: default-resources}]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 4 resources
[INFO] Copying 3 resources
[INFO] [antrun:run {execution: default}]
[INFO] Executing tasks
[taskdef] Could not load definitions from resource
net/sf/antcontrib/antcontrib.properties. It could not be found.
[HUDSON] Archiving
https://hudson.apache.org/hudson/job/sling-contrib-1.5/org.apache.sling$org.apache.sling.extensions.dojo/ws/pom.xml
to
/home/hudson/hudson/jobs/sling-contrib-1.5/modules/org.apache.sling$org.apache.sling.extensions.dojo/builds/2010-08-26_10-43-56/archive/org.apache.sling/org.apache.sling.extensions.dojo/1.1.0.002-SNAPSHOT/pom.xml
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] An Ant BuildException has occured: Problem: failed to create task or
type if
Cause: The name is undefined.
Action: Check the spelling.
Action: Check that any custom tasks/types have been declared.
Action: Check that any presetdef/macrodef declarations have taken place.
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
[INFO] Total time: 1 minute 6 seconds
[INFO] Finished at: Thu Aug 26 10:45:09 UTC 2010
[INFO] Final Memory: 42M/84M
[INFO]
[jira] Updated: (SLING-1671) New features for jQuery JCR Explorer - step 1
[ https://issues.apache.org/jira/browse/SLING-1671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clemens Wyss updated SLING-1671: Description: + property (type) specific editors (e.g. date, boolean) + search (SQL2, JQDOM, sql and xpath) + optimized tree (navigation) + pluggable resource/node editors was: + property (type) specific editors (e.g. date, boolean) + search (SQL2, JQOM, sql and xpath) + optimized tree (navigation) + pluggable resource/node editors New features for jQuery JCR Explorer - step 1 - Key: SLING-1671 URL: https://issues.apache.org/jira/browse/SLING-1671 Project: Sling Issue Type: New Feature Components: Extensions Reporter: Clemens Wyss Priority: Minor + property (type) specific editors (e.g. date, boolean) + search (SQL2, JQDOM, sql and xpath) + optimized tree (navigation) + pluggable resource/node editors -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1671) New features for jQuery JCR Explorer - step 1
[ https://issues.apache.org/jira/browse/SLING-1671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12902825#action_12902825 ] Clemens Wyss commented on SLING-1671: - btw, I am the Assignee ;-) but can't assign myself... New features for jQuery JCR Explorer - step 1 - Key: SLING-1671 URL: https://issues.apache.org/jira/browse/SLING-1671 Project: Sling Issue Type: New Feature Components: Extensions Reporter: Clemens Wyss Priority: Minor + property (type) specific editors (e.g. date, boolean) + search (SQL2, JQDOM, sql and xpath) + optimized tree (navigation) + pluggable resource/node editors -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1671) New features for jQuery JCR Explorer - step 1
[ https://issues.apache.org/jira/browse/SLING-1671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12902824#action_12902824 ] Clemens Wyss commented on SLING-1671: - we intend to release an initial version this afternoon, or tomorrow New features for jQuery JCR Explorer - step 1 - Key: SLING-1671 URL: https://issues.apache.org/jira/browse/SLING-1671 Project: Sling Issue Type: New Feature Components: Extensions Reporter: Clemens Wyss Priority: Minor + property (type) specific editors (e.g. date, boolean) + search (SQL2, JQDOM, sql and xpath) + optimized tree (navigation) + pluggable resource/node editors -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1671) New features for jQuery JCR Explorer - step 1
[ https://issues.apache.org/jira/browse/SLING-1671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12902835#action_12902835 ] Bertrand Delacretaz commented on SLING-1671: I just gave user Clemens Wyss the Contributor role, you should be able to assign the issue to yourself now New features for jQuery JCR Explorer - step 1 - Key: SLING-1671 URL: https://issues.apache.org/jira/browse/SLING-1671 Project: Sling Issue Type: New Feature Components: Extensions Reporter: Clemens Wyss Priority: Minor + property (type) specific editors (e.g. date, boolean) + search (SQL2, JQDOM, sql and xpath) + optimized tree (navigation) + pluggable resource/node editors -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (SLING-1671) New features for jQuery JCR Explorer - step 1
[ https://issues.apache.org/jira/browse/SLING-1671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clemens Wyss reassigned SLING-1671: --- Assignee: Clemens Wyss New features for jQuery JCR Explorer - step 1 - Key: SLING-1671 URL: https://issues.apache.org/jira/browse/SLING-1671 Project: Sling Issue Type: New Feature Components: Extensions Reporter: Clemens Wyss Assignee: Clemens Wyss Priority: Minor + property (type) specific editors (e.g. date, boolean) + search (SQL2, JQDOM, sql and xpath) + optimized tree (navigation) + pluggable resource/node editors -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-1700) contrib/scripting/velocity embeds velocity, causing classloading issue at runtime
contrib/scripting/velocity embeds velocity, causing classloading issue at
runtime
-
Key: SLING-1700
URL: https://issues.apache.org/jira/browse/SLING-1700
Project: Sling
Issue Type: Bug
Components: Scripting
Environment: Felix 1.4, Sling 2.0.7, Apache Velocity 1.6.2
Reporter: Olaf Otto
Affects: Rev. 989119 of
https://svn.apache.org/repos/asf/sling/trunk/contrib/scripting/velocity
(2.0.0-SNAPSHOT)
The maven-bundle-configuration in the pom of the velocity support module
(https://svn.apache.org/repos/asf/sling/trunk/contrib/scripting/velocity/pom.xml)
embeds a couple of dependencies:
...
Embed-Dependency
velocity;oro;commons-lang;inline=true
/Embed-Dependency
...
However, these libraries are available as bundles and should not be embedded.
In the case of velocity, this causes an issue when a apache velocity bundle is
also deployed in felix, as the org.apache.velocity.runtime.log.LogChute
interface is loaded from both the velocity scripting support bundle and the
deployed apache velocity bundle:
Suggested resolution: Remove the embedding. It is bad practice anyway. I've
successfully tested this with the following maven-bundle-configuration
configuration:
configuration
instructions
Private-Package
org.apache.sling.scripting.velocity
/Private-Package
Import-Package
org.apache.velocity.runtime.log,
com.werken.xpath; javax.sql;
org.apache.commons.*; org.apache.log.*;
org.apache.log4j; org.apache.tools.ant.*;
org.jdom.*;resolution:=optional, *
/Import-Package
ScriptEngine-Name${pom.name}/ScriptEngine-Name
ScriptEngine-Version${pom.version}/ScriptEngine-Version
/instructions
/configuration
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [VOTE] Release Commons ClassLoader 1.2.0 and JCR ClassLoader 3.1.2
+1 Regards Felix On 25.08.2010 14:33, Carsten Ziegeler wrote: Hi, We solved some issues in the classloaders: https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truepid=12310710fixfor=12314758 https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truepid=12310710fixfor=12314757 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-143/ You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 143 /tmp/sling-staging Please vote to approve this release: [ ] +1 Approve the release [ ] 0 Don't care [ ] -1 Don't release, because ... This vote will be open for 72 hours.
[jira] Commented: (SLING-1697) Log the start of each test class run
[ https://issues.apache.org/jira/browse/SLING-1697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12902846#action_12902846 ] Justin Edelson commented on SLING-1697: --- That wasn't the behavior I wanted, but it's also not the behavior I'm seeing... Do you see multiple Added lines for each of these? You should see the same number of Added lines as Running lines: $ grep CreateUserTest junit.log 11:04:53.978 INFO [main] TestAll.java:78 Added org.apache.sling.launchpad.webapp.integrationtest.userManager.CreateUserTest 11:05:46.415 INFO [main] LoggingSuite.java:29 Running test class org.apache.sling.launchpad.webapp.integrationtest.userManager.CreateUserTest Log the start of each test class run Key: SLING-1697 URL: https://issues.apache.org/jira/browse/SLING-1697 Project: Sling Issue Type: Improvement Components: Testing Reporter: Justin Edelson Fix For: Launchpad Testing 6 Attachments: HttpTestBase.java.patch -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-1697) Log the start of each test class run
[ https://issues.apache.org/jira/browse/SLING-1697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Edelson updated SLING-1697: -- Comment: was deleted (was: That wasn't the behavior I wanted, but it's also not the behavior I'm seeing... Do you see multiple Added lines for each of these? You should see the same number of Added lines as Running lines: $ grep CreateUserTest junit.log 11:04:53.978 INFO [main] TestAll.java:78 Added org.apache.sling.launchpad.webapp.integrationtest.userManager.CreateUserTest 11:05:46.415 INFO [main] LoggingSuite.java:29 Running test class org.apache.sling.launchpad.webapp.integrationtest.userManager.CreateUserTest ) Log the start of each test class run Key: SLING-1697 URL: https://issues.apache.org/jira/browse/SLING-1697 Project: Sling Issue Type: Improvement Components: Testing Reporter: Justin Edelson Fix For: Launchpad Testing 6 Attachments: HttpTestBase.java.patch -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Hudson build is unstable: sling-trunk-1.5 #847
See https://hudson.apache.org/hudson/job/sling-trunk-1.5/847/changes
[jira] Commented: (SLING-1697) Log the start of each test class run
[ https://issues.apache.org/jira/browse/SLING-1697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12902847#action_12902847 ] Justin Edelson commented on SLING-1697: --- (sorry about that spurious comment, I thought I'd already committed a fix for this) I implemented this in r989653 via the TestAll class so that it appears along side the log messages indicating when a test class is discovered. Log the start of each test class run Key: SLING-1697 URL: https://issues.apache.org/jira/browse/SLING-1697 Project: Sling Issue Type: Improvement Components: Testing Reporter: Justin Edelson Fix For: Launchpad Testing 6 Attachments: HttpTestBase.java.patch -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-1697) Log the start of each test class run
[ https://issues.apache.org/jira/browse/SLING-1697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Edelson resolved SLING-1697. --- Assignee: Justin Edelson Resolution: Fixed Log the start of each test class run Key: SLING-1697 URL: https://issues.apache.org/jira/browse/SLING-1697 Project: Sling Issue Type: Improvement Components: Testing Reporter: Justin Edelson Assignee: Justin Edelson Fix For: Launchpad Testing 6 Attachments: HttpTestBase.java.patch -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1695) form auth should be able to set the auth cookie on a specific domain
[ https://issues.apache.org/jira/browse/SLING-1695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12902848#action_12902848 ] Justin Edelson commented on SLING-1695: --- for completeness I suspect my use case is very specific and is intertwined with a few other things, but basically... I make heavy use of workspaces in my CMS for content branches. Subdomains of a parent domain are used to identify which workspace should be used. Setting the auth cookie on the parent domain allows for users to view content in different branches (workspaces) without re-authenticating. Another use case (just thinking out loud here), would be to use Sling as an SSO provider, again by setting the cookie on a parent domain and then having a ServletFilter on each client application which check the cookie against the Sling instance. It's no SAML, but would work. form auth should be able to set the auth cookie on a specific domain Key: SLING-1695 URL: https://issues.apache.org/jira/browse/SLING-1695 Project: Sling Issue Type: Improvement Components: Authentication Reporter: Justin Edelson -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-1695) form auth should be able to set the auth cookie on a specific domain
[ https://issues.apache.org/jira/browse/SLING-1695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Edelson resolved SLING-1695. --- Assignee: Justin Edelson Resolution: Fixed done in r989652. default cookie domain can be set via config admin and overridden via AuthenticationInfo map. form auth should be able to set the auth cookie on a specific domain Key: SLING-1695 URL: https://issues.apache.org/jira/browse/SLING-1695 Project: Sling Issue Type: Improvement Components: Authentication Reporter: Justin Edelson Assignee: Justin Edelson -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-1701) contrib/scripting/velocity VelocityTemplatesScriptEngine has multiple issues
contrib/scripting/velocity VelocityTemplatesScriptEngine has multiple issues Key: SLING-1701 URL: https://issues.apache.org/jira/browse/SLING-1701 Project: Sling Issue Type: Improvement Components: Scripting Environment: Felix 1.4, Sling 2.0.7, Apache Velocity 1.6.2 Reporter: Olaf Otto Priority: Critical Affects: Rev. 989119 of https://svn.apache.org/repos/asf/sling/trunk/contrib/scripting/velocity (2.0.0-SNAPSHOT) The VelocityTemplatesScriptEngine has several issues, such as bad exception handling (catching Throwable instead of Exception), potential NPE's and bad naming, discarding of exception stacktrace and misleading error messages, missing Javadoc. Attached is a refactored version of the class. Note that there are still some opened questions marked with //TODO. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-1702) contrib/scripting/velocity VelocityTemplatesScriptEngineFactory needs workaround in case of engine instantiation errors
contrib/scripting/velocity VelocityTemplatesScriptEngineFactory needs
workaround in case of engine instantiation errors
---
Key: SLING-1702
URL: https://issues.apache.org/jira/browse/SLING-1702
Project: Sling
Issue Type: Improvement
Components: Scripting
Environment: Felix 1.4, Sling 2.0.7, Apache Velocity 1.6.2
Reporter: Olaf Otto
Affects: Rev. 989119 of
https://svn.apache.org/repos/asf/sling/trunk/contrib/scripting/velocity
(2.0.0-SNAPSHOT)
The (terrible!) Sun implementation of javax.script.ScriptEngineManager silently
discards all exceptions thrown when a scripting factory creates an engine:
...
private static final boolean DEBUG = false;
...
} catch (Exception exp) {
if (DEBUG) exp.printStackTrace();
}
This hides any error with the velocity configuration from the user. Thus the
VelocityTemplatesScriptEngineFactory should provide a log-and-re-throw
workaround, like so:
...
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
...
private final Logger logger = LoggerFactory.getLogger(getClass());
public ScriptEngine getScriptEngine() {
ScriptEngine engine;
try {
engine = new VelocityTemplatesScriptEngine(this);
} catch (RuntimeException e) {
logger.error(Unable to instantiate the velocity
template engine., e);
throw e;
}
return engine;
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1702) contrib/scripting/velocity VelocityTemplatesScriptEngineFactory needs workaround in case of engine instantiation errors
[
https://issues.apache.org/jira/browse/SLING-1702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12902854#action_12902854
]
Olaf Otto commented on SLING-1702:
--
Concerning the flawed Sun implementation: The discarding of exceptions affects
(at least) JDK 1.6.0 U 21 for Linux / 32 bit
contrib/scripting/velocity VelocityTemplatesScriptEngineFactory needs
workaround in case of engine instantiation errors
---
Key: SLING-1702
URL: https://issues.apache.org/jira/browse/SLING-1702
Project: Sling
Issue Type: Improvement
Components: Scripting
Environment: Felix 1.4, Sling 2.0.7, Apache Velocity 1.6.2
Reporter: Olaf Otto
Original Estimate: 0.5h
Remaining Estimate: 0.5h
Affects: Rev. 989119 of
https://svn.apache.org/repos/asf/sling/trunk/contrib/scripting/velocity
(2.0.0-SNAPSHOT)
The (terrible!) Sun implementation of javax.script.ScriptEngineManager
silently discards all exceptions thrown when a scripting factory creates an
engine:
...
private static final boolean DEBUG = false;
...
} catch (Exception exp) {
if (DEBUG) exp.printStackTrace();
}
This hides any error with the velocity configuration from the user. Thus the
VelocityTemplatesScriptEngineFactory should provide a log-and-re-throw
workaround, like so:
...
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
...
private final Logger logger = LoggerFactory.getLogger(getClass());
public ScriptEngine getScriptEngine() {
ScriptEngine engine;
try {
engine = new VelocityTemplatesScriptEngine(this);
} catch (RuntimeException e) {
logger.error(Unable to instantiate the velocity
template engine., e);
throw e;
}
return engine;
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Expose standard SlingPostOperations as services?
On Thu, Aug 26, 2010 at 14:47, Felix Meschberger fmesc...@gmail.com wrote: Hi, What is the exact use case ? Have some servlet create something, but then use the standardized sling post request syntax to add additional unstructured data. Could it be solved by your servlet handling part of the post, and for example create a request wrapper which exposes modified parameters. That servlet could then forward to the default POST servlet for final processing. Then the servlet looses a lot of control: - response handling - what operations are allowed to run That could be handled, but only be complex logic where the servlet has to inspect the parameters, complex response wrappers, etc. The nice thing is that the SlingPostOperation interface is there, ready to use... why not? As such I am currently opposed to exporting the internal operations. Then making all of them services (2) is the way to go. I probably could also have a SlingPostOperation myself, instead of the servlet, but that one couldn't make use of all the built-in logic of the existing operations. Regards, Alex -- Alexander Klimetschek alexander.klimetsc...@day.com
Re: Expose standard SlingPostOperations as services?
On Thu, Aug 26, 2010 at 15:34, Alexander Klimetschek aklim...@day.com wrote: Then making all of them services (2) is the way to go. No, I meant (1), of course. Alex -- Alexander Klimetschek alexander.klimetsc...@day.com
[jira] Updated: (SLING-1701) contrib/scripting/velocity VelocityTemplatesScriptEngine has multiple issues
[ https://issues.apache.org/jira/browse/SLING-1701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olaf Otto updated SLING-1701: - Attachment: (was: VelocityTemplatesScriptEngine.java) contrib/scripting/velocity VelocityTemplatesScriptEngine has multiple issues Key: SLING-1701 URL: https://issues.apache.org/jira/browse/SLING-1701 Project: Sling Issue Type: Improvement Components: Scripting Environment: Felix 1.4, Sling 2.0.7, Apache Velocity 1.6.2 Reporter: Olaf Otto Priority: Critical Original Estimate: 1h Remaining Estimate: 1h Affects: Rev. 989119 of https://svn.apache.org/repos/asf/sling/trunk/contrib/scripting/velocity (2.0.0-SNAPSHOT) The VelocityTemplatesScriptEngine has several issues, such as bad exception handling (catching Throwable instead of Exception), potential NPE's and bad naming, discarding of exception stacktrace and misleading error messages, missing Javadoc. Attached is a refactored version of the class. Note that there are still some opened questions marked with //TODO. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-1701) contrib/scripting/velocity VelocityTemplatesScriptEngine has multiple issues
[ https://issues.apache.org/jira/browse/SLING-1701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olaf Otto updated SLING-1701: - Attachment: VelocityTemplatesScriptEngine.java Refactored version of rev. 989119 of https://svn.apache.org/repos/asf/sling/trunk/contrib/scripting/velocity/src/main/java/org/apache/sling/scripting/velocity/VelocityTemplatesScriptEngine.java contrib/scripting/velocity VelocityTemplatesScriptEngine has multiple issues Key: SLING-1701 URL: https://issues.apache.org/jira/browse/SLING-1701 Project: Sling Issue Type: Improvement Components: Scripting Environment: Felix 1.4, Sling 2.0.7, Apache Velocity 1.6.2 Reporter: Olaf Otto Priority: Critical Attachments: VelocityTemplatesScriptEngine.java Original Estimate: 1h Remaining Estimate: 1h Affects: Rev. 989119 of https://svn.apache.org/repos/asf/sling/trunk/contrib/scripting/velocity (2.0.0-SNAPSHOT) The VelocityTemplatesScriptEngine has several issues, such as bad exception handling (catching Throwable instead of Exception), potential NPE's and bad naming, discarding of exception stacktrace and misleading error messages, missing Javadoc. Attached is a refactored version of the class. Note that there are still some opened questions marked with //TODO. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Expose standard SlingPostOperations as services?
On Thu, Aug 26, 2010 at 3:34 PM, Alexander Klimetschek aklim...@day.com wrote: On Thu, Aug 26, 2010 at 14:47, Felix Meschberger fmesc...@gmail.com wrote: ...As such I am currently opposed to exporting the internal operations. Then making all of them services (1) is the way to go... I'm +1 on this, being able to reuse operations in custom servlets is useful, and I don't see a downside. ... - ModifyOperation requires objects passed in its constructor + NodeNameGenerator and DateParser: their configuration should be moved from the SlingPostServlet component to the new ModifyOperation component (only used there anyway)... ok + ServletContext: required only for getting the mime types configured in the servlet engine, to be used for file uploads; not sure how to solve that (*) You could use the Sling MimeTypeService I guess. -Bertrand
Build failed in Hudson: sling-installer-1.5 #100
See https://hudson.apache.org/hudson/job/sling-installer-1.5/100/changes Changes: [cziegeler] Don't log shutdown as a warning [cziegeler] Interrupt thread on shutdown [cziegeler] Cleanup ununsed watched folders. [cziegeler] SLING-1681 : Remove intermediate reactor pom -- Started by an SCM change Building remotely on minerva.apache.org (Ubuntu) Updating http://svn.apache.org/repos/asf/sling/trunk/installer D pom.xml U osgi/installer/src/main/java/org/apache/sling/osgi/installer/impl/Activator.java U jcr/jcrinstall/src/main/java/org/apache/sling/jcr/jcrinstall/impl/JcrInstaller.java U jcr/jcrinstall/pom.xml At revision 989707 [locks-and-latches] Checking to see if we really have the locks [locks-and-latches] Have all the locks, build can start Parsing POMs [locks-and-latches] Releasing all the locks [locks-and-latches] All the locks released ERROR: No such file https://hudson.apache.org/hudson/job/sling-installer-1.5/ws/contrib-1.5/pom.xml Perhaps you need to specify the correct POM file path in the project configuration?
[jira] Assigned: (SLING-1701) contrib/scripting/velocity VelocityTemplatesScriptEngine has multiple issues
[ https://issues.apache.org/jira/browse/SLING-1701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Müller reassigned SLING-1701: -- Assignee: Mike Müller contrib/scripting/velocity VelocityTemplatesScriptEngine has multiple issues Key: SLING-1701 URL: https://issues.apache.org/jira/browse/SLING-1701 Project: Sling Issue Type: Improvement Components: Scripting Environment: Felix 1.4, Sling 2.0.7, Apache Velocity 1.6.2 Reporter: Olaf Otto Assignee: Mike Müller Priority: Critical Attachments: VelocityTemplatesScriptEngine.java Original Estimate: 1h Remaining Estimate: 1h Affects: Rev. 989119 of https://svn.apache.org/repos/asf/sling/trunk/contrib/scripting/velocity (2.0.0-SNAPSHOT) The VelocityTemplatesScriptEngine has several issues, such as bad exception handling (catching Throwable instead of Exception), potential NPE's and bad naming, discarding of exception stacktrace and misleading error messages, missing Javadoc. Attached is a refactored version of the class. Note that there are still some opened questions marked with //TODO. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: sling 6 releases visualization
On 8/26/10 4:10 AM, Ian Boston wrote: Hey thats excellent, makes it much easier to see what needs to be worked on. ( feeling very Guilty of not having enough time to do that work just at the moment) That's what I was going for (the making it easier to see what needs work, not the making you feel guilty part) Thanks Ian On 25 Aug 2010, at 22:42, Justin Edelson wrote: I put this together to help visualize the releases leading up to Sling 6: https://cwiki.apache.org/confluence/download/attachments/2743/sling6-bundles-viz.pdf Red Boxes - modules with outstanding issues Green Boxes - modules with no outstanding issues Blue Boxes - modules up for vote White Boxes - released modules Black line - dependency on released module Brown line - dependency on unreleased module So... a Green Box with only brown lines is good to go. One thing that jumped out is that Servlets Post will need to be released before the JCR modules (at least some of them). That dependency feels wrong, almost like whatever it is should be in JCR Base or a new Servlets Base ? Although thats what Post Servlets is in a way. Justin
Re: Expose standard SlingPostOperations as services?
Hi, On 26.08.2010 15:34, Alexander Klimetschek wrote: On Thu, Aug 26, 2010 at 14:47, Felix Meschberger fmesc...@gmail.com wrote: Hi, What is the exact use case ? Have some servlet create something, but then use the standardized sling post request syntax to add additional unstructured data. Could it be solved by your servlet handling part of the post, and for example create a request wrapper which exposes modified parameters. That servlet could then forward to the default POST servlet for final processing. Then the servlet looses a lot of control: - response handling Would it be helpful to be able to inject another HtmlResponse class to be used instead of the default ones ? - what operations are allowed to run Why would you want to restrict ? But then you could check the :operation property and act accordingly. That could be handled, but only be complex logic where the servlet has to inspect the parameters, complex response wrappers, etc. The nice thing is that the SlingPostOperation interface is there, ready to use... why not? Because that interface is for use by operation providers consumed by the Sling POST Servlet and you should not replicate the functionality of Sling POST Servlet. As such I am currently opposed to exporting the internal operations. Then making all of them services (2) is the way to go. I probably could also have a SlingPostOperation myself, instead of the servlet, but that one couldn't make use of all the built-in logic of the existing operations. What built-in logic ? Maybe we could expose some of this support logic. You might also want to consider providing a SlingPostProcessor. The problem around this is, that I do not see a clear and coherent concept behind this please expose the implementation request. I would like to keep as much of the functionality private to reserve the freedom to change the implementation. Exposing the existing SlingPostOperation implementations might be an option, but I fear invitation to duplicate code ... Regards Felix
Hudson build is unstable: sling-trunk-1.6 #540
See https://hudson.apache.org/hudson/job/sling-trunk-1.6/540/changes
Hudson build is back to stable : sling-trun k-1.5 » Apache Sling Launchpad Testing #848
See https://hudson.apache.org/hudson/job/sling-trunk-1.5/org.apache.sling$org.apache.sling.launchpad.testing/848/changes
Hudson build is still unstable: sling-trunk-1.5 #848
See https://hudson.apache.org/hudson/job/sling-trunk-1.5/changes
Re: Expose standard SlingPostOperations as services?
On Thu, Aug 26, 2010 at 16:52, Felix Meschberger fmesc...@gmail.com wrote: On 26.08.2010 15:34, Alexander Klimetschek wrote: On Thu, Aug 26, 2010 at 14:47, Felix Meschberger fmesc...@gmail.com wrote: Then the servlet looses a lot of control: - response handling Would it be helpful to be able to inject another HtmlResponse class to be used instead of the default ones ? No. - what operations are allowed to run Why would you want to restrict ? I only want modify operations in my case, no moves, or deletes. But then you could check the :operation property and act accordingly. I don't want to do that, just calling the SlingPostOperation would be IMO much more elegant than a forward with all its required request/response wrapping. That could be handled, but only be complex logic where the servlet has to inspect the parameters, complex response wrappers, etc. The nice thing is that the SlingPostOperation interface is there, ready to use... why not? Because that interface is for use by operation providers consumed by the Sling POST Servlet and you should not replicate the functionality of Sling POST Servlet. I am not replicating it, I want to integrate a certain part of it inside the logic of my servlet. As such I am currently opposed to exporting the internal operations. Then making all of them services (2) is the way to go. I probably could also have a SlingPostOperation myself, instead of the servlet, but that one couldn't make use of all the built-in logic of the existing operations. What built-in logic ? Maybe we could expose some of this support logic. That's exactly what I want :-) Making them available as services is fine for me, as long as one can directly call the modify post operation service. You might also want to consider providing a SlingPostProcessor. No, I want to use the ModifyOperation in my context, not the other way around. Apart from doing an internal forward (I find this awkward, also not sure if this properly works for new nodes/resources created in the request's session), there is no way to call this useful, existing logic. The problem around this is, that I do not see a clear and coherent concept behind this please expose the implementation request. I would like to keep as much of the functionality private to reserve the freedom to change the implementation. But the associations of operations to their names are fixed, as they are exposed as HTTP API already. Also, the SlingPostOperation is a public interface already. Exposing the existing SlingPostOperation implementations might be an option, but I fear invitation to duplicate code ... Why? If they are not accessible, one is invited to re-implement the logic from the ModifyOperation themselves. That would be code duplication. Regards, Alex -- Alexander Klimetschek alexander.klimetsc...@day.com
Re: Expose standard SlingPostOperations as services?
On Thu, Aug 26, 2010 at 18:38, Alexander Klimetschek aklim...@day.com wrote: On Thu, Aug 26, 2010 at 16:52, Felix Meschberger fmesc...@gmail.com wrote: You might also want to consider providing a SlingPostProcessor. No, I want to use the ModifyOperation in my context, not the other way around. Apart from doing an internal forward (I find this awkward, also not sure if this properly works for new nodes/resources created in the request's session), there is no way to call this useful, existing logic. An important part of my use case is that I first create a node using a service that already exists and then want to run the modify operation on the newly created node. This is difficult to do with another SlingPostOperation... also that operation should not be used outside of what my servlet defines (the operation namespace is kind of global). Regards, Alex -- Alexander Klimetschek alexander.klimetsc...@day.com
Re: Expose standard SlingPostOperations as services?
On Aug 26, 2010, at 12:42 PM, Alexander Klimetschek aklim...@day.com wrote: On Thu, Aug 26, 2010 at 18:38, Alexander Klimetschek aklim...@day.com wrote: On Thu, Aug 26, 2010 at 16:52, Felix Meschberger fmesc...@gmail.com wrote: You might also want to consider providing a SlingPostProcessor. No, I want to use the ModifyOperation in my context, not the other way around. Apart from doing an internal forward (I find this awkward, also not sure if this properly works for new nodes/resources created in the request's session), there is no way to call this useful, existing logic. An important part of my use case is that I first create a node using a service that already exists and then want to run the modify operation on the newly created node. This is difficult to do with another SlingPostOperation... also that operation should not be used outside of what my servlet defines (the operation namespace is kind of global). Regards, Alex -- Alexander Klimetschek alexander.klimetsc...@day.com I agree with Alex that forwarding doesn't seem right. If one was to use an existing SlingPostOperation to create a composite (which is what this looks like), you would probably want to use a transaction and only commit the transaction at the end of the composite. It isn't directly related, but looking at the dependency between the two jackrabbit bundles and servlets.post (and some of my own code) along with this thread makes me think we do need to expose more of the post servlet innards to other bundles. There's good stuff in there which is of general use. As this means new APIs, let's be thoughtful about it. In the interim... Alex - can you use Embed-Dependency like jackrabbit-accessmanager does? It's not pretty, but works. Justin
[jira] Resolved: (SLING-1270) Replace Session.logout from SlingMainServlet
[ https://issues.apache.org/jira/browse/SLING-1270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger resolved SLING-1270. -- Resolution: Fixed Finally resolving this issue after changing some comments in Rev. 989912. Replace Session.logout from SlingMainServlet Key: SLING-1270 URL: https://issues.apache.org/jira/browse/SLING-1270 Project: Sling Issue Type: Task Components: Engine Affects Versions: Engine 2.0.6 Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: Engine 2.1.0 The new Commons Auth bundle from SLING-966 registers a ServletRequestListener to be informed when the request has terminated and the session may be logged out. Currently, the Http Service implementation does not support such listeners and the session may not be logged out at all. As a workaround the Commons Auth bundle implements a Java VM finalize() method to try to ensure logging the session out. As a further workaround the SlingMainServlet should - in a finally clause - logout the session of the request's resource resolver. The SlingMainServlet configuration should be removed as soon as we can reasonably be sure of ServletRequestListener support. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-1240) Allow configuration of URL space open without credentials
[ https://issues.apache.org/jira/browse/SLING-1240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger resolved SLING-1240. -- Assignee: Felix Meschberger Resolution: Duplicate Resolving as duplicate of SLING-966 without an actual fix version. Allow configuration of URL space open without credentials - Key: SLING-1240 URL: https://issues.apache.org/jira/browse/SLING-1240 Project: Sling Issue Type: Improvement Components: Engine Affects Versions: Engine 2.0.6 Reporter: Felix Meschberger Assignee: Felix Meschberger Currently the SlingAuthenticator has a single flag -- auth.annonymous -- defining whether anonymous access is allowed or not. To allow for more flexibility it would be interesting to be able to partition the URL space into areas requiring authentication and ares not requiring authentication. As such the current situation just has a single area -- the complete URL space -- which may be configured to require authentication or not. Such configuration may be of different form: * authentication handler declaring part of the URL space as requiring authentication * SlingAuthenticator configuration listing regular expressions to partition the URL space into authentication requiring areas. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (SLING-1240) Allow configuration of URL space open without credentials
[ https://issues.apache.org/jira/browse/SLING-1240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger closed SLING-1240. Nothing more to do here. Close this. Allow configuration of URL space open without credentials - Key: SLING-1240 URL: https://issues.apache.org/jira/browse/SLING-1240 Project: Sling Issue Type: Improvement Components: Engine Affects Versions: Engine 2.0.6 Reporter: Felix Meschberger Assignee: Felix Meschberger Currently the SlingAuthenticator has a single flag -- auth.annonymous -- defining whether anonymous access is allowed or not. To allow for more flexibility it would be interesting to be able to partition the URL space into areas requiring authentication and ares not requiring authentication. As such the current situation just has a single area -- the complete URL space -- which may be configured to require authentication or not. Such configuration may be of different form: * authentication handler declaring part of the URL space as requiring authentication * SlingAuthenticator configuration listing regular expressions to partition the URL space into authentication requiring areas. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-333) Implement object cleanup mechanism
[ https://issues.apache.org/jira/browse/SLING-333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger resolved SLING-333. - Resolution: Won't Fix Looking back at the discussion and reconsidering, I don't think we really needs such a generalized cleanup functionality. Each piece of code should care to cleanup up behind itself. Implement object cleanup mechanism -- Key: SLING-333 URL: https://issues.apache.org/jira/browse/SLING-333 Project: Sling Issue Type: New Feature Components: Engine Reporter: Felix Meschberger In a message on the dev list [1] Bertrand stipulated a cleanup feature along these lines: I'm talking about *automatic* cleanup of such objects at the end of a request, scenario: 1. Object A calls a method M of class C, that creates something that must be cleaned up (ThreadLocal variable for example) 2. Before returning, Method M registers itself to be called for cleanup at the end of request processing 3. Object A doesn't have to care about cleanup, it will happen automatically. This is much more foolproof than requiring A to call cleanup explicitely, hence my suggestion to implement a general (request-scope for now) cleanup mechanism. [1] http://markmail.org/message/eeilivxyrm7s5z42 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-1196) Sling Authentication - SlingAuthenticator hides LoginFailure reason
[
https://issues.apache.org/jira/browse/SLING-1196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Felix Meschberger updated SLING-1196:
-
Affects Version/s: (was: Engine 2.0.6)
Component/s: Authentication
(was: Engine)
This is now an Auth Core issue.
Sling Authentication - SlingAuthenticator hides LoginFailure reason
---
Key: SLING-1196
URL: https://issues.apache.org/jira/browse/SLING-1196
Project: Sling
Issue Type: Improvement
Components: Authentication
Reporter: Hakim Sadikali
Attachments: SlingAuthenticator.java
Original Estimate: 2h
Remaining Estimate: 2h
The SlingAuthenticator does not provide the handler with the reason a login
failed, it only logs the reason and proceeds to try again:
// request authentication information and send 403 (Forbidden)
// if no handler can request authentication information.
log.info(authenticate: Unable to authenticate: {},
reason.getMessage());
log.debug(authenticate, reason);
login(request, response);
Applications often want to provide more detailed information to the end user,
username not found, password does not match username etc.
An easy solution would be to put the LoginException in the request for the
login handler to have access to it, and then remove it after the login
handler has processed the request - works but not particularly elegant.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1196) Sling Authentication - SlingAuthenticator hides LoginFailure reason
[
https://issues.apache.org/jira/browse/SLING-1196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12903037#action_12903037
]
Felix Meschberger commented on SLING-1196:
--
Reconsidering, I am not sure, whether this has really any use because the
information in the LoginException is not generally informative and second it is
security-wise a bad idea to tell the user more than a generic sorry,
name/password do not match. Otherwise they might deduce that a user might
exist and they just have to try more passwords.
Sling Authentication - SlingAuthenticator hides LoginFailure reason
---
Key: SLING-1196
URL: https://issues.apache.org/jira/browse/SLING-1196
Project: Sling
Issue Type: Improvement
Components: Authentication
Reporter: Hakim Sadikali
Attachments: SlingAuthenticator.java
Original Estimate: 2h
Remaining Estimate: 2h
The SlingAuthenticator does not provide the handler with the reason a login
failed, it only logs the reason and proceeds to try again:
// request authentication information and send 403 (Forbidden)
// if no handler can request authentication information.
log.info(authenticate: Unable to authenticate: {},
reason.getMessage());
log.debug(authenticate, reason);
login(request, response);
Applications often want to provide more detailed information to the end user,
username not found, password does not match username etc.
An easy solution would be to put the LoginException in the request for the
login handler to have access to it, and then remove it after the login
handler has processed the request - works but not particularly elegant.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-1086) SlingRequestDispatcher must not include redirect resources as is
[ https://issues.apache.org/jira/browse/SLING-1086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger resolved SLING-1086. -- Assignee: Felix Meschberger Resolution: Duplicate Duplicate of SLING-1087 SlingRequestDispatcher must not include redirect resources as is Key: SLING-1086 URL: https://issues.apache.org/jira/browse/SLING-1086 Project: Sling Issue Type: Bug Components: Engine Affects Versions: Engine 2.0.4 Reporter: Felix Meschberger Assignee: Felix Meschberger When including a resource the SlingRequestDispatcher calls the ResourceResolver.resolve() method if the dispatcher has been created with a path instead of a resource. This method can return a redirect resource (a synthetic resource with resource type sling:redirect). In the case of request dispatching rendering a redirect resource will probably not be the desired result. Thus the SlingRequestDispatcher.dispatch method should be modified around line 145 (in Rev. 788719) to probably first call ResourceResolver.getResource() and only try resolve() if getResource() returns null. (info: resolve is called for ease of use to handle selector and extension overwrites for the included resource) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-1410) VanityPath not working in middle of URL
[ https://issues.apache.org/jira/browse/SLING-1410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated SLING-1410: - Component/s: JCR (was: Engine) VanityPath not working in middle of URL --- Key: SLING-1410 URL: https://issues.apache.org/jira/browse/SLING-1410 Project: Sling Issue Type: Bug Components: JCR Environment: -r 911442, max osx 10.5, jdk 1.6 on karaf 1.2 using launchpad feature Reporter: Jason Rose $ curl -F title=hello -Fjcr:mixinTypes=sling:VanityPath -Fsling:vanityPath=/nice/path http://admin:ad...@localhost:8181/content/test/this/is/a/nasty/path $ curl -Ftitle=test http://admin:ad...@localhost:8181/content/test/this/is/a/nasty/path/even/more/path Now, the inconsistency is here: $ curl localhost:8181/nice/path works as intended. $ curl localhost:8181/nice/path/even/more/path returns a 404 $ curl localhost:8181/nice/path.infinity.json shows that the nodes are indeed there, but I can't seem to access them. Is this the intended behavior of the vanityPath, i.e. to not allow the path as part of the resource resolution process? It doesn't seem to be the case, since calling .infinity.json on the vanityPath shows the nodes I want to access under them. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1410) VanityPath not working in middle of URL
[ https://issues.apache.org/jira/browse/SLING-1410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12903047#action_12903047 ] Felix Meschberger commented on SLING-1410: -- The vanity path functionality is what it is called: a vanity path. As such it is supported unmodied (your first example) or with selectors and extensions (your third) example. But the vanity path is not intended as an intermediate node (your second sample). You could use the /etc/map functionality though, to map a path prefix. See http://sling.apache.org/site/mappings-for-resource-resolution.html VanityPath not working in middle of URL --- Key: SLING-1410 URL: https://issues.apache.org/jira/browse/SLING-1410 Project: Sling Issue Type: Bug Components: JCR Environment: -r 911442, max osx 10.5, jdk 1.6 on karaf 1.2 using launchpad feature Reporter: Jason Rose $ curl -F title=hello -Fjcr:mixinTypes=sling:VanityPath -Fsling:vanityPath=/nice/path http://admin:ad...@localhost:8181/content/test/this/is/a/nasty/path $ curl -Ftitle=test http://admin:ad...@localhost:8181/content/test/this/is/a/nasty/path/even/more/path Now, the inconsistency is here: $ curl localhost:8181/nice/path works as intended. $ curl localhost:8181/nice/path/even/more/path returns a 404 $ curl localhost:8181/nice/path.infinity.json shows that the nodes are indeed there, but I can't seem to access them. Is this the intended behavior of the vanityPath, i.e. to not allow the path as part of the resource resolution process? It doesn't seem to be the case, since calling .infinity.json on the vanityPath shows the nodes I want to access under them. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (SLING-1086) SlingRequestDispatcher must not include redirect resources as is
[ https://issues.apache.org/jira/browse/SLING-1086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger closed SLING-1086. Done. SlingRequestDispatcher must not include redirect resources as is Key: SLING-1086 URL: https://issues.apache.org/jira/browse/SLING-1086 Project: Sling Issue Type: Bug Components: Engine Affects Versions: Engine 2.0.4 Reporter: Felix Meschberger Assignee: Felix Meschberger When including a resource the SlingRequestDispatcher calls the ResourceResolver.resolve() method if the dispatcher has been created with a path instead of a resource. This method can return a redirect resource (a synthetic resource with resource type sling:redirect). In the case of request dispatching rendering a redirect resource will probably not be the desired result. Thus the SlingRequestDispatcher.dispatch method should be modified around line 145 (in Rev. 788719) to probably first call ResourceResolver.getResource() and only try resolve() if getResource() returns null. (info: resolve is called for ease of use to handle selector and extension overwrites for the included resource) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-823) Allow overriding default workspace via request parameter cookie (like the sudo parameter)
[ https://issues.apache.org/jira/browse/SLING-823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger resolved SLING-823. - Assignee: Felix Meschberger Resolution: Duplicate Duplicates SLING-1444. Allow overriding default workspace via request parameter cookie (like the sudo parameter) --- Key: SLING-823 URL: https://issues.apache.org/jira/browse/SLING-823 Project: Sling Issue Type: New Feature Components: Engine Affects Versions: Engine 2.0.2 Reporter: Rory Douglas Assignee: Felix Meschberger Priority: Minor Attachments: metatype.properties, SlingAuthenticator.java Enable access to non-default workspace using a request parameter cookie analogous to how the sudo impersonation is currently handled. Make this override behavior configurable via a property, and default it to off for backwards compatibility/security. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-1400) OPTIONS request on / returns login form if Allow Anonymous Access set to false
[ https://issues.apache.org/jira/browse/SLING-1400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated SLING-1400: - Component/s: Authentication (was: Engine) This can still be reproduced but slightly different: The response is now a redirect to the login form. This, of course, is completely wrong. Don't know the correct solution, but probably the authentication handlers should not request credentials for non-GET/POST requests OPTIONS request on / returns login form if Allow Anonymous Access set to false Key: SLING-1400 URL: https://issues.apache.org/jira/browse/SLING-1400 Project: Sling Issue Type: Bug Components: Authentication Reporter: Bertrand Delacretaz Priority: Minor If Allow Anonymous Access is true (that's the default default) in theorg.apache.sling.engine.impl.auth.SlingAuthenticator config, curl -X OPTIONS http://localhost:/ correctly returns a 401 status. If the setting is false, the same request returns 200 and the login form. Not sure if that's really a problem, but I thought I'd report it as it caused the WebDAV mount on / to become unusable with samples that recommend setting that parameter to false. I'll change the samples to use sling:authRequestLogin=true instead. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-1097) ResourceResolverFactory service missing after restarting repository
[ https://issues.apache.org/jira/browse/SLING-1097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger resolved SLING-1097. -- Assignee: Felix Meschberger Resolution: Fixed I think we can mark this issue fixed, as it can be solved with the upgraded (long done) Apache Felix Declarative Services bundle. ResourceResolverFactory service missing after restarting repository Key: SLING-1097 URL: https://issues.apache.org/jira/browse/SLING-1097 Project: Sling Issue Type: Bug Components: Engine Affects Versions: Engine 2.0.4 Reporter: Bertrand Delacretaz Assignee: Felix Meschberger Priority: Minor Steps to reproduce: 1. Start launchpad/app 2. Stop and restart the org.apache.sling.jcr.jackrabbit.server bundle 3. http://localhost:/index.html now says ResourceResolverFactory service missing, cannot service requests which come from the SlingMainServlet's service() method. Stopping and restarting the org.apache.sling.jcr.resource.internal.JcrResourceResolverFactoryImpl component has the same effect. In both cases, stopping and restarting the org.apache.sling.engine.impl.SlingMainServlet component solves the problem. The component is declared as follows in SlingMainServlet, looks ok to me: /** @scr.reference cardinality=0..1 policy=dynamic */ private JcrResourceResolverFactory resourceResolverFactory; -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (SLING-1097) ResourceResolverFactory service missing after restarting repository
[ https://issues.apache.org/jira/browse/SLING-1097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger closed SLING-1097. Done ResourceResolverFactory service missing after restarting repository Key: SLING-1097 URL: https://issues.apache.org/jira/browse/SLING-1097 Project: Sling Issue Type: Bug Components: Engine Affects Versions: Engine 2.0.4 Reporter: Bertrand Delacretaz Assignee: Felix Meschberger Priority: Minor Steps to reproduce: 1. Start launchpad/app 2. Stop and restart the org.apache.sling.jcr.jackrabbit.server bundle 3. http://localhost:/index.html now says ResourceResolverFactory service missing, cannot service requests which come from the SlingMainServlet's service() method. Stopping and restarting the org.apache.sling.jcr.resource.internal.JcrResourceResolverFactoryImpl component has the same effect. In both cases, stopping and restarting the org.apache.sling.engine.impl.SlingMainServlet component solves the problem. The component is declared as follows in SlingMainServlet, looks ok to me: /** @scr.reference cardinality=0..1 policy=dynamic */ private JcrResourceResolverFactory resourceResolverFactory; -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-1140) Rewriter Filter not called when error is handled
[ https://issues.apache.org/jira/browse/SLING-1140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated SLING-1140: - Component/s: (was: Engine) Affects Version/s: (was: Engine 2.0.4) Component/s: Extensions This is probably more an issue of the Rewriter module Rewriter Filter not called when error is handled Key: SLING-1140 URL: https://issues.apache.org/jira/browse/SLING-1140 Project: Sling Issue Type: Bug Components: Extensions Reporter: Honwai Wong Priority: Minor In case an errorhandler is triggered (e.g. 404 occurred), the Rewriter Filter and thus custom filters in the pipeline are ignored. Filters should be triggered even when an error occurred beforehand. Use-case: - have a custom 404-errorhandler in place, /apps/sling/servlet/errorhandler/404.jsp - do a RequestDispatcher#forward to a resource whose output is usually being rewritten -- filters are ignored, output of forwarded resource is not rewritten -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-235) UjaxFileUploadHandler needs tests for the nt:file vs. nt:resource decisions
[ https://issues.apache.org/jira/browse/SLING-235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger resolved SLING-235. - Resolution: Fixed I think this is not relevant any longer, uSling and Ujax ain't no more ;-) UjaxFileUploadHandler needs tests for the nt:file vs. nt:resource decisions --- Key: SLING-235 URL: https://issues.apache.org/jira/browse/SLING-235 Project: Sling Issue Type: Test Components: Engine Reporter: Bertrand Delacretaz Priority: Minor I'm modifying UjaxFileUploadHandler so that it creates an nt:file node (as opposed to nt:resource) if the name of the file being uploaded includes an extension. The rationale for the choice between nt:file and nt:resource is that if the filename is important the upload handler creates an nt:file, and if not it's an nt:resource. We need to add some tests to verify this logic, including what the class did before my changes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Hudson build is back to stable : sling-trunk-1.6 » Apache Sling OSGi Installer Integration Tests #541
See https://hudson.apache.org/hudson/job/sling-trunk-1.6/org.apache.sling$org.apache.sling.osgi.installer.it/541/
Hudson build is back to stable : sling-trunk-1.6 #541
See https://hudson.apache.org/hudson/job/sling-trunk-1.6/541/changes
[jira] Closed: (SLING-235) UjaxFileUploadHandler needs tests for the nt:file vs. nt:resource decisions
[ https://issues.apache.org/jira/browse/SLING-235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger closed SLING-235. --- Done UjaxFileUploadHandler needs tests for the nt:file vs. nt:resource decisions --- Key: SLING-235 URL: https://issues.apache.org/jira/browse/SLING-235 Project: Sling Issue Type: Test Components: Engine Reporter: Bertrand Delacretaz Assignee: Felix Meschberger Priority: Minor I'm modifying UjaxFileUploadHandler so that it creates an nt:file node (as opposed to nt:resource) if the name of the file being uploaded includes an extension. The rationale for the choice between nt:file and nt:resource is that if the filename is important the upload handler creates an nt:file, and if not it's an nt:resource. We need to add some tests to verify this logic, including what the class did before my changes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (SLING-235) UjaxFileUploadHandler needs tests for the nt:file vs. nt:resource decisions
[ https://issues.apache.org/jira/browse/SLING-235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger reassigned SLING-235: --- Assignee: Felix Meschberger UjaxFileUploadHandler needs tests for the nt:file vs. nt:resource decisions --- Key: SLING-235 URL: https://issues.apache.org/jira/browse/SLING-235 Project: Sling Issue Type: Test Components: Engine Reporter: Bertrand Delacretaz Assignee: Felix Meschberger Priority: Minor I'm modifying UjaxFileUploadHandler so that it creates an nt:file node (as opposed to nt:resource) if the name of the file being uploaded includes an extension. The rationale for the choice between nt:file and nt:resource is that if the filename is important the upload handler creates an nt:file, and if not it's an nt:resource. We need to add some tests to verify this logic, including what the class did before my changes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1700) contrib/scripting/velocity embeds velocity, causing classloading issue at runtime
[
https://issues.apache.org/jira/browse/SLING-1700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12903080#action_12903080
]
Felix Meschberger commented on SLING-1700:
--
Remove the embedding. It is bad practice anyway
Not necessairily. It is IMHO a nice feature of OSGi to actually embed stuff,
which may be private to some bundle for some reason, e.g. a hard requirement on
a specific version, etc.
So, I agree with not including commons-lang (we have this bundle in Sling
already). I don't agree with not including oro and velocity, though: This
bundle is about velocity, so I would include it. Oro is really not of much use
any longer and IMHO should be treated as a private dependency of velocity, too.
Thus also to be embedded. This simplifies isolation of what the Velocity bundle
really needs from the world.
contrib/scripting/velocity embeds velocity, causing classloading issue at
runtime
-
Key: SLING-1700
URL: https://issues.apache.org/jira/browse/SLING-1700
Project: Sling
Issue Type: Bug
Components: Scripting
Environment: Felix 1.4, Sling 2.0.7, Apache Velocity 1.6.2
Reporter: Olaf Otto
Original Estimate: 2h
Remaining Estimate: 2h
Affects: Rev. 989119 of
https://svn.apache.org/repos/asf/sling/trunk/contrib/scripting/velocity
(2.0.0-SNAPSHOT)
The maven-bundle-configuration in the pom of the velocity support module
(https://svn.apache.org/repos/asf/sling/trunk/contrib/scripting/velocity/pom.xml)
embeds a couple of dependencies:
...
Embed-Dependency
velocity;oro;commons-lang;inline=true
/Embed-Dependency
...
However, these libraries are available as bundles and should not be embedded.
In the case of velocity, this causes an issue when a apache velocity bundle
is also deployed in felix, as the org.apache.velocity.runtime.log.LogChute
interface is loaded from both the velocity scripting support bundle and the
deployed apache velocity bundle:
Suggested resolution: Remove the embedding. It is bad practice anyway. I've
successfully tested this with the following maven-bundle-configuration
configuration:
configuration
instructions
Private-Package
org.apache.sling.scripting.velocity
/Private-Package
Import-Package
org.apache.velocity.runtime.log,
com.werken.xpath; javax.sql;
org.apache.commons.*; org.apache.log.*;
org.apache.log4j; org.apache.tools.ant.*;
org.jdom.*;resolution:=optional, *
/Import-Package
ScriptEngine-Name${pom.name}/ScriptEngine-Name
ScriptEngine-Version${pom.version}/ScriptEngine-Version
/instructions
/configuration
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Hudson build is back to stable : sling-trunk-1.5 » Apache Sling OSGi Installer Integration Tests #849
See https://hudson.apache.org/hudson/job/sling-trunk-1.5/org.apache.sling$org.apache.sling.osgi.installer.it/849/
Hudson build is back to stable : sling-trunk-1.5 #849
See https://hudson.apache.org/hudson/job/sling-trunk-1.5/849/changes
Build failed in Hudson: sling-contrib-1.5 » Apache Sling Dojo JavaScript Library #570
See
https://hudson.apache.org/hudson/job/sling-contrib-1.5/org.apache.sling$org.apache.sling.extensions.dojo/570/
--
[INFO]
[INFO] Building Apache Sling Dojo JavaScript Library
[INFO]task-segment: [clean, install]
[INFO]
[INFO] [clean:clean {execution: default-clean}]
[INFO] Deleting file set:
https://hudson.apache.org/hudson/job/sling-contrib-1.5/org.apache.sling$org.apache.sling.extensions.dojo/ws/target
(included: [**], excluded: [])
[INFO] [enforcer:enforce {execution: enforce-java}]
[INFO] [remote-resources:process {execution: default}]
[INFO] [resources:resources {execution: default-resources}]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 4 resources
[INFO] Copying 3 resources
[INFO] [antrun:run {execution: default}]
[INFO] Executing tasks
[taskdef] Could not load definitions from resource
net/sf/antcontrib/antcontrib.properties. It could not be found.
[HUDSON] Archiving
https://hudson.apache.org/hudson/job/sling-contrib-1.5/org.apache.sling$org.apache.sling.extensions.dojo/ws/pom.xml
to
/home/hudson/hudson/jobs/sling-contrib-1.5/modules/org.apache.sling$org.apache.sling.extensions.dojo/builds/2010-08-26_22-22-53/archive/org.apache.sling/org.apache.sling.extensions.dojo/1.1.0.002-SNAPSHOT/pom.xml
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] An Ant BuildException has occured: Problem: failed to create task or
type if
Cause: The name is undefined.
Action: Check the spelling.
Action: Check that any custom tasks/types have been declared.
Action: Check that any presetdef/macrodef declarations have taken place.
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
[INFO] Total time: 1 minute 1 second
[INFO] Finished at: Thu Aug 26 22:24:02 UTC 2010
[INFO] Final Memory: 41M/62M
[INFO]
Build failed in Hudson: sling-contrib-1.5 #570
See https://hudson.apache.org/hudson/job/sling-contrib-1.5/570/
--
[...truncated 345 lines...]
at java.util.concurrent.FutureTask.run(FutureTask.java:123)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:651)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:676)
at java.lang.Thread.run(Thread.java:595)
[INFO] Writing OBR metadata
[HUDSON] Archiving
https://hudson.apache.org/hudson/job/sling-contrib-1.5/ws/contrib-1.5/commons/html/target/org.apache.sling.commons.html-1.0.1-SNAPSHOT-sources.jar
to
/home/hudson/hudson/jobs/sling-contrib-1.5/modules/org.apache.sling$org.apache.sling.commons.html/builds/2010-08-26_22-22-53/archive/org.apache.sling/org.apache.sling.commons.html/1.0.1-SNAPSHOT/org.apache.sling.commons.html-1.0.1-SNAPSHOT-sources.jar
[INFO]
[INFO] Building Apache Sling APT parser
[INFO]task-segment: [clean, install]
[INFO]
[INFO] [clean:clean {execution: default-clean}]
[INFO] Deleting file set:
https://hudson.apache.org/hudson/job/sling-contrib-1.5/ws/contrib-1.5/extensions/apt/parser/target
(included: [**], excluded: [])
[INFO] [enforcer:enforce {execution: enforce-java}]
[INFO] [remote-resources:process {execution: default}]
[INFO] [resources:resources {execution: default-resources}]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 0 resource
[INFO] Copying 3 resources
[INFO] [antrun:run {execution: default}]
[INFO] Executing tasks
[echo] ** WARNING (SLING-443)
**
[echo] On most platforms, you'll get OutOfMemoryErrors when building
unless you set
[echo] MAVEN_OPTS=-Xmx256M -XX:MaxPermSize=128M, see SLING-443.
[echo]
*
[INFO] Executed tasks
[INFO] [compiler:compile {execution: default-compile}]
[INFO] Compiling 7 source files to
https://hudson.apache.org/hudson/job/sling-contrib-1.5/ws/contrib-1.5/extensions/apt/parser/target/classes
[INFO] [scr:scr {execution: generate-scr-scrdescriptor}]
[INFO] Writing abstract service descriptor
https://hudson.apache.org/hudson/job/sling-contrib-1.5/ws/contrib-1.5/extensions/apt/parser/target/scr-plugin-generated/OSGI-INF/scr-plugin/scrinfo.xml
with 1 entries.
[INFO] Generating 1 Service Component Descriptors to
https://hudson.apache.org/hudson/job/sling-contrib-1.5/ws/contrib-1.5/extensions/apt/parser/target/scr-plugin-generated/OSGI-INF/serviceComponents.xml
[INFO] [resources:testResources {execution: default-testResources}]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory
https://hudson.apache.org/hudson/job/sling-contrib-1.5/ws/contrib-1.5/extensions/apt/parser/src/test/resources
[INFO] Copying 3 resources
[INFO] [compiler:testCompile {execution: default-testCompile}]
[INFO] Compiling 1 source file to
https://hudson.apache.org/hudson/job/sling-contrib-1.5/ws/contrib-1.5/extensions/apt/parser/target/test-classes
[INFO] [surefire:test {execution: default-test}]
[INFO] Surefire report directory:
https://hudson.apache.org/hudson/job/sling-contrib-1.5/ws/contrib-1.5/extensions/apt/parser/target/surefire-reports
---
T E S T S
---
Running org.apache.sling.apt.parser.internal.SlingAptParserImplTest
Tests run: 12, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.054 sec
Results :
Tests run: 12, Failures: 0, Errors: 0, Skipped: 0
[HUDSON] Recording test results
[INFO] [bundle:bundle {execution: default-bundle}]
[WARNING] Warning building bundle
org.apache.sling:org.apache.sling.extensions.apt.parser:bundle:2.0.3-SNAPSHOT :
Split package org/apache/maven/doxia/sink
Use directive -split-package:=(merge-first|merge-last|error|first) on
Export/Private Package instruction to get rid of this warning
Package found in [Jar:doxia-core, Jar:doxia-sink-api]
Reference from
/home/hudson/.m2/repository/org/apache/maven/doxia/doxia-sink-api/1.0-alpha-10/doxia-sink-api-1.0-alpha-10.jar
Classpath [Jar:., Jar:doxia-module-apt, Jar:plexus-utils,
Jar:doxia-core, Jar:doxia-sink-api, Jar:plexus-container-default,
Jar:plexus-classworlds]
[INFO] Preparing source:jar
[WARNING] Removing: jar from forked lifecycle, to prevent recursive invocation.
[HUDSON] Archiving
https://hudson.apache.org/hudson/job/sling-contrib-1.5/ws/contrib-1.5/extensions/apt/parser/pom.xml
to
/home/hudson/hudson/jobs/sling-contrib-1.5/modules/org.apache.sling$org.apache.sling.extensions.apt.parser/builds/2010-08-26_22-22-53/archive/org.apache.sling/org.apache.sling.extensions.apt.parser/2.0.3-SNAPSHOT/pom.xml
[HUDSON] Archiving
Build failed in Hudson: sling-installer-1.5 #101
See https://hudson.apache.org/hudson/job/sling-installer-1.5/101/ -- Started by upstream project sling-trunk-1.5 build number 849 Building remotely on ubuntu1 Updating http://svn.apache.org/repos/asf/sling/trunk/installer At revision 989956 no change for http://svn.apache.org/repos/asf/sling/trunk/installer since the previous build [locks-and-latches] Checking to see if we really have the locks [locks-and-latches] Have all the locks, build can start Parsing POMs [locks-and-latches] Releasing all the locks [locks-and-latches] All the locks released ERROR: No such file https://hudson.apache.org/hudson/job/sling-installer-1.5/ws/contrib-1.5/pom.xml Perhaps you need to specify the correct POM file path in the project configuration?
[jira] Commented: (SLING-1700) contrib/scripting/velocity embeds velocity, causing classloading issue at runtime
[
https://issues.apache.org/jira/browse/SLING-1700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12903191#action_12903191
]
Justin Edelson commented on SLING-1700:
---
Agree with Felix that Velocity and ORO should be embedded here.
It looks like the problem is that velocity packages are being imported. That
shouldn't be the case.
Note - it would be better if Velocity simply provided an OSGi bundle with
support for JSR-223. See VELOCITY-735 and VELOCITY-765. If this was done, we
wouldn't need this module at all.
contrib/scripting/velocity embeds velocity, causing classloading issue at
runtime
-
Key: SLING-1700
URL: https://issues.apache.org/jira/browse/SLING-1700
Project: Sling
Issue Type: Bug
Components: Scripting
Environment: Felix 1.4, Sling 2.0.7, Apache Velocity 1.6.2
Reporter: Olaf Otto
Original Estimate: 2h
Remaining Estimate: 2h
Affects: Rev. 989119 of
https://svn.apache.org/repos/asf/sling/trunk/contrib/scripting/velocity
(2.0.0-SNAPSHOT)
The maven-bundle-configuration in the pom of the velocity support module
(https://svn.apache.org/repos/asf/sling/trunk/contrib/scripting/velocity/pom.xml)
embeds a couple of dependencies:
...
Embed-Dependency
velocity;oro;commons-lang;inline=true
/Embed-Dependency
...
However, these libraries are available as bundles and should not be embedded.
In the case of velocity, this causes an issue when a apache velocity bundle
is also deployed in felix, as the org.apache.velocity.runtime.log.LogChute
interface is loaded from both the velocity scripting support bundle and the
deployed apache velocity bundle:
Suggested resolution: Remove the embedding. It is bad practice anyway. I've
successfully tested this with the following maven-bundle-configuration
configuration:
configuration
instructions
Private-Package
org.apache.sling.scripting.velocity
/Private-Package
Import-Package
org.apache.velocity.runtime.log,
com.werken.xpath; javax.sql;
org.apache.commons.*; org.apache.log.*;
org.apache.log4j; org.apache.tools.ant.*;
org.jdom.*;resolution:=optional, *
/Import-Package
ScriptEngine-Name${pom.name}/ScriptEngine-Name
ScriptEngine-Version${pom.version}/ScriptEngine-Version
/instructions
/configuration
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
