Re: [VOTE] Deprecate ResourceDecorator.decorate(Resource, HttpServletRequest)

2012-02-13 Thread Felix Meschberger 

Am 13.02.2012 um 22:15 schrieb Bertrand Delacretaz:

> On Sat, Feb 11, 2012 at 2:19 AM, Justin Edelson  wrote:
>> ...Please vote..
> 
> +1 - deprecate ResourceDecorator.decorate(Resource, HttpServletRequest)
> 
> Just to be clear, as I don't think this was clearly mentioned in this
> thread, this means keeping the first method of this interface as is,
> and deprecating the second one:
> 
> interface ResourceDecorator {
>Resource decorate(Resource)
@Deprecated
>Resource decorate(Resource, HttpServletRequest)
> }
> 

Yes.

Regards
Felix


> Note that http://sling.apache.org/site/wrap-or-decorate-resources.html
> will have to be updated as well.
> 
> -Bertrand

Re: [VOTE] Deprecate ResourceDecorator.decorate(Resource, HttpServletRequest)

2012-02-13 Thread Bertrand Delacretaz 
On Sat, Feb 11, 2012 at 2:19 AM, Justin Edelson  wrote:
> ...Please vote..

+1 - deprecate ResourceDecorator.decorate(Resource, HttpServletRequest)

Just to be clear, as I don't think this was clearly mentioned in this
thread, this means keeping the first method of this interface as is,
and deprecating the second one:

interface ResourceDecorator {
Resource decorate(Resource)
Resource decorate(Resource, HttpServletRequest)
}

Note that http://sling.apache.org/site/wrap-or-decorate-resources.html
will have to be updated as well.

-Bertrand

Re: [VOTE] Deprecate ResourceDecorator.decorate(Resource, HttpServletRequest)

2012-02-13 Thread Alexander Klimetschek 
+1 (non binding)

Based on my experience, a ResourceDecorator almost never applies globally to 
all resources all the time, but is very often based on request-dependent 
information (such as parameters).

Cheers,
Alex

Am 13.02.2012 um 11:05 schrieb Felix Meschberger:

> 
> Hi
> 
> Am 11.02.2012 um 02:19 schrieb Justin Edelson:
> 
>> As described here: https://issues.apache.org/jira/browse/SLING-2411, we
>> do not currently have a way of enforcing that ResourceResolver clients invoke
>> resolve(HttpServletRequest, String) when they are doing a resolve
>> inside a request
>> context. The net effect of this is that implementors of ResourceDecorator 
>> have
>> inconsistent results.
>> 
>> I've uploaded a strawman patch to
>> https://issues.apache.org/jira/browse/SLING-2411 to
>> illustrate how this might be solved using a ThreadLocal. However, I
>> personally feel
>> like we should just go ahead and deprecate this method and I'd like to
>> call a vote for it.
>> 
>> Please vote:
>> [ ] +1 - deprecate ResourceDecorator.decorate(Resource, HttpServletRequest)
>> [ ] 0
>> [ ] -1 - don't deprecate
>> 
>> Note - if you vote -1, please provide an alternative. It could be the
>> strawman, it could be
>> something else, but I'd really like to see this fixed.
> 
> +1 to deprecate.
> 
> Regards
> Felix
> 
>> 
>> Thanks
>> Justin
> 

-- 
Alexander Klimetschek
Developer // Adobe (Day) // Berlin - Basel

[jira] [Commented] (SLING-2364) ResourceUtil should provide a method to get the parent on an arbitrary level

2012-02-13 Thread Alexander Klimetschek (Commented) (JIRA) 

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

Alexander Klimetschek commented on SLING-2364:
--

FWIW: The org.apache.jackrabbit.Text helper in jackrabbit-jcr-commons already 
provides getRelativeParent() (and one to ignore trailing slashes) and 
getAbsoluteParent().

http://jackrabbit.apache.org/api/2.2/org/apache/jackrabbit/util/Text.html



> ResourceUtil should provide a method to get the parent on an arbitrary level
> 
>
> Key: SLING-2364
> URL: https://issues.apache.org/jira/browse/SLING-2364
> Project: Sling
>  Issue Type: Improvement
>  Components: API
>Affects Versions: API 2.2.2
>Reporter: Konrad Windszus
> Attachments: getParent.patch
>
>
> Please provide the method "String getAbsoluteParent(String path, int level)" 
> to return the parent path on the given level.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

Build failed in Jenkins: sling-trunk-1.5 #1594

2012-02-13 Thread Apache Jenkins Server 
See 

Changes:

[fmeschbe] SLING-2420 Prevent deadlocks with the framework while registering 
and unregistering services

--
Started by an SCM change
Building remotely on ubuntu1 in workspace 

Updating http://svn.apache.org/repos/asf/sling/trunk
U 
contrib/extensions/i18n/src/main/java/org/apache/sling/i18n/impl/JcrResourceBundleProvider.java
At revision 1243486
[locks-and-latches] Checking to see if we really have the locks
[locks-and-latches] Have all the locks, build can start
Parsing POMs
Modules changed, recalculating dependency graph
[trunk] $ /home/hudson/tools/java/latest1.5/bin/java -Xmx512M 
-XX:MaxPermSize=256M -enableassertions -cp 
/home/jenkins/jenkins-slave/maven3-agent.jar:/home/hudson/tools/maven/apache-maven-3.0.3/boot/plexus-classworlds-2.4.jar
 org.jvnet.hudson.maven3.agent.Maven3Main 
/home/hudson/tools/maven/apache-maven-3.0.3 
/home/jenkins/jenkins-slave/slave.jar 
/home/jenkins/jenkins-slave/maven3-interceptor.jar 46795
channel started
<===[JENKINS REMOTING CAPACITY]===>   channel stopped
[locks-and-latches] Releasing all the locks
[locks-and-latches] All the locks released
ERROR: Failed to parse POMs
java.io.IOException: Remote call on Channel to Maven 
[/home/hudson/tools/java/latest1.5/bin/java, -Xmx512M, -XX:MaxPermSize=256M, 
-enableassertions, -cp, 
/home/jenkins/jenkins-slave/maven3-agent.jar:/home/hudson/tools/maven/apache-maven-3.0.3/boot/plexus-classworlds-2.4.jar,
 org.jvnet.hudson.maven3.agent.Maven3Main, 
/home/hudson/tools/maven/apache-maven-3.0.3, 
/home/jenkins/jenkins-slave/slave.jar, 
/home/jenkins/jenkins-slave/maven3-interceptor.jar, 46795] failed
at hudson.remoting.Channel.call(Channel.java:690)
at hudson.maven.ProcessCache$MavenProcess.call(ProcessCache.java:156)
at 
hudson.maven.MavenModuleSetBuild$RunnerImpl.doRun(MavenModuleSetBuild.java:795)
at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:470)
at hudson.model.Run.run(Run.java:1409)
at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:481)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:238)
Caused by: java.lang.ClassFormatError: Failed to load 
javax.servlet.ServletException
at 
hudson.remoting.RemoteClassLoader.loadClassFile(RemoteClassLoader.java:154)
at 
hudson.remoting.RemoteClassLoader.findClass(RemoteClassLoader.java:131)
at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
at 
hudson.plugins.cobertura.MavenCoberturaPublisher.(MavenCoberturaPublisher.java:239)
at sun.misc.Unsafe.ensureClassInitialized(Native Method)
at 
sun.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeFieldAccessorFactory.java:25)
at 
sun.reflect.ReflectionFactory.newFieldAccessor(ReflectionFactory.java:122)
at java.lang.reflect.Field.acquireFieldAccessor(Field.java:918)
at java.lang.reflect.Field.getFieldAccessor(Field.java:899)
at java.lang.reflect.Field.getLong(Field.java:528)
at 
java.io.ObjectStreamClass.getDeclaredSUID(ObjectStreamClass.java:1586)
at java.io.ObjectStreamClass.access$700(ObjectStreamClass.java:52)
at java.io.ObjectStreamClass$2.run(ObjectStreamClass.java:408)
at java.security.AccessController.doPrivileged(Native Method)
at java.io.ObjectStreamClass.(ObjectStreamClass.java:400)
at java.io.ObjectStreamClass.lookup(ObjectStreamClass.java:297)
at java.io.ObjectStreamClass.initNonProxy(ObjectStreamClass.java:531)
at 
java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1552)
at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1466)
at 
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1699)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348)
at java.util.ArrayList.readObject(ArrayList.java:591)
at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:592)
at 
java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:946)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1812)
at 
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1719)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348)
at java.util.HashM

Build failed in Jenkins: sling-contrib-1.5 #832

2012-02-13 Thread Apache Jenkins Server 
See 

Changes:

[fmeschbe] SLING-2420 Prevent deadlocks with the framework while registering 
and unregistering services

--
Started by an SCM change
Building remotely on ubuntu1 in workspace 

Updating http://svn.apache.org/repos/asf/sling/trunk/contrib
U 
extensions/i18n/src/main/java/org/apache/sling/i18n/impl/JcrResourceBundleProvider.java
At revision 1243486
[locks-and-latches] Checking to see if we really have the locks
[locks-and-latches] Have all the locks, build can start
Parsing POMs
Modules changed, recalculating dependency graph
[contrib-1.5] $ /home/hudson/tools/java/latest1.5/bin/java -Xmx256M 
-XX:MaxPermSize=128M -enableassertions -cp 
/home/jenkins/jenkins-slave/maven-agent.jar:/home/jenkins/jenkins-slave/classworlds.jar
 hudson.maven.agent.Main /home/hudson/tools/maven/apache-maven-2.2.1 
/home/jenkins/jenkins-slave/slave.jar 
/home/jenkins/jenkins-slave/maven-interceptor.jar 57727 
/home/jenkins/jenkins-slave/maven2.1-interceptor.jar
<===[JENKINS REMOTING CAPACITY]===>   channel started
channel stopped
[locks-and-latches] Releasing all the locks
[locks-and-latches] All the locks released
ERROR: Failed to parse POMs
java.io.IOException: Remote call on Channel to Maven 
[/home/hudson/tools/java/latest1.5/bin/java, -Xmx256M, -XX:MaxPermSize=128M, 
-enableassertions, -cp, 
/home/jenkins/jenkins-slave/maven-agent.jar:/home/jenkins/jenkins-slave/classworlds.jar,
 hudson.maven.agent.Main, /home/hudson/tools/maven/apache-maven-2.2.1, 
/home/jenkins/jenkins-slave/slave.jar, 
/home/jenkins/jenkins-slave/maven-interceptor.jar, 57727, 
/home/jenkins/jenkins-slave/maven2.1-interceptor.jar] failed
at hudson.remoting.Channel.call(Channel.java:690)
at hudson.maven.ProcessCache$MavenProcess.call(ProcessCache.java:156)
at 
hudson.maven.MavenModuleSetBuild$RunnerImpl.doRun(MavenModuleSetBuild.java:795)
at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:470)
at hudson.model.Run.run(Run.java:1409)
at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:481)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:238)
Caused by: java.lang.ClassFormatError: Failed to load 
javax.servlet.ServletException
at 
hudson.remoting.RemoteClassLoader.loadClassFile(RemoteClassLoader.java:154)
at 
hudson.remoting.RemoteClassLoader.findClass(RemoteClassLoader.java:131)
at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
at 
hudson.plugins.cobertura.MavenCoberturaPublisher.(MavenCoberturaPublisher.java:239)
at sun.misc.Unsafe.ensureClassInitialized(Native Method)
at 
sun.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeFieldAccessorFactory.java:25)
at 
sun.reflect.ReflectionFactory.newFieldAccessor(ReflectionFactory.java:122)
at java.lang.reflect.Field.acquireFieldAccessor(Field.java:918)
at java.lang.reflect.Field.getFieldAccessor(Field.java:899)
at java.lang.reflect.Field.getLong(Field.java:528)
at 
java.io.ObjectStreamClass.getDeclaredSUID(ObjectStreamClass.java:1586)
at java.io.ObjectStreamClass.access$700(ObjectStreamClass.java:52)
at java.io.ObjectStreamClass$2.run(ObjectStreamClass.java:408)
at java.security.AccessController.doPrivileged(Native Method)
at java.io.ObjectStreamClass.(ObjectStreamClass.java:400)
at java.io.ObjectStreamClass.lookup(ObjectStreamClass.java:297)
at java.io.ObjectStreamClass.initNonProxy(ObjectStreamClass.java:531)
at 
java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1552)
at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1466)
at 
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1699)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348)
at java.util.ArrayList.readObject(ArrayList.java:591)
at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:592)
at 
java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:946)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1812)
at 
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1719)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348)
at j

[jira] [Resolved] (SLING-2420) Prevent deadlock with Framework

2012-02-13 Thread Felix Meschberger (Resolved) (JIRA) 

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

Felix Meschberger resolved SLING-2420.
--

Resolution: Fixed

Fixed in Rev. 1243476

> Prevent deadlock with Framework
> ---
>
> Key: SLING-2420
> URL: https://issues.apache.org/jira/browse/SLING-2420
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Affects Versions:  i18n 2.2.0
>Reporter: Felix Meschberger
>Assignee: Felix Meschberger
> Fix For: i18n 2.2.2
>
>
> JcrResourceBundleProvider may cause a deadlock between itself and the OSGi 
> Framework:
> * clearCache is called from framework and synchronizes on itself while 
> calling into the framework
> * getResoureBundleInternal  synchronizes on itself and calls into the 
> framework
> Fixes:
>   - clearCache synchronizes on self to get a copy of the service registration 
> list and clears the list; the services are unregistered outside of the sync
>   - getResourceBundleInternal only stores the service registration in the 
> internal list in the synchronized block

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (SLING-2420) Prevent deadlock with Framework

2012-02-13 Thread Felix Meschberger (Created) (JIRA) 
Prevent deadlock with Framework
---

 Key: SLING-2420
 URL: https://issues.apache.org/jira/browse/SLING-2420
 Project: Sling
  Issue Type: Improvement
  Components: Extensions
Affects Versions:  i18n 2.2.0
Reporter: Felix Meschberger
Assignee: Felix Meschberger
 Fix For: i18n 2.2.2


JcrResourceBundleProvider may cause a deadlock between itself and the OSGi 
Framework:

* clearCache is called from framework and synchronizes on itself while calling 
into the framework
* getResoureBundleInternal  synchronizes on itself and calls into the framework

Fixes:
  - clearCache synchronizes on self to get a copy of the service registration 
list and clears the list; the services are unregistered outside of the sync
  - getResourceBundleInternal only stores the service registration in the 
internal list in the synchronized block

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: [VOTE] Deprecate ResourceDecorator.decorate(Resource, HttpServletRequest)

2012-02-13 Thread Felix Meschberger 

Hi

Am 11.02.2012 um 02:19 schrieb Justin Edelson:

> As described here: https://issues.apache.org/jira/browse/SLING-2411, we
> do not currently have a way of enforcing that ResourceResolver clients invoke
> resolve(HttpServletRequest, String) when they are doing a resolve
> inside a request
> context. The net effect of this is that implementors of ResourceDecorator have
> inconsistent results.
> 
> I've uploaded a strawman patch to
> https://issues.apache.org/jira/browse/SLING-2411 to
> illustrate how this might be solved using a ThreadLocal. However, I
> personally feel
> like we should just go ahead and deprecate this method and I'd like to
> call a vote for it.
> 
> Please vote:
> [ ] +1 - deprecate ResourceDecorator.decorate(Resource, HttpServletRequest)
> [ ] 0
> [ ] -1 - don't deprecate
> 
> Note - if you vote -1, please provide an alternative. It could be the
> strawman, it could be
> something else, but I'd really like to see this fixed.

+1 to deprecate.

Regards
Felix

> 
> Thanks
> Justin