[jira] [Commented] (SLING-3734) 'org.apache.sling.api.SlingException: Failed to generate name' when posting under load

[Bertrand Delacretaz (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-3734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14052203#comment-14052203
 ] 

Bertrand Delacretaz commented on SLING-3734:


There was indeed something about < 1000 in 
AbstractCreateOperation.ensureUniquePath, which is meant to break ties in case 
the default and/or configured NodeNameGenerator generate a path that's not 
unique.

I have replaced the incremental suffix with a random integer in 
http://svn.apache.org/r1607787 which should fix the issue. To test it I 
replaced this line

{code}
generatedName = defaultNodeNameGenerator.getNodeName(request, basePath, 
requirePrefix, defaultNodeNameGenerator);
{code}

with {{generated_name = "CONSTANT"}} to trigger the call to ensureUniquePath, 
and without my fix that cause node additions to fail after node 999 as you saw.

Please cross-check with the current snapshot of bundles/servlets/post, you 
shouldn't need to replace anything else.

> 'org.apache.sling.api.SlingException: Failed to generate name' when posting 
> under load
> --
>
> Key: SLING-3734
> URL: https://issues.apache.org/jira/browse/SLING-3734
> Project: Sling
>  Issue Type: Bug
>  Components: Servlets
>Affects Versions: Servlets Post 2.3.4, Launchpad Builder 7
>Reporter: David Bosschaert
> Attachments: jmeter-config.jmx
>
>
> I was doing some load testing on the current Sling (trunk) launchpad which I 
> started as follows:
>  java -jar org.apache.sling.launchpad-7-SNAPSHOT-standalone.jar
> I used a multitreaded client (JMeter, 4 threads) to send a whole bunch of 
> post requests to http://machine:8080/content/mynoderoot/ to get the node name 
> auto-generated.
> However, on about 25% of the requests I'm getting a 500 response with the 
> following exception message: org.apache.sling.api.SlingException: Failed to 
> generate name. The full stack trace is below.
> {code}org.apache.sling.api.SlingException: Failed to generate name
> org.apache.sling.servlets.post.impl.operations.ModifyOperation.getItemPath(ModifyOperation.java:175)
> org.apache.sling.servlets.post.AbstractPostOperation.run(AbstractPostOperation.java:77)
> org.apache.sling.servlets.post.impl.SlingPostServlet.doPost(SlingPostServlet.java:199)
> org.apache.sling.api.servlets.SlingAllMethodsServlet.mayService(SlingAllMethodsServlet.java:148)
> org.apache.sling.api.servlets.SlingSafeMethodsServlet.service(SlingSafeMethodsServlet.java:344)
> org.apache.sling.api.servlets.SlingSafeMethodsServlet.service(SlingSafeMethodsServlet.java:375)
> org.apache.sling.engine.impl.request.RequestData.service(RequestData.java:511)
> org.apache.sling.engine.impl.SlingRequestProcessorImpl.processComponent(SlingRequestProcessorImpl.java:289)
> org.apache.sling.engine.impl.filter.RequestSlingFilterChain.render(RequestSlingFilterChain.java:49)
> org.apache.sling.engine.impl.filter.AbstractSlingFilterChain.doFilter(AbstractSlingFilterChain.java:64)
> org.apache.sling.engine.impl.debug.RequestProgressTrackerLogFilter.doFilter(RequestProgressTrackerLogFilter.java:64)
> org.apache.sling.engine.impl.filter.AbstractSlingFilterChain.doFilter(AbstractSlingFilterChain.java:60)
> org.apache.sling.engine.impl.SlingRequestProcessorImpl.doProcessRequest(SlingRequestProcessorImpl.java:153)
> org.apache.sling.engine.impl.SlingMainServlet.service(SlingMainServlet.java:206)
> org.apache.felix.http.base.internal.handler.ServletHandler.doHandle(ServletHandler.java:96)
> org.apache.felix.http.base.internal.handler.ServletHandler.handle(ServletHandler.java:79)
> org.apache.felix.http.base.internal.dispatch.ServletPipeline.handle(ServletPipeline.java:42)
> org.apache.felix.http.base.internal.dispatch.InvocationFilterChain.doFilter(InvocationFilterChain.java:49)
> org.apache.felix.http.base.internal.dispatch.HttpFilterChain.doFilter(HttpFilterChain.java:33)
> org.apache.sling.engine.impl.log.RequestLoggerFilter.doFilter(RequestLoggerFilter.java:75)
> org.apache.felix.http.base.internal.handler.FilterHandler.doHandle(FilterHandler.java:88)
> org.apache.felix.http.base.internal.handler.FilterHandler.handle(FilterHandler.java:76)
> org.apache.felix.http.base.internal.dispatch.InvocationFilterChain.doFilter(InvocationFilterChain.java:47)
> org.apache.felix.http.base.internal.dispatch.HttpFilterChain.doFilter(HttpFilterChain.java:33)
> org.apache.felix.http.base.internal.dispatch.FilterPipeline.dispatch(FilterPipeline.java:48)
> org.apache.felix.http.base.internal.dispatch.Dispatcher.dispatch(Dispatcher.java:39)
> org.apache.felix.http.base.internal.DispatcherServlet.service(DispatcherServlet.java:67)
> javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
> org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:654)
> org.eclipse.jetty.servlet.ServletHandler.d

[jira] [Comment Edited] (SLING-3734) 'org.apache.sling.api.SlingException: Failed to generate name' when posting under load

[Bertrand Delacretaz (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-3734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14052203#comment-14052203
 ] 

Bertrand Delacretaz edited comment on SLING-3734 at 7/4/14 6:54 AM:


There was indeed something about < 1000 in 
AbstractCreateOperation.ensureUniquePath, which is meant to break ties in case 
the default and/or configured NodeNameGenerator generate a path that's not 
unique.

I have replaced the incremental suffix with a random integer in 
http://svn.apache.org/r1607787 which should fix the issue. To test it I 
replaced this line

{code}
generatedName = defaultNodeNameGenerator.getNodeName(request, basePath, 
requirePrefix, defaultNodeNameGenerator);
{code}

with {{generated_name = "CONSTANT"}} to trigger the call to ensureUniquePath, 
and without node additions would fail after node 999 as you saw.

Please cross-check with the current snapshot of bundles/servlets/post, you 
shouldn't need to replace anything else.


was (Author: bdelacretaz):
There was indeed something about < 1000 in 
AbstractCreateOperation.ensureUniquePath, which is meant to break ties in case 
the default and/or configured NodeNameGenerator generate a path that's not 
unique.

I have replaced the incremental suffix with a random integer in 
http://svn.apache.org/r1607787 which should fix the issue. To test it I 
replaced this line

{code}
generatedName = defaultNodeNameGenerator.getNodeName(request, basePath, 
requirePrefix, defaultNodeNameGenerator);
{code}

with {{generated_name = "CONSTANT"}} to trigger the call to ensureUniquePath, 
and without my fix that cause node additions to fail after node 999 as you saw.

Please cross-check with the current snapshot of bundles/servlets/post, you 
shouldn't need to replace anything else.

> 'org.apache.sling.api.SlingException: Failed to generate name' when posting 
> under load
> --
>
> Key: SLING-3734
> URL: https://issues.apache.org/jira/browse/SLING-3734
> Project: Sling
>  Issue Type: Bug
>  Components: Servlets
>Affects Versions: Servlets Post 2.3.4, Launchpad Builder 7
>Reporter: David Bosschaert
> Attachments: jmeter-config.jmx
>
>
> I was doing some load testing on the current Sling (trunk) launchpad which I 
> started as follows:
>  java -jar org.apache.sling.launchpad-7-SNAPSHOT-standalone.jar
> I used a multitreaded client (JMeter, 4 threads) to send a whole bunch of 
> post requests to http://machine:8080/content/mynoderoot/ to get the node name 
> auto-generated.
> However, on about 25% of the requests I'm getting a 500 response with the 
> following exception message: org.apache.sling.api.SlingException: Failed to 
> generate name. The full stack trace is below.
> {code}org.apache.sling.api.SlingException: Failed to generate name
> org.apache.sling.servlets.post.impl.operations.ModifyOperation.getItemPath(ModifyOperation.java:175)
> org.apache.sling.servlets.post.AbstractPostOperation.run(AbstractPostOperation.java:77)
> org.apache.sling.servlets.post.impl.SlingPostServlet.doPost(SlingPostServlet.java:199)
> org.apache.sling.api.servlets.SlingAllMethodsServlet.mayService(SlingAllMethodsServlet.java:148)
> org.apache.sling.api.servlets.SlingSafeMethodsServlet.service(SlingSafeMethodsServlet.java:344)
> org.apache.sling.api.servlets.SlingSafeMethodsServlet.service(SlingSafeMethodsServlet.java:375)
> org.apache.sling.engine.impl.request.RequestData.service(RequestData.java:511)
> org.apache.sling.engine.impl.SlingRequestProcessorImpl.processComponent(SlingRequestProcessorImpl.java:289)
> org.apache.sling.engine.impl.filter.RequestSlingFilterChain.render(RequestSlingFilterChain.java:49)
> org.apache.sling.engine.impl.filter.AbstractSlingFilterChain.doFilter(AbstractSlingFilterChain.java:64)
> org.apache.sling.engine.impl.debug.RequestProgressTrackerLogFilter.doFilter(RequestProgressTrackerLogFilter.java:64)
> org.apache.sling.engine.impl.filter.AbstractSlingFilterChain.doFilter(AbstractSlingFilterChain.java:60)
> org.apache.sling.engine.impl.SlingRequestProcessorImpl.doProcessRequest(SlingRequestProcessorImpl.java:153)
> org.apache.sling.engine.impl.SlingMainServlet.service(SlingMainServlet.java:206)
> org.apache.felix.http.base.internal.handler.ServletHandler.doHandle(ServletHandler.java:96)
> org.apache.felix.http.base.internal.handler.ServletHandler.handle(ServletHandler.java:79)
> org.apache.felix.http.base.internal.dispatch.ServletPipeline.handle(ServletPipeline.java:42)
> org.apache.felix.http.base.internal.dispatch.InvocationFilterChain.doFilter(InvocationFilterChain.java:49)
> org.apache.felix.http.base.internal.dispatch.HttpFilterChain.doFilter(HttpFilterChain.java:33)
> org.apache.sling.engine.impl.log.RequestLoggerFilter.doFilter(RequestLoggerFilter.java:75)
> org.

[jira] [Updated] (SLING-3734) 'org.apache.sling.api.SlingException: Failed to generate name' when posting under load

[Bertrand Delacretaz (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-3734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bertrand Delacretaz updated SLING-3734:
---

Affects Version/s: Servlets Post 2.3.4

> 'org.apache.sling.api.SlingException: Failed to generate name' when posting 
> under load
> --
>
> Key: SLING-3734
> URL: https://issues.apache.org/jira/browse/SLING-3734
> Project: Sling
>  Issue Type: Bug
>  Components: Servlets
>Affects Versions: Servlets Post 2.3.4, Launchpad Builder 7
>Reporter: David Bosschaert
> Attachments: jmeter-config.jmx
>
>
> I was doing some load testing on the current Sling (trunk) launchpad which I 
> started as follows:
>  java -jar org.apache.sling.launchpad-7-SNAPSHOT-standalone.jar
> I used a multitreaded client (JMeter, 4 threads) to send a whole bunch of 
> post requests to http://machine:8080/content/mynoderoot/ to get the node name 
> auto-generated.
> However, on about 25% of the requests I'm getting a 500 response with the 
> following exception message: org.apache.sling.api.SlingException: Failed to 
> generate name. The full stack trace is below.
> {code}org.apache.sling.api.SlingException: Failed to generate name
> org.apache.sling.servlets.post.impl.operations.ModifyOperation.getItemPath(ModifyOperation.java:175)
> org.apache.sling.servlets.post.AbstractPostOperation.run(AbstractPostOperation.java:77)
> org.apache.sling.servlets.post.impl.SlingPostServlet.doPost(SlingPostServlet.java:199)
> org.apache.sling.api.servlets.SlingAllMethodsServlet.mayService(SlingAllMethodsServlet.java:148)
> org.apache.sling.api.servlets.SlingSafeMethodsServlet.service(SlingSafeMethodsServlet.java:344)
> org.apache.sling.api.servlets.SlingSafeMethodsServlet.service(SlingSafeMethodsServlet.java:375)
> org.apache.sling.engine.impl.request.RequestData.service(RequestData.java:511)
> org.apache.sling.engine.impl.SlingRequestProcessorImpl.processComponent(SlingRequestProcessorImpl.java:289)
> org.apache.sling.engine.impl.filter.RequestSlingFilterChain.render(RequestSlingFilterChain.java:49)
> org.apache.sling.engine.impl.filter.AbstractSlingFilterChain.doFilter(AbstractSlingFilterChain.java:64)
> org.apache.sling.engine.impl.debug.RequestProgressTrackerLogFilter.doFilter(RequestProgressTrackerLogFilter.java:64)
> org.apache.sling.engine.impl.filter.AbstractSlingFilterChain.doFilter(AbstractSlingFilterChain.java:60)
> org.apache.sling.engine.impl.SlingRequestProcessorImpl.doProcessRequest(SlingRequestProcessorImpl.java:153)
> org.apache.sling.engine.impl.SlingMainServlet.service(SlingMainServlet.java:206)
> org.apache.felix.http.base.internal.handler.ServletHandler.doHandle(ServletHandler.java:96)
> org.apache.felix.http.base.internal.handler.ServletHandler.handle(ServletHandler.java:79)
> org.apache.felix.http.base.internal.dispatch.ServletPipeline.handle(ServletPipeline.java:42)
> org.apache.felix.http.base.internal.dispatch.InvocationFilterChain.doFilter(InvocationFilterChain.java:49)
> org.apache.felix.http.base.internal.dispatch.HttpFilterChain.doFilter(HttpFilterChain.java:33)
> org.apache.sling.engine.impl.log.RequestLoggerFilter.doFilter(RequestLoggerFilter.java:75)
> org.apache.felix.http.base.internal.handler.FilterHandler.doHandle(FilterHandler.java:88)
> org.apache.felix.http.base.internal.handler.FilterHandler.handle(FilterHandler.java:76)
> org.apache.felix.http.base.internal.dispatch.InvocationFilterChain.doFilter(InvocationFilterChain.java:47)
> org.apache.felix.http.base.internal.dispatch.HttpFilterChain.doFilter(HttpFilterChain.java:33)
> org.apache.felix.http.base.internal.dispatch.FilterPipeline.dispatch(FilterPipeline.java:48)
> org.apache.felix.http.base.internal.dispatch.Dispatcher.dispatch(Dispatcher.java:39)
> org.apache.felix.http.base.internal.DispatcherServlet.service(DispatcherServlet.java:67)
> javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
> org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:654)
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:445)
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:225)
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1044)
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:372)
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:189)
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:978)
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255)
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
> org.eclipse.jetty.server.Server.handle(Server.java:369)
> org.eclipse.jetty.se

[jira] [Updated] (SLING-3734) 'org.apache.sling.api.SlingException: Failed to generate name' when posting under load

[Bertrand Delacretaz (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-3734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bertrand Delacretaz updated SLING-3734:
---

Component/s: Servlets

> 'org.apache.sling.api.SlingException: Failed to generate name' when posting 
> under load
> --
>
> Key: SLING-3734
> URL: https://issues.apache.org/jira/browse/SLING-3734
> Project: Sling
>  Issue Type: Bug
>  Components: Servlets
>Affects Versions: Servlets Post 2.3.4, Launchpad Builder 7
>Reporter: David Bosschaert
> Attachments: jmeter-config.jmx
>
>
> I was doing some load testing on the current Sling (trunk) launchpad which I 
> started as follows:
>  java -jar org.apache.sling.launchpad-7-SNAPSHOT-standalone.jar
> I used a multitreaded client (JMeter, 4 threads) to send a whole bunch of 
> post requests to http://machine:8080/content/mynoderoot/ to get the node name 
> auto-generated.
> However, on about 25% of the requests I'm getting a 500 response with the 
> following exception message: org.apache.sling.api.SlingException: Failed to 
> generate name. The full stack trace is below.
> {code}org.apache.sling.api.SlingException: Failed to generate name
> org.apache.sling.servlets.post.impl.operations.ModifyOperation.getItemPath(ModifyOperation.java:175)
> org.apache.sling.servlets.post.AbstractPostOperation.run(AbstractPostOperation.java:77)
> org.apache.sling.servlets.post.impl.SlingPostServlet.doPost(SlingPostServlet.java:199)
> org.apache.sling.api.servlets.SlingAllMethodsServlet.mayService(SlingAllMethodsServlet.java:148)
> org.apache.sling.api.servlets.SlingSafeMethodsServlet.service(SlingSafeMethodsServlet.java:344)
> org.apache.sling.api.servlets.SlingSafeMethodsServlet.service(SlingSafeMethodsServlet.java:375)
> org.apache.sling.engine.impl.request.RequestData.service(RequestData.java:511)
> org.apache.sling.engine.impl.SlingRequestProcessorImpl.processComponent(SlingRequestProcessorImpl.java:289)
> org.apache.sling.engine.impl.filter.RequestSlingFilterChain.render(RequestSlingFilterChain.java:49)
> org.apache.sling.engine.impl.filter.AbstractSlingFilterChain.doFilter(AbstractSlingFilterChain.java:64)
> org.apache.sling.engine.impl.debug.RequestProgressTrackerLogFilter.doFilter(RequestProgressTrackerLogFilter.java:64)
> org.apache.sling.engine.impl.filter.AbstractSlingFilterChain.doFilter(AbstractSlingFilterChain.java:60)
> org.apache.sling.engine.impl.SlingRequestProcessorImpl.doProcessRequest(SlingRequestProcessorImpl.java:153)
> org.apache.sling.engine.impl.SlingMainServlet.service(SlingMainServlet.java:206)
> org.apache.felix.http.base.internal.handler.ServletHandler.doHandle(ServletHandler.java:96)
> org.apache.felix.http.base.internal.handler.ServletHandler.handle(ServletHandler.java:79)
> org.apache.felix.http.base.internal.dispatch.ServletPipeline.handle(ServletPipeline.java:42)
> org.apache.felix.http.base.internal.dispatch.InvocationFilterChain.doFilter(InvocationFilterChain.java:49)
> org.apache.felix.http.base.internal.dispatch.HttpFilterChain.doFilter(HttpFilterChain.java:33)
> org.apache.sling.engine.impl.log.RequestLoggerFilter.doFilter(RequestLoggerFilter.java:75)
> org.apache.felix.http.base.internal.handler.FilterHandler.doHandle(FilterHandler.java:88)
> org.apache.felix.http.base.internal.handler.FilterHandler.handle(FilterHandler.java:76)
> org.apache.felix.http.base.internal.dispatch.InvocationFilterChain.doFilter(InvocationFilterChain.java:47)
> org.apache.felix.http.base.internal.dispatch.HttpFilterChain.doFilter(HttpFilterChain.java:33)
> org.apache.felix.http.base.internal.dispatch.FilterPipeline.dispatch(FilterPipeline.java:48)
> org.apache.felix.http.base.internal.dispatch.Dispatcher.dispatch(Dispatcher.java:39)
> org.apache.felix.http.base.internal.DispatcherServlet.service(DispatcherServlet.java:67)
> javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
> org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:654)
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:445)
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:225)
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1044)
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:372)
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:189)
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:978)
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255)
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
> org.eclipse.jetty.server.Server.handle(Server.java:369)
> org.eclipse.jetty.server.AbstractHttp

[jira] [Commented] (SLING-3730) ResourceResolver does not always set the metadata "sling.resolutionPath" properly

[Carsten Ziegeler (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-3730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14052186#comment-14052186
 ] 

Carsten Ziegeler commented on SLING-3730:
-

While it would be correct to remove the call from SyntheticResource it's an API 
change which I would like to avoid. The call there doesn't play a role as the 
ResourceResolver will override the values set there anyway. But if someone is 
using SyntheticResource in a totally different context, we don't break that 
code.

> ResourceResolver does not always set the metadata "sling.resolutionPath" 
> properly
> -
>
> Key: SLING-3730
> URL: https://issues.apache.org/jira/browse/SLING-3730
> Project: Sling
>  Issue Type: Bug
>Affects Versions: JCR Resource 2.3.6, Resource Resolver 1.1.0
>Reporter: Konrad Windszus
>Assignee: Carsten Ziegeler
>Priority: Critical
> Fix For: JCR Resource 2.3.8, Resource Resolver 1.1.2
>
> Attachments: rewriter-issue-1.0.zip
>
>
> This metadata is evaluated by calling: 
> SlingHttpServletRequest.getRequestPathInfo().getResourcePath() (you can see 
> how this field is initially set in 
> org.apache.sling.engine.impl.request.SlingRequestPathInfo, line 59). This is 
> e.g. the case in 
> org.apache.sling.rewriter.impl.ProcessorConfigurationImpl.match(ProcessorConfigurationImpl.java:411).
>  If it returns null like it does for MergedResources (due to that metadata 
> not being set) that leads easily to NPEs like in the example with the 
> SlingRewriter.
> According to the Javadocs of RequestPathInfo 
> (https://github.com/apache/sling/blob/trunk/bundles/api/src/main/java/org/apache/sling/api/request/RequestPathInfo.java)
>  I would assume that getResourcePath() never returns null. For all the other 
> methods it is explicitly stated if they are expected to return null in some 
> cases. All the other Resources like SyntheticResource or JcrItemResource 
> already set that metadata in their constructor.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Jenkins build is still unstable: sling-trunk-1.6 #2256

[Apache Jenkins Server]

See 

Jenkins build is still unstable: sling-trunk-1.6 » Apache Sling Launchpad Testing #2256

[Apache Jenkins Server]

See 

Jenkins build is still unstable: sling-trunk-1.7 #629

[Apache Jenkins Server]

See 

Jenkins build is still unstable: sling-trunk-1.7 » Apache Sling Launchpad Testing #629

[Apache Jenkins Server]

See 

Jenkins build is still unstable: sling-trunk-1.6 #2255

[Apache Jenkins Server]

See 

[jira] [Updated] (SLING-3734) 'org.apache.sling.api.SlingException: Failed to generate name' when posting under load

[David Bosschaert (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-3734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Bosschaert updated SLING-3734:


Attachment: (was: jmeter-config.jmx)

> 'org.apache.sling.api.SlingException: Failed to generate name' when posting 
> under load
> --
>
> Key: SLING-3734
> URL: https://issues.apache.org/jira/browse/SLING-3734
> Project: Sling
>  Issue Type: Bug
>Affects Versions: Launchpad Builder 7
>Reporter: David Bosschaert
> Attachments: jmeter-config.jmx
>
>
> I was doing some load testing on the current Sling (trunk) launchpad which I 
> started as follows:
>  java -jar org.apache.sling.launchpad-7-SNAPSHOT-standalone.jar
> I used a multitreaded client (JMeter, 4 threads) to send a whole bunch of 
> post requests to http://machine:8080/content/mynoderoot/ to get the node name 
> auto-generated.
> However, on about 25% of the requests I'm getting a 500 response with the 
> following exception message: org.apache.sling.api.SlingException: Failed to 
> generate name. The full stack trace is below.
> {code}org.apache.sling.api.SlingException: Failed to generate name
> org.apache.sling.servlets.post.impl.operations.ModifyOperation.getItemPath(ModifyOperation.java:175)
> org.apache.sling.servlets.post.AbstractPostOperation.run(AbstractPostOperation.java:77)
> org.apache.sling.servlets.post.impl.SlingPostServlet.doPost(SlingPostServlet.java:199)
> org.apache.sling.api.servlets.SlingAllMethodsServlet.mayService(SlingAllMethodsServlet.java:148)
> org.apache.sling.api.servlets.SlingSafeMethodsServlet.service(SlingSafeMethodsServlet.java:344)
> org.apache.sling.api.servlets.SlingSafeMethodsServlet.service(SlingSafeMethodsServlet.java:375)
> org.apache.sling.engine.impl.request.RequestData.service(RequestData.java:511)
> org.apache.sling.engine.impl.SlingRequestProcessorImpl.processComponent(SlingRequestProcessorImpl.java:289)
> org.apache.sling.engine.impl.filter.RequestSlingFilterChain.render(RequestSlingFilterChain.java:49)
> org.apache.sling.engine.impl.filter.AbstractSlingFilterChain.doFilter(AbstractSlingFilterChain.java:64)
> org.apache.sling.engine.impl.debug.RequestProgressTrackerLogFilter.doFilter(RequestProgressTrackerLogFilter.java:64)
> org.apache.sling.engine.impl.filter.AbstractSlingFilterChain.doFilter(AbstractSlingFilterChain.java:60)
> org.apache.sling.engine.impl.SlingRequestProcessorImpl.doProcessRequest(SlingRequestProcessorImpl.java:153)
> org.apache.sling.engine.impl.SlingMainServlet.service(SlingMainServlet.java:206)
> org.apache.felix.http.base.internal.handler.ServletHandler.doHandle(ServletHandler.java:96)
> org.apache.felix.http.base.internal.handler.ServletHandler.handle(ServletHandler.java:79)
> org.apache.felix.http.base.internal.dispatch.ServletPipeline.handle(ServletPipeline.java:42)
> org.apache.felix.http.base.internal.dispatch.InvocationFilterChain.doFilter(InvocationFilterChain.java:49)
> org.apache.felix.http.base.internal.dispatch.HttpFilterChain.doFilter(HttpFilterChain.java:33)
> org.apache.sling.engine.impl.log.RequestLoggerFilter.doFilter(RequestLoggerFilter.java:75)
> org.apache.felix.http.base.internal.handler.FilterHandler.doHandle(FilterHandler.java:88)
> org.apache.felix.http.base.internal.handler.FilterHandler.handle(FilterHandler.java:76)
> org.apache.felix.http.base.internal.dispatch.InvocationFilterChain.doFilter(InvocationFilterChain.java:47)
> org.apache.felix.http.base.internal.dispatch.HttpFilterChain.doFilter(HttpFilterChain.java:33)
> org.apache.felix.http.base.internal.dispatch.FilterPipeline.dispatch(FilterPipeline.java:48)
> org.apache.felix.http.base.internal.dispatch.Dispatcher.dispatch(Dispatcher.java:39)
> org.apache.felix.http.base.internal.DispatcherServlet.service(DispatcherServlet.java:67)
> javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
> org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:654)
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:445)
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:225)
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1044)
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:372)
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:189)
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:978)
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255)
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
> org.eclipse.jetty.server.Server.handle(Server.java:369)
> org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpCon

[jira] [Updated] (SLING-3734) 'org.apache.sling.api.SlingException: Failed to generate name' when posting under load

[David Bosschaert (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-3734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Bosschaert updated SLING-3734:


Attachment: jmeter-config.jmx

> 'org.apache.sling.api.SlingException: Failed to generate name' when posting 
> under load
> --
>
> Key: SLING-3734
> URL: https://issues.apache.org/jira/browse/SLING-3734
> Project: Sling
>  Issue Type: Bug
>Affects Versions: Launchpad Builder 7
>Reporter: David Bosschaert
> Attachments: jmeter-config.jmx
>
>
> I was doing some load testing on the current Sling (trunk) launchpad which I 
> started as follows:
>  java -jar org.apache.sling.launchpad-7-SNAPSHOT-standalone.jar
> I used a multitreaded client (JMeter, 4 threads) to send a whole bunch of 
> post requests to http://machine:8080/content/mynoderoot/ to get the node name 
> auto-generated.
> However, on about 25% of the requests I'm getting a 500 response with the 
> following exception message: org.apache.sling.api.SlingException: Failed to 
> generate name. The full stack trace is below.
> {code}org.apache.sling.api.SlingException: Failed to generate name
> org.apache.sling.servlets.post.impl.operations.ModifyOperation.getItemPath(ModifyOperation.java:175)
> org.apache.sling.servlets.post.AbstractPostOperation.run(AbstractPostOperation.java:77)
> org.apache.sling.servlets.post.impl.SlingPostServlet.doPost(SlingPostServlet.java:199)
> org.apache.sling.api.servlets.SlingAllMethodsServlet.mayService(SlingAllMethodsServlet.java:148)
> org.apache.sling.api.servlets.SlingSafeMethodsServlet.service(SlingSafeMethodsServlet.java:344)
> org.apache.sling.api.servlets.SlingSafeMethodsServlet.service(SlingSafeMethodsServlet.java:375)
> org.apache.sling.engine.impl.request.RequestData.service(RequestData.java:511)
> org.apache.sling.engine.impl.SlingRequestProcessorImpl.processComponent(SlingRequestProcessorImpl.java:289)
> org.apache.sling.engine.impl.filter.RequestSlingFilterChain.render(RequestSlingFilterChain.java:49)
> org.apache.sling.engine.impl.filter.AbstractSlingFilterChain.doFilter(AbstractSlingFilterChain.java:64)
> org.apache.sling.engine.impl.debug.RequestProgressTrackerLogFilter.doFilter(RequestProgressTrackerLogFilter.java:64)
> org.apache.sling.engine.impl.filter.AbstractSlingFilterChain.doFilter(AbstractSlingFilterChain.java:60)
> org.apache.sling.engine.impl.SlingRequestProcessorImpl.doProcessRequest(SlingRequestProcessorImpl.java:153)
> org.apache.sling.engine.impl.SlingMainServlet.service(SlingMainServlet.java:206)
> org.apache.felix.http.base.internal.handler.ServletHandler.doHandle(ServletHandler.java:96)
> org.apache.felix.http.base.internal.handler.ServletHandler.handle(ServletHandler.java:79)
> org.apache.felix.http.base.internal.dispatch.ServletPipeline.handle(ServletPipeline.java:42)
> org.apache.felix.http.base.internal.dispatch.InvocationFilterChain.doFilter(InvocationFilterChain.java:49)
> org.apache.felix.http.base.internal.dispatch.HttpFilterChain.doFilter(HttpFilterChain.java:33)
> org.apache.sling.engine.impl.log.RequestLoggerFilter.doFilter(RequestLoggerFilter.java:75)
> org.apache.felix.http.base.internal.handler.FilterHandler.doHandle(FilterHandler.java:88)
> org.apache.felix.http.base.internal.handler.FilterHandler.handle(FilterHandler.java:76)
> org.apache.felix.http.base.internal.dispatch.InvocationFilterChain.doFilter(InvocationFilterChain.java:47)
> org.apache.felix.http.base.internal.dispatch.HttpFilterChain.doFilter(HttpFilterChain.java:33)
> org.apache.felix.http.base.internal.dispatch.FilterPipeline.dispatch(FilterPipeline.java:48)
> org.apache.felix.http.base.internal.dispatch.Dispatcher.dispatch(Dispatcher.java:39)
> org.apache.felix.http.base.internal.DispatcherServlet.service(DispatcherServlet.java:67)
> javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
> org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:654)
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:445)
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:225)
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1044)
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:372)
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:189)
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:978)
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255)
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
> org.eclipse.jetty.server.Server.handle(Server.java:369)
> org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.jav

[jira] [Updated] (SLING-3734) 'org.apache.sling.api.SlingException: Failed to generate name' when posting under load

[David Bosschaert (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-3734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Bosschaert updated SLING-3734:


Attachment: jmeter-config.jmx

To reproduce simply run the attached JMeter file.

I noticed that it happens a *lot* more after node number 999... Is that a hard 
limit on the node number?

> 'org.apache.sling.api.SlingException: Failed to generate name' when posting 
> under load
> --
>
> Key: SLING-3734
> URL: https://issues.apache.org/jira/browse/SLING-3734
> Project: Sling
>  Issue Type: Bug
>Affects Versions: Launchpad Builder 7
>Reporter: David Bosschaert
> Attachments: jmeter-config.jmx
>
>
> I was doing some load testing on the current Sling (trunk) launchpad which I 
> started as follows:
>  java -jar org.apache.sling.launchpad-7-SNAPSHOT-standalone.jar
> I used a multitreaded client (JMeter, 4 threads) to send a whole bunch of 
> post requests to http://machine:8080/content/mynoderoot/ to get the node name 
> auto-generated.
> However, on about 25% of the requests I'm getting a 500 response with the 
> following exception message: org.apache.sling.api.SlingException: Failed to 
> generate name. The full stack trace is below.
> {code}org.apache.sling.api.SlingException: Failed to generate name
> org.apache.sling.servlets.post.impl.operations.ModifyOperation.getItemPath(ModifyOperation.java:175)
> org.apache.sling.servlets.post.AbstractPostOperation.run(AbstractPostOperation.java:77)
> org.apache.sling.servlets.post.impl.SlingPostServlet.doPost(SlingPostServlet.java:199)
> org.apache.sling.api.servlets.SlingAllMethodsServlet.mayService(SlingAllMethodsServlet.java:148)
> org.apache.sling.api.servlets.SlingSafeMethodsServlet.service(SlingSafeMethodsServlet.java:344)
> org.apache.sling.api.servlets.SlingSafeMethodsServlet.service(SlingSafeMethodsServlet.java:375)
> org.apache.sling.engine.impl.request.RequestData.service(RequestData.java:511)
> org.apache.sling.engine.impl.SlingRequestProcessorImpl.processComponent(SlingRequestProcessorImpl.java:289)
> org.apache.sling.engine.impl.filter.RequestSlingFilterChain.render(RequestSlingFilterChain.java:49)
> org.apache.sling.engine.impl.filter.AbstractSlingFilterChain.doFilter(AbstractSlingFilterChain.java:64)
> org.apache.sling.engine.impl.debug.RequestProgressTrackerLogFilter.doFilter(RequestProgressTrackerLogFilter.java:64)
> org.apache.sling.engine.impl.filter.AbstractSlingFilterChain.doFilter(AbstractSlingFilterChain.java:60)
> org.apache.sling.engine.impl.SlingRequestProcessorImpl.doProcessRequest(SlingRequestProcessorImpl.java:153)
> org.apache.sling.engine.impl.SlingMainServlet.service(SlingMainServlet.java:206)
> org.apache.felix.http.base.internal.handler.ServletHandler.doHandle(ServletHandler.java:96)
> org.apache.felix.http.base.internal.handler.ServletHandler.handle(ServletHandler.java:79)
> org.apache.felix.http.base.internal.dispatch.ServletPipeline.handle(ServletPipeline.java:42)
> org.apache.felix.http.base.internal.dispatch.InvocationFilterChain.doFilter(InvocationFilterChain.java:49)
> org.apache.felix.http.base.internal.dispatch.HttpFilterChain.doFilter(HttpFilterChain.java:33)
> org.apache.sling.engine.impl.log.RequestLoggerFilter.doFilter(RequestLoggerFilter.java:75)
> org.apache.felix.http.base.internal.handler.FilterHandler.doHandle(FilterHandler.java:88)
> org.apache.felix.http.base.internal.handler.FilterHandler.handle(FilterHandler.java:76)
> org.apache.felix.http.base.internal.dispatch.InvocationFilterChain.doFilter(InvocationFilterChain.java:47)
> org.apache.felix.http.base.internal.dispatch.HttpFilterChain.doFilter(HttpFilterChain.java:33)
> org.apache.felix.http.base.internal.dispatch.FilterPipeline.dispatch(FilterPipeline.java:48)
> org.apache.felix.http.base.internal.dispatch.Dispatcher.dispatch(Dispatcher.java:39)
> org.apache.felix.http.base.internal.DispatcherServlet.service(DispatcherServlet.java:67)
> javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
> org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:654)
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:445)
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:225)
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1044)
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:372)
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:189)
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:978)
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255)
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.

[jira] [Commented] (SLING-3730) ResourceResolver does not always set the metadata "sling.resolutionPath" properly

[Konrad Windszus (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-3730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14051605#comment-14051605
 ] 

Konrad Windszus commented on SLING-3730:


[~cziegeler] Would you mind removing the call from 
https://github.com/apache/sling/blob/trunk/bundles/api/src/main/java/org/apache/sling/api/resource/SyntheticResource.java
 as well?

> ResourceResolver does not always set the metadata "sling.resolutionPath" 
> properly
> -
>
> Key: SLING-3730
> URL: https://issues.apache.org/jira/browse/SLING-3730
> Project: Sling
>  Issue Type: Bug
>Affects Versions: JCR Resource 2.3.6, Resource Resolver 1.1.0
>Reporter: Konrad Windszus
>Assignee: Carsten Ziegeler
>Priority: Critical
> Fix For: JCR Resource 2.3.8, Resource Resolver 1.1.2
>
> Attachments: rewriter-issue-1.0.zip
>
>
> This metadata is evaluated by calling: 
> SlingHttpServletRequest.getRequestPathInfo().getResourcePath() (you can see 
> how this field is initially set in 
> org.apache.sling.engine.impl.request.SlingRequestPathInfo, line 59). This is 
> e.g. the case in 
> org.apache.sling.rewriter.impl.ProcessorConfigurationImpl.match(ProcessorConfigurationImpl.java:411).
>  If it returns null like it does for MergedResources (due to that metadata 
> not being set) that leads easily to NPEs like in the example with the 
> SlingRewriter.
> According to the Javadocs of RequestPathInfo 
> (https://github.com/apache/sling/blob/trunk/bundles/api/src/main/java/org/apache/sling/api/request/RequestPathInfo.java)
>  I would assume that getResourcePath() never returns null. For all the other 
> methods it is explicitly stated if they are expected to return null in some 
> cases. All the other Resources like SyntheticResource or JcrItemResource 
> already set that metadata in their constructor.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (SLING-3734) 'org.apache.sling.api.SlingException: Failed to generate name' when posting under load

[David Bosschaert (JIRA)]

David Bosschaert created SLING-3734:
---

 Summary: 'org.apache.sling.api.SlingException: Failed to generate 
name' when posting under load
 Key: SLING-3734
 URL: https://issues.apache.org/jira/browse/SLING-3734
 Project: Sling
  Issue Type: Bug
Affects Versions: Launchpad Builder 7
Reporter: David Bosschaert


I was doing some load testing on the current Sling (trunk) launchpad which I 
started as follows:
 java -jar org.apache.sling.launchpad-7-SNAPSHOT-standalone.jar

I used a multitreaded client (JMeter, 4 threads) to send a whole bunch of post 
requests to http://machine:8080/content/mynoderoot/ to get the node name 
auto-generated.
However, on about 25% of the requests I'm getting a 500 response with the 
following exception message: org.apache.sling.api.SlingException: Failed to 
generate name. The full stack trace is below.

{code}org.apache.sling.api.SlingException: Failed to generate name
org.apache.sling.servlets.post.impl.operations.ModifyOperation.getItemPath(ModifyOperation.java:175)
org.apache.sling.servlets.post.AbstractPostOperation.run(AbstractPostOperation.java:77)
org.apache.sling.servlets.post.impl.SlingPostServlet.doPost(SlingPostServlet.java:199)
org.apache.sling.api.servlets.SlingAllMethodsServlet.mayService(SlingAllMethodsServlet.java:148)
org.apache.sling.api.servlets.SlingSafeMethodsServlet.service(SlingSafeMethodsServlet.java:344)
org.apache.sling.api.servlets.SlingSafeMethodsServlet.service(SlingSafeMethodsServlet.java:375)
org.apache.sling.engine.impl.request.RequestData.service(RequestData.java:511)
org.apache.sling.engine.impl.SlingRequestProcessorImpl.processComponent(SlingRequestProcessorImpl.java:289)
org.apache.sling.engine.impl.filter.RequestSlingFilterChain.render(RequestSlingFilterChain.java:49)
org.apache.sling.engine.impl.filter.AbstractSlingFilterChain.doFilter(AbstractSlingFilterChain.java:64)
org.apache.sling.engine.impl.debug.RequestProgressTrackerLogFilter.doFilter(RequestProgressTrackerLogFilter.java:64)
org.apache.sling.engine.impl.filter.AbstractSlingFilterChain.doFilter(AbstractSlingFilterChain.java:60)
org.apache.sling.engine.impl.SlingRequestProcessorImpl.doProcessRequest(SlingRequestProcessorImpl.java:153)
org.apache.sling.engine.impl.SlingMainServlet.service(SlingMainServlet.java:206)
org.apache.felix.http.base.internal.handler.ServletHandler.doHandle(ServletHandler.java:96)
org.apache.felix.http.base.internal.handler.ServletHandler.handle(ServletHandler.java:79)
org.apache.felix.http.base.internal.dispatch.ServletPipeline.handle(ServletPipeline.java:42)
org.apache.felix.http.base.internal.dispatch.InvocationFilterChain.doFilter(InvocationFilterChain.java:49)
org.apache.felix.http.base.internal.dispatch.HttpFilterChain.doFilter(HttpFilterChain.java:33)
org.apache.sling.engine.impl.log.RequestLoggerFilter.doFilter(RequestLoggerFilter.java:75)
org.apache.felix.http.base.internal.handler.FilterHandler.doHandle(FilterHandler.java:88)
org.apache.felix.http.base.internal.handler.FilterHandler.handle(FilterHandler.java:76)
org.apache.felix.http.base.internal.dispatch.InvocationFilterChain.doFilter(InvocationFilterChain.java:47)
org.apache.felix.http.base.internal.dispatch.HttpFilterChain.doFilter(HttpFilterChain.java:33)
org.apache.felix.http.base.internal.dispatch.FilterPipeline.dispatch(FilterPipeline.java:48)
org.apache.felix.http.base.internal.dispatch.Dispatcher.dispatch(Dispatcher.java:39)
org.apache.felix.http.base.internal.DispatcherServlet.service(DispatcherServlet.java:67)
javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:654)
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:445)
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:225)
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1044)
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:372)
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:189)
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:978)
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255)
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
org.eclipse.jetty.server.Server.handle(Server.java:369)
org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:486)
org.eclipse.jetty.server.AbstractHttpConnection.content(AbstractHttpConnection.java:944)
org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.content(AbstractHttpConnection.java:1005)
org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:865)
org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:240)
org.eclipse.jetty.server.AsyncHttpConnection

Jenkins build is still unstable: sling-trunk-1.6 » Apache Sling Launchpad Testing #2255

[Apache Jenkins Server]

See 

[jira] [Resolved] (SLING-3710) Incorrect handling of nt:hierarchyNode instances nested within jcr:content nodes of other nt:hieararchyNode node

[Robert Munteanu (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-3710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Munteanu resolved SLING-3710.


Resolution: Fixed

> Incorrect handling of nt:hierarchyNode instances nested within jcr:content 
> nodes of other nt:hieararchyNode node
> 
>
> Key: SLING-3710
> URL: https://issues.apache.org/jira/browse/SLING-3710
> Project: Sling
>  Issue Type: Bug
>  Components: IDE
>Affects Versions: Sling Eclipse IDE 1.0.0
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
> Fix For: Sling Eclipse IDE 1.0.2
>
>
> Consider the following content structure
> {code}
> - mapping1 [sling:Mapping]
> \- jcr:content [nt:unstructured]
>  \- par1 [nt:unstructured]
>   \- par2 [nt:unstructured]
> + jcr:title = "Title"
>\- folder [sling:Folder]
> {code}
> FileVault will try to collapse all nodes under the jcr:content child node in 
> the same .content.xml aggregate. However, since it encounters an nt:folder 
> node, it will create the filesystem hierarchy as well, leading to the 
> following filesystem representation:
> {code}
> .
> └── mapping1
> ├── .content.xml
> └── _jcr_content
> └── par2
> └── folder
> └── .content.xml
> {code}
> Since we encounter a plain folder at {{mapping1/_jcr_content/par2}}, we 
> assume it's a nt:folder node and don't look at {{mapping1/.content.xml}} to 
> see if its attributes are serialized there.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (SLING-3710) Incorrect handling of nt:hierarchyNode instances nested within jcr:content nodes of other nt:hieararchyNode node

[Robert Munteanu (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-3710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14051599#comment-14051599
 ] 

Robert Munteanu commented on SLING-3710:


* http://svn.apache.org/viewvc?view=revision&revision=1607676 - added missing 
license
* http://svn.apache.org/viewvc?view=revision&revision=1607677 - fix 
ResourceProxy.covers for depth > 1
* http://svn.apache.org/viewvc?view=revision&revision=1607679  - added 
ResourceProxy.getChild
* http://svn.apache.org/viewvc?view=revision&revision=1607680 - ResourceProxy - 
validate paths when adding a child
* http://svn.apache.org/viewvc?view=revision&revision=1607681 - looks for 
serialization data higher in the filesystem if none is found

> Incorrect handling of nt:hierarchyNode instances nested within jcr:content 
> nodes of other nt:hieararchyNode node
> 
>
> Key: SLING-3710
> URL: https://issues.apache.org/jira/browse/SLING-3710
> Project: Sling
>  Issue Type: Bug
>  Components: IDE
>Affects Versions: Sling Eclipse IDE 1.0.0
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
> Fix For: Sling Eclipse IDE 1.0.2
>
>
> Consider the following content structure
> {code}
> - mapping1 [sling:Mapping]
> \- jcr:content [nt:unstructured]
>  \- par1 [nt:unstructured]
>   \- par2 [nt:unstructured]
> + jcr:title = "Title"
>\- folder [sling:Folder]
> {code}
> FileVault will try to collapse all nodes under the jcr:content child node in 
> the same .content.xml aggregate. However, since it encounters an nt:folder 
> node, it will create the filesystem hierarchy as well, leading to the 
> following filesystem representation:
> {code}
> .
> └── mapping1
> ├── .content.xml
> └── _jcr_content
> └── par2
> └── folder
> └── .content.xml
> {code}
> Since we encounter a plain folder at {{mapping1/_jcr_content/par2}}, we 
> assume it's a nt:folder node and don't look at {{mapping1/.content.xml}} to 
> see if its attributes are serialized there.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Jenkins build is still unstable: sling-trunk-1.7 #628

[Apache Jenkins Server]

See 

Jenkins build is still unstable: sling-trunk-1.7 » Apache Sling Launchpad Testing #628

[Apache Jenkins Server]

See 

[jira] [Commented] (SLING-3730) ResourceResolver does not always set the metadata "sling.resolutionPath" properly

[Carsten Ziegeler (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-3730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14051559#comment-14051559
 ] 

Carsten Ziegeler commented on SLING-3730:
-

I've added two missing calls and also removed the set call from the 
JcrItemResource.

> ResourceResolver does not always set the metadata "sling.resolutionPath" 
> properly
> -
>
> Key: SLING-3730
> URL: https://issues.apache.org/jira/browse/SLING-3730
> Project: Sling
>  Issue Type: Bug
>Affects Versions: JCR Resource 2.3.6, Resource Resolver 1.1.0
>Reporter: Konrad Windszus
>Assignee: Carsten Ziegeler
>Priority: Critical
> Fix For: JCR Resource 2.3.8, Resource Resolver 1.1.2
>
> Attachments: rewriter-issue-1.0.zip
>
>
> This metadata is evaluated by calling: 
> SlingHttpServletRequest.getRequestPathInfo().getResourcePath() (you can see 
> how this field is initially set in 
> org.apache.sling.engine.impl.request.SlingRequestPathInfo, line 59). This is 
> e.g. the case in 
> org.apache.sling.rewriter.impl.ProcessorConfigurationImpl.match(ProcessorConfigurationImpl.java:411).
>  If it returns null like it does for MergedResources (due to that metadata 
> not being set) that leads easily to NPEs like in the example with the 
> SlingRewriter.
> According to the Javadocs of RequestPathInfo 
> (https://github.com/apache/sling/blob/trunk/bundles/api/src/main/java/org/apache/sling/api/request/RequestPathInfo.java)
>  I would assume that getResourcePath() never returns null. For all the other 
> methods it is explicitly stated if they are expected to return null in some 
> cases. All the other Resources like SyntheticResource or JcrItemResource 
> already set that metadata in their constructor.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (SLING-3730) ResourceResolver does not always set the metadata "sling.resolutionPath" properly

[Carsten Ziegeler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-3730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Carsten Ziegeler updated SLING-3730:


Affects Version/s: JCR Resource 2.3.6

> ResourceResolver does not always set the metadata "sling.resolutionPath" 
> properly
> -
>
> Key: SLING-3730
> URL: https://issues.apache.org/jira/browse/SLING-3730
> Project: Sling
>  Issue Type: Bug
>Affects Versions: JCR Resource 2.3.6, Resource Resolver 1.1.0
>Reporter: Konrad Windszus
>Assignee: Carsten Ziegeler
>Priority: Critical
> Fix For: JCR Resource 2.3.8, Resource Resolver 1.1.2
>
> Attachments: rewriter-issue-1.0.zip
>
>
> This metadata is evaluated by calling: 
> SlingHttpServletRequest.getRequestPathInfo().getResourcePath() (you can see 
> how this field is initially set in 
> org.apache.sling.engine.impl.request.SlingRequestPathInfo, line 59). This is 
> e.g. the case in 
> org.apache.sling.rewriter.impl.ProcessorConfigurationImpl.match(ProcessorConfigurationImpl.java:411).
>  If it returns null like it does for MergedResources (due to that metadata 
> not being set) that leads easily to NPEs like in the example with the 
> SlingRewriter.
> According to the Javadocs of RequestPathInfo 
> (https://github.com/apache/sling/blob/trunk/bundles/api/src/main/java/org/apache/sling/api/request/RequestPathInfo.java)
>  I would assume that getResourcePath() never returns null. For all the other 
> methods it is explicitly stated if they are expected to return null in some 
> cases. All the other Resources like SyntheticResource or JcrItemResource 
> already set that metadata in their constructor.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (SLING-3730) ResourceResolver does not always set the metadata "sling.resolutionPath" properly

[Carsten Ziegeler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-3730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Carsten Ziegeler updated SLING-3730:


Fix Version/s: JCR Resource 2.3.8

> ResourceResolver does not always set the metadata "sling.resolutionPath" 
> properly
> -
>
> Key: SLING-3730
> URL: https://issues.apache.org/jira/browse/SLING-3730
> Project: Sling
>  Issue Type: Bug
>Affects Versions: JCR Resource 2.3.6, Resource Resolver 1.1.0
>Reporter: Konrad Windszus
>Assignee: Carsten Ziegeler
>Priority: Critical
> Fix For: JCR Resource 2.3.8, Resource Resolver 1.1.2
>
> Attachments: rewriter-issue-1.0.zip
>
>
> This metadata is evaluated by calling: 
> SlingHttpServletRequest.getRequestPathInfo().getResourcePath() (you can see 
> how this field is initially set in 
> org.apache.sling.engine.impl.request.SlingRequestPathInfo, line 59). This is 
> e.g. the case in 
> org.apache.sling.rewriter.impl.ProcessorConfigurationImpl.match(ProcessorConfigurationImpl.java:411).
>  If it returns null like it does for MergedResources (due to that metadata 
> not being set) that leads easily to NPEs like in the example with the 
> SlingRewriter.
> According to the Javadocs of RequestPathInfo 
> (https://github.com/apache/sling/blob/trunk/bundles/api/src/main/java/org/apache/sling/api/request/RequestPathInfo.java)
>  I would assume that getResourcePath() never returns null. For all the other 
> methods it is explicitly stated if they are expected to return null in some 
> cases. All the other Resources like SyntheticResource or JcrItemResource 
> already set that metadata in their constructor.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (SLING-3730) ResourceResolver does not always set the metadata "sling.resolutionPath" properly

[Carsten Ziegeler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-3730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Carsten Ziegeler updated SLING-3730:


Summary: ResourceResolver does not always set the metadata 
"sling.resolutionPath" properly  (was: MergedResource does not set the metadata 
"sling.resolutionPath" properly)

> ResourceResolver does not always set the metadata "sling.resolutionPath" 
> properly
> -
>
> Key: SLING-3730
> URL: https://issues.apache.org/jira/browse/SLING-3730
> Project: Sling
>  Issue Type: Bug
>Affects Versions: Resource Resolver 1.1.0
>Reporter: Konrad Windszus
>Assignee: Carsten Ziegeler
>Priority: Critical
> Fix For: Resource Resolver 1.1.2
>
> Attachments: rewriter-issue-1.0.zip
>
>
> This metadata is evaluated by calling: 
> SlingHttpServletRequest.getRequestPathInfo().getResourcePath() (you can see 
> how this field is initially set in 
> org.apache.sling.engine.impl.request.SlingRequestPathInfo, line 59). This is 
> e.g. the case in 
> org.apache.sling.rewriter.impl.ProcessorConfigurationImpl.match(ProcessorConfigurationImpl.java:411).
>  If it returns null like it does for MergedResources (due to that metadata 
> not being set) that leads easily to NPEs like in the example with the 
> SlingRewriter.
> According to the Javadocs of RequestPathInfo 
> (https://github.com/apache/sling/blob/trunk/bundles/api/src/main/java/org/apache/sling/api/request/RequestPathInfo.java)
>  I would assume that getResourcePath() never returns null. For all the other 
> methods it is explicitly stated if they are expected to return null in some 
> cases. All the other Resources like SyntheticResource or JcrItemResource 
> already set that metadata in their constructor.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (SLING-3730) MergedResource does not set the metadata "sling.resolutionPath" properly

[Carsten Ziegeler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-3730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Carsten Ziegeler updated SLING-3730:


Fix Version/s: Resource Resolver 1.1.2

> MergedResource does not set the metadata "sling.resolutionPath" properly
> 
>
> Key: SLING-3730
> URL: https://issues.apache.org/jira/browse/SLING-3730
> Project: Sling
>  Issue Type: Bug
>Affects Versions: Resource Resolver 1.1.0
>Reporter: Konrad Windszus
>Priority: Critical
> Fix For: Resource Resolver 1.1.2
>
> Attachments: rewriter-issue-1.0.zip
>
>
> This metadata is evaluated by calling: 
> SlingHttpServletRequest.getRequestPathInfo().getResourcePath() (you can see 
> how this field is initially set in 
> org.apache.sling.engine.impl.request.SlingRequestPathInfo, line 59). This is 
> e.g. the case in 
> org.apache.sling.rewriter.impl.ProcessorConfigurationImpl.match(ProcessorConfigurationImpl.java:411).
>  If it returns null like it does for MergedResources (due to that metadata 
> not being set) that leads easily to NPEs like in the example with the 
> SlingRewriter.
> According to the Javadocs of RequestPathInfo 
> (https://github.com/apache/sling/blob/trunk/bundles/api/src/main/java/org/apache/sling/api/request/RequestPathInfo.java)
>  I would assume that getResourcePath() never returns null. For all the other 
> methods it is explicitly stated if they are expected to return null in some 
> cases. All the other Resources like SyntheticResource or JcrItemResource 
> already set that metadata in their constructor.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (SLING-3730) MergedResource does not set the metadata "sling.resolutionPath" properly

[Carsten Ziegeler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-3730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Carsten Ziegeler updated SLING-3730:


Affects Version/s: (was: Resource Merger 1.1.2)
   Resource Resolver 1.1.0

> MergedResource does not set the metadata "sling.resolutionPath" properly
> 
>
> Key: SLING-3730
> URL: https://issues.apache.org/jira/browse/SLING-3730
> Project: Sling
>  Issue Type: Bug
>Affects Versions: Resource Resolver 1.1.0
>Reporter: Konrad Windszus
>Priority: Critical
> Fix For: Resource Resolver 1.1.2
>
> Attachments: rewriter-issue-1.0.zip
>
>
> This metadata is evaluated by calling: 
> SlingHttpServletRequest.getRequestPathInfo().getResourcePath() (you can see 
> how this field is initially set in 
> org.apache.sling.engine.impl.request.SlingRequestPathInfo, line 59). This is 
> e.g. the case in 
> org.apache.sling.rewriter.impl.ProcessorConfigurationImpl.match(ProcessorConfigurationImpl.java:411).
>  If it returns null like it does for MergedResources (due to that metadata 
> not being set) that leads easily to NPEs like in the example with the 
> SlingRewriter.
> According to the Javadocs of RequestPathInfo 
> (https://github.com/apache/sling/blob/trunk/bundles/api/src/main/java/org/apache/sling/api/request/RequestPathInfo.java)
>  I would assume that getResourcePath() never returns null. For all the other 
> methods it is explicitly stated if they are expected to return null in some 
> cases. All the other Resources like SyntheticResource or JcrItemResource 
> already set that metadata in their constructor.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Assigned] (SLING-3730) MergedResource does not set the metadata "sling.resolutionPath" properly

[Carsten Ziegeler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-3730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Carsten Ziegeler reassigned SLING-3730:
---

Assignee: Carsten Ziegeler

> MergedResource does not set the metadata "sling.resolutionPath" properly
> 
>
> Key: SLING-3730
> URL: https://issues.apache.org/jira/browse/SLING-3730
> Project: Sling
>  Issue Type: Bug
>Affects Versions: Resource Resolver 1.1.0
>Reporter: Konrad Windszus
>Assignee: Carsten Ziegeler
>Priority: Critical
> Fix For: Resource Resolver 1.1.2
>
> Attachments: rewriter-issue-1.0.zip
>
>
> This metadata is evaluated by calling: 
> SlingHttpServletRequest.getRequestPathInfo().getResourcePath() (you can see 
> how this field is initially set in 
> org.apache.sling.engine.impl.request.SlingRequestPathInfo, line 59). This is 
> e.g. the case in 
> org.apache.sling.rewriter.impl.ProcessorConfigurationImpl.match(ProcessorConfigurationImpl.java:411).
>  If it returns null like it does for MergedResources (due to that metadata 
> not being set) that leads easily to NPEs like in the example with the 
> SlingRewriter.
> According to the Javadocs of RequestPathInfo 
> (https://github.com/apache/sling/blob/trunk/bundles/api/src/main/java/org/apache/sling/api/request/RequestPathInfo.java)
>  I would assume that getResourcePath() never returns null. For all the other 
> methods it is explicitly stated if they are expected to return null in some 
> cases. All the other Resources like SyntheticResource or JcrItemResource 
> already set that metadata in their constructor.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (SLING-3730) MergedResource does not set the metadata "sling.resolutionPath" properly

[Carsten Ziegeler (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-3730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14051544#comment-14051544
 ] 

Carsten Ziegeler commented on SLING-3730:
-

Good catch, yes, the resource resolver should always set both values - it's the 
only component who knows this information.

> MergedResource does not set the metadata "sling.resolutionPath" properly
> 
>
> Key: SLING-3730
> URL: https://issues.apache.org/jira/browse/SLING-3730
> Project: Sling
>  Issue Type: Bug
>Affects Versions: Resource Resolver 1.1.0
>Reporter: Konrad Windszus
>Priority: Critical
> Fix For: Resource Resolver 1.1.2
>
> Attachments: rewriter-issue-1.0.zip
>
>
> This metadata is evaluated by calling: 
> SlingHttpServletRequest.getRequestPathInfo().getResourcePath() (you can see 
> how this field is initially set in 
> org.apache.sling.engine.impl.request.SlingRequestPathInfo, line 59). This is 
> e.g. the case in 
> org.apache.sling.rewriter.impl.ProcessorConfigurationImpl.match(ProcessorConfigurationImpl.java:411).
>  If it returns null like it does for MergedResources (due to that metadata 
> not being set) that leads easily to NPEs like in the example with the 
> SlingRewriter.
> According to the Javadocs of RequestPathInfo 
> (https://github.com/apache/sling/blob/trunk/bundles/api/src/main/java/org/apache/sling/api/request/RequestPathInfo.java)
>  I would assume that getResourcePath() never returns null. For all the other 
> methods it is explicitly stated if they are expected to return null in some 
> cases. All the other Resources like SyntheticResource or JcrItemResource 
> already set that metadata in their constructor.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Jenkins build is unstable: sling-trunk-1.6 #2254

[Apache Jenkins Server]

See 

Jenkins build is back to normal : sling-trunk-1.6 » Apache Sling Launchpad Application Builder #2254

[Apache Jenkins Server]

See 

Jenkins build is unstable: sling-trunk-1.6 » Apache Sling Launchpad Testing #2254

[Apache Jenkins Server]

See 

Jenkins build is still unstable: sling-trunk-1.7 #627

[Apache Jenkins Server]

See 

Jenkins build is still unstable: sling-trunk-1.7 » Apache Sling Launchpad Testing #627

[Apache Jenkins Server]

See 

[jira] [Comment Edited] (SLING-3730) MergedResource does not set the metadata "sling.resolutionPath" properly

[Konrad Windszus (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-3730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14051506#comment-14051506
 ] 

Konrad Windszus edited comment on SLING-3730 at 7/3/14 2:30 PM:


I assume that under certain circumstances only the ResolutionPathInfo is set 
(https://github.com/apache/sling/blob/trunk/bundles/resourceresolver/src/main/java/org/apache/sling/resourceresolver/impl/ResourceResolverImpl.java#L819)
 but not the ResolutionPath as it is in 
https://github.com/apache/sling/blob/trunk/bundles/resourceresolver/src/main/java/org/apache/sling/resourceresolver/impl/ResourceResolverImpl.java#L869.
 It seems to me that the first option (checking the path directly) does not 
seem to be implemented correctly in ResourceResolverImpl.resolveInternal(), as 
it sets only ResolutionPathInfo but not ResolutionPath. Also there is a lot of 
duplicate code in the method.


was (Author: kwin):
I assume that under certain circumstances only the ResolutionPathInfo is set 
(https://github.com/apache/sling/blob/trunk/bundles/resourceresolver/src/main/java/org/apache/sling/resourceresolver/impl/ResourceResolverImpl.java#L819)
 but not the ResolutionPath as it is in 
https://github.com/apache/sling/blob/trunk/bundles/resourceresolver/src/main/java/org/apache/sling/resourceresolver/impl/ResourceResolverImpl.java#L869.
 To me the first option (checking the path directly) does not seem to be 
implemented correctly in ResourceResolverImpl.resolveInternal()

> MergedResource does not set the metadata "sling.resolutionPath" properly
> 
>
> Key: SLING-3730
> URL: https://issues.apache.org/jira/browse/SLING-3730
> Project: Sling
>  Issue Type: Bug
>Affects Versions: Resource Merger 1.1.2
>Reporter: Konrad Windszus
>Priority: Critical
> Attachments: rewriter-issue-1.0.zip
>
>
> This metadata is evaluated by calling: 
> SlingHttpServletRequest.getRequestPathInfo().getResourcePath() (you can see 
> how this field is initially set in 
> org.apache.sling.engine.impl.request.SlingRequestPathInfo, line 59). This is 
> e.g. the case in 
> org.apache.sling.rewriter.impl.ProcessorConfigurationImpl.match(ProcessorConfigurationImpl.java:411).
>  If it returns null like it does for MergedResources (due to that metadata 
> not being set) that leads easily to NPEs like in the example with the 
> SlingRewriter.
> According to the Javadocs of RequestPathInfo 
> (https://github.com/apache/sling/blob/trunk/bundles/api/src/main/java/org/apache/sling/api/request/RequestPathInfo.java)
>  I would assume that getResourcePath() never returns null. For all the other 
> methods it is explicitly stated if they are expected to return null in some 
> cases. All the other Resources like SyntheticResource or JcrItemResource 
> already set that metadata in their constructor.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (SLING-3730) MergedResource does not set the metadata "sling.resolutionPath" properly

[Konrad Windszus (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-3730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14051506#comment-14051506
 ] 

Konrad Windszus commented on SLING-3730:


I assume that under certain circumstances only the ResolutionPathInfo is set 
(https://github.com/apache/sling/blob/trunk/bundles/resourceresolver/src/main/java/org/apache/sling/resourceresolver/impl/ResourceResolverImpl.java#L819)
 but not the ResolutionPath as it is in 
https://github.com/apache/sling/blob/trunk/bundles/resourceresolver/src/main/java/org/apache/sling/resourceresolver/impl/ResourceResolverImpl.java#L869.
 To me the first option (checking the path directly) does not seem to be 
implemented correctly in ResourceResolverImpl.resolveInternal()

> MergedResource does not set the metadata "sling.resolutionPath" properly
> 
>
> Key: SLING-3730
> URL: https://issues.apache.org/jira/browse/SLING-3730
> Project: Sling
>  Issue Type: Bug
>Affects Versions: Resource Merger 1.1.2
>Reporter: Konrad Windszus
>Priority: Critical
> Attachments: rewriter-issue-1.0.zip
>
>
> This metadata is evaluated by calling: 
> SlingHttpServletRequest.getRequestPathInfo().getResourcePath() (you can see 
> how this field is initially set in 
> org.apache.sling.engine.impl.request.SlingRequestPathInfo, line 59). This is 
> e.g. the case in 
> org.apache.sling.rewriter.impl.ProcessorConfigurationImpl.match(ProcessorConfigurationImpl.java:411).
>  If it returns null like it does for MergedResources (due to that metadata 
> not being set) that leads easily to NPEs like in the example with the 
> SlingRewriter.
> According to the Javadocs of RequestPathInfo 
> (https://github.com/apache/sling/blob/trunk/bundles/api/src/main/java/org/apache/sling/api/request/RequestPathInfo.java)
>  I would assume that getResourcePath() never returns null. For all the other 
> methods it is explicitly stated if they are expected to return null in some 
> cases. All the other Resources like SyntheticResource or JcrItemResource 
> already set that metadata in their constructor.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (SLING-3733) Remodel API for more natural usage of IO operations

[Robert Munteanu (JIRA)]

Robert Munteanu created SLING-3733:
--

 Summary: Remodel API for more natural usage of IO operations
 Key: SLING-3733
 URL: https://issues.apache.org/jira/browse/SLING-3733
 Project: Sling
  Issue Type: Improvement
  Components: IDE
Reporter: Robert Munteanu
Priority: Critical
 Fix For: Sling Eclipse IDE 1.1.0


The current approach for working with I/O is a bit convoluted. To make sure we 
integrate properly with multiple potential environments - Eclipse, IntelliJ, 
Netbeans, CLI - our APIs work mainly with Strings and InputStreams ( or 
byte-arrays ).

Although it works fine, it's starting to become awkward, as a single operation 
can consist of multiple calls to API methods due to this back-and-forth. For 
instance:

{code}
  // Sling IDE API
String serializationFilePath = 
serializationManager.getSerializationFilePath(resourceLocation,
serializationKind);
   // Eclipse API
IPath serializationFilePath2 = 
Path.fromPortableString(serializationFilePath);
// Eclipse API
IResource serializationResource = 
syncDirectory.findMember(serializationFilePath2);
// a bit later...
   // Sling IDE API
   serializationManager.readSerializationData(serializationFilePath, 
serializationResource.getContents();
{code}

We should overhaul the I/O-based APIs to work with I/O abstractios ( e.g. 
FileReader -> EclipseFileReader ) and make those operations more coherent.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (SLING-3648) CLONE - Content Loader ignores bundles that were upgraded when the OSGi container was offline

[Bertrand Delacretaz (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-3648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bertrand Delacretaz resolved SLING-3648.


Resolution: Fixed
  Assignee: Bertrand Delacretaz

Thanks for your contribution, committed in r1607658

> CLONE - Content Loader ignores bundles that were upgraded when the OSGi 
> container was offline
> -
>
> Key: SLING-3648
> URL: https://issues.apache.org/jira/browse/SLING-3648
> Project: Sling
>  Issue Type: Bug
>  Components: JCR
>Affects Versions: JCR ContentLoader 2.1.8
>Reporter: Artyom Stetsenko
>Assignee: Bertrand Delacretaz
> Attachments: SLING-3648.patch
>
>
> If a bundle is updated when the OSGi container is offline or as a result of 
> an update during startup, the content loader does not consider the bundle to 
> have been updated and consequently does not inspect the new content to see if 
> it should be loaded.
> I have a patch, that uses the bundle last modified date (bound to when it was 
> installed) and the content loaded at timestamp on the bundle registration 
> node to determine if the bundle should be reloaded. It appears to work for 
> me, waiting for on list review before committing.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (SLING-3730) MergedResource does not set the metadata "sling.resolutionPath" properly

[Konrad Windszus (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-3730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14051498#comment-14051498
 ] 

Konrad Windszus commented on SLING-3730:


I only have an example for AEM6. You find the according content package 
attached. By just registering your Sling Rewriter to a custom path prefix (in 
this case /content) an NPE is thrown when clicking on "Publish" within 
/editor.html/content/geometrixx.html.

> MergedResource does not set the metadata "sling.resolutionPath" properly
> 
>
> Key: SLING-3730
> URL: https://issues.apache.org/jira/browse/SLING-3730
> Project: Sling
>  Issue Type: Bug
>Affects Versions: Resource Merger 1.1.2
>Reporter: Konrad Windszus
>Priority: Critical
> Attachments: rewriter-issue-1.0.zip
>
>
> This metadata is evaluated by calling: 
> SlingHttpServletRequest.getRequestPathInfo().getResourcePath() (you can see 
> how this field is initially set in 
> org.apache.sling.engine.impl.request.SlingRequestPathInfo, line 59). This is 
> e.g. the case in 
> org.apache.sling.rewriter.impl.ProcessorConfigurationImpl.match(ProcessorConfigurationImpl.java:411).
>  If it returns null like it does for MergedResources (due to that metadata 
> not being set) that leads easily to NPEs like in the example with the 
> SlingRewriter.
> According to the Javadocs of RequestPathInfo 
> (https://github.com/apache/sling/blob/trunk/bundles/api/src/main/java/org/apache/sling/api/request/RequestPathInfo.java)
>  I would assume that getResourcePath() never returns null. For all the other 
> methods it is explicitly stated if they are expected to return null in some 
> cases. All the other Resources like SyntheticResource or JcrItemResource 
> already set that metadata in their constructor.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (SLING-3730) MergedResource does not set the metadata "sling.resolutionPath" properly

[Konrad Windszus (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-3730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Konrad Windszus updated SLING-3730:
---

Attachment: rewriter-issue-1.0.zip

> MergedResource does not set the metadata "sling.resolutionPath" properly
> 
>
> Key: SLING-3730
> URL: https://issues.apache.org/jira/browse/SLING-3730
> Project: Sling
>  Issue Type: Bug
>Affects Versions: Resource Merger 1.1.2
>Reporter: Konrad Windszus
>Priority: Critical
> Attachments: rewriter-issue-1.0.zip
>
>
> This metadata is evaluated by calling: 
> SlingHttpServletRequest.getRequestPathInfo().getResourcePath() (you can see 
> how this field is initially set in 
> org.apache.sling.engine.impl.request.SlingRequestPathInfo, line 59). This is 
> e.g. the case in 
> org.apache.sling.rewriter.impl.ProcessorConfigurationImpl.match(ProcessorConfigurationImpl.java:411).
>  If it returns null like it does for MergedResources (due to that metadata 
> not being set) that leads easily to NPEs like in the example with the 
> SlingRewriter.
> According to the Javadocs of RequestPathInfo 
> (https://github.com/apache/sling/blob/trunk/bundles/api/src/main/java/org/apache/sling/api/request/RequestPathInfo.java)
>  I would assume that getResourcePath() never returns null. For all the other 
> methods it is explicitly stated if they are expected to return null in some 
> cases. All the other Resources like SyntheticResource or JcrItemResource 
> already set that metadata in their constructor.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Re: release of fsresource bundle?

[Oliver Lietz]

On Monday 30 June 2014 17:09:16 Bertrand Delacretaz wrote:
> On Mon, Jun 30, 2014 at 12:05 PM, Oliver Lietz  
wrote:
> > On Monday 30 June 2014 11:44:33 Stefan Seifert wrote:
> >> can we make a new release of the fsresource bundle?
> 
> ...
> 
> > +1 (as this is one of two snapshot bundles left over in the Karaf feature
> > descriptor)
> 
> Sounds like a great job for a newly elected PMC member ;-)

sure, it's on my list but I have to get Thymeleaf Scripting and XING 
authentication out and finished first. And the Jackrabbit Server bundle needs 
some care. Not sure if I get everything done before going on holiday next 
week... 8)

O.

> Instructions at
> http://sling.apache.org/documentation/development/release-management.html
> 
> -Bertrand

[jira] [Comment Edited] (SLING-3730) MergedResource does not set the metadata "sling.resolutionPath" properly

[Carsten Ziegeler (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-3730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14051484#comment-14051484
 ] 

Carsten Ziegeler edited comment on SLING-3730 at 7/3/14 2:16 PM:
-

Actually this should be set by the resource resolver, can you provide a test 
case where this is not the case?
And actually the code in the jcr resource (or other resources) is wrong and 
should be removed, e.g. the jcr resource sets this to the path in the 
repository which could be a totally different path then request path


was (Author: cziegeler):
Actually this should be set by the resource resolver, can you provide a test 
case where this is not the case?

> MergedResource does not set the metadata "sling.resolutionPath" properly
> 
>
> Key: SLING-3730
> URL: https://issues.apache.org/jira/browse/SLING-3730
> Project: Sling
>  Issue Type: Bug
>Affects Versions: Resource Merger 1.1.2
>Reporter: Konrad Windszus
>Priority: Critical
>
> This metadata is evaluated by calling: 
> SlingHttpServletRequest.getRequestPathInfo().getResourcePath() (you can see 
> how this field is initially set in 
> org.apache.sling.engine.impl.request.SlingRequestPathInfo, line 59). This is 
> e.g. the case in 
> org.apache.sling.rewriter.impl.ProcessorConfigurationImpl.match(ProcessorConfigurationImpl.java:411).
>  If it returns null like it does for MergedResources (due to that metadata 
> not being set) that leads easily to NPEs like in the example with the 
> SlingRewriter.
> According to the Javadocs of RequestPathInfo 
> (https://github.com/apache/sling/blob/trunk/bundles/api/src/main/java/org/apache/sling/api/request/RequestPathInfo.java)
>  I would assume that getResourcePath() never returns null. For all the other 
> methods it is explicitly stated if they are expected to return null in some 
> cases. All the other Resources like SyntheticResource or JcrItemResource 
> already set that metadata in their constructor.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (SLING-3730) MergedResource does not set the metadata "sling.resolutionPath" properly

[Carsten Ziegeler (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-3730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14051484#comment-14051484
 ] 

Carsten Ziegeler commented on SLING-3730:
-

Actually this should be set by the resource resolver, can you provide a test 
case where this is not the case?

> MergedResource does not set the metadata "sling.resolutionPath" properly
> 
>
> Key: SLING-3730
> URL: https://issues.apache.org/jira/browse/SLING-3730
> Project: Sling
>  Issue Type: Bug
>Affects Versions: Resource Merger 1.1.2
>Reporter: Konrad Windszus
>Priority: Critical
>
> This metadata is evaluated by calling: 
> SlingHttpServletRequest.getRequestPathInfo().getResourcePath() (you can see 
> how this field is initially set in 
> org.apache.sling.engine.impl.request.SlingRequestPathInfo, line 59). This is 
> e.g. the case in 
> org.apache.sling.rewriter.impl.ProcessorConfigurationImpl.match(ProcessorConfigurationImpl.java:411).
>  If it returns null like it does for MergedResources (due to that metadata 
> not being set) that leads easily to NPEs like in the example with the 
> SlingRewriter.
> According to the Javadocs of RequestPathInfo 
> (https://github.com/apache/sling/blob/trunk/bundles/api/src/main/java/org/apache/sling/api/request/RequestPathInfo.java)
>  I would assume that getResourcePath() never returns null. For all the other 
> methods it is explicitly stated if they are expected to return null in some 
> cases. All the other Resources like SyntheticResource or JcrItemResource 
> already set that metadata in their constructor.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (SLING-3699) [Job Scheduling] A job scheduled using JobBuilder does not get removed if the JobConsumer returns JobResult.OK

[Carsten Ziegeler (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-3699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14051465#comment-14051465
 ] 

Carsten Ziegeler commented on SLING-3699:
-

[~anshika] The workaround should not pose a problem once this is fixed.
However, the job should actually get removed, the TimedEventSender#execute 
method contains a remove instruction at the end. Could you please debug what is 
going wrong there?

> [Job Scheduling] A job scheduled using JobBuilder does not get removed if the 
> JobConsumer returns JobResult.OK
> --
>
> Key: SLING-3699
> URL: https://issues.apache.org/jira/browse/SLING-3699
> Project: Sling
>  Issue Type: Bug
>  Components: API
>Reporter: Anshika Agarwal
>Assignee: Carsten Ziegeler
>Priority: Critical
>  Labels: scheduler, scheduling
> Fix For: Event 3.3.12
>
>
> Behavior:
> If we schedule a job to be executed at a specific time for a topic using:
> JobBuilder jobBuilder = jobManager.createJob(EVENT_TOPIC);
> jobBuilder.properties(props).schedule().at(activationTime).add();
> It first creates a node of type "slingevent:TimedEvent" in crx repository 
> under "/var/eventing/scheduled-jobs" and when the exact time arrives (in this 
> case activationTime), a node of type "slingevent:Job" gets created under 
> assigned jobs and posts an event to the JobConsumer.
> Issue:
> When the JobConsumer returns JobResult.OK the node of type 
> "slingevent:TimedEvent" (scheduled job) does not get removed from the list.
> Due to this issue, when the server restarts, all the jobs that were earlier 
> scheduled and had finished with their execution, get executed again to become 
> nodes of type "slingevent:Job" and again post an event to the JobConsumer. 
> This happens for all the jobs scheduled for a time that is before the current 
> time (when the server restarts)
> Desired:
> Although, we wish to have the scheduled jobs to persist even after the server 
> restarts, but only the jobs that have not yet been executed should be 
> executed after restart. This implies that all the jobs that are executed 
> should be removed from the list of scheduled jobs once the JobConsumer gets 
> the control.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (SLING-3731) add an authentication module using XING API with OAuth

[Oliver Lietz (JIRA)]

Oliver Lietz created SLING-3731:
---

 Summary: add an authentication module using XING API with OAuth
 Key: SLING-3731
 URL: https://issues.apache.org/jira/browse/SLING-3731
 Project: Sling
  Issue Type: New Feature
  Components: Authentication
Reporter: Oliver Lietz
Assignee: Oliver Lietz


* use the [XING API|https://dev.xing.com/docs] with OAuth 1.0 for 
[authentication|https://dev.xing.com/docs/authentication]
* allow creating and updating JCR users based on supplied user data from XING



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (SLING-3701) [Job Scheduling] : No API to search through the scheduled jobs based on some properties.

[Carsten Ziegeler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-3701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Carsten Ziegeler resolved SLING-3701.
-

Resolution: Fixed

I've added a new method getScheduledJobs with takes similar arguments as 
findJobs.

> [Job Scheduling] : No API to search through the scheduled jobs based on some 
> properties.
> 
>
> Key: SLING-3701
> URL: https://issues.apache.org/jira/browse/SLING-3701
> Project: Sling
>  Issue Type: Improvement
>  Components: API
>Reporter: Anshika Agarwal
>Assignee: Carsten Ziegeler
>  Labels: scheduler, scheduling
> Fix For: Event 3.3.12
>
>
> JobManager has the following API to search for jobs of jcr:primaryType as 
> "slingevent:Job":
> Job getJob(String topic, Map template);
> Collection findJobs(QueryType type, String topic, long limit, 
> Map... templates);
> However, I am unable to find an API that will help me search through the 
> scheduled jobs that are of jcr:primaryType as "slingevent:TimedEvent" and are 
> scheduled to become slingevent:Job at a specific time in future.
> Issue:
> Since the above mentioned APIs do not return the scheduled jobs, we are left 
> with the option of retrieving ALL the scheduled jobs using 
> jobManager.getScheduledJobs();
> and then iterating through each of these jobs to find a particular desired 
> job.
> Requirement:
> An API providing search on scheduled jobs based on the event topic and 
> properties would be good. This is required to check if a replication job 
> already exists for a  asset and if it does, it needs to be rescheduled.
> Workaround:
> Collection scheduledJobs = jobManager.getScheduledJobs();
> for (ScheduledJobInfo eachJob : scheduledJobs) {
> if (criteria matches with eachJob)
> { eachJob.reschedule(); }
> }



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (SLING-3732) add an authentication module using "Login with XING"

[Oliver Lietz (JIRA)]

Oliver Lietz created SLING-3732:
---

 Summary: add an authentication module using "Login with XING"
 Key: SLING-3732
 URL: https://issues.apache.org/jira/browse/SLING-3732
 Project: Sling
  Issue Type: New Feature
  Components: Authentication
Reporter: Oliver Lietz
Assignee: Oliver Lietz


* use the cookie-based “[Login with 
XING|https://dev.xing.com/plugins/login_with]” for authentication
* allow creating and updating JCR users based on supplied user data from XING



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Build failed in Jenkins: sling-trunk-1.6 #2253

[Apache Jenkins Server]

See 

Changes:

[bdelacretaz] Fix wrong comment

[rombert] SLING-3681 - Enable the maven-launchpad-plugin to generate the XSD 
for bundles list XML document

Update the target namespace.

Submitted by: Simone Tripodi

--
[...truncated 31125 lines...]
[INFO] Sling Launchpad Standalone Archetype .. SUCCESS [15.203s]
[INFO] Sling Launchpad Webapp Archetype .. SUCCESS [12.599s]
[INFO] Sling Initial Content Archetype ... SUCCESS [10.921s]
[INFO] Sling Servlet Archetype ... SUCCESS [11.615s]
[INFO] Sling Bundle Archetype  SUCCESS [9.445s]
[INFO] Sling JCRInstall Bundle Archetype . SUCCESS [11.188s]
[INFO] Sling Taglib Archetype  SUCCESS [5.989s]
[INFO] Apache Sling API .. SUCCESS [14.496s]
[INFO] Apache Sling Resource Resolver  SUCCESS [14.504s]
[INFO] Apache Sling System Bundle Extension: Java Transaction API  SUCCESS 
[7.870s]
[INFO] Apache Sling System Bundle Extension: XML APIs  SUCCESS [6.185s]
[INFO] Apache Sling System Bundle Extension: Activation API  SUCCESS [8.572s]
[INFO] Apache Sling System Bundle Extension: WS APIs . SUCCESS [3.717s]
[INFO] Apache Sling Dynamic Class Loader Support . SUCCESS [12.064s]
[INFO] Apache Sling Commons Java Compiler  SUCCESS [10.848s]
[INFO] Apache Sling JSON Library . SUCCESS [6.315s]
[INFO] Apache Sling SLF4J Implementation (Logback) ... SUCCESS [36.080s]
[INFO] Apache Sling OSGi LogService Implementation ... SUCCESS [4.056s]
[INFO] Apache Sling MIME type mapping support  SUCCESS [6.293s]
[INFO] Apache Sling Commons OSGi support . SUCCESS [8.416s]
[INFO] Apache Sling Scheduler Support  SUCCESS [5.674s]
[INFO] Apache Sling Testing Utilities  SUCCESS [42.846s]
[INFO] Apache Sling Thread Dumper  SUCCESS [5.630s]
[INFO] Apache Sling Thread Support ... SUCCESS [5.689s]
[INFO] Apache Sling Authentication Service ... SUCCESS [8.968s]
[INFO] Apache Sling OpenID Authentication  SUCCESS [11.417s]
[INFO] Apache Sling Form Based Authentication Handler  SUCCESS [11.669s]
[INFO] Apache Sling Authentication Selector .. SUCCESS [5.980s]
[INFO] Apache Sling Engine Implementation  SUCCESS [24.000s]
[INFO] Apache Sling Repository API Bundle  SUCCESS [6.369s]
[INFO] Apache Sling JCR Base Bundle .. SUCCESS [8.330s]
[INFO] Apache Sling JCR ClassLoader .. SUCCESS [6.547s]
[INFO] Apache Sling Initial Content Loader ... SUCCESS [11.589s]
[INFO] Apache Sling Jackrabbit Embedded Repository ... SUCCESS [11.749s]
[INFO] Apache Sling Jackrabbit UserManager Support ... SUCCESS [8.959s]
[INFO] Apache Sling Jackrabbit JSR-283 Access Control Manager Support  SUCCESS 
[6.197s]
[INFO] Apache Sling Wrapper Bundle for the JCR API ... SUCCESS [5.709s]
[INFO] Apache Sling Object Content Mapping ... SUCCESS [8.820s]
[INFO] Apache Sling JCR Resource Resolver  SUCCESS [51.911s]
[INFO] Apache Sling JCR Repository Registration .. SUCCESS [6.403s]
[INFO] Apache Sling Simple WebDAV Access to repositories . SUCCESS [8.846s]
[INFO] Apache Sling DavEx Access to repositories . SUCCESS [8.628s]
[INFO] Apache Sling JCR WebConsole Bundle  SUCCESS [6.207s]
[INFO] Apache Sling Oak Repository Server  SUCCESS [8.257s]
[INFO] Apache Sling SlingRepository Integration Tests  SUCCESS [50.528s]
[INFO] Apache Sling Servlet Resolver . SUCCESS [8.671s]
[INFO] Apache Sling Default GET Servlets . SUCCESS [8.746s]
[INFO] Apache Sling Default POST Servlets  SUCCESS [9.141s]
[INFO] Apache Sling Compat Servlets .. SUCCESS [3.795s]
[INFO] Apache Sling Scripting Implementation API . SUCCESS [5.947s]
[INFO] Apache Sling Scripting Core implementation  SUCCESS [14.403s]
[INFO] Apache Sling Scripting JavaScript Support . SUCCESS [27.250s]
[INFO] Apache Sling Scripting JSP Support  SUCCESS [12.029s]
[INFO] Apache Sling JSP Tag Library .. SUCCESS [8.811s]
[INFO] Apache Sling JSP Standard Tag Library . SUCCESS [6.104s]
[INFO] Apache Sling Adapter Manager Implementation ... SUCCESS [8.286s]
[INFO] Apache Sling Bundle Resource Provider . SUCCESS [5.897s]
[INFO] Apache Sling Discovery API  SUCCESS [5.644s]
[INFO] Apache Sling Resource-Based Discovery Service . SUCCESS [3:38.901s]
[INFO] Apache Sling Discovery Support Bundle . SUCCESS [5.699s]
[INFO] Apache Sling Discovery Standalone

Build failed in Jenkins: sling-trunk-1.6 » Apache Sling Launchpad Application Builder #2253

[Apache Jenkins Server]

See 


--
[INFO] 
[INFO] 
[INFO] Building Apache Sling Launchpad Application Builder 7-SNAPSHOT
[INFO] 
Downloading: 
http://repository.apache.org/snapshots/org/apache/sling/org.apache.sling.scripting.jsp/2.1.3-SNAPSHOT/org.apache.sling.scripting.jsp-2.1.3-SNAPSHOT.pom
[WARNING] The POM for 
org.apache.sling:org.apache.sling.scripting.jsp:jar:2.1.3-SNAPSHOT is missing, 
no dependency information available
Downloading: 
http://repository.apache.org/snapshots/org/apache/sling/org.apache.sling.scripting.jsp/2.1.3-SNAPSHOT/org.apache.sling.scripting.jsp-2.1.3-SNAPSHOT.jar
[JENKINS] Archiving disabled

Jenkins build is still unstable: sling-trunk-1.7 #626

[Apache Jenkins Server]

See 

Jenkins build is still unstable: sling-trunk-1.7 » Apache Sling Launchpad Testing #626

[Apache Jenkins Server]

See 

Jenkins build is back to stable : sling-trunk-1.7 » Apache Sling Installer Integration Tests #626

[Apache Jenkins Server]

See 

[jira] [Updated] (SLING-3730) MergedResource does not set the metadata "sling.resolutionPath" properly

[Konrad Windszus (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-3730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Konrad Windszus updated SLING-3730:
---

Description: 
This metadata is evaluated by calling: 
SlingHttpServletRequest.getRequestPathInfo().getResourcePath() (you can see how 
this field is initially set in 
org.apache.sling.engine.impl.request.SlingRequestPathInfo, line 59). This is 
e.g. the case in 
org.apache.sling.rewriter.impl.ProcessorConfigurationImpl.match(ProcessorConfigurationImpl.java:411).
 If it returns null like it does for MergedResources (due to that metadata not 
being set) that leads easily to NPEs like in the example with the SlingRewriter.
According to the Javadocs of RequestPathInfo 
(https://github.com/apache/sling/blob/trunk/bundles/api/src/main/java/org/apache/sling/api/request/RequestPathInfo.java)
 I would assume that getResourcePath() never returns null. For all the other 
methods it is explicitly stated if they are expected to return null in some 
cases. All the other Resources like SyntheticResource or JcrItemResource 
already set that metadata in their constructor.

  was:This metadata is evaluated by calling: 
SlingHttpServletRequest().getRequestPathInfo().getResourcePath() (you can see 
how this field is initially set in 
org.apache.sling.engine.impl.request.SlingRequestPathInfo, line 59). This is 
e.g. the case in 
org.apache.sling.rewriter.impl.ProcessorConfigurationImpl.match(ProcessorConfigurationImpl.java:411).
 If it returns null like it does for MergedResources (due to that metadata not 
being set) that leads easily to NPEs like in the example with the SlingRewriter.


> MergedResource does not set the metadata "sling.resolutionPath" properly
> 
>
> Key: SLING-3730
> URL: https://issues.apache.org/jira/browse/SLING-3730
> Project: Sling
>  Issue Type: Bug
>Affects Versions: Resource Merger 1.1.2
>Reporter: Konrad Windszus
>Priority: Critical
>
> This metadata is evaluated by calling: 
> SlingHttpServletRequest.getRequestPathInfo().getResourcePath() (you can see 
> how this field is initially set in 
> org.apache.sling.engine.impl.request.SlingRequestPathInfo, line 59). This is 
> e.g. the case in 
> org.apache.sling.rewriter.impl.ProcessorConfigurationImpl.match(ProcessorConfigurationImpl.java:411).
>  If it returns null like it does for MergedResources (due to that metadata 
> not being set) that leads easily to NPEs like in the example with the 
> SlingRewriter.
> According to the Javadocs of RequestPathInfo 
> (https://github.com/apache/sling/blob/trunk/bundles/api/src/main/java/org/apache/sling/api/request/RequestPathInfo.java)
>  I would assume that getResourcePath() never returns null. For all the other 
> methods it is explicitly stated if they are expected to return null in some 
> cases. All the other Resources like SyntheticResource or JcrItemResource 
> already set that metadata in their constructor.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (SLING-3730) MergedResource does not set the metadata "sling.resolutionPath" properly

[Konrad Windszus (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-3730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14051424#comment-14051424
 ] 

Konrad Windszus commented on SLING-3730:


I would propose setting that to the resource path of the first resource in the 
given list of resources 
(https://github.com/apache/sling/blob/trunk/contrib/extensions/resourcemerger/src/main/java/org/apache/sling/resourcemerger/impl/MergedResource.java)

> MergedResource does not set the metadata "sling.resolutionPath" properly
> 
>
> Key: SLING-3730
> URL: https://issues.apache.org/jira/browse/SLING-3730
> Project: Sling
>  Issue Type: Bug
>Affects Versions: Resource Merger 1.1.2
>Reporter: Konrad Windszus
>Priority: Critical
>
> This metadata is evaluated by calling: 
> SlingHttpServletRequest().getRequestPathInfo().getResourcePath() (you can see 
> how this field is initially set in 
> org.apache.sling.engine.impl.request.SlingRequestPathInfo, line 59). This is 
> e.g. the case in 
> org.apache.sling.rewriter.impl.ProcessorConfigurationImpl.match(ProcessorConfigurationImpl.java:411).
>  If it returns null like it does for MergedResources (due to that metadata 
> not being set) that leads easily to NPEs like in the example with the 
> SlingRewriter.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Re: adaptTo and results ....

[Alexander Klimetschek]

On 03.07.2014, at 13:58, Justin Edelson  wrote:

> It won't work :) This is a hugely non-backwards compatible change. It
> happens to be binary compatible, but it is not semantically compatible
> (which is in some ways just as important). Callers of adaptTo() assume
> (because we have told them to assume) that null will be returned if
> the adaptation can't be done. We can't now start throwing exceptions.
> Callers won't expect this.

There is a conflict with the other stated problem: that most callers don't 
expect null either :) So if we change something, this will have an effect on at 
least some callers either way, unless we add a new method with a different 
semantic.

But I'd say this is just adding complexity for no notable benefit. And just 
improving the logging in case of exceptions in AdpaterFactories and Adaptables 
or that static adaptOrThrow helper should be enough.

Maybe some actual real world cases would help (i.e. no "Foo.class" adaptations 
:). The only one I see is the Sling Models validation case as originally 
outlined here [1] - but could you elaborate? I probably miss the knowledge 
about sling models to see the issue.

[1] http://markmail.org/message/lcujo4flwek3liez

Cheers,
Alex

[jira] [Commented] (SLING-3714) Allow for a caller to request a non-null response from adaptTo()

[Alexander Klimetschek (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-3714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14051413#comment-14051413
 ] 

Alexander Klimetschek commented on SLING-3714:
--

Another option as discussed on the list:
* do not change the Adaptable interface
* just add a static helper that checks for null result and throws in that case: 
{code}
Foo f = AdapterHelper.adaptOrThrow(Foo.class);
{code}

> Allow for a caller to request a non-null response from adaptTo()
> 
>
> Key: SLING-3714
> URL: https://issues.apache.org/jira/browse/SLING-3714
> Project: Sling
>  Issue Type: Improvement
>Reporter: Justin Edelson
>
> See SLING-3709 for a Sling Models-specific request. As I commented there, I 
> think this makes more sense as a core change to the Adaptable interface.
> One option:
> resource.adaptTo(Result.class)
> Which returns a Result object, which has an API like:
> interface Result {
> boolean isSuccess();
> T getObject();
> List getErrors();
> }



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (SLING-3730) MergedResource does not set the metadata "sling.resolutionPath" properly

[Konrad Windszus (JIRA)]

Konrad Windszus created SLING-3730:
--

 Summary: MergedResource does not set the metadata 
"sling.resolutionPath" properly
 Key: SLING-3730
 URL: https://issues.apache.org/jira/browse/SLING-3730
 Project: Sling
  Issue Type: Bug
Affects Versions: Resource Merger 1.1.2
Reporter: Konrad Windszus
Priority: Critical


This metadata is evaluated by calling: 
SlingHttpServletRequest().getRequestPathInfo().getResourcePath() (you can see 
how this field is initially set in 
org.apache.sling.engine.impl.request.SlingRequestPathInfo, line 59). This is 
e.g. the case in 
org.apache.sling.rewriter.impl.ProcessorConfigurationImpl.match(ProcessorConfigurationImpl.java:411).
 If it returns null like it does for MergedResources (due to that metadata not 
being set) that leads easily to NPEs like in the example with the SlingRewriter.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Re: adaptTo and results ....

[Alexander Klimetschek]

On 03.07.2014, at 12:19, Felix Meschberger  wrote:

>>> I guess it would make sense to have adapterfactories et. al. to work like 
>>> this:
>>> a) if it is not of the desired type, i.e. cannot semantically be adapted, 
>>> return null
> 
> example: resource.adaptTo(Node.class) for a resource not backed by a JCR Node 
> instance.
> 
>>> b) if it fails due to some actual exception, throw a runtimexception
> 
> example: resource.adaptTo(Comment.class) when the required data to setup the 
> Comment instance cannot be read from persistence or the data is inconsistent 
> and thus a consistent Comment instance cannot be provided.

This is on the edge - could also be seen as a). To me b) would be if while 
creating/reading that Comment instance, some unexpected JCR RepositoryException 
is thrown (i.e. network failure).

> If handling just is catching and logging, there is no use in throwing in the 
> first place — better immediately log and return some decent value that client 
> can cope with, which in the case of adaptTo is just null (as documented). 
> Plus: the boiler plate to catch and log is more complicated and convoluted 
> than the boiler plate for the null check.

If it's a runtime exception, you don't have to catch it immediately. In a 
request context, the sling request execution would catch & log that exception 
for you, thus by default the request would fail, which makes sense in case of 
an unexpected error like b). But if you want, you could catch it too (i.e. 
would need to be documented what kind of RuntimeException) and do things like 
retry etc. (although generally b) is something you can't do much about and 
almost always would make the whole request or operation fail).

Cheers,
Alex

[jira] [Updated] (SLING-3699) [Job Scheduling] A job scheduled using JobBuilder does not get removed if the JobConsumer returns JobResult.OK

[Carsten Ziegeler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-3699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Carsten Ziegeler updated SLING-3699:


Fix Version/s: Event 3.3.12

> [Job Scheduling] A job scheduled using JobBuilder does not get removed if the 
> JobConsumer returns JobResult.OK
> --
>
> Key: SLING-3699
> URL: https://issues.apache.org/jira/browse/SLING-3699
> Project: Sling
>  Issue Type: Bug
>  Components: API
>Reporter: Anshika Agarwal
>Priority: Critical
>  Labels: scheduler, scheduling
> Fix For: Event 3.3.12
>
>
> Behavior:
> If we schedule a job to be executed at a specific time for a topic using:
> JobBuilder jobBuilder = jobManager.createJob(EVENT_TOPIC);
> jobBuilder.properties(props).schedule().at(activationTime).add();
> It first creates a node of type "slingevent:TimedEvent" in crx repository 
> under "/var/eventing/scheduled-jobs" and when the exact time arrives (in this 
> case activationTime), a node of type "slingevent:Job" gets created under 
> assigned jobs and posts an event to the JobConsumer.
> Issue:
> When the JobConsumer returns JobResult.OK the node of type 
> "slingevent:TimedEvent" (scheduled job) does not get removed from the list.
> Due to this issue, when the server restarts, all the jobs that were earlier 
> scheduled and had finished with their execution, get executed again to become 
> nodes of type "slingevent:Job" and again post an event to the JobConsumer. 
> This happens for all the jobs scheduled for a time that is before the current 
> time (when the server restarts)
> Desired:
> Although, we wish to have the scheduled jobs to persist even after the server 
> restarts, but only the jobs that have not yet been executed should be 
> executed after restart. This implies that all the jobs that are executed 
> should be removed from the list of scheduled jobs once the JobConsumer gets 
> the control.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Assigned] (SLING-3699) [Job Scheduling] A job scheduled using JobBuilder does not get removed if the JobConsumer returns JobResult.OK

[Carsten Ziegeler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-3699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Carsten Ziegeler reassigned SLING-3699:
---

Assignee: Carsten Ziegeler

> [Job Scheduling] A job scheduled using JobBuilder does not get removed if the 
> JobConsumer returns JobResult.OK
> --
>
> Key: SLING-3699
> URL: https://issues.apache.org/jira/browse/SLING-3699
> Project: Sling
>  Issue Type: Bug
>  Components: API
>Reporter: Anshika Agarwal
>Assignee: Carsten Ziegeler
>Priority: Critical
>  Labels: scheduler, scheduling
> Fix For: Event 3.3.12
>
>
> Behavior:
> If we schedule a job to be executed at a specific time for a topic using:
> JobBuilder jobBuilder = jobManager.createJob(EVENT_TOPIC);
> jobBuilder.properties(props).schedule().at(activationTime).add();
> It first creates a node of type "slingevent:TimedEvent" in crx repository 
> under "/var/eventing/scheduled-jobs" and when the exact time arrives (in this 
> case activationTime), a node of type "slingevent:Job" gets created under 
> assigned jobs and posts an event to the JobConsumer.
> Issue:
> When the JobConsumer returns JobResult.OK the node of type 
> "slingevent:TimedEvent" (scheduled job) does not get removed from the list.
> Due to this issue, when the server restarts, all the jobs that were earlier 
> scheduled and had finished with their execution, get executed again to become 
> nodes of type "slingevent:Job" and again post an event to the JobConsumer. 
> This happens for all the jobs scheduled for a time that is before the current 
> time (when the server restarts)
> Desired:
> Although, we wish to have the scheduled jobs to persist even after the server 
> restarts, but only the jobs that have not yet been executed should be 
> executed after restart. This implies that all the jobs that are executed 
> should be removed from the list of scheduled jobs once the JobConsumer gets 
> the control.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Build failed in Jenkins: sling-trunk-1.6 #2252

[Apache Jenkins Server]

See 

Changes:

[rombert] SLING-3710 - Incorrect handling of nt:hierarchyNode instances nested
within jcr:content nodes of other nt:hieararchyNode node

Added an ignored test which shows the failure scenario

--
[...truncated 31161 lines...]
[INFO] Sling Launchpad Standalone Archetype .. SUCCESS [26.656s]
[INFO] Sling Launchpad Webapp Archetype .. SUCCESS [15.923s]
[INFO] Sling Initial Content Archetype ... SUCCESS [11.858s]
[INFO] Sling Servlet Archetype ... SUCCESS [12.237s]
[INFO] Sling Bundle Archetype  SUCCESS [11.632s]
[INFO] Sling JCRInstall Bundle Archetype . SUCCESS [11.176s]
[INFO] Sling Taglib Archetype  SUCCESS [6.553s]
[INFO] Apache Sling API .. SUCCESS [18.297s]
[INFO] Apache Sling Resource Resolver  SUCCESS [18.193s]
[INFO] Apache Sling System Bundle Extension: Java Transaction API  SUCCESS 
[8.316s]
[INFO] Apache Sling System Bundle Extension: XML APIs  SUCCESS [8.580s]
[INFO] Apache Sling System Bundle Extension: Activation API  SUCCESS [8.077s]
[INFO] Apache Sling System Bundle Extension: WS APIs . SUCCESS [8.324s]
[INFO] Apache Sling Dynamic Class Loader Support . SUCCESS [18.245s]
[INFO] Apache Sling Commons Java Compiler  SUCCESS [9.646s]
[INFO] Apache Sling JSON Library . SUCCESS [9.475s]
[INFO] Apache Sling SLF4J Implementation (Logback) ... SUCCESS [44.294s]
[INFO] Apache Sling OSGi LogService Implementation ... SUCCESS [6.278s]
[INFO] Apache Sling MIME type mapping support  SUCCESS [12.002s]
[INFO] Apache Sling Commons OSGi support . SUCCESS [8.974s]
[INFO] Apache Sling Scheduler Support  SUCCESS [9.085s]
[INFO] Apache Sling Testing Utilities  SUCCESS [42.340s]
[INFO] Apache Sling Thread Dumper  SUCCESS [6.068s]
[INFO] Apache Sling Thread Support ... SUCCESS [6.838s]
[INFO] Apache Sling Authentication Service ... SUCCESS [11.975s]
[INFO] Apache Sling OpenID Authentication  SUCCESS [17.669s]
[INFO] Apache Sling Form Based Authentication Handler  SUCCESS [21.233s]
[INFO] Apache Sling Authentication Selector .. SUCCESS [8.777s]
[INFO] Apache Sling Engine Implementation  SUCCESS [26.983s]
[INFO] Apache Sling Repository API Bundle  SUCCESS [8.683s]
[INFO] Apache Sling JCR Base Bundle .. SUCCESS [11.827s]
[INFO] Apache Sling JCR ClassLoader .. SUCCESS [8.709s]
[INFO] Apache Sling Initial Content Loader ... SUCCESS [15.074s]
[INFO] Apache Sling Jackrabbit Embedded Repository ... SUCCESS [18.105s]
[INFO] Apache Sling Jackrabbit UserManager Support ... SUCCESS [11.133s]
[INFO] Apache Sling Jackrabbit JSR-283 Access Control Manager Support  SUCCESS 
[8.674s]
[INFO] Apache Sling Wrapper Bundle for the JCR API ... SUCCESS [5.918s]
[INFO] Apache Sling Object Content Mapping ... SUCCESS [8.806s]
[INFO] Apache Sling JCR Resource Resolver  SUCCESS [59.754s]
[INFO] Apache Sling JCR Repository Registration .. SUCCESS [11.620s]
[INFO] Apache Sling Simple WebDAV Access to repositories . SUCCESS [14.472s]
[INFO] Apache Sling DavEx Access to repositories . SUCCESS [8.254s]
[INFO] Apache Sling JCR WebConsole Bundle  SUCCESS [8.458s]
[INFO] Apache Sling Oak Repository Server  SUCCESS [11.118s]
[INFO] Apache Sling SlingRepository Integration Tests  SUCCESS [50.949s]
[INFO] Apache Sling Servlet Resolver . SUCCESS [12.235s]
[INFO] Apache Sling Default GET Servlets . SUCCESS [11.930s]
[INFO] Apache Sling Default POST Servlets  SUCCESS [14.810s]
[INFO] Apache Sling Compat Servlets .. SUCCESS [9.114s]
[INFO] Apache Sling Scripting Implementation API . SUCCESS [11.122s]
[INFO] Apache Sling Scripting Core implementation  SUCCESS [17.732s]
[INFO] Apache Sling Scripting JavaScript Support . SUCCESS [29.973s]
[INFO] Apache Sling Scripting JSP Support  SUCCESS [20.180s]
[INFO] Apache Sling JSP Tag Library .. SUCCESS [14.324s]
[INFO] Apache Sling JSP Standard Tag Library . SUCCESS [5.831s]
[INFO] Apache Sling Adapter Manager Implementation ... SUCCESS [9.110s]
[INFO] Apache Sling Bundle Resource Provider . SUCCESS [8.513s]
[INFO] Apache Sling Discovery API  SUCCESS [5.930s]
[INFO] Apache Sling Resource-Based Discovery Service . SUCCESS [3:45.227s]
[INFO] Apache Sling Discovery Support Bundle . SUCCESS [6.405s]
[INFO] Apache Sling Discovery Standal

Build failed in Jenkins: sling-trunk-1.6 » Apache Sling Launchpad Application Builder #2252

[Apache Jenkins Server]

See 


--
[INFO] 
[INFO] 
[INFO] Building Apache Sling Launchpad Application Builder 7-SNAPSHOT
[INFO] 
Downloading: 
http://repository.ops4j.org/maven2/org/apache/sling/org.apache.sling.installer.core/3.5.2/org.apache.sling.installer.core-3.5.2.pom
[INFO] I/O exception 
(org.apache.maven.wagon.providers.http.httpclient.NoHttpResponseException) 
caught when processing request: The target server failed to respond
[INFO] Retrying request
Downloading: 
http://repo.maven.apache.org/maven2/org/apache/sling/org.apache.sling.installer.core/3.5.2/org.apache.sling.installer.core-3.5.2.pom
Downloaded: 
http://repo.maven.apache.org/maven2/org/apache/sling/org.apache.sling.installer.core/3.5.2/org.apache.sling.installer.core-3.5.2.pom
 (8 KB at 145.2 KB/sec)
Downloading: 
http://repository.apache.org/snapshots/org/apache/sling/org.apache.sling.scripting.jsp/2.1.3-SNAPSHOT/maven-metadata.xml
Downloading: 
http://repository.apache.org/snapshots/org/apache/sling/org.apache.sling.scripting.jsp/2.1.3-SNAPSHOT/org.apache.sling.scripting.jsp-2.1.3-SNAPSHOT.pom
[WARNING] The POM for 
org.apache.sling:org.apache.sling.scripting.jsp:jar:2.1.3-SNAPSHOT is missing, 
no dependency information available
Downloading: 
http://repository.ops4j.org/maven2/org/apache/sling/org.apache.sling.installer.factory.configuration/1.0.14/org.apache.sling.installer.factory.configuration-1.0.14.pom
Downloading: 
http://repo.maven.apache.org/maven2/org/apache/sling/org.apache.sling.installer.factory.configuration/1.0.14/org.apache.sling.installer.factory.configuration-1.0.14.pom
Downloaded: 
http://repo.maven.apache.org/maven2/org/apache/sling/org.apache.sling.installer.factory.configuration/1.0.14/org.apache.sling.installer.factory.configuration-1.0.14.pom
 (4 KB at 64.0 KB/sec)
Downloading: 
http://repository.ops4j.org/maven2/org/apache/sling/org.apache.sling.installer.core/3.5.2/org.apache.sling.installer.core-3.5.2.jar
Downloading: 
http://repository.ops4j.org/maven2/org/apache/sling/org.apache.sling.installer.factory.configuration/1.0.14/org.apache.sling.installer.factory.configuration-1.0.14.jar
Downloading: 
http://repo.maven.apache.org/maven2/org/apache/sling/org.apache.sling.installer.core/3.5.2/org.apache.sling.installer.core-3.5.2.jar
Downloading: 
http://repo.maven.apache.org/maven2/org/apache/sling/org.apache.sling.installer.factory.configuration/1.0.14/org.apache.sling.installer.factory.configuration-1.0.14.jar
Downloaded: 
http://repo.maven.apache.org/maven2/org/apache/sling/org.apache.sling.installer.factory.configuration/1.0.14/org.apache.sling.installer.factory.configuration-1.0.14.jar
 (25 KB at 1501.3 KB/sec)
Downloaded: 
http://repo.maven.apache.org/maven2/org/apache/sling/org.apache.sling.installer.core/3.5.2/org.apache.sling.installer.core-3.5.2.jar
 (144 KB at 4215.3 KB/sec)
Downloading: 
http://repository.apache.org/snapshots/org/apache/sling/org.apache.sling.scripting.jsp/2.1.3-SNAPSHOT/org.apache.sling.scripting.jsp-2.1.3-SNAPSHOT.jar
[JENKINS] Archiving disabled

Jenkins build is still unstable: sling-trunk-1.7 #625

[Apache Jenkins Server]

See 

Jenkins build became unstable: sling-trunk-1.7 » Apache Sling Installer Integration Tests #625

[Apache Jenkins Server]

See 

Jenkins build is still unstable: sling-trunk-1.7 » Apache Sling Launchpad Testing #625

[Apache Jenkins Server]

See 

[jira] [Commented] (SLING-3681) Enable the maven-launchpad-plugin to generate the XSD for bundles list XML document

[Robert Munteanu (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-3681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14051382#comment-14051382
 ] 

Robert Munteanu commented on SLING-3681:


Updated just now. You might need to force a refresh.

> Enable the maven-launchpad-plugin to generate the XSD for bundles list XML 
> document
> ---
>
> Key: SLING-3681
> URL: https://issues.apache.org/jira/browse/SLING-3681
> Project: Sling
>  Issue Type: Improvement
>  Components: Maven Plugins and Archetypes
>Affects Versions: Maven Launchpad Plugin 2.3.2
>Reporter: Simone Tripodi
>Assignee: Robert Munteanu
> Fix For: Maven Launchpad Plugin 2.3.2
>
> Attachments: SLING-3681.patch, SLING-3681.patch, Screen Shot 
> 2014-06-19 at 11.05.11.pdf
>
>
> More recent versions of the Modello plugin for Maven is able to generate the 
> model's XSchema that, once published on Sling's public site and declared in 
> {{list.xml}} documents, would be really useful in "intelligent" IDEs able to 
> read the schema, understand the structure and assist users for content 
> creation, otherwise it is not clear at all which elements are allowed and 
> which not.
> Patch going to be submitted!



--
This message was sent by Atlassian JIRA
(v6.2#6252)

RE: adaptTo and results ....

[Stefan Seifert]

>* My original suggestion of using a Result interface. This requires
>more verbose code on the caller side -- the caller needs to check a
>success flag -- but allows for fine-grained information (which would
>be appropriate for a validation use case).

+1

https://issues.apache.org/jira/browse/SLING-3714

and following alex hint it is still possible to use separate static method to 
convert this result object adaption call into a single-line "adaptOrThrow" 
method with throws a runtime exception, without having to build this into the 
adaptto API. for projects that use this a lot.

stefan

[jira] [Updated] (SLING-3681) Enable the maven-launchpad-plugin to generate the XSD for bundles list XML document

[Simone Tripodi (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-3681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Simone Tripodi updated SLING-3681:
--

Attachment: SLING-3681.patch

[~rombert] [~cziegeler] I'd like to kindly ask you to republish the XSD 
modifying the target namespace.

HTH!

> Enable the maven-launchpad-plugin to generate the XSD for bundles list XML 
> document
> ---
>
> Key: SLING-3681
> URL: https://issues.apache.org/jira/browse/SLING-3681
> Project: Sling
>  Issue Type: Improvement
>  Components: Maven Plugins and Archetypes
>Affects Versions: Maven Launchpad Plugin 2.3.2
>Reporter: Simone Tripodi
>Assignee: Robert Munteanu
> Fix For: Maven Launchpad Plugin 2.3.2
>
> Attachments: SLING-3681.patch, SLING-3681.patch, Screen Shot 
> 2014-06-19 at 11.05.11.pdf
>
>
> More recent versions of the Modello plugin for Maven is able to generate the 
> model's XSchema that, once published on Sling's public site and declared in 
> {{list.xml}} documents, would be really useful in "intelligent" IDEs able to 
> read the schema, understand the structure and assist users for content 
> creation, otherwise it is not clear at all which elements are allowed and 
> which not.
> Patch going to be submitted!



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (SLING-3709) Sling Models: Allow caller to deal with exceptions

[Justin Edelson (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-3709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14051365#comment-14051365
 ] 

Justin Edelson commented on SLING-3709:
---

No. Such a change violates the contract of AdapterFactory and goes against Java 
best practices.

The current behavior must stay as is unless we have a way for the caller to 
explicitly indicate that she wants something else to happen. A configuration 
switch is not appropriate as that leaves the decision in the hands of the 
administrator, not the caller.

> Sling Models: Allow caller to deal with exceptions
> --
>
> Key: SLING-3709
> URL: https://issues.apache.org/jira/browse/SLING-3709
> Project: Sling
>  Issue Type: Improvement
>Affects Versions: Sling Models Implementation 1.0.4, Sling Models 
> Implementation 1.0.6
>Reporter: Konrad Windszus
>
> Currently due to the specification of the adaptTo-method to return null if 
> adaptation is not possible, the caller is not notified about any exceptions 
> (because they are caught within the ModelAdapterFactory).
> This is e.g. necessary to deal with validation exceptions properly (i.e. 
> required field injection not possible).  The problem was also discussed 
> briefly in 
> http://apache-sling.73963.n3.nabble.com/Silng-Models-Validation-Framework-td4033411.html.
> All exceptions either being thrown by the 
> @PostConstruct method or caused by the field/method injection are not 
> propagated but basically swallowed by Sling Models.
> It would be great to be able to catch those exceptions either in the view or 
> in a servlet filter. I think it should be possible to throw unchecked 
> exceptions in the ModelAdapterFactory.getFactory() method if it is requested 
> (i.e. through a global OSGi configuration flag for Sling Models).
> WDYT?
> Would you accept such a patch or do you think this breaks the API (also 
> compare with 
> https://issues.apache.org/jira/browse/SLING-2712?focusedCommentId=13561516&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13561516).
> If it does not work through the adaptTo, SlingModels should provide an 
> alternative way of instanciating models (and propagating exceptions), 
> although this is kind of tricky, because it internally relies on adaptTo as 
> well (e.g. in 
> https://github.com/apache/sling/blob/trunk/bundles/extensions/models/impl/src/main/java/org/apache/sling/models/impl/ModelAdapterFactory.java#L647)



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Re: adaptTo and results ....

[Justin Edelson]

Hi,

On Thu, Jul 3, 2014 at 4:50 AM, Alexander Klimetschek
 wrote:
> On 03.07.2014, at 09:12, Konrad Windszus  wrote:
>
>> - The client can decide how to expose that error (whether just logging is 
>> fine or something more obvious). This cannot be achieved by just setting up 
>> a utility method, because that one does only see the null return value and 
>> not the original reason for that.
>
> Yes, but my question is whether there is any need to pass through the 
> exception at all.
>
>> - Tracing problems during development is much easier (instead of looking at 
>> the log I can see the full exception)
>
> You can debug exceptions inside the adapterfactories as well (after seeing 
> them in the log).
>
>> - It allows to use it for something like validation in Sling Models
>
> How would that work? (I saw the reference earlier in the thread, but I don't 
> know how you'd use adaptTo for validation and can't really imagine it's a 
> good fit)

Validation means a lot of things; I would say that your example below
where a resource has to be a certain type to be adapted to a resource
collection is a form of validation. As you note, using exceptions for
validation use cases is wrong.

>
>> - It is less error-prone to the developers (you can easily forget to either 
>> use the utility method or check for null)
>
> The null-returning method is out there, it cannot be changed to throw a 
> checked exception (which is the only way to force handling for devs)
>
>> - In my regard in most of the cases if adaptation fails, there is something 
>> wrong with the deployment (required bundles are not installed, components 
>> are not running, ….) and I cannot reasonably work around that issue in the 
>> code -> that calls for an exception
>
> It's not only exception, it's also a way to check if something is of a 
> certain type (say adapting a resource to a resourcecollection). In this case 
> an exception is not the right thing.
>
> I guess it would make sense to have adapterfactories et. al. to work like 
> this:
> a) if it is not of the desired type, i.e. cannot semantically be adapted, 
> return null
> b) if it fails due to some actual exception, throw a runtimexception
>
> But not sure if that will work.

It won't work :) This is a hugely non-backwards compatible change. It
happens to be binary compatible, but it is not semantically compatible
(which is in some ways just as important). Callers of adaptTo() assume
(because we have told them to assume) that null will be returned if
the adaptation can't be done. We can't now start throwing exceptions.
Callers won't expect this.

The caller *must* indicate in some way that she wants behavior which
is different than the current. AFAICT, there are only two viable
solutions:

* My original suggestion of using a Result interface. This requires
more verbose code on the caller side -- the caller needs to check a
success flag -- but allows for fine-grained information (which would
be appropriate for a validation use case).
* Bertrand's suggestion of using some kind of ThreadLocal. Less
verbose code on the caller side. Would seem to violate Effective Java
#57 in that it is using exceptions for control flow.

Both cases can be implemented without impacting existing callers or
adapter factories. Adapter factories would need indicate that they
support the Result interface or exception throwing via a service
property. For factories without the property, the AdapterManagerImpl
would simulate the proper behavior.

Justin

>
> Cheers,
> Alex

[jira] [Commented] (SLING-3710) Incorrect handling of nt:hierarchyNode instances nested within jcr:content nodes of other nt:hieararchyNode node

[Robert Munteanu (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-3710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14051356#comment-14051356
 ] 

Robert Munteanu commented on SLING-3710:


Added a failing and ignored test in 
http://svn.apache.org/viewvc?view=revision&revision=1607593

> Incorrect handling of nt:hierarchyNode instances nested within jcr:content 
> nodes of other nt:hieararchyNode node
> 
>
> Key: SLING-3710
> URL: https://issues.apache.org/jira/browse/SLING-3710
> Project: Sling
>  Issue Type: Bug
>  Components: IDE
>Affects Versions: Sling Eclipse IDE 1.0.0
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
> Fix For: Sling Eclipse IDE 1.0.2
>
>
> Consider the following content structure
> {code}
> - mapping1 [sling:Mapping]
> \- jcr:content [nt:unstructured]
>  \- par1 [nt:unstructured]
>   \- par2 [nt:unstructured]
> + jcr:title = "Title"
>\- folder [sling:Folder]
> {code}
> FileVault will try to collapse all nodes under the jcr:content child node in 
> the same .content.xml aggregate. However, since it encounters an nt:folder 
> node, it will create the filesystem hierarchy as well, leading to the 
> following filesystem representation:
> {code}
> .
> └── mapping1
> ├── .content.xml
> └── _jcr_content
> └── par2
> └── folder
> └── .content.xml
> {code}
> Since we encounter a plain folder at {{mapping1/_jcr_content/par2}}, we 
> assume it's a nt:folder node and don't look at {{mapping1/.content.xml}} to 
> see if its attributes are serialized there.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Re: adaptTo and results ....

[Felix Meschberger]

Hi

Am 03.07.2014 um 12:29 schrieb Konrad Windszus :

> The AdapterFactory should clearly state, which RuntimeExceptions are thrown 
> under which condition. You know in most of the cases, which AdapterFactory is 
> responsible for your adaptTo-method (or you should be able to find out with 
> the web console)

I see. How about thus adding an annotation for the AdapterFactory to declare 
the exceptions thrown so the web console could expose this information as well 
— in the same way as there is the annotations to declare the adapters and 
adaptables.


> Handling in some cases is more than simple logging. The AEM6 
> WCMDeveloperModeFilter is a good example for another error treatment 
> (catching the error within a servlet filter and then exposing via the Web UI).

Good point

Regards
Felix

> 
> On 03 Jul 2014, at 12:19, Felix Meschberger  wrote:
> 
>> Hi
>> 
>> Am 03.07.2014 um 11:10 schrieb Konrad Windszus :
>> 
>>> 
>>> On 03 Jul 2014, at 10:50, Alexander Klimetschek  wrote:
>>> 
 
 I guess it would make sense to have adapterfactories et. al. to work like 
 this:
 a) if it is not of the desired type, i.e. cannot semantically be adapted, 
 return null
>> 
>> example: resource.adaptTo(Node.class) for a resource not backed by a JCR 
>> Node instance.
>> 
 b) if it fails due to some actual exception, throw a runtimexception
>> 
>> example: resource.adaptTo(Comment.class) when the required data to setup the 
>> Comment instance cannot be read from persistence or the data is inconsistent 
>> and thus a consistent Comment instance cannot be provided.
>> 
>>> 
>>> I would be fine with that approach. So the only change is a clarification 
>>> in the Javadocs that adaptTo in fact may throw a RuntimeException (if the 
>>> AdapterFactory has thrown an exception) and also that AdapterFactory may 
>>> throw a RuntimeException.
>> 
>> The question always remains: Do you expect the caller to handle this 
>> exception in some way or another ? Also, what exception can be expected by 
>> the client (you don't want to catch RuntimeException, do you ?) ? and what 
>> does it mean ?
>> 
>> If handling just is catching and logging, there is no use in throwing in the 
>> first place — better immediately log and return some decent value that 
>> client can cope with, which in the case of adaptTo is just null (as 
>> documented). Plus: the boiler plate to catch and log is more complicated and 
>> convoluted than the boiler plate for the null check.
>> 
>> Regards
>> Felix
>> 
>> 
>>> As Felix Meschberger already pointed out, neither the SlingAdaptable nor 
>>> the AdapterManager currently catch any exceptions so that would work 
>>> already with existing code and Sling Models could start right away throwing 
>>> RuntimeExceptions for validation purposes.
>>> 
 
 But not sure if that will work.
 
 Cheers,
 Alex
>>> 
>> 
> 

Re: adaptTo and results ....

[Konrad Windszus]

The AdapterFactory should clearly state, which RuntimeExceptions are thrown 
under which condition. You know in most of the cases, which AdapterFactory is 
responsible for your adaptTo-method (or you should be able to find out with the 
web console)
Handling in some cases is more than simple logging. The AEM6 
WCMDeveloperModeFilter is a good example for another error treatment (catching 
the error within a servlet filter and then exposing via the Web UI).

On 03 Jul 2014, at 12:19, Felix Meschberger  wrote:

> Hi
> 
> Am 03.07.2014 um 11:10 schrieb Konrad Windszus :
> 
>> 
>> On 03 Jul 2014, at 10:50, Alexander Klimetschek  wrote:
>> 
>>> 
>>> I guess it would make sense to have adapterfactories et. al. to work like 
>>> this:
>>> a) if it is not of the desired type, i.e. cannot semantically be adapted, 
>>> return null
> 
> example: resource.adaptTo(Node.class) for a resource not backed by a JCR Node 
> instance.
> 
>>> b) if it fails due to some actual exception, throw a runtimexception
> 
> example: resource.adaptTo(Comment.class) when the required data to setup the 
> Comment instance cannot be read from persistence or the data is inconsistent 
> and thus a consistent Comment instance cannot be provided.
> 
>> 
>> I would be fine with that approach. So the only change is a clarification in 
>> the Javadocs that adaptTo in fact may throw a RuntimeException (if the 
>> AdapterFactory has thrown an exception) and also that AdapterFactory may 
>> throw a RuntimeException.
> 
> The question always remains: Do you expect the caller to handle this 
> exception in some way or another ? Also, what exception can be expected by 
> the client (you don't want to catch RuntimeException, do you ?) ? and what 
> does it mean ?
> 
> If handling just is catching and logging, there is no use in throwing in the 
> first place — better immediately log and return some decent value that client 
> can cope with, which in the case of adaptTo is just null (as documented). 
> Plus: the boiler plate to catch and log is more complicated and convoluted 
> than the boiler plate for the null check.
> 
> Regards
> Felix
> 
> 
>> As Felix Meschberger already pointed out, neither the SlingAdaptable nor the 
>> AdapterManager currently catch any exceptions so that would work already 
>> with existing code and Sling Models could start right away throwing 
>> RuntimeExceptions for validation purposes.
>> 
>>> 
>>> But not sure if that will work.
>>> 
>>> Cheers,
>>> Alex
>> 
> 

Build failed in Jenkins: sling-trunk-1.6 #2251

[Apache Jenkins Server]

See 

Changes:

[stefanegli] SLING-3690 : moved 'New Node...' action under 'New' menu to be 
consistent

[cziegeler] [maven-release-plugin] prepare for next development iteration

[cziegeler] [maven-release-plugin] prepare release 
org.apache.sling.scripting.java-2.0.10

[cziegeler] Use latest scripting.jsp snapshot

[cziegeler] [maven-release-plugin] prepare for next development iteration

[cziegeler] [maven-release-plugin] prepare release 
org.apache.sling.scripting.jsp-2.1.4

[cziegeler] SLING-3724 : Provide option to always use current vm version for 
source and target

[cziegeler] SLING-3724 : Provide option to always use current vm version for 
source and target

--
[...truncated 40034 lines...]
[INFO] Sling Launchpad Standalone Archetype .. SUCCESS [27.278s]
[INFO] Sling Launchpad Webapp Archetype .. SUCCESS [17.518s]
[INFO] Sling Initial Content Archetype ... SUCCESS [12.278s]
[INFO] Sling Servlet Archetype ... SUCCESS [12.049s]
[INFO] Sling Bundle Archetype  SUCCESS [9.472s]
[INFO] Sling JCRInstall Bundle Archetype . SUCCESS [11.614s]
[INFO] Sling Taglib Archetype  SUCCESS [6.223s]
[INFO] Apache Sling API .. SUCCESS [23.888s]
[INFO] Apache Sling Resource Resolver  SUCCESS [21.273s]
[INFO] Apache Sling System Bundle Extension: Java Transaction API  SUCCESS 
[8.689s]
[INFO] Apache Sling System Bundle Extension: XML APIs  SUCCESS [6.562s]
[INFO] Apache Sling System Bundle Extension: Activation API  SUCCESS [6.233s]
[INFO] Apache Sling System Bundle Extension: WS APIs . SUCCESS [6.246s]
[INFO] Apache Sling Dynamic Class Loader Support . SUCCESS [23.372s]
[INFO] Apache Sling Commons Java Compiler  SUCCESS [11.291s]
[INFO] Apache Sling JSON Library . SUCCESS [12.038s]
[INFO] Apache Sling SLF4J Implementation (Logback) ... SUCCESS [50.688s]
[INFO] Apache Sling OSGi LogService Implementation ... SUCCESS [9.066s]
[INFO] Apache Sling MIME type mapping support  SUCCESS [8.998s]
[INFO] Apache Sling Commons OSGi support . SUCCESS [9.365s]
[INFO] Apache Sling Scheduler Support  SUCCESS [8.592s]
[INFO] Apache Sling Testing Utilities  SUCCESS [50.194s]
[INFO] Apache Sling Thread Dumper  SUCCESS [8.287s]
[INFO] Apache Sling Thread Support ... SUCCESS [9.186s]
[INFO] Apache Sling Authentication Service ... SUCCESS [14.061s]
[INFO] Apache Sling OpenID Authentication  SUCCESS [15.146s]
[INFO] Apache Sling Form Based Authentication Handler  SUCCESS [17.756s]
[INFO] Apache Sling Authentication Selector .. SUCCESS [8.954s]
[INFO] Apache Sling Engine Implementation  SUCCESS [33.362s]
[INFO] Apache Sling Repository API Bundle  SUCCESS [8.903s]
[INFO] Apache Sling JCR Base Bundle .. SUCCESS [9.457s]
[INFO] Apache Sling JCR ClassLoader .. SUCCESS [9.216s]
[INFO] Apache Sling Initial Content Loader ... SUCCESS [14.116s]
[INFO] Apache Sling Jackrabbit Embedded Repository ... SUCCESS [14.698s]
[INFO] Apache Sling Jackrabbit UserManager Support ... SUCCESS [8.515s]
[INFO] Apache Sling Jackrabbit JSR-283 Access Control Manager Support  SUCCESS 
[8.510s]
[INFO] Apache Sling Wrapper Bundle for the JCR API ... SUCCESS [6.103s]
[INFO] Apache Sling Object Content Mapping ... SUCCESS [12.754s]
[INFO] Apache Sling JCR Resource Resolver  SUCCESS [2:23.121s]
[INFO] Apache Sling JCR Repository Registration .. SUCCESS [8.797s]
[INFO] Apache Sling Simple WebDAV Access to repositories . SUCCESS [9.035s]
[INFO] Apache Sling DavEx Access to repositories . SUCCESS [8.939s]
[INFO] Apache Sling JCR WebConsole Bundle  SUCCESS [8.410s]
[INFO] Apache Sling Oak Repository Server  SUCCESS [9.286s]
[INFO] Apache Sling SlingRepository Integration Tests  SUCCESS [1:02.844s]
[INFO] Apache Sling Servlet Resolver . SUCCESS [12.179s]
[INFO] Apache Sling Default GET Servlets . SUCCESS [14.777s]
[INFO] Apache Sling Default POST Servlets  SUCCESS [18.082s]
[INFO] Apache Sling Compat Servlets .. SUCCESS [8.589s]
[INFO] Apache Sling Scripting Implementation API . SUCCESS [8.925s]
[INFO] Apache Sling Scripting Core implementation  SUCCESS [20.170s]
[INFO] Apache Sling Scripting JavaScript Support . SUCCESS [33.051s]
[INFO] Apache Sling Scripting JSP Support  SUCCESS [15.210s]
[INFO] Apache Sling JSP Tag Library .. SUCCESS [11.543s]
[INFO] Apache Sling JSP Stan

Re: adaptTo and results ....

[Felix Meschberger]

Hi

Am 03.07.2014 um 11:10 schrieb Konrad Windszus :

> 
> On 03 Jul 2014, at 10:50, Alexander Klimetschek  wrote:
> 
>> 
>> I guess it would make sense to have adapterfactories et. al. to work like 
>> this:
>> a) if it is not of the desired type, i.e. cannot semantically be adapted, 
>> return null

example: resource.adaptTo(Node.class) for a resource not backed by a JCR Node 
instance.

>> b) if it fails due to some actual exception, throw a runtimexception

example: resource.adaptTo(Comment.class) when the required data to setup the 
Comment instance cannot be read from persistence or the data is inconsistent 
and thus a consistent Comment instance cannot be provided.

> 
> I would be fine with that approach. So the only change is a clarification in 
> the Javadocs that adaptTo in fact may throw a RuntimeException (if the 
> AdapterFactory has thrown an exception) and also that AdapterFactory may 
> throw a RuntimeException.

The question always remains: Do you expect the caller to handle this exception 
in some way or another ? Also, what exception can be expected by the client 
(you don't want to catch RuntimeException, do you ?) ? and what does it mean ?

If handling just is catching and logging, there is no use in throwing in the 
first place — better immediately log and return some decent value that client 
can cope with, which in the case of adaptTo is just null (as documented). Plus: 
the boiler plate to catch and log is more complicated and convoluted than the 
boiler plate for the null check.

Regards
Felix


> As Felix Meschberger already pointed out, neither the SlingAdaptable nor the 
> AdapterManager currently catch any exceptions so that would work already with 
> existing code and Sling Models could start right away throwing 
> RuntimeExceptions for validation purposes.
> 
>> 
>> But not sure if that will work.
>> 
>> Cheers,
>> Alex
> 

Build failed in Jenkins: sling-trunk-1.6 » Apache Sling Launchpad Application Builder #2251

[Apache Jenkins Server]

See 


Changes:

[cziegeler] Use latest scripting.jsp snapshot

--
[INFO] 
[INFO] 
[INFO] Building Apache Sling Launchpad Application Builder 7-SNAPSHOT
[INFO] 
Downloading: 
http://repository.ops4j.org/maven2/org/apache/sling/org.apache.sling.installer.core/3.5.2/org.apache.sling.installer.core-3.5.2.pom
Downloading: 
http://repo.maven.apache.org/maven2/org/apache/sling/org.apache.sling.installer.core/3.5.2/org.apache.sling.installer.core-3.5.2.pom
Downloaded: 
http://repo.maven.apache.org/maven2/org/apache/sling/org.apache.sling.installer.core/3.5.2/org.apache.sling.installer.core-3.5.2.pom
 (8 KB at 23.9 KB/sec)
Downloading: 
http://repository.apache.org/snapshots/org/apache/sling/org.apache.sling.scripting.jsp/2.1.3-SNAPSHOT/maven-metadata.xml
Downloading: 
http://repository.apache.org/snapshots/org/apache/sling/org.apache.sling.scripting.jsp/2.1.3-SNAPSHOT/org.apache.sling.scripting.jsp-2.1.3-SNAPSHOT.pom
[WARNING] The POM for 
org.apache.sling:org.apache.sling.scripting.jsp:jar:2.1.3-SNAPSHOT is missing, 
no dependency information available
Downloading: 
http://repository.ops4j.org/maven2/org/apache/sling/org.apache.sling.installer.factory.configuration/1.0.14/org.apache.sling.installer.factory.configuration-1.0.14.pom
Downloading: 
http://repo.maven.apache.org/maven2/org/apache/sling/org.apache.sling.installer.factory.configuration/1.0.14/org.apache.sling.installer.factory.configuration-1.0.14.pom
Downloaded: 
http://repo.maven.apache.org/maven2/org/apache/sling/org.apache.sling.installer.factory.configuration/1.0.14/org.apache.sling.installer.factory.configuration-1.0.14.pom
 (4 KB at 21.6 KB/sec)
Downloading: 
http://repository.ops4j.org/maven2/org/apache/sling/org.apache.sling.installer.core/3.5.2/org.apache.sling.installer.core-3.5.2.jar
Downloading: 
http://repository.ops4j.org/maven2/org/apache/sling/org.apache.sling.installer.factory.configuration/1.0.14/org.apache.sling.installer.factory.configuration-1.0.14.jar
Downloading: 
http://repo.maven.apache.org/maven2/org/apache/sling/org.apache.sling.installer.core/3.5.2/org.apache.sling.installer.core-3.5.2.jar
Downloading: 
http://repo.maven.apache.org/maven2/org/apache/sling/org.apache.sling.installer.factory.configuration/1.0.14/org.apache.sling.installer.factory.configuration-1.0.14.jar
Downloaded: 
http://repo.maven.apache.org/maven2/org/apache/sling/org.apache.sling.installer.factory.configuration/1.0.14/org.apache.sling.installer.factory.configuration-1.0.14.jar
 (25 KB at 87.7 KB/sec)
Downloaded: 
http://repo.maven.apache.org/maven2/org/apache/sling/org.apache.sling.installer.core/3.5.2/org.apache.sling.installer.core-3.5.2.jar
 (144 KB at 414.2 KB/sec)
Downloading: 
http://repository.apache.org/snapshots/org/apache/sling/org.apache.sling.scripting.jsp/2.1.3-SNAPSHOT/org.apache.sling.scripting.jsp-2.1.3-SNAPSHOT.jar
[JENKINS] Archiving disabled

[jira] [Commented] (SLING-3681) Enable the maven-launchpad-plugin to generate the XSD for bundles list XML document

[Simone Tripodi (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-3681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14051283#comment-14051283
 ] 

Simone Tripodi commented on SLING-3681:
---

AMAZING thanks Robert for your support! :)

> Enable the maven-launchpad-plugin to generate the XSD for bundles list XML 
> document
> ---
>
> Key: SLING-3681
> URL: https://issues.apache.org/jira/browse/SLING-3681
> Project: Sling
>  Issue Type: Improvement
>  Components: Maven Plugins and Archetypes
>Affects Versions: Maven Launchpad Plugin 2.3.2
>Reporter: Simone Tripodi
>Assignee: Robert Munteanu
> Fix For: Maven Launchpad Plugin 2.3.2
>
> Attachments: SLING-3681.patch, Screen Shot 2014-06-19 at 11.05.11.pdf
>
>
> More recent versions of the Modello plugin for Maven is able to generate the 
> model's XSchema that, once published on Sling's public site and declared in 
> {{list.xml}} documents, would be really useful in "intelligent" IDEs able to 
> read the schema, understand the structure and assist users for content 
> creation, otherwise it is not clear at all which elements are allowed and 
> which not.
> Patch going to be submitted!



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (SLING-3729) Register XML catalog contribtion for bundle list schema

[Robert Munteanu (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-3729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Munteanu updated SLING-3729:
---

Description: 
With SLING-3681, we now have an XML schema file which can be used to validate 
the correctness of the bundle list xml file.

It would be nice to contribute this to the XML catalog from Eclipse, so that 
it's usable even without a network connection.

The relevant extension point is 
{{org.eclipse.wst.xml.core.catalogContributions}} .

  was:
With SLING-3681, we now have an XML schema file which can be used to validate 
the correctness of the bundle list xml file.

It would be nice to contribute this to the XML catalog from Eclipse, so that 
it's usable even without a network connection.


> Register XML catalog contribtion for bundle list schema
> ---
>
> Key: SLING-3729
> URL: https://issues.apache.org/jira/browse/SLING-3729
> Project: Sling
>  Issue Type: Improvement
>  Components: IDE
>Reporter: Robert Munteanu
>Priority: Minor
> Fix For: Sling Eclipse IDE 1.1.0
>
>
> With SLING-3681, we now have an XML schema file which can be used to validate 
> the correctness of the bundle list xml file.
> It would be nice to contribute this to the XML catalog from Eclipse, so that 
> it's usable even without a network connection.
> The relevant extension point is 
> {{org.eclipse.wst.xml.core.catalogContributions}} .



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Comment Edited] (SLING-3681) Enable the maven-launchpad-plugin to generate the XSD for bundles list XML document

[Robert Munteanu (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-3681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14051225#comment-14051225
 ] 

Robert Munteanu edited comment on SLING-3681 at 7/3/14 10:01 AM:
-

(Sorry, this dropped off my radar). I looked at what the Jackrabbit project 
does, and they have a top-level /dtd/ directory - 
https://jackrabbit.apache.org/dtd/  . I would incline to follow the same route 
and use https://sling.apache.org/xsd/bundle-list-1.0.0.xsd . The reasons would 
be

* it's not really a Maven artifact, but an xsd file, so maven -> xsd
* prefixing it with the version does not add much, and for instance 
bundle-list-1.0.0.xsd with some-other-file-1.0.0.xsd have no relation but the 
version.

WDYT?


was (Author: rombert):
(Sorry, this dropped on my radar). I looked at what the Jackrabbit project 
does, and they have a top-level /dtd/ directory - 
https://jackrabbit.apache.org/dtd/  . I would incline to follow the same route 
and use https://sling.apache.org/xsd/bundle-list-1.0.0.xsd . The reasons would 
be

* it's not really a Maven artifact, but an xsd file, so maven -> xsd
* prefixing it with the version does not add much, and for instance 
bundle-list-1.0.0.xsd with some-other-file-1.0.0.xsd have no relation but the 
version.

WDYT?

> Enable the maven-launchpad-plugin to generate the XSD for bundles list XML 
> document
> ---
>
> Key: SLING-3681
> URL: https://issues.apache.org/jira/browse/SLING-3681
> Project: Sling
>  Issue Type: Improvement
>  Components: Maven Plugins and Archetypes
>Affects Versions: Maven Launchpad Plugin 2.3.2
>Reporter: Simone Tripodi
>Assignee: Robert Munteanu
> Fix For: Maven Launchpad Plugin 2.3.2
>
> Attachments: SLING-3681.patch, Screen Shot 2014-06-19 at 11.05.11.pdf
>
>
> More recent versions of the Modello plugin for Maven is able to generate the 
> model's XSchema that, once published on Sling's public site and declared in 
> {{list.xml}} documents, would be really useful in "intelligent" IDEs able to 
> read the schema, understand the structure and assist users for content 
> creation, otherwise it is not clear at all which elements are allowed and 
> which not.
> Patch going to be submitted!



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (SLING-3729) Register XML catalog contribtion for bundle list schema

[Robert Munteanu (JIRA)]

Robert Munteanu created SLING-3729:
--

 Summary: Register XML catalog contribtion for bundle list schema
 Key: SLING-3729
 URL: https://issues.apache.org/jira/browse/SLING-3729
 Project: Sling
  Issue Type: Improvement
  Components: IDE
Reporter: Robert Munteanu
Priority: Minor
 Fix For: Sling Eclipse IDE 1.1.0


With SLING-3681, we now have an XML schema file which can be used to validate 
the correctness of the bundle list xml file.

It would be nice to contribute this to the XML catalog from Eclipse, so that 
it's usable even without a network connection.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Jenkins build is still unstable: sling-trunk-1.7 #624

[Apache Jenkins Server]

See 

[jira] [Commented] (SLING-3681) Enable the maven-launchpad-plugin to generate the XSD for bundles list XML document

[Robert Munteanu (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-3681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14051277#comment-14051277
 ] 

Robert Munteanu commented on SLING-3681:


https://sling.apache.org/xsd/bundle-list-1.0.0.xsd is now live . 

> Enable the maven-launchpad-plugin to generate the XSD for bundles list XML 
> document
> ---
>
> Key: SLING-3681
> URL: https://issues.apache.org/jira/browse/SLING-3681
> Project: Sling
>  Issue Type: Improvement
>  Components: Maven Plugins and Archetypes
>Affects Versions: Maven Launchpad Plugin 2.3.2
>Reporter: Simone Tripodi
>Assignee: Robert Munteanu
> Fix For: Maven Launchpad Plugin 2.3.2
>
> Attachments: SLING-3681.patch, Screen Shot 2014-06-19 at 11.05.11.pdf
>
>
> More recent versions of the Modello plugin for Maven is able to generate the 
> model's XSchema that, once published on Sling's public site and declared in 
> {{list.xml}} documents, would be really useful in "intelligent" IDEs able to 
> read the schema, understand the structure and assist users for content 
> creation, otherwise it is not clear at all which elements are allowed and 
> which not.
> Patch going to be submitted!



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (SLING-915) [Rhino] Implement Compilable

[Felix Meschberger (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Felix Meschberger updated SLING-915:


Summary: [Rhino] Implement Compilable  (was: Implement Compilable)

> [Rhino] Implement Compilable
> 
>
> Key: SLING-915
> URL: https://issues.apache.org/jira/browse/SLING-915
> Project: Sling
>  Issue Type: Sub-task
>  Components: Scripting
>Affects Versions: Scripting JavaScript 2.0.2
>Reporter: Felix Meschberger
> Attachments: SLING-915.patch
>
>
> Add support for the Compilable and CompiledScript interfaces to the Rhino 
> ECMAScript ScriptEngine



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (SLING-914) [JSP] Implement Compilable

[Felix Meschberger (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Felix Meschberger updated SLING-914:


Summary: [JSP] Implement Compilable  (was: Implement Compilable)

> [JSP] Implement Compilable
> --
>
> Key: SLING-914
> URL: https://issues.apache.org/jira/browse/SLING-914
> Project: Sling
>  Issue Type: Sub-task
>  Components: Scripting
>Affects Versions: Scripting JSP 2.0.2
>Reporter: Felix Meschberger
>
> Add support for the Compilable and CompiledScript interfaces to the JSP 
> ScriptEngine implementation



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (SLING-3709) Sling Models: Allow caller to deal with exceptions

[Konrad Windszus (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-3709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14051269#comment-14051269
 ] 

Konrad Windszus commented on SLING-3709:


It seems that throwing a RuntimeException from an AdapterFactory should be fine 
(http://www.mail-archive.com/dev@sling.apache.org/msg31420.html).
[~justinedelson] Would you accept a patch which lets the ModelAdapterFactory 
throw RuntimeExceptions if
# Required methods/fields could not be injected (for whatever reason)
# Model class does not have a usable constructor
# Invoking PostConstruct does fail for whatever reason

Do you think we would need a switch for that behaviour (as configurable OSGi 
property) or we can just change to throwing RuntimeException instead of 
returning null in that case?

> Sling Models: Allow caller to deal with exceptions
> --
>
> Key: SLING-3709
> URL: https://issues.apache.org/jira/browse/SLING-3709
> Project: Sling
>  Issue Type: Improvement
>Affects Versions: Sling Models Implementation 1.0.4, Sling Models 
> Implementation 1.0.6
>Reporter: Konrad Windszus
>
> Currently due to the specification of the adaptTo-method to return null if 
> adaptation is not possible, the caller is not notified about any exceptions 
> (because they are caught within the ModelAdapterFactory).
> This is e.g. necessary to deal with validation exceptions properly (i.e. 
> required field injection not possible).  The problem was also discussed 
> briefly in 
> http://apache-sling.73963.n3.nabble.com/Silng-Models-Validation-Framework-td4033411.html.
> All exceptions either being thrown by the 
> @PostConstruct method or caused by the field/method injection are not 
> propagated but basically swallowed by Sling Models.
> It would be great to be able to catch those exceptions either in the view or 
> in a servlet filter. I think it should be possible to throw unchecked 
> exceptions in the ModelAdapterFactory.getFactory() method if it is requested 
> (i.e. through a global OSGi configuration flag for Sling Models).
> WDYT?
> Would you accept such a patch or do you think this breaks the API (also 
> compare with 
> https://issues.apache.org/jira/browse/SLING-2712?focusedCommentId=13561516&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13561516).
> If it does not work through the adaptTo, SlingModels should provide an 
> alternative way of instanciating models (and propagating exceptions), 
> although this is kind of tricky, because it internally relies on adaptTo as 
> well (e.g. in 
> https://github.com/apache/sling/blob/trunk/bundles/extensions/models/impl/src/main/java/org/apache/sling/models/impl/ModelAdapterFactory.java#L647)



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Jenkins build became unstable: sling-contrib-1.6 » Apache Sling Replication Integration Tests #1167

[Apache Jenkins Server]

See 

Jenkins build is still unstable: sling-trunk-1.7 » Apache Sling Launchpad Testing #624

[Apache Jenkins Server]

See 

[jira] [Commented] (SLING-3681) Enable the maven-launchpad-plugin to generate the XSD for bundles list XML document

[Carsten Ziegeler (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-3681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14051237#comment-14051237
 ] 

Carsten Ziegeler commented on SLING-3681:
-

+1 for https://sling.apache.org/xsd/bundle-list-1.0.0.xsd 

> Enable the maven-launchpad-plugin to generate the XSD for bundles list XML 
> document
> ---
>
> Key: SLING-3681
> URL: https://issues.apache.org/jira/browse/SLING-3681
> Project: Sling
>  Issue Type: Improvement
>  Components: Maven Plugins and Archetypes
>Affects Versions: Maven Launchpad Plugin 2.3.2
>Reporter: Simone Tripodi
>Assignee: Robert Munteanu
> Fix For: Maven Launchpad Plugin 2.3.2
>
> Attachments: SLING-3681.patch, Screen Shot 2014-06-19 at 11.05.11.pdf
>
>
> More recent versions of the Modello plugin for Maven is able to generate the 
> model's XSchema that, once published on Sling's public site and declared in 
> {{list.xml}} documents, would be really useful in "intelligent" IDEs able to 
> read the schema, understand the structure and assist users for content 
> creation, otherwise it is not clear at all which elements are allowed and 
> which not.
> Patch going to be submitted!



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (SLING-3681) Enable the maven-launchpad-plugin to generate the XSD for bundles list XML document

[Simone Tripodi (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-3681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14051231#comment-14051231
 ] 

Simone Tripodi commented on SLING-3681:
---

it works for me, thanks for following-up! :)

> Enable the maven-launchpad-plugin to generate the XSD for bundles list XML 
> document
> ---
>
> Key: SLING-3681
> URL: https://issues.apache.org/jira/browse/SLING-3681
> Project: Sling
>  Issue Type: Improvement
>  Components: Maven Plugins and Archetypes
>Affects Versions: Maven Launchpad Plugin 2.3.2
>Reporter: Simone Tripodi
>Assignee: Robert Munteanu
> Fix For: Maven Launchpad Plugin 2.3.2
>
> Attachments: SLING-3681.patch, Screen Shot 2014-06-19 at 11.05.11.pdf
>
>
> More recent versions of the Modello plugin for Maven is able to generate the 
> model's XSchema that, once published on Sling's public site and declared in 
> {{list.xml}} documents, would be really useful in "intelligent" IDEs able to 
> read the schema, understand the structure and assist users for content 
> creation, otherwise it is not clear at all which elements are allowed and 
> which not.
> Patch going to be submitted!



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Re: adaptTo and results ....

[Konrad Windszus]

On 03 Jul 2014, at 10:50, Alexander Klimetschek  wrote:

> 
> I guess it would make sense to have adapterfactories et. al. to work like 
> this:
> a) if it is not of the desired type, i.e. cannot semantically be adapted, 
> return null
> b) if it fails due to some actual exception, throw a runtimexception

I would be fine with that approach. So the only change is a clarification in 
the Javadocs that adaptTo in fact may throw a RuntimeException (if the 
AdapterFactory has thrown an exception) and also that AdapterFactory may throw 
a RuntimeException.
As Felix Meschberger already pointed out, neither the SlingAdaptable nor the 
AdapterManager currently catch any exceptions so that would work already with 
existing code and Sling Models could start right away throwing 
RuntimeExceptions for validation purposes.

> 
> But not sure if that will work.
> 
> Cheers,
> Alex

[jira] [Commented] (SLING-3681) Enable the maven-launchpad-plugin to generate the XSD for bundles list XML document

[Robert Munteanu (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-3681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14051225#comment-14051225
 ] 

Robert Munteanu commented on SLING-3681:


(Sorry, this dropped on my radar). I looked at what the Jackrabbit project 
does, and they have a top-level /dtd/ directory - 
https://jackrabbit.apache.org/dtd/  . I would incline to follow the same route 
and use https://sling.apache.org/xsd/bundle-list-1.0.0.xsd . The reasons would 
be

* it's not really a Maven artifact, but an xsd file, so maven -> xsd
* prefixing it with the version does not add much, and for instance 
bundle-list-1.0.0.xsd with some-other-file-1.0.0.xsd have no relation but the 
version.

WDYT?

> Enable the maven-launchpad-plugin to generate the XSD for bundles list XML 
> document
> ---
>
> Key: SLING-3681
> URL: https://issues.apache.org/jira/browse/SLING-3681
> Project: Sling
>  Issue Type: Improvement
>  Components: Maven Plugins and Archetypes
>Affects Versions: Maven Launchpad Plugin 2.3.2
>Reporter: Simone Tripodi
>Assignee: Robert Munteanu
> Fix For: Maven Launchpad Plugin 2.3.2
>
> Attachments: SLING-3681.patch, Screen Shot 2014-06-19 at 11.05.11.pdf
>
>
> More recent versions of the Modello plugin for Maven is able to generate the 
> model's XSchema that, once published on Sling's public site and declared in 
> {{list.xml}} documents, would be really useful in "intelligent" IDEs able to 
> read the schema, understand the structure and assist users for content 
> creation, otherwise it is not clear at all which elements are allowed and 
> which not.
> Patch going to be submitted!



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Re: adaptTo and results ....

[Bertrand Delacretaz]

Hi,

On Tue, Jul 1, 2014 at 5:16 PM, Felix Meschberger  wrote:
> Am 01.07.2014 um 09:44 schrieb Bertrand Delacretaz :
> ...Unfortunately, I don't think this works, because the adaptTo signature is:
>
>   public  AdapterType adaptTo(Class type);
>
> Hence the return type is the same as provided as the argument, that is if you 
> pass
> RequireAdapter, you get a RequireAdapter object and not a Foo 
> object...

You're right, I overlooked that.

The someObject.adaptTo(RequireAdapter.for(Foo.class)) variant should
work if for(...) returns Foo.class but uses a ThreadLocal to tell the
AdapterManagerImpl about the options. Not sure if it's worth the
effort or if a new API is better, we could implement a bridge between
the new and old API to avoid having to change all existing adapters.

I see that the use case is under discussion anyway, so let's see what
comes out of that...

-Bertrand

Re: adaptTo and results ....

[Alexander Klimetschek]

On 03.07.2014, at 09:12, Konrad Windszus  wrote:

> - The client can decide how to expose that error (whether just logging is 
> fine or something more obvious). This cannot be achieved by just setting up a 
> utility method, because that one does only see the null return value and not 
> the original reason for that.

Yes, but my question is whether there is any need to pass through the exception 
at all.

> - Tracing problems during development is much easier (instead of looking at 
> the log I can see the full exception)

You can debug exceptions inside the adapterfactories as well (after seeing them 
in the log).

> - It allows to use it for something like validation in Sling Models

How would that work? (I saw the reference earlier in the thread, but I don't 
know how you'd use adaptTo for validation and can't really imagine it's a good 
fit)

> - It is less error-prone to the developers (you can easily forget to either 
> use the utility method or check for null)

The null-returning method is out there, it cannot be changed to throw a checked 
exception (which is the only way to force handling for devs)

> - In my regard in most of the cases if adaptation fails, there is something 
> wrong with the deployment (required bundles are not installed, components are 
> not running, ….) and I cannot reasonably work around that issue in the code 
> -> that calls for an exception

It's not only exception, it's also a way to check if something is of a certain 
type (say adapting a resource to a resourcecollection). In this case an 
exception is not the right thing.

I guess it would make sense to have adapterfactories et. al. to work like this:
a) if it is not of the desired type, i.e. cannot semantically be adapted, 
return null
b) if it fails due to some actual exception, throw a runtimexception

But not sure if that will work.

Cheers,
Alex

[jira] [Closed] (SLING-3632) Configuration installer should ignore location events

[Carsten Ziegeler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-3632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Carsten Ziegeler closed SLING-3632.
---


> Configuration installer should ignore location events
> -
>
> Key: SLING-3632
> URL: https://issues.apache.org/jira/browse/SLING-3632
> Project: Sling
>  Issue Type: Bug
>  Components: Installer
>Affects Versions: Installer Configuration Factory 1.0.12
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: Installer Configuration Factory 1.0.14
>
>
> The configuration listener assumes that only deleted and updated events can 
> occur, however with OSGi R5 a location changed event has been added which is 
> now treated as an update event



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Re: [VOTE] Release Apache Sling Scripting JSP 2.1.4 and Apache Sling Scripting Java 2.0.10

[Carsten Ziegeler]

+1


2014-07-03 10:04 GMT+02:00 Robert Munteanu :

> +1
>
> Robert
>
> On Thu, Jul 3, 2014 at 10:39 AM, Carsten Ziegeler 
> wrote:
> > Hi,
> >
> > We solved two issues for each scripting bundle, especially with
> SLING-3724
> > these bundles now provide a better experience with Java 8 as they run
> > without configuration changes on Java 8 as well as previous versions.
> >
> > Scripting JSP
> > https://issues.apache.org/jira/browse/SLING/fixforversion/12326855
> > Scripting Java
> > https://issues.apache.org/jira/browse/SLING/fixforversion/12321863
> >
> > Staging repository:
> > https://repository.apache.org/content/repositories/orgapachesling-1074
> >
> > 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 1074 /tmp/sling-staging
> >
> > Please vote to approve this release:
> >
> >   [ ] +1 Approve the release
> >   [ ]  0 Don't care
> >   [ ] -1 Don't release, because ...
> >
> > This majority vote is open for at least 72 hours.
> >
> > Regards
> >
> > --
> > Carsten Ziegeler
> > Adobe Research Switzerland
> > cziege...@apache.org
>



-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

Re: [VOTE] Release Apache Sling Scripting JSP 2.1.4 and Apache Sling Scripting Java 2.0.10

[Robert Munteanu]

+1

Robert

On Thu, Jul 3, 2014 at 10:39 AM, Carsten Ziegeler  wrote:
> Hi,
>
> We solved two issues for each scripting bundle, especially with SLING-3724
> these bundles now provide a better experience with Java 8 as they run
> without configuration changes on Java 8 as well as previous versions.
>
> Scripting JSP
> https://issues.apache.org/jira/browse/SLING/fixforversion/12326855
> Scripting Java
> https://issues.apache.org/jira/browse/SLING/fixforversion/12321863
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-1074
>
> 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 1074 /tmp/sling-staging
>
> Please vote to approve this release:
>
>   [ ] +1 Approve the release
>   [ ]  0 Don't care
>   [ ] -1 Don't release, because ...
>
> This majority vote is open for at least 72 hours.
>
> Regards
>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org

[jira] [Resolved] (SLING-3690) Cannot create JCR Nodes under a sling:Folder

[Stefan Egli (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-3690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Egli resolved SLING-3690.


Resolution: Fixed

fixed:
moved 'New Node...' action under 'New' menu to be consistent

> Cannot create JCR Nodes under a sling:Folder
> 
>
> Key: SLING-3690
> URL: https://issues.apache.org/jira/browse/SLING-3690
> Project: Sling
>  Issue Type: Bug
>  Components: IDE
>Affects Versions: Sling Eclipse IDE 1.0.0
>Reporter: Catalin Buzoiu
>Assignee: Stefan Egli
> Fix For: Sling Eclipse IDE 1.0.2
>
>
> The {{New > Node...}} option is not shown when right-clicking on 
> {{sling:Folder}} nodes, although JCR Nodes should be allowed there.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[VOTE] Release Apache Sling Scripting JSP 2.1.4 and Apache Sling Scripting Java 2.0.10

[Carsten Ziegeler]

Hi,

We solved two issues for each scripting bundle, especially with SLING-3724
these bundles now provide a better experience with Java 8 as they run
without configuration changes on Java 8 as well as previous versions.

Scripting JSP
https://issues.apache.org/jira/browse/SLING/fixforversion/12326855
Scripting Java
https://issues.apache.org/jira/browse/SLING/fixforversion/12321863

Staging repository:
https://repository.apache.org/content/repositories/orgapachesling-1074

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 1074 /tmp/sling-staging

Please vote to approve this release:

  [ ] +1 Approve the release
  [ ]  0 Don't care
  [ ] -1 Don't release, because ...

This majority vote is open for at least 72 hours.

Regards

-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

[jira] [Created] (SLING-3728) MapEntries->aliasMap ds incorrect information in case of alias path removal

[Antonio Sanso (JIRA)]

Antonio Sanso created SLING-3728:


 Summary: MapEntries->aliasMap ds incorrect information in case of 
alias path removal
 Key: SLING-3728
 URL: https://issues.apache.org/jira/browse/SLING-3728
 Project: Sling
  Issue Type: Bug
  Components: ResourceResolver
Reporter: Antonio Sanso
Assignee: Antonio Sanso


MapEntries->aliasMap ds incorrect information in case of alias path removal 
(specifically when the node is jcr:content)

I will also add a test case that shows the issue



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Re: adaptTo and results ....

[Konrad Windszus]

Passing through exceptions has the following advantages IMHO:

- The client can decide how to expose that error (whether just logging is fine 
or something more obvious). This cannot be achieved by just setting up a 
utility method, because that one does only see the null return value and not 
the original reason for that.
- Tracing problems during development is much easier (instead of looking at the 
log I can see the full exception)
- It allows to use it for something like validation in Sling Models
- It is less error-prone to the developers (you can easily forget to either use 
the utility method or check for null)
- In my regard in most of the cases if adaptation fails, there is something 
wrong with the deployment (required bundles are not installed, components are 
not running, ….) and I cannot reasonably work around that issue in the code -> 
that calls for an exception

Regards,
Konrad

On 02 Jul 2014, at 12:33, Alexander Klimetschek  wrote:

> Just reading up on this and have the basic question: what is the motivation 
> for passing through the exceptions?
> 
> From what I can see it is simply that the exceptions become visible to the 
> developer, which can be done by properly logging them (in the 
> adapterfactories etc.). It was mentioned that this decision (whether to log 
> or not) depends on the application = user of the adaptTo call. But I haven't 
> seen an example of that and are unsure that really is the case.
> 
> The example Stefan gave [1] is just about removing the boilerplate of the 
> null check + throwing a runtime exception, which could be handled using a 
> static utility method (adaptOrThrow, but outside the adaptable interface). 
> Also, this seems to be heavily depending on the style of the application 
> code, whether exceptions are used a lot or null handling (using optionals 
> etc.) is prefered and done consistently. Hence I am not sure if that requires 
> a major change in the adaptable interface contract.
> 
> [1] 
> https://issues.apache.org/jira/browse/SLING-3714?focusedCommentId=14048040&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14048040
> 
> Cheers,
> Alex

Re: [VOTE] Release Apache Sling Scripting JSP 2.1.2 and Apache Sling Scripting Java 2.0.8

[Carsten Ziegeler]

I have to cancel the vote as these artifacts do not run under 1.6
I accidentially check the wrong system property :(

I'll fix this, create new artifacts and start a new vote

Carsten


2014-07-03 7:35 GMT+02:00 Carsten Ziegeler :

> +1
>
>
> 2014-07-02 16:37 GMT+02:00 Justin Edelson :
>
> +1
>>
>> On Wed, Jul 2, 2014 at 9:28 AM, Robert Munteanu 
>> wrote:
>> > +1
>> >
>> > Robert
>> >
>> > On Wed, Jul 2, 2014 at 2:51 PM, Carsten Ziegeler 
>> > wrote:
>> >> Hi,
>> >>
>> >> We solved two issues for each scripting bundle, especially with
>> SLING-3724
>> >> these bundles now provide a better experience with Java 8 as they run
>> >> without configuration changes on Java 8 as well as previous versions.
>> >>
>> >> Scripting JSP
>> >> https://issues.apache.org/jira/browse/SLING/fixforversion/12326855
>> >> Scripting Java
>> >> https://issues.apache.org/jira/browse/SLING/fixforversion/12321863
>> >>
>> >> Staging repository:
>> >> https://repository.apache.org/content/repositories/orgapachesling-1073
>> >>
>> >> 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 1073 /tmp/sling-staging
>> >>
>> >> Please vote to approve this release:
>> >>
>> >> [ ] +1 Approve the release
>> >> [ ] 0 Don't care
>> >> [ ] -1 Don't release, because ...
>> >>
>> >> This majority vote is open for at least 72 hours.
>> >>
>> >> Regards
>> >>
>> >> --
>> >> Carsten Ziegeler
>> >> Adobe Research Switzerland
>> >> cziege...@apache.org
>>
>
>
>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org
>



-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org