12 Replies Latest reply on Oct 1, 2012 10:52 AM by davidr4w

    Help getting more Info about a error regarding a listener class when deploying a WAR.

    davidr4w

      When deploying an ear that contains a war I am getting the following error.

       

       

      15:23:11,496 ERROR [org.apache.catalina.core.StandardContext] (MSC service thread 1-8) Error listenerStart

      15:23:11,496 ERROR [org.apache.catalina.core.StandardContext] (MSC service thread 1-8) Context [/CunaAdvised] startup failed due to previous errors

      15:23:11,512 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC000001: Failed to start service jboss.web.deployment.default-host./CunaAdvised: org.jboss.msc.service.StartException in service jboss.web.deployment.default-host./CunaAdvised: JBAS018040: Failed to start context

          at org.jboss.as.web.deployment.WebDeploymentService.start(WebDeploymentService.java:95)

          at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA-redhat-1.jar:1.0.2.GA-redhat-1]

          at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA-redhat-1.jar:1.0.2.GA-redhat-1]

          at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [rt.jar:1.7.0_07]

          at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [rt.jar:1.7.0_07]

          at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_07]

       

      The only listener defined in the WAR is as follows

       

      <listener>
      <display-name>Spring Context Loader</display-name>
      <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
      </listener>

       

      And I have the latest release versions of Spring included in the WAR.

       

      Can anyone suggest any changes I can make to get more information out into the log regarding this error, as what I have above is all that is currently showing.

       

      Thanks in advance

       

      David

        • 1. Re: Help getting more Info about a error regarding a listener class when deploying a WAR.
          sfcoy

          Please attach the entire server.log. I'd expect to see something earlier in it that may be useful.

           

          Also, please show the versions of everything in your environment.

          • 2. Re: Help getting more Info about a error regarding a listener class when deploying a WAR.
            davidr4w

            Hi

             

            I have attached the full server and boot log files, as well as a full copy of the web.xml file.

             

            The version of spring being used is 3.1.2.RELEASE.

            Java is the 32 bit version 1.7.0 07.

            Jboss is version EAP 6.0 running in domain mode.

             

            The deployment is done using the command line jboss-cli : deploy CunaAdvised.ear --server-groups=main-server-group

             

            Regards

             

            David

            • 3. Re: Help getting more Info about a error regarding a listener class when deploying a WAR.
              sfcoy

              I can see a few JNDI names that look very fishy:

               

              {quote}16:16:51,525 INFO  [org.jboss.as.mail.extension] (MSC service thread 1-16) JBAS015400: Bound mail session [java:/comp/env/mail/CunaAdvised/FPP/MailSession]

              16:16:51,526 INFO  [org.jboss.as.mail.extension] (MSC service thread 1-15) JBAS015400: Bound mail session [java:/comp/env/mail/CunaAdvised/MailSession]

              ...

              16:16:51,532 INFO  [org.jboss.as.mail.extension] (MSC service thread 1-1) JBAS015400: Bound mail session [java:/comp/env/mail/CunaAdvised/MPP/MailSession]

              ...

              16:16:52,388 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-3) JBAS010400: Bound data source [java:/comp/env/jdbc/CunaAdvisedDB]

              16:16:52,398 INFO  [org.jboss.as.deployment.connector] (MSC service thread 1-14) JBAS010406: Registered connection factory java:/comp/env/jca/CunaAdvised/ldap/ldapServer

              ...

              16:16:52,418 INFO  [org.jboss.as.deployment.connector] (MSC service thread 1-4) JBAS010401: Bound JCA ConnectionFactory [java:/comp/env/jca/CunaAdvised/ldap/ldapServer]

              ...

              etc

              {quote}

               

              These are all almost JNDI environment naming context (ENC) names. Normally, these begin with "java:comp/env/...".

               

              ENC names are directly linked to all of the ejb-ref and resource-ref elements in your web.xml.

               

              Where you have:

               

              {code:xml}<res-ref-name>jdbc/CunaAdvisedDB</res-ref-name>{code}

              your application would be performing a JNDI lookup:

               

              {code:java}Context initialContext = new InitialContext();

              DataSource ds = (DataSource)initialContext.lookup("java:comp/env/jdbc/CunaAdvisedDB");

              {code}

               

              In order to support this correctly, you need a  jboss-web.xml file that maps "jdbc/CunaAdvisedDB" to the actual JDBC DataSource resource that you have configured in the server:

               

              {code:xml}

              <jboss-web>

                   ...

                  <resource-ref>

                      <res-ref-name>jdbc/CunaAdvisedDB</res-ref-name>

                      <jndi-name>java:jboss/CunaAdvisedDB</jndi-name>

                  </resource-ref>

                   ...

              </jboss-web>

              {code}

               

              You have named yours "java:/comp/env/jdbc/CunaAdvisedDB" rather than the "java:jboss/CunaAdvisedDB" that I used above.

               

              This mechanism exists so that JNDI lookups in java can be hard coded and then mapped to any compatible physical server resource in a deployment descriptor.

               

              So, I think you have JNDI resource mapping issues. None of your EJBs were deployed either, suggesting similar issues there. The mapping file for ejb-jar files is jboss-ejb3.xml. The schema for this can be found in the docs/schema directory of your server distribution. Somewhat mysteriously*, the schema for jboss-web.xml is not provided, however you can find it in JBoss 5/6 distributions.

               

              Which server implementation are you porting this from?

               

               

              *this mystery has been resolved in the source trunk so it will be fixed in 7.2 and presumably some EAP release soon.

              • 4. Re: Help getting more Info about a error regarding a listener class when deploying a WAR.
                davidr4w

                Hi

                 

                Yes there is a jboss-web.xml file please see attached with all the correct mapping.

                 

                The application is currently running on IBM Websphere 7 and is being ported acress.

                 

                All the EJB's within the ear also have there own jboss.ejb.xml, an example of which is attached. if I remove the web module from the attached application.xml file then the ear is deployed.

                 

                 

                Regards

                 

                David

                • 5. Re: Help getting more Info about a error regarding a listener class when deploying a WAR.
                  davidr4w

                  Hi

                   

                  I have been doing some further investigation and have found the following.

                   

                  The following code is taken from the class org.apache.catalina.core.StandardContext which is part of the org.jboss.as.web module.

                   

                      /**
                       * Configure the set of instantiated application event listeners
                       * for this Context.  Return <code>true</code> if all listeners wre
                       * initialized successfully, or <code>false</code> otherwise.
                       */
                      public boolean listenerStart() {
                  
                          if (log.isDebugEnabled())
                              log.debug("Configuring application event listeners");
                  
                          // Instantiate the required listeners
                          String listeners[] = findApplicationListeners();
                          Object results[] = new Object[listeners.length];
                          boolean ok = true;
                          for (int i = 0; i < results.length; i++) {
                              if (getLogger().isDebugEnabled())
                                  getLogger().debug(" Configuring event listener class '" +
                                      listeners[i] + "'");
                              try {
                                  results[i] = instanceManager.newInstance(listeners[i]);
                              } catch (Throwable t) {
                                  t = ExceptionUtils.unwrapInvocationTargetException(t);
                                  ExceptionUtils.handleThrowable(t);
                                  getLogger().error
                                      (sm.getString("standardContext.applicationListener",
                                                    listeners[i]), t);
                                  ok = false;
                              }
                          }
                          if (!ok) {
                              getLogger().error(sm.getString("standardContext.applicationSkipped"));
                              return (false);
                          }
                  
                          // Sort listeners in two arrays
                          ArrayList<Object> eventListeners = new ArrayList<Object>();
                          ArrayList<Object> lifecycleListeners = new ArrayList<Object>();
                          for (int i = 0; i < results.length; i++) {
                              if ((results[i] instanceof ServletContextAttributeListener)
                                  || (results[i] instanceof ServletRequestAttributeListener)
                                  || (results[i] instanceof ServletRequestListener)
                                  || (results[i] instanceof HttpSessionAttributeListener)) {
                                  eventListeners.add(results[i]);
                              }
                              if ((results[i] instanceof ServletContextListener)
                                  || (results[i] instanceof HttpSessionListener)) {
                                  lifecycleListeners.add(results[i]);
                              }
                          }
                  
                          //Listeners may have been added by ServletContextInitializers.  Put them after the ones we know about.
                          for (Object eventListener: getApplicationEventListeners()) {
                              eventListeners.add(eventListener);
                          }
                          setApplicationEventListeners(eventListeners.toArray());
                          for (Object lifecycleListener: getApplicationLifecycleListeners()) {
                              lifecycleListeners.add(lifecycleListener);
                          }
                          setApplicationLifecycleListeners(lifecycleListeners.toArray());
                  
                          // Send application start events
                  
                          if (getLogger().isDebugEnabled())
                              getLogger().debug("Sending application start events");
                  
                          // Ensure context is not null
                          getServletContext();
                          context.setNewServletContextListenerAllowed(false);
                  
                          Object instances[] = getApplicationLifecycleListeners();
                          if (instances == null)
                              return (ok);
                          ServletContextEvent event =
                            new ServletContextEvent(getServletContext());
                          for (int i = 0; i < instances.length; i++) {
                              if (instances[i] == null)
                                  continue;
                              if (!(instances[i] instanceof ServletContextListener))
                                  continue;
                              ServletContextListener listener =
                                  (ServletContextListener) instances[i];
                              try {
                                  fireContainerEvent("beforeContextInitialized", listener);
                                  listener.contextInitialized(event);
                                  fireContainerEvent("afterContextInitialized", listener);
                              } catch (Throwable t) {
                                  ExceptionUtils.handleThrowable(t);
                                  fireContainerEvent("afterContextInitialized", listener);
                                  getLogger().error
                                      (sm.getString("standardContext.listenerStart",
                                                    instances[i].getClass().getName()), t);
                                  ok = false;
                              }
                          }
                          return (ok);
                  
                      }
                  

                   

                  It shows the process of starting the listeners defined in the web.xml file. I noticed that information is being logged in two ways one is by using a class variable called log defined as follows

                   

                  private static final Log log = LogFactory.getLog(StandardContext.class);
                  

                   

                  the other is a call to the method getLogger which is implemented in the class org.apache.catalina.core.ContainerBase which StandardContext extends. What I am seeing is that all logging using the class variable log are showing up in the server.log file when I set the logging level to DEBUG, but the calls to getLogger are not coming out in the server.log file.

                   

                  So for example the line “15:17:43,851 DEBUG [org.apache.catalina.core.StandardContext] (MSC service thread 1-13) Processing standard container startup” shows up in the server.log file generated on entry to the method but there is no logging showing up for the debug line "Configuring event listener class" which is part of the first for loop.

                   

                  I believe that my deployment issue is probably ether a ClassNotFoundException or ClassDefNotFoundException, or some other classloader issue, but as the exception is not being logged I have no way to track it down for sure as the stack trace in the catch block uses a call to getLogger and therefore is never logged to the log file.

                   

                  Is this an error with my logging config and if is what do I need to do to correct it, or is it an error with the logging implementation in which case what do I need to do to fix it, is it just a case of replacing getLogger calls with the class variable log and then adding this updated class to my server.

                   

                  The following is the config in JBoss for logging and I have also attached the file logging.properties from the configuration directory on the server.

                   

                              <subsystem xmlns="urn:jboss:domain:logging:1.1">
                                  <console-handler name="CONSOLE">
                                      <level name="DEBUG"/>
                                      <formatter>
                                          <pattern-formatter pattern="%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n"/>
                                      </formatter>
                                  </console-handler>
                                  <periodic-rotating-file-handler name="FILE">
                                      <level name="DEBUG"/>
                                      <formatter>
                                          <pattern-formatter pattern="%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n"/>
                                      </formatter>
                                      <file relative-to="jboss.server.log.dir" path="server.log"/>
                                      <suffix value=".yyyy-MM-dd"/>
                                      <append value="true"/>
                                  </periodic-rotating-file-handler>
                                  <logger category="com.arjuna">
                                      <level name="WARN"/>
                                  </logger>
                                  <logger category="org.apache.tomcat.util.modeler">
                                      <level name="WARN"/>
                                  </logger>
                                  <logger category="sun.rmi">
                                      <level name="WARN"/>
                                  </logger>
                                  <logger category="jacorb">
                                      <level name="WARN"/>
                                  </logger>
                                  <logger category="jacorb.config">
                                      <level name="ERROR"/>
                                  </logger>
                                  <logger category="org.hornetq">
                                      <level name="INFO"/>
                                  </logger>
                                  <logger category="org.jboss.modcluster.ModClusterService">
                                      <level name="INFO"/>
                                  </logger>
                                  <root-logger>
                                      <level name="DEBUG"/>
                                      <handlers>
                                          <handler name="CONSOLE"/>
                                          <handler name="FILE"/>
                                      </handlers>
                                  </root-logger>
                              </subsystem>
                  

                   

                   

                  Regards

                   

                  David.

                  • 6. Re: Help getting more Info about a error regarding a listener class when deploying a WAR.
                    sfcoy

                    How have you configured these?

                     

                    {code:xml}

                         ...

                            <jndi-name>java:/comp/env/url/CunaAdvised/LogConfig</jndi-name>

                         ...

                            <jndi-name>java:/comp/env/url/server/genResourcesSrc</jndi-name>

                         ...

                            <jndi-name>java:/comp/env/url/CunaAdvised/DataExtract/DataStoreRoot</jndi-name>

                         ...

                           <jndi-name>java:/comp/env/url/CunaAdvised/AFDWebService</jndi-name>

                         ...

                    {code}

                    • 7. Re: Help getting more Info about a error regarding a listener class when deploying a WAR.
                      sfcoy

                      Which version of Spring Framework are you using? Versions in the range [2.5, 3.0.2] are completely incompatible with JBoss 5 thru 7.

                      • 8. Re: Help getting more Info about a error regarding a listener class when deploying a WAR.
                        davidr4w

                        In answer to your two question yes I have configured the resources you mentioned by creating a new module that has a custom ObjectFactory implementation and is configured as follows

                         

                        <object-factory name="java:/comp/env/url/CunaAdvised/LogConfig" module="co.uk.iquo.URLObjectFactory" class="co.uk.iquo.cunamutual.advisedsales.components.urlobjectfactory.URLObjectFactory"/>
                        

                         

                        As for the version of Spring being used it is version 3.1.2.RELEASE

                         

                        Regards

                         

                        David.

                        • 9. Re: Help getting more Info about a error regarding a listener class when deploying a WAR.
                          zenzei2k

                          Hi David,

                           

                          I'm having the same issue in Jboss 7.1.2.Final and I also suppose is some ClassNotFoundException. Do you manage to get the full log from StandardContext to discover the problem?

                           

                          Thanks and regards

                          • 10. Re: Help getting more Info about a error regarding a listener class when deploying a WAR.
                            davidr4w

                            Hi Nico

                             

                            No so far I have not been able to find out why the logging information from StandardContext is not showing up in the log, The more I look into it the more I suspect is maybe something to do with the logging Manager, reading info from the Tomcat website I have dicovered that the category name used when calling getLogger is as follows

                             

                            org.apache.catalina.core.ContainerBase.[${engine}].[${host}].[${context}]
                            

                             

                            where engine, host and context are all configured at runtime. This is not a convetional category name which normally is just the fully qualified class name.

                             

                            If I am right, which at the moment I am not 100% sure that I am, then I need to make some change in the logging framework to resolve the problem which I have just started to look into.

                             

                            Regards

                             

                            David

                            • 11. Re: Help getting more Info about a error regarding a listener class when deploying a WAR.
                              zenzei2k

                              David, I don't know if would help you, but in my case the logging problem was related to a log4j.properties inside one of the jars included in the lib directory of the war. It seems that this file was processed by the jboss deployer and conflict with the logging subsytems configuration.

                               

                              After removing the log4j file, logging lines start to appear in server.log.

                              1 of 1 people found this helpful
                              • 12. Re: Help getting more Info about a error regarding a listener class when deploying a WAR.
                                davidr4w

                                Hi Nico

                                 

                                Thanks for the pointer, turns out had the same issue there was a log4j.properties file in the war which looks like was messing up the logging for some reason.

                                 

                                Thanks

                                 

                                David