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). 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] >
