AEM 6.5 : Approach to avoid Cloud Manager AEM Rule for working listener implementation.

[cquser1]

Hi All,

The error we are getting in CM is below

1] AEM-3[Non-thread safe object used as a field of Servlet/ Filter etc.]

Listener is working fine, but throwing above error for declaring session in our listener class which implements EventListener

private Session session ;

We are using this in activate() and deactivate() methods and looks like not possible to avoid the CM error.

2] Tried using Event Handler approach, wherein we want this to be invoked when page under certain path "/content/xxx" and few properties like "jcr:title"

are changed, the handler to be invoked for some custom processing.

Tried multiple things but no luck.

https://github.com/arunpatidar02/aem63app-repo/blob/master/java/TestEventHandler.java  didnt work either.

3] Via ResourceChangeListener approach, resourceChange.getAddedPropertyNames()/resourceChange.getChangedPropertyNames(); are deprecated.

4] Is it possible to solve this issue with the above approaches mentioned?

5] If no to #4, Creating launchers/workflows is the only alternative to get this to work?

Any thoughts/pointers on this will be really helpful.

Arun Patidar​

[cquser1]

Just adding details : The listener implemented is on similar lines as done in Creating an Event Listener for Adobe Experience Manager 6.4.

To that implementation,  we are checking if eventIterator.nextEvent().getPath(); has the jcr:title and other properties and based on that we are adding our custom logic.

[arunpatidar]

Hi,

I tried same code from Creating an Event Listener for Adobe Experience Manager 6.4  in 6.5 and I am not getting any exception.

[cquser1]

Hi Arun,

I mean the code in Creating an Event Listener for Adobe Experience Manager 6.4  is working fine but cloud manager is throwing AEM-3[Non-thread safe object used as a field of Servlet/ Filter etc.] while deployment to our servers, which probably we will not be able to fix.

So, we were exploring other ways[mentioned above] of resolving this issue and if there is a way out.

[arunpatidar]

I guess it is AMS SonarQube Rules which is throwing warning

AEM Rules:AEM-3 Non-thread safe object used as a field of Servlet / Filter etc. Bug Critical aem

You need to add finally after catch to close session

finally {

        if (adminSession != null) {

        adminSession.logout();

        }

      }

    }

[Jörg_Hoh]

This is an programming error indicated by the integrated sonar checks.

A filter is a singleton, which can be run concurrently. Thus it must not have any non-static final members, because these would be shared among the invocations, and invocation A could overwrite the value of invocation B. Thus avoid any global member inside a filter. (For servlets the same limitations exists.)

[cquser1]

Hi Joerg,

Thank you for the information provided.

However, we are not very sure as to how to modify the code to avoid this CM rule check.

Arun Patidar​ Adding a finally block didn't help much. Any pointers/ thoughts on how this can be done will be helpful.

[arunpatidar]

Hi,

According to adobe

The quality scanning process is not perfect and will sometimes incorrectly identify issues which are not actually problematic. This is referred to as a "false positive".

In these cases, the source code can be annotated with the standard Java @SuppressWarnings annotation specifying the rule ID as the annotation attribute.

Example

@SuppressWarnings("AEM Rules:AEM-3")

private Session adminSession;

[Jörg_Hoh]

Hi,

you are opening a session within activate() of a filter and close it as part of deactivate(). And you store the session as a member of this filter object.

This is problematic, as every invocation of the filter is accessing the very same session object. While technically you are not overwriting the value of the session object with every invocation (thus you could consider that this is no violation of this rule), you violate a few rules regarding session handling:

* JCR sessions are not thread safe. Using the same session object from different threads (this is the case here!) is causing lock contention.

* You are using a long-running session, which could cause problems if not properly handled. In your case the session never sees any update which is happening in the repo during the runtime of this session.

Thus:

* Open (and close) this session when it's actually needed and not globally in activate(). Then you can have this session object declared within the filter() method and the CM rule does not longer apply.

* Opening a session comes with a cost; be sure that there's no other way to handle this situation.

HTH,

Jörg