Am 29.10.14 um 11:13 schrieb Dominik Süß: > Hi Carsten, > > thanks for your quick feedback - yes it works without functional > degradations but it actually spams the error.log with INFO messages which > is not acceptable in productive Code. Do you see a way to workaround this > issue and/or give an estimation when this issue could be fixed? I'd help > myself but this part was tweaked a lot in the mentioned ticket and I'd fear > to break things. > > A minor fix would be to add a try catch block for contentlenght and skip it > if this exception occurs (don't know if there is other logic relying on > contentlenght that would break).
There is already a try/catch block which catches this exception, but logs them. As this is an exception error we can reduce the log level to debug. But the code itself hasn't changed for a long time, it just moved. Now, I think the first step would be to open an issue for this, so we don't forget it. And if someone has a good idea on how to fix this, patches welcome. Maybe we can avoid running into this problem be doing some check before. Regards Carsten > > Best regards, > Dominik > > On Tue, Oct 28, 2014 at 8:48 PM, Carsten Ziegeler <[email protected]> > wrote: > >> This is the ugly code trying to get the content length for a resource. I >> think this code is unchanged, it's now just invoked different and maybe >> the reporting of the exception is new. However, the exception is >> swalled, so your provider should still work. >> >> But maybe we have to revisit the code in order to properly avoid the >> exception if possible. >> >> Carsten >> >> Am 28.10.14 um 14:46 schrieb Dominik Süß: >>> Hi everybody, >>> >>> I might have found a bug related to the changes of SLING-3848. >>> Due to some requirements some properties of a resource had to be moved >> to a >>> third location for the resources of one very specific contentbranch. Now >> I >>> do have a ResourceProvider that does nothing more then creating a >>> ResourceWrapper in the original location hiding the JCRNodeResource >>> underneath. As proposed by Carsten in another thread (see [0]) I solve >> the >>> problem of the locked JCRNodeResourceMetadata via creating a new Metadata >>> object and setting the entries via putAll() in the constructor of the own >>> Wrapper. At this point I get an exception caused by a >> node.getPrimaryItem() >>> call in JCRNodeResourceMetadata ([1] Line 164). >>> >>> --- >>> org.apache.sling.jcr.resource.internal.helper.jcr.JcrNodeResource >>> setMetaData: Problem extracting metadata information for >>> /etc/mypath/jcr:content >>> javax.jcr.ItemNotFoundException: No primary item present on node >>> getPrimaryItem >>> --- >>> >>> I verified that this happens on oak based and jcr 2 based instances. I >>> don't know the exact mechanism of SLING-3848 [2], how that node is >> supposed >>> to behave and what the goal of that codefragment exactly is, but I expect >>> other consumers to fail as well since SuperImposingResource [3] actually >> is >>> doing the same (although in an own resource not a ResourceWrapper, but >> that >>> shouldn't be a difference in the constructor. >>> >>> Any ideas what's going on here? >>> >>> Best regards >>> Dominik >>> >>> [0] http://markmail.org/thread/ortcft2vjjs2ukga >>> [1] >>> >> http://svn.apache.org/viewvc/sling/trunk/bundles/jcr/resource/src/main/java/org/apache/sling/jcr/resource/internal/helper/jcr/JcrNodeResourceMetadata.java >>> [2] https://issues.apache.org/jira/browse/SLING-3848 >>> [3] >>> >> https://github.com/apache/sling/blob/trunk/contrib/extensions/superimposing/src/main/java/org/apache/sling/superimposing/impl/SuperimposingResource.java#L44 >>> >> >> >> -- >> Carsten Ziegeler >> Adobe Research Switzerland >> [email protected] >> > -- Carsten Ziegeler Adobe Research Switzerland [email protected]
