Skip to main content

This content has been archived and is no longer being updated.

Links may not function; however, this content may be relevant to outdated versions of the product.

Troubleshooting: System Management Application "HTTP 404 Servlet action not available" (Tomcat)

Suggest edit Updated on February 27, 2017

Summary

Your PRPC 6.3 SP1 deployment is running on Tomcat 7.0.42. When you start the System Management Application, the screen displays the error:

HTTP Status 404 - Servlet action is not available

The Tomcat log stack trace shows the following information (partial):

SEVERE: Servlet /prsysmgmt threw load() exception org.apache.commons.logging.LogConfigurationException: Class org.apache.commons.logging.impl.Log4JLogger does not implement Log

at

org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:246)

at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:395)

Errors

Screen Error

HTTP Status 404 - Servlet action is not available

type Status report

message Servlet action is not available

description The requested resource (Servlet action is not available) is not available.

Stack Trace

The Tomcat localhost log reports the following error:

SEVERE: Servlet /prsysmgmt threw load() exception

org.apache.commons.logging.LogConfigurationException: Class org.apache.commons.logging.impl.Log4JLogger does not implement Log

at org.apache.commons.logging.impl.LogFactoryImpl.getLogConstructor(LogFactoryImpl.java:412)

at org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:525)

at org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:272)

at org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:246)

at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:395)

at org.apache.struts.action.ActionServlet.<clinit>(ActionServlet.java:374)

at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)

at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)

at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)

at java.lang.reflect.Constructor.newInstance(Constructor.java:526)

at java.lang.Class.newInstance(Class.java:374)

at org.apache.catalina.core.DefaultInstanceManager.newInstance(DefaultInstanceManager.java:138)

at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1144)

at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1088)

at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:5176)

at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5460)

at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)

at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901)

at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:877)

at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:633)

at org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:1113)

at org.apache.catalina.startup.HostConfig$DeployDirectory.run(HostConfig.java:1671)

at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)

at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)

at java.util.concurrent.FutureTask.run(FutureTask.java:166)

at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)

at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)

at java.lang.Thread.run(Thread.java:724)

Explanation

Analysis of the problem involved adding the required libraries to the <TOMCAT_INSTALL_DIR>/lib folder and understanding how Tomcat class loading works.

The Reference, Understanding The Tomcat Classpath - Common Problems And How To Fix Them, within the section How Tomcat Classpath Usage Differs From Standard Usage, is critical to understanding how the Tomcat application server resolves the classpath.

Remember that SMA is an embedded application using Struts. When SMA is embedded in an application that includes another core web framework such as Apache Wicket or the Spring Framework, Tomcat will load the core class using the System classloader when starting the web framework instead of loading it from the WEB-INF/lib directory of the application.

This default behavior makes sense when Tomcat is running as a standalone application container. However, when Tomcat is embedded in another core web framework application, it results in the resource being made unavailable to the web application.

Java class loading is "lazy"; the first classloader that requests a certain class owns the class for the remainder of its lifecycle. If the System classloader, whose classes are not visible to the web application, loads the framework class first, the JVM will prevent additional instances of the class from being created, causing the classpath errors.

To work around this problem, the Support engineer performed the following steps:

  1. Added a custom bootstrap classloader to the application
  2. Configured this classloader to load the appropriate libraries on behalf of the web application
  3. Triggered the startup of the rest of the application as normally done

These actions resolved all classloader conflicts in favor of the application.

Next, the Support engineer considered whether duplicate JAR files might be causing the classloading problem. Independent of the Tomcat application server, JBoss Tattletale is a good tool for analyzing web application dependencies. JBossTatteltale identified conflicting Class Jdk14Logger and duplicate JAR files:

org.apache.commons.logging.impl.Jdk14Logger commons-logging-1.1.jar

org.apache.commons.logging.impl.Jdk14Logger commons-logging.jar

The class org.apache.commons.logging.impl.Jdk14Logger is found in two different JAR files because Jdk14Logger is used by the ActionServlet class, as seen in the stack trace. This is the crux of the problem.

Suggested Approach

To prevent the SMA HTTP 404 error on a Tomcat application server:

  1. Stop the Tomcat application server.
  2. Navigate to the Tomcat webapps directory, <TOMCAT_INSTALL_LOCATION>/webapps/prsysmgmt/WEB-INF/lib .
  3. Delete the file common-logging.jar.
  4. Restart the Tomcat application server.
  5. Start the System Management Application: http:<host_name>:<port>/prsysmgmt
  6. Check the Tomcat localhost log to confirm that the error previously shown in the stack trace is gone.
  7. After verifying that the System Management Application initializes successfully, open the PRPC application by addressing its URL in the browser.

Additional Information

System Management Application (SMA)

References

Understanding The Tomcat Classpath - Common Problems And How To Fix Them

Apache Commons Logging Guide

Did you find this content helpful? YesNo

100% found this useful

Have a question? Get answers now.

Visit the Collaboration Center to ask questions, engage in discussions, share ideas, and help others.

Ready to crush complexity?

Experience the benefits of Pega Community when you log in.

We'd prefer it if you saw us at our best.

Pega.com is not optimized for Internet Explorer. For the optimal experience, please use:

Close Deprecation Notice
Contact us