5 Replies Latest reply on Dec 17, 2001 7:34 PM by adrian.brock

    SOAP weirdness on 3.0.0

    ftg314159

      I'm awfully confused.

      I captured a CVS image of 3.0.0 on November 19 and built a system which I incorporated into a J2EE testbed environment for my developers. At that time, one of the tests I did was to copy the soap-2.2 soap.war to the deploy directory, bring up JBoss, and verify that I could get to the servlet and get the "I don't support GET, use POST" error. I tried this under Win98 and the IBM 1.3 JDK and Linux under Sun 1.3.1_01. It worked fine.

      One of my developers tried this under Win98 with the Sun 1.3.1_01 JDK, and got an exception thrown:

      ==============================================
      [2001-12-08 17:03:46,138,AutoDeployer,INFO] Auto deploy of file:/C:/jboss-3.0.0alpha/deploy/soap.war
      [2001-12-08 17:03:46,138,J2eeDeployer#Default,INFO] Deploy J2EE application: file:/C:/jboss-3.0.0alpha/deploy/soap.war
      [2001-12-08 17:03:46,218,J2eeDeployer#Default,INFO] Create application soap.war
      [2001-12-08 17:03:46,218,J2eeDeployer#Default,INFO] inflate and install WEB module soap.war
      [2001-12-08 17:03:47,760,ContainerFactory,INFO] Deploying:file:/C:/jboss-3.0.0alpha/deploy/Default/soap.war
      [2001-12-08 17:03:47,790,ContainerFactory,INFO] Deployed application: file:/C:/jboss-3.0.0alpha/deploy/Default/soap.war
      [2001-12-08 17:03:47,790,J2eeDeployer#Default,INFO] Starting module soap.war
      [2001-12-08 17:03:48,000,Default,INFO] Did not find the UCL resource org/mortbay/http/mime_en.properties
      [2001-12-08 17:03:48,090,Default,INFO] Did not find the UCL resource org/mortbay/http/mime_en_US.properties
      [2001-12-08 17:03:48,251,Default,INFO] Did not find the UCL resource org/mortbay/http/encoding_en.properties
      [2001-12-08 17:03:48,351,Default,INFO] Did not find the UCL resource org/mortbay/http/encoding_en_US.properties
      [2001-12-08 17:03:48,361,Jetty,WARN] WARNING: Unsuitable contextPathSpec /soap, Assuming: /soap/*
      [2001-12-08 17:03:48,631,Default,INFO] Did not find the UCL resource org/mortbay/jetty/jmx/mbean_en_US.properties
      [2001-12-08 17:03:48,802,AutoDeployer,DEBUG] Received notification of mbean Jetty:Jetty=0,context=/soap,WebApplicationContext=0's deployment.
      [2001-12-08 17:03:48,802,Jetty,INFO] Registered Jetty:Jetty=0,context=/soap,WebApplicationContext=0
      [2001-12-08 17:03:48,842,Jetty,INFO] resolving -//Sun Microsystems, Inc.//DTD Web Application 2.2//EN : http://java.sun.com/j2ee/dtds/web-app_2_2.dtd
      [2001-12-08 17:03:48,852,Jetty,INFO] resolved -//Sun Microsystems, Inc.//DTD Web Application 2.2//EN : jar:file:/C:/jboss-3.0.0alpha/tmp/deploy/ServiceDeployer/copydeploy.39.org.mortbay.jetty.jar!/org/mortbay/jetty/servlet/web.dtd
      [2001-12-08 17:03:48,892,Jetty,INFO] no jboss-web.xml found
      [2001-12-08 17:03:49,272,WebContainer,DEBUG] AbstractWebContainer.parseWebAppDescriptors, Begin
      [2001-12-08 17:03:49,292,WebContainer,DEBUG] addEnvEntries
      [2001-12-08 17:03:49,292,WebContainer,DEBUG] linkResourceRefs
      [2001-12-08 17:03:49,292,WebContainer,DEBUG] linkEjbRefs
      [2001-12-08 17:03:49,292,WebContainer,DEBUG] linkSecurityDomain
      [2001-12-08 17:03:49,292,WebContainer,DEBUG] Binding security/securityMgr to NullSecurityManager
      [2001-12-08 17:03:49,322,WebContainer,DEBUG] AbstractWebContainer.parseWebAppDescriptors, End
      [2001-12-08 17:03:49,362,Jetty,INFO] +++ Created JBossUserRealm, realmName=null
      [2001-12-08 17:03:49,382,Jetty,INFO] Started SetupHandler in WebApplicationContext[/soap,Apache-SOAP]
      [2001-12-08 17:03:49,382,Jetty,INFO] Started SecurityHandler in WebApplicationContext[/soap,Apache-SOAP]
      [2001-12-08 17:03:49,633,Default,INFO] Did not find the UCL resource javax/servlet/http/LocalStrings_en.properties
      [2001-12-08 17:03:49,743,Default,INFO] Did not find the UCL resource javax/servlet/http/LocalStrings_en_US.properties
      [2001-12-08 17:03:49,753,Jetty,INFO] JSP: init
      [2001-12-08 17:03:49,973,Default,INFO] Did not find the UCL resource org/apache/jasper/resources/messages_en.properties
      [2001-12-08 17:03:50,083,Default,INFO] Did not find the UCL resource org/apache/jasper/resources/messages_en_US.properties
      [2001-12-08 17:03:50,173,J2eeDeployer#Default,ERROR] Starting soap.war failed!
      javax.management.RuntimeErrorException: Error thrown in operation deploy
      at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1642)
      at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523)
      at org.jboss.deployment.J2eeDeployer.startModules(J2eeDeployer.java:506)
      at org.jboss.deployment.J2eeDeployer.startApplication(J2eeDeployer.java:469)
      at org.jboss.deployment.J2eeDeployer.deploy(J2eeDeployer.java:231)
      at java.lang.reflect.Method.invoke(Native Method)
      at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628)
      at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523)
      at org.jboss.deployment.AutoDeployer.deploy(AutoDeployer.java:633)
      at org.jboss.deployment.AutoDeployer.run(AutoDeployer.java:308)
      at java.lang.Thread.run(Thread.java:484)
      [2001-12-08 17:03:50,244,J2eeDeployer#Default,INFO] Module soap.war is not running
      [2001-12-08 17:03:50,244,J2eeDeployer#Default,INFO] Stopping module soap.war
      [2001-12-08 17:03:50,254,ContainerFactory,INFO] Undeploying:file:/C:/jboss-3.0.0alpha/deploy/Default/soap.war
      [2001-12-08 17:03:50,304,ContainerFactory,INFO] Undeployed application: file:/C:/jboss-3.0.0alpha/deploy/Default/soap.war
      [2001-12-08 17:03:50,324,J2eeDeployer#Default,INFO] Destroying application soap.war
      [2001-12-08 17:03:50,704,J2eeDeployer#Default,INFO] Destroyed
      [2001-12-08 17:03:50,704,AutoDeployer,ERROR] Deployment failed:file:/C:/jboss-3.0.0alpha/deploy/soap.war
      org.jboss.deployment.J2eeDeploymentException: Error while starting soap.war: javax/servlet/http/HttpServlet, Cause: java.lang.NoClassDefFoundError: javax/servlet/http/HttpServlet
      at org.jboss.deployment.J2eeDeployer.startModules(J2eeDeployer.java:549)
      at org.jboss.deployment.J2eeDeployer.startApplication(J2eeDeployer.java:469)
      at org.jboss.deployment.J2eeDeployer.deploy(J2eeDeployer.java:231)
      at java.lang.reflect.Method.invoke(Native Method)
      at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628)
      at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523)
      at org.jboss.deployment.AutoDeployer.deploy(AutoDeployer.java:633)
      at org.jboss.deployment.AutoDeployer.run(AutoDeployer.java:308)
      at java.lang.Thread.run(Thread.java:484)
      ================================================

      I said Ok, let me go test some more. I tried it under Win2000 with the Sun JDK - no problem. I tried under Win98 with the Sun JDK - no problem. I'm now thinking that my developer has gotten some very bad mushrooms.

      However, I notice that under Win98 (but not Win2000) run.bat is giving me three "syntax error" messages at the start which don't seem to impede the server coming up, so I decide to look into it.

      It turns out that this is some sort of bug in the Win98 batch script engine, and that none of the SETs for JAVA_OPTS or JAXP are taking effect. Why, I don't know, unless it has something to do with length or the inclusion of blanks in some of the values. I don't get this under Win2000.

      So, I create a modified run.bat which just hard-codes all of the JAVA_OPTS and JAXP stuff directly on the command line. This works just fine under Win98, and soap.war auto-deploys correctly, as it always has.

      I go back to Win2000 and re-test with the new run.bat, and lo and behold I get the error my developer got. I say "ah, I've found the conditions", blow away the changes and restore my totally virgin jboss-3.0.0alpha directory with the original run.bat, AND I GET THE SAME ERROR. So I say to myself, "self, you've probably done some sort of nasty to the sticky Windows environment variables", and I reboot, and STILL GET THE ERROR.

      I can't figure out what triggers this. I'm working with JBoss code that I built ONCE from the CVS tree and have been using in every environment that did or did not get the error. The error that I couldn't get to happen when it was reported I suddenly can't get NOT to happen under the Win2000 platform which didn't have a whisper of a problem originally.

      Can anyone help here ?

        • 1. Re: SOAP weirdness on 3.0.0

          Sorry to use this old chestnut on you, but have you
          tried updating your CVS.

          I don't know much about the Jetty service, but looking
          at the CVS archive the jetty service-xml was redone on Nov 19 at 15:34 UTC which suggests there was major update.

          jules_gosnell seems to be the maintainer, so he can probably throw some more light on it.

          I imagine SOAP relies heavily the JAXP configuration,
          but I can't see this stopping javax.servlet.jar being
          in the classpath which is what your exception suggests.

          Regards,
          Adrian

          • 2. Re: SOAP weirdness on 3.0.0
            ftg314159

            Thanks for your reply. I'll rebuild the CVS. That would have been my first path of action if it looked like a JBoss bug, but I couldn't get past the fact that it worked on Linux always, and, at first, consistently on Windows, and later consistently NOT on Windows, with no other changes.

            I'm still curious about seeing this with a Java application, but in the words of the sage, "not everthing worth doing is worth doing well". I try refreshing JBoss and see if it goes away.

            • 3. Re: SOAP weirdness on 3.0.0

              Noticed there's a proposed patch to run.bat

              https://sourceforge.net/tracker/index.php?func=detail&aid=481803&group_id=22866&atid=376687

              this might solve your JAXP problems.

              Regards,
              Adrian

              • 4. Re: SOAP weirdness on 3.0.0
                ftg314159

                I think I've nailed this. The problem appears to be a conflict between the Apache "soap.jar" and other stuff in the JBoss classpath.

                In my initial testing that worked, I *believe* it's because I put soap.jar in the JBoss/lib directory and didn't mess with JBOSS_CLASSPATH. Once I placed soap.jar in JBOSS_CLASSPATH, the error started occurring. If I understand correctly, JBoss picks up everything from its "lib" directory automatically, and probably appends it to the end of the classpath. JBOSS_CLASSPATH gets prepended to the start by run.sh/bat even before run.jar.

                I've verified that, on a Win2000 system with JBOSS_CLASSPATH set to %JBOSS_DIST%\lib\soap.jar, if I have a soap.jar present, I get the error, and if I don't have a soap.jar, I don't.

                So, now the question is, "is this conflict significant ?". In other words, is this a conflict between versions of truly identical classes where the JBoss one will serve SOAP as well, or will I have problems with SOAP down the road because two sets of first cousins named their babies "Sam" ? This is Apache SOAP by the way; I've lost track of the version (it was a binary from November), but if anybody thinks this is corrected by a later version, I'll try that.

                Thanks,
                Frank

                • 5. Re: SOAP weirdness on 3.0.0

                  Hi,

                  I think Marc would probably kill you for setting JBOSS_CLASSPATH :-)

                  The idea behind JBOSS_CLASSPATH is supposed to be
                  that JBoss doesn't use anything from the command line.

                  It has a small number of bootstrap jars. The rest is
                  under JBoss classloader control.

                  The rules are different, it's a sort of a pool of
                  classloaders.
                  Classes from one deployment can access classes from another without having to worry about
                  classloader hierarchies.

                  You probably want to just add soap to lib/ext, lib is really for the core system. Forget about JBOSS_CLASSPATH.

                  There might be a conflict between the servlet api
                  used by Jetty/Tomcat/JBoss and the version included
                  with Soap (if any?) You would have to look at what's in
                  each jar.

                  Regards,
                  Adrian