2 Replies Latest reply on Feb 29, 2012 4:57 AM by swoeste

    problems with filters in jboss 7

    swoeste Newbie

      Hi Everybody,


      I am trying to port our application from jboss 4.2.3 to jboss 7.0.2.Final. I’ve started with the migration guides and made some progress, so far I could deploy the application. But if I try to access the context of WAR2 I get an exception:


      Our Application has the following structure:






      WAR1 has the context “/authentication” and WAR2 has the context “/control”. Both WARs make use of some filters.


      If I access the “/authentication” context it runs through 3 filters (let’s call them F1, F2 and F3). The filters are loaded by the classloader of WAR1. Then I try to access the other context (“/control”) and it runs through F1 and F2 but in F3 I get an exception.


          public static WebApplicationContext getWebApplicationContext(ServletContext sc, String attrName) {
              Assert.notNull(sc, "ServletContext must not be null");
              Object attr = sc.getAttribute(attrName);
              if (attr == null) {
                  return null;
              if (attr instanceof RuntimeException) {
                  throw (RuntimeException) attr;
              if (attr instanceof Error) {
                  throw (Error) attr;
              if (attr instanceof Exception) {
                  throw new IllegalStateException((Exception) attr);
              if (!(attr instanceof WebApplicationContext)) {
                  // this exception will be thrown
                  // attr= XMLWebApplicationContext (CL: WAR2)
                  // this.class = org.springframework.web.context.support.WebApplicationContextUtils (CL of F3 and so WAR1)
                  throw new IllegalStateException("Context attribute is not of type WebApplicationContext: " + attr);
              return (WebApplicationContext) attr;


      The strange thing is that F3 at this point is not loaded by the classloader of WAR2 but of WAR1. Same for F1 and F2 both are loaded from WAR1; because they make just a small check without calling any other method/class everything is fine. F3 instead calls other classes which will be loaded from WAR2 which causes the exception.


      We would expect, that each filter is loaded from its own WAR and not from the first WAR that registrate it. In jboss 4.2.3 and I think in jboss 5 everything was fine – so why doesn’t this work in jboss7? And what could we do to fix it? Or is this a bug?


      Our Application is very big so I created a very small ear to reproduce the problem.

      Just deploy it and check both of this contexts:



      In your console you should then see, that the filter is only loaded from the first WAR.




        • 1. Re: problems with filters in jboss 7
          swoeste Newbie

          I've made some further investigations at the weekend. If i modify the application from the attachment above, so that i can delpoy it with jboss 4, the filter is loaded from and for the WAR that use it.


          In JBoss 7 this is different, both filters are loaded:

          [Loaded de.zeb.test.SpecialFilter from vfs:/j:/content/SessionHostEAR.ear/SessionHost.war/WEB-INF/lib/SessionFilter-0.0.1-SNAPSHOT.jar]
          [Loaded de.zeb.test.SpecialFilter from vfs:/j:/content/SessionHostEAR.ear/SessionClient.war/WEB-INF/lib/SessionFilter-0.0.1-SNAPSHOT.jar]


          but only the first one that was loaded will be used:

          open http://localhost:8080/SessionHost/OpenSession

          ModuleClassLoader for Module "deployment.SessionHostEAR.ear.SessionHost.war:main" from Service Module Loader

          open http://localhost:8080/SessionClient/ReadSession

          ModuleClassLoader for Module "deployment.SessionHostEAR.ear.SessionHost.war:main" from Service Module Loader


          If i change the order of modules in the application.xml so that the SessionClient.war is the first one then the lines above look like this:

          ModuleClassLoader for Module "deployment.SessionHostEAR.ear.SessionClient.war:main" from Service Module Loader


          I am beginning to think that this is not the correct behavior ...




          (still searching for some help)