jcl-over-slf4j causes Agent to crash

[CommunityUser]

It appears the Java Agent for AppDynamics scans for Loggers. The issues is that jcl-over-slf4j throws exceptions when it's static methods are invoked which AppDynamics doesn't handle.

Any suggestions besides removing jcl-over-slf4j?

Here is the exception:

Could not start Java Agent,org.apache.commons.logging.LogConfigurationException: The chosen LogFactory implementation does not extend LogFactory. Please check your configuration. (Caused by java.lang.UnsupportedOperationException: Operation [getClassLoader] is not supported in jcl-over-slf4j. See also http://www.slf4j.org/codes.html#unsupported_operation_in_jcl_over_slf4j) ,Please check log files

org.apache.commons.logging.LogConfigurationException: The chosen LogFactory implementation does not extend LogFactory. Please check your configuration. (Caused by java.lang.UnsupportedOperationException: Operation [getClassLoader] is not supported in jcl-over-slf4j. See also http://www.slf4j.org/codes.html#unsupported_operation_in_jcl_over_slf4j)
    at org.apache.commons.logging.LogFactory.createFactory(LogFactory.java:1271)
    at org.apache.commons.logging.LogFactory$2.run(LogFactory.java:1065)
    at java.security.AccessController.doPrivileged(Native Method)
    at org.apache.commons.logging.LogFactory.newFactory(LogFactory.java:1062)
    at org.apache.commons.logging.LogFactory.getFactory(LogFactory.java:497)
    at com.singularity.ee.agent.appagent.kernel.JavaAgent.b(JavaAgent.java:234)
    at com.singularity.ee.agent.appagent.kernel.JavaAgent.initialize(JavaAgent.java:100)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at com.singularity.ee.agent.appagent.AgentEntryPoint.premain(AgentEntryPoint.java:153)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at sun.instrument.InstrumentationImpl.loadClassAndStartAgent(InstrumentationImpl.java:323)
    at sun.instrument.InstrumentationImpl.loadClassAndCallPremain(InstrumentationImpl.java:338)
Caused by: java.lang.UnsupportedOperationException: Operation [getClassLoader] is not supported in jcl-over-slf4j. See also http://www.slf4j.org/codes.html#unsupported_operation_in_jcl_over_slf4j
    at org.apache.commons.logging.LogFactory.getClassLoader(LogFactory.java:375)
    at org.apache.commons.logging.impl.LogFactoryImpl.getClassLoader(LogFactoryImpl.java:447)
    at org.apache.commons.logging.impl.LogFactoryImpl.initDiagnostics(LogFactoryImpl.java:476)
    at org.apache.commons.logging.impl.LogFactoryImpl.<init>(LogFactoryImpl.java:95)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
    at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
    at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
    at java.lang.Class.newInstance0(Class.java:357)
    at java.lang.Class.newInstance(Class.java:310)
    at org.apache.commons.logging.LogFactory.createFactory(LogFactory.java:1160)

[Arun_Dasetty · Accepted solution]

Hi Andrew,

Please try either of the following suggestions which we tried in few customer environments and it resolved the issue:

1) Add the following -D property to set the LogFactory implementation to be used for commons logging
-Dorg.apache.commons.logging.LogFactory=org.apache.commons.logging.impl.LogFactoryImpl

2) If you have commons-logging-1.1.1.jar and jcl-over-slf4j-1.6.6.jar in the classpath

if the above jars are in the reverse order of our requirement. - If this classpath is set manually, you can try exchanging the positions and that should help.
- If its picked up by the server automatically, you can try adding commons-logging.commons-logging-1.1.1.jar or javaagent.jar ahead in the classpath manually using the server startup scripts.

we can see the workaround mentioned at http://www.slf4j.org/codes.html#unsupported_operation_in_jcl_over_slf4j:

"if you place jcl-over-slf4j.jar in WEB-INF/lib directory of your web-application instead of $TOMCAT_HOME/common/lib, where $TOMCAT_HOME stands for the directory where Tomcat is installed. In order to fully benefit from the stability offered by jcl-over-slf4j.jar, we recommend that you place jcl-over-slf4j.jar in $TOMCAT_HOME/common/lib without placing a copy in your web-applications."

Please let us know how it goes.

Thanks,

Arun

[Arun_Dasetty · Accepted solution]

Hi Andrew,

Please try either of the following suggestions which we tried in few customer environments and it resolved the issue:

1) Add the following -D property to set the LogFactory implementation to be used for commons logging
-Dorg.apache.commons.logging.LogFactory=org.apache.commons.logging.impl.LogFactoryImpl

2) If you have commons-logging-1.1.1.jar and jcl-over-slf4j-1.6.6.jar in the classpath

if the above jars are in the reverse order of our requirement. - If this classpath is set manually, you can try exchanging the positions and that should help.
- If its picked up by the server automatically, you can try adding commons-logging.commons-logging-1.1.1.jar or javaagent.jar ahead in the classpath manually using the server startup scripts.

we can see the workaround mentioned at http://www.slf4j.org/codes.html#unsupported_operation_in_jcl_over_slf4j:

"if you place jcl-over-slf4j.jar in WEB-INF/lib directory of your web-application instead of $TOMCAT_HOME/common/lib, where $TOMCAT_HOME stands for the directory where Tomcat is installed. In order to fully benefit from the stability offered by jcl-over-slf4j.jar, we recommend that you place jcl-over-slf4j.jar in $TOMCAT_HOME/common/lib without placing a copy in your web-applications."

Please let us know how it goes.

Thanks,

Arun

[CommunityUser · Accepted solution]

I appreciate the quick response. In my myopic view of the problem I had already isolated it to being a AppDynamics issue since the software worked without the Java Agent but it was a more general problem with jcl and commons. It is resolved now.

[CommunityUser]

Hello Andrew, 

Great to hear that the issue is resolved! Appreciate if you could let us know if either of the 2 options worked for you OR did you use some other solution? That will help us make the product & documentation better.

Thanks

Sid