All,
I have a custom process step within the dam update asset workflow where the step needs a resource resolver instance which I get from the workflow session via adaptTo
ResourceResolver resResolver = workflowSession.adaptTo(ResourceResolver.class);
I do NOT have a closeable try block as in below since i am not opening it..
try(ResourceResolver resResolver = workflowSession.adaptTo(ResourceResolver.class))
using com.adobe.granite.workflow.WorkflowSession
I noticed the "Unclosed resolver opened here" at INFO log level and at the above line.
Since it is not something i have opened, per my understanding, i don't believe i should be closing it.
Just an FYI: This resource resolver instance is then used to make an update to the metadata, i see ACS using similar approach just that i am not using autoclosable try cause i am not opening it, wonder why we need it?
https://github.com/Adobe-Consulting-Services/acs-aem-commons/blob/master/bundle/src/main/java/com/ad...
https://github.com/Adobe-Consulting-Services/acs-aem-commons/blob/master/bundle/src/main/java/com/ad...
public final ResourceResolver getResourceResolver(com.adobe.granite.workflow.WorkflowSession workflowSession) {
return workflowSession.adaptTo(ResourceResolver.class);
}
cc @Jörg_Hoh
Solved! Go to Solution.
Views
Replies
Total Likes
You are correct, the code instantiates a new ResourceResolver there. My blog post is actually incorrect in that area. So you need to close this RR.
Thanks for spotting. I will update the post.
ResoureResolver is an interface, you can not instantiate it. There are different ways to get the implementation in ResoureResolver, either which way it could be it is always a good practice to close it.
Hi @Anudeep_Garnepudi not sure what you mean but I know it is not the wrong way to get the resolver . Question becomes, should I close it ? Which I believe should be a no , since u have not opened it .hence I believe no need for an auto close able try block
i do not want to get the resolver via service user , when I have the workflow session.
closing it if I have not opened it , I fear it can just cause troubles across
I see acs using similar approach just that i am not using autoclosable try, cause i am not opening it, wonder why we need it?
https://github.com/Adobe-Consulting-Services/acs-aem-commons/blob/master/bundle/src/main/java/com/ad...
https://github.com/Adobe-Consulting-Services/acs-aem-commons/blob/master/bundle/src/main/java/com/ad...
public final ResourceResolver getResourceResolver(com.adobe.granite.workflow.WorkflowSession workflowSession) {
return workflowSession.adaptTo(ResourceResolver.class);
}
If you would obtain a resourceResolver
You did not open the resolver from a request or workflow session and do not need to close it.
Check if there is any other resource resolvers causing it.
Thanks,
Kiran Vedantam
i am not sure I follow . I have obtained it from workflow session via adaptTo and hence I don’t believe I should close it or use the autoclosable try block. I don’t want to close the resolver and create an issue with the resolver being closed for next steps within workflow
please let me know
update- I know there are OOTB ones but can’t say if they are causing it since the custom class comes up , for this unclosed resolver
Class reference from similar acs code - they are using similar approach just that i am not using autoclosable try cause i am not opening it, wonder why we need it?
https://github.com/Adobe-Consulting-Services/acs-aem-commons/blob/master/bundle/src/main/java/com/ad...
https://github.com/Adobe-Consulting-Services/acs-aem-commons/blob/master/bundle/src/main/java/com/ad...
public final ResourceResolver getResourceResolver(com.adobe.granite.workflow.WorkflowSession workflowSession) {
return workflowSession.adaptTo(ResourceResolver.class);
}
You dont need to close the resourceResolver coming from workflow session, check if anything else is causing the issue.
Thanks Kiran, i totally agree.,..but i see nothing else causing it. How would you identify? below are the logs. I am on 6.5.12 and before this i see bunch of unclosed resolvers in ootb code
Btw, my step is after the "metadata processor" in the OOTB update asset workflow
org.apache.sling.resourceresolver.impl.CommonResourceResolverFactoryImpl Unclosed ResourceResolver was created here:
java.lang.Exception: Opening Stacktrace
at org.apache.sling.resourceresolver.impl.CommonResourceResolverFactoryImpl$ResolverReference.<init>(CommonResourceResolverFactoryImpl.java:538) [org.apache.sling.resourceresolver:1.7.10]
at org.apache.sling.resourceresolver.impl.CommonResourceResolverFactoryImpl.register(CommonResourceResolverFactoryImpl.java:228) [org.apache.sling.resourceresolver:1.7.10]
at org.apache.sling.resourceresolver.impl.ResourceResolverImpl.<init>(ResourceResolverImpl.java:110) [org.apache.sling.resourceresolver:1.7.10]
at org.apache.sling.resourceresolver.impl.ResourceResolverImpl.<init>(ResourceResolverImpl.java:103) [org.apache.sling.resourceresolver:1.7.10]
at org.apache.sling.resourceresolver.impl.CommonResourceResolverFactoryImpl.getResourceResolverInternal(CommonResourceResolverFactoryImpl.java:273) [org.apache.sling.resourceresolver:1.7.10]
at org.apache.sling.resourceresolver.impl.CommonResourceResolverFactoryImpl.getResourceResolver(CommonResourceResolverFactoryImpl.java:183) [org.apache.sling.resourceresolver:1.7.10]
at org.apache.sling.resourceresolver.impl.ResourceResolverFactoryImpl.getResourceResolver(ResourceResolverFactoryImpl.java:98) [org.apache.sling.resourceresolver:1.7.10]
at com.adobe.granite.workflow.core.WorkflowSessionImpl.adaptTo(WorkflowSessionImpl.java:2193) [com.adobe.granite.workflow.core:2.0.240.CQ656-B0017]
at com.xxx.aem.core.workflows.CustomProcessStep.execute(CustomProcessStep.java:43)
As per my understanding you don't need to close the resource resolver in this case.
Please refer these links -
https://cqdump.joerghoh.de/2018/11/12/resourceresolvers-and-sessions-you-open-it-you-close-it/
I have learnt from @Jorg_Hoh
.adaptTo() is not listed as one of methods opening a ResourceResolver, thus we should not close it.
Agreed and hence the confusion .. Using closeable try means we are closing it .. right @DEBAL_DAS ?
try(ResourceResolver resResolver = workflowSession.adaptTo(ResourceResolver.class))
yes, reason i confirmed is, strangely, when i tried adding the autocloseable try and the info message for the custom class disappeared. The blogs however, unless i am missing something do not speak to workflow session . I see it implemented with autocloseable try to close the session/resolver in ACS(links above) , makes me wonder if this is an internal bug for which autocloseable try, to close the session/resolver, is a workaround.. raised a ticket.. as a bug with tagid is confirmed
on adaptTo
You are correct, the code instantiates a new ResourceResolver there. My blog post is actually incorrect in that area. So you need to close this RR.
Thanks for spotting. I will update the post.
Thanks a lot @Jörg_Hoh , and please do not apologize, it is a needle in a haystack. Please do provide me with the url of the post you update and i will keep it for reference.
Quick question - If i do this , which is closing it, will it hamper next steps in the workflow by any chance ?
try(ResourceResolver resResolver = workflowSession.adaptTo(ResourceResolver.class)){
//body of the code and persisting logic with session.refresh and save/commits and NO session.close or resolver.close needed
}
Views
Likes
Replies
Views
Likes
Replies
Views
Likes
Replies