Unclosed Resource resolver - Custom workflow step

[NitroHazeDev]

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 

[Anudeep_Garnepudi]

@NitroHazeDev 

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.

[NitroHazeDev]

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);
}

[Kiran_Vedantam]

Hi @NitroHazeDev 

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

[NitroHazeDev]

Hi @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);
}

[Kiran_Vedantam]

You dont need to close the resourceResolver coming from workflow session, check if anything else is causing the issue.

[NitroHazeDev]

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)

[DEBAL_DAS]

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/

https://cqdump.joerghoh.de/2013/07/23/cq-development-patterns-sling-resourceresolver-and-jcr-session...

I have learnt from @Jorg_Hoh

.adaptTo() is not listed as one of methods opening a ResourceResolver, thus we should not close it.

[NitroHazeDev]

Agreed and hence the confusion .. Using closeable try means we are closing it .. right @DEBAL_DAS ? 

try(ResourceResolver resResolver = workflowSession.adaptTo(ResourceResolver.class))

[DEBAL_DAS]

yes -

https://cqdump.joerghoh.de/2018/11/14/try-with-resource-or-i-will-never-forget-to-close-a-resource-r...

[NitroHazeDev]

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

[Jörg_Hoh · Accepted solution]

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.

[NitroHazeDev]

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

}