4

I'm migrating an application to JBoss 7, where all dependencies were in "JBOSS_HOME/server/default/lib" (JBoss 4). I included the lib "servlet.jar" (javax.servlet. *), however, after setting a Global Module for JBoss 7 (modules.xml, standalone.xml, jboss-deployment-structure.xml in war files), libraries are loaded normally by JBoss.

When JBoss 7 tries to start the filters, I get following exception:

15:09:15,222 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/RegistrarValorDolar]] (MSC service thread 1-2) Exception starting filter cripto: java.lang.ClassCastException: cenpra.com.sigtec.business.utilities.SessionFilter cannot be cast to javax.servlet.Filter
at org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:441) [jbossweb-7.0.13.Final.jar:]
at org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:3269) [jbossweb-7.0.13.Final.jar:]
at org.apache.catalina.core.StandardContext.start(StandardContext.java:3865) [jbossweb-7.0.13.Final.jar:]
at org.jboss.as.web.deployment.WebDeploymentService.start(WebDeploymentService.java:90) [jboss-as-web-7.1.1.Final.jar:7.1.1.Final]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) [rt.jar:1.7.0_15]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) [rt.jar:1.7.0_15]
at java.lang.Thread.run(Unknown Source) [rt.jar:1.7.0_15]

Trying to remove the library "servlet.jar" from Global Modules, in a try that the server loads it's own classes using an internal jar, I got a ClassNotFoundExceptionof javax.servlet.Filter class.

  • I want to use global modules, since I need to reuse a lot of libraries.
axcdnt
  • 14,004
  • 7
  • 26
  • 31
Rafael Orágio
  • 1,718
  • 5
  • 19
  • 26

1 Answers1

8

Your classpath is polluted with multiple different versioned javax.servlet.Filter classes. A class which is loaded by classloader X (e.g. the one responsible for container's internal classes) is not the same class when it's loaded by classloader Y (e.g. the one responsible for webapp's classes).

I included the lib "servlet.jar" (javax.servlet.)

This does at least not sound right. This is supposed to be already provided by the target servletcontainer (which is JBoss in your case). You should absolutely not provide servletcontainer-specific libraries along with the webapp in its /WEB-INF/lib folder. This would only end up in runtime classpath disaster because they get classloading precedence over the ones provided by the servletcontainer itself and thus conflicts with servletcontainer's internal classes which are in turn using servletcontainer's own classes.

Get rid of servletcontainer-specific libraries in /WEB-INF/lib folder.

This is a common starter's mistake in a careless attempt to fix/circumvent compilation errors on javax.servlet API which they face in their IDE. It should have been solved differently. To the point, you need to tell the IDE to associate the web project with the given target container. The IDE will then automatically do the necessary build path magic.

See also:

Community
  • 1
  • 1
BalusC
  • 1,082,665
  • 372
  • 3,610
  • 3,555
  • At no time I mention that the dependencies are in the /WEB-INF/lib of my web app. The classpath isn't polluted, are only specifc dependencies . Did I mention it was used Global Modules of JBoss as the link in question. Do not know if you paid attention on the question, but when I remove the lib servlet.jar from Global Modules, I get ClassNotFoundException for class Filter. The web app has not seek by the Filter class loaded from container. – Rafael Orágio Feb 27 '13 at 19:36
  • My answer is based on the exception+stacktrace which you got. Exceptions don't lie. Your runtime classpath is definitely polluted with multiple copies of Servlet API. I was just trying to point out a possible cause based on your question which appears to be somewhat ambiguous. I do at least not see any other possible causes based on the information provided so far. All I can tell is to take a sweep through the entire runtime classpath. `/WEB-INF/lib`, `JRE/lib`, `JRE/lib/ext`, `JBoss/lib`, etc..etc.. – BalusC Feb 27 '13 at 19:42