On Wed, Oct 29, 2014 at 5:24 PM, Carsten Ziegeler <[email protected]> wrote: > 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.
Filed SLING-4116 [1] with the details and also a small code hint from Jackrabbit. Maybe someone how hit this problem already wants to jump in and provide a patch ;-) Cheers, Robert [1]: https://issues.apache.org/jira/browse/SLING-4116 > > 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]
