You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Dominik Süß <do...@gmail.com> on 2014/10/28 14:46:08 UTC
ResourceWrapper issue with ResourceMetadata
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
Re: ResourceWrapper issue with ResourceMetadata
Posted by Robert Munteanu <ro...@apache.org>.
On Wed, Oct 29, 2014 at 5:24 PM, Carsten Ziegeler <cz...@apache.org> 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 <cz...@apache.org>
>> 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
>>> cziegeler@apache.org
>>>
>>
>
>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziegeler@apache.org
Re: ResourceWrapper issue with ResourceMetadata
Posted by Carsten Ziegeler <cz...@apache.org>.
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 <cz...@apache.org>
> 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
>> cziegeler@apache.org
>>
>
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: ResourceWrapper issue with ResourceMetadata
Posted by Dominik Süß <do...@gmail.com>.
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 <cz...@apache.org>
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
> cziegeler@apache.org
>
Re: ResourceWrapper issue with ResourceMetadata
Posted by Carsten Ziegeler <cz...@apache.org>.
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
cziegeler@apache.org