Skip to main content
Gdubz-57m2mu
Gdubz-57m2mu
Level 5
Jan 27, 2017 5:31 PM UTC
Solved

ResourceResolver try-with-resources in AEM 6.2

Based on the versions I've found, it should work but I just wanted to confirm if anyone has used/tested this with any luck, without leaving tons of sessions open all over the place.

According to SLING-4805[1], ResourceResolver should properly extend AutoCloseable[2] as of Sling API 2.11.0. And according to the bundle I'm seeing in my system console of my local AEM 6.2 instance, it's using Sling API 2.11.0. So I should be able to refactor all of our try-catch-finally resource resolver code to try-with-resources[3], yeah?

try (ResourceResolver resolver = resourceResolverFactory.getServiceResourceResolver(null)) { // do something with the resolver } catch (LoginException e) { // error handle }

Probably just being paranoid and second guessing myself, wondering if anyone else has tried this.

[1] https://issues.apache.org/jira/browse/SLING-4805
[2] https://docs.oracle.com/javase/8/docs/api/java/lang/AutoCloseable.html
[3] https://docs.oracle.com/javase/8/docs/technotes/guides/language/try-with-resources.html

    This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
    Gdubz-57m2mu
    Gdubz-57m2muAccepted solution
    Level 5
    Jan 30, 2017 12:39 PM UTC

    smacdonald2008 wrote...

    Most ppl that is speak with about this manually close sessions. Have you tried this API? 

     

    We have historically done something like the following code, albeit with the getting/closing abstracted away to util class methods:

    String serviceName = “some-service-name”; ResourceResolver serviceResolver = null; try { Map<String, Object> serviceParams = new HashMap<>(); serviceParams.put(ResourceResolverFactory.SUBSERVICE, serviceName); serviceResolver = resolverFactory.getServiceResourceResolver(serviceParams); // do whatever is needed with the resolver here } catch (LoginException e) { LOG.error("Error getting service resolver for \"{}\": {}", serviceName, e); } finally { Session session = serviceResolver.adaptTo(Session.class); if (session != null) { session.logout(); session = null; } if (serviceResolver != null) { if (serviceResolver.isLive()) { serviceResolver.close(); } serviceResolver = null; } }

    Just thought we could simplify our code a bit by not having to deal with the finally block.

    To answer your question, yes I just tried it out on Friday and it's error free, but that doesn't necessarily mean that it's closing properly. I suppose I could try to fetch some resources with it after the try-with-resources block and see if it's still open... 

    After having memory leak problems with CQ 5.5 and 5.6.1 because of unclosed sessions, I'm just a bit paranoid, I guess.

    View in thread

    6 replies

    smacdonald2008
    smacdonald2008
    Level 10
    Jan 28, 2017 7:23 PM UTC

    Most ppl that is speak with about this manually close sessions. Have you tried this API? 

    Translate
      Gdubz-57m2mu
      Gdubz-57m2muAuthorAccepted solution
      Level 5
      Jan 30, 2017 12:39 PM UTC

      smacdonald2008 wrote...

      Most ppl that is speak with about this manually close sessions. Have you tried this API? 

       

      We have historically done something like the following code, albeit with the getting/closing abstracted away to util class methods:

      String serviceName = “some-service-name”; ResourceResolver serviceResolver = null; try { Map<String, Object> serviceParams = new HashMap<>(); serviceParams.put(ResourceResolverFactory.SUBSERVICE, serviceName); serviceResolver = resolverFactory.getServiceResourceResolver(serviceParams); // do whatever is needed with the resolver here } catch (LoginException e) { LOG.error("Error getting service resolver for \"{}\": {}", serviceName, e); } finally { Session session = serviceResolver.adaptTo(Session.class); if (session != null) { session.logout(); session = null; } if (serviceResolver != null) { if (serviceResolver.isLive()) { serviceResolver.close(); } serviceResolver = null; } }

      Just thought we could simplify our code a bit by not having to deal with the finally block.

      To answer your question, yes I just tried it out on Friday and it's error free, but that doesn't necessarily mean that it's closing properly. I suppose I could try to fetch some resources with it after the try-with-resources block and see if it's still open... 

      After having memory leak problems with CQ 5.5 and 5.6.1 because of unclosed sessions, I'm just a bit paranoid, I guess.

      Translate
      Feike_Visser1
      Adobe Employee
      Feike_Visser1Adobe Employee
      Adobe Employee
      Jan 30, 2017 12:52 PM UTC

      I like your way/suggestion.I think the main reason why it is not used much is because this requires Java 8.

      Translate
        Gdubz-57m2mu
        Gdubz-57m2muAuthor
        Level 5
        Jan 30, 2017 1:06 PM UTC

        Feike Visser wrote...

        I like your way/suggestion.I think the main reason why it is not used much is because this requires Java 8.

         

        Fair enough. We just recently finished upgrading all of our PROD servers to 1.8 and we're now in the process of refactoring code to take advantage of some of these new features.

        Translate
          daniel_henriqu1
          daniel_henriqu1
          Level 4
          Apr 3, 2017 6:26 PM UTC

          Hi, Feike.

          Isn't try-with-resources a Java 7 thing?

          So, I believe we just need to import the right Sling API in order to use it, right?

          Regards,

          Daniel.

          Translate
          Feike_Visser1
          Adobe Employee
          Feike_Visser1Adobe Employee
          Adobe Employee
          Apr 3, 2017 6:34 PM UTC

          Indeed Java7, however I don't if this is available prior 6.2

          And AEM6.2 requires Java8. 

          Translate
          Terms & ConditionsAccessibility statement

          Loading footer...