Announcement Announcement Module
No announcement yet.
Anyone using Java 6 & Tomcat 6.0? Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Anyone using Java 6 & Tomcat 6.0?

    I'm thinking of upgrading my Spring web service from Java 5 & Tomcat 5.5 which works fine to Java 6 and Tomcat 6.0. Anyone have that working? Anyone have intractible problems?

    Btw, I *love* Spring-WS. Works great. Thanks for all the great work!

  • #2
    Well, since no one answered my question I tried it myself.

    I upgraded to Tomcat 6.0.13 and Java 1.6.0_02 and Spring-WS 1.0-RC2 and everything runs and tests as before.

    The only problem I've encountered was upgrading from Spring 2.0.6 to 2.1-M2, so I've backed off that upgrade. :o


    • #3
      Arrgh! Compile error under Java 6

      Apparently, my switchover to Java 6 was not clean.

      When I compile my Java 1.5.0_11 + Spring-WS 1.0-rc2-SNAPSHOT or 1.0-rc2 under Java 6.0, I get several deprecation warnings and one error message:

      [wrote C:\cygwin\home\cgeek\svn\testapp\webservices\target\classes\com\nodeless\ws\schema\GetWidgetsResponseType.class]
      [wrote C:\cygwin\home\cgeek\svn\testapp\webservices\target\classes\com\nodeless\ws\schema\GetWidgetsResponse.class]
      C:\cygwin\home\cgeek\svn\testapp\webservices\target\generated-sources\main\java\com\nodeless\ws\schema\impl\runtime\ warning: [deprecation] getProperty(java.lang.String) in javax.xml.bind.Validator has been deprecated
          public Object getProperty( String name )
      C:\cygwin\home\cgeek\svn\testapp\webservices\target\generated-sources\main\java\com\nodeless\ws\schema\impl\runtime\[153,16] [deprecation] setProperty(java.lang.String,java.lang.Object) in javax.xml.bind.Validator has been deprecated
      C:\cygwin\home\cgeek\svn\testapp\webservices\target\generated-sources\main\java\com\nodeless\ws\schema\impl\runtime\[89,19] [deprecation] validateRoot(java.lang.Object) in javax.xml.bind.Validator has been deprecated
      C:\cygwin\home\cgeek\svn\testapp\webservices\target\generated-sources\main\java\com\nodeless\ws\schema\impl\runtime\[98,19] [deprecation] validate(java.lang.Object) in javax.xml.bind.Validator has been deprecated
      C:\cygwin\home\cgeek\svn\testapp\webservices\target\generated-sources\main\java\com\nodeless\ws\schema\impl\runtime\[137,34] [deprecation] getEventHandler() in javax.xml.bind.Validator has been deprecated
      C:\cygwin\home\cgeek\svn\testapp\webservices\target\generated-sources\main\java\com\nodeless\ws\schema\impl\runtime\[141,16] [deprecation] setEventHandler(javax.xml.bind.ValidationEventHandler) in javax.xml.bind.Validator has been deprecated
      could not parse error message: [loading c:\Program Files\Java\jdk1.6.0_02\lib\ct.sym(META-INF/sym/rt.jar/javax/xml/bind/DatatypeConverterInterface.class)]
      [loading c:\Program Files\Java\jdk1.6.0_02\lib\ct.sym(META-INF/sym/rt.jar/java/lang/IllegalArgumentException.class)]
      [wrote C:\cygwin\home\cgeek\svn\testapp\webservices\target\classes\com\nodeless\ws\schema\impl\runtime\ValidatorImpl$EventInterceptor.class]
      [wrote C:\cygwin\home\cgeek\svn\testapp\webservices\target\classes\com\nodeless\ws\schema\impl\runtime\ValidatorImpl.class]
      C:\cygwin\home\cgeek\svn\testapp\webservices\target\generated-sources\main\java\com\nodeless\ws\schema\impl\runtime\ warning: [deprecation] createValidator()in javax.xml.bind.JAXBContext has been deprecated
          public Validator createValidator() throws JAXBException {
      C:\cygwin\home\cgeek\svn\testapp\webservices\target\generated-sources\main\java\com\nodeless\ws\schema\impl\runtime\[119,21] [deprecation] createValidator() in javax.xml.bind.JAXBContext has been deprecated
      Any ideas as to why I get the:

      could not parse error message: [loading c:\Program Files\Java\jdk1.6.0_02\lib\ct.sym(META-INF/sym/rt.jar/javax/xml/bind/DatatypeConverterInterface.class)]
      error message???


      • #4
        Java 6 contains JAXB2, and the oxm module needs JAXB1 to compile. JAXB2 changed some things, including deprecating a lot of methods.

        As far as I know, there is no way to force Java 6 to use JAXB1, so that's why I use Java 5 to build.


        • #5
          Progress report. I deserve hazard pay... ;-)

          I was fiddling around with Java 6 & Tomcat 6 yesterday and actually got my webapp compiled and running. The maven-jaxb-plugin generates its classes without the Blah/BlahImpl interface/implementation pairs that the Ant 'xjc' target had used.

          Once I changed about a dozen of the older style generated schema classes BlahBlahImpl() classes to the newer BlahBlah() classes and I got rid of a couple of com.sun.xml.bind.util.ListImpl usages, my webapp compiled.

          Then, the problem I ran into 2 problems when deploying the webapp.

          The first was that the webapp initialization was exceptioning out with a:
          java.lang.LinkageError: JAXB 2.0 API is being loaded from the bootstrap classloader, but this RI (from jar:file:/C:/Program%20Files/Apache%20Software%20Foundation/Tomcat%206.0/webapps/ZacksTool-ws-1.0-SNAPSHOT/WEB-INF/lib/jaxb-impl-2.1.3.jar!/com/sun/xml/bind/v2/model/impl/ModelBuilder.class) needs 2.1 API. Use the endorsed directory mechanism to place jaxb-api.jar in the bootstrap classloader. (See
          Java 6 uses JAXB 2.0 by default. JAXB happens to be one of the APIs you can override by using 'endorsed directories'. Unfortunately, the Tomcat 6 documentation for handling these endorsed directories seems to be incorrect. As a matter of fact, it looks like they didn't update it from Java 1.5. Anyway, if you're using Tomcat 6 and want to update your jaxb-api library to 2.1, you need to create a $CATALINA_HOME/common/endorsed directory with the jaxb-api.jar file; THAT is the default endorsed directory under Tomcat 6, in spite of the documentation.

          The second problem when deploying was an exception that stated that I was still specifying the 'validating' property of the jaxbMarshaller bean, but in the 2.1 reincarnation there is no such property. So I took it out. I looked through the javadocs, but there doesn't seem to be a replacement property for that.

          Once that was in place, the webapp seems to function just fine. The problem I'm looking into right now is that Flex seems to think that the SOAP responses are not well-formed. So today I'm going to check the responses and see if there is some obvious error. Just looking at it visually right now, the only thing I see in the response that looks peculiar is the additional header:
          Content-Type: Multipart/Related; start-info="text/xml"; type="application/xop+xml"; boundary="----=_Part_12_19188912.1185518595843"
          Transfer-Encoding: chunked
          Date: Fri, 27 Jul 2007 06:43:15 GMT
          Content-Type: application/xop+xml; charset=utf-8; type="text/xml"
          <SOAP-ENV:Envelope xmlns:SOAP-ENV="">
          Hopefully, this is not a hopeless pursuit...


          • #6
            Try setting the mtomEnabled property on the Jaxb2Marshaller to false, that should do the trick. It will be false by default in 1.0 final.


            • #7
              Sweet! Java 6 &amp; Tomcat 6 working!

              Setting the 'mtomEnabled' property to 'false' got it working! With that change to the applicationContext-ws.xml Flex doesn't barf out the Error #1088 exception:
              [RPC Fault faultString="Error #1088: The markup in the document following the root element must be well-formed." faultCode="DecodingError" faultDetail="null"]
              	at mx.rpc.soap::Operation/
              	at mx.rpc::AbstractInvoker/
              	at mx.rpc::Responder/result()
              	at mx.rpc::AsyncRequest/acknowledge()
              	at ::DirectHTTPMessageResponder/completeHandler()
              anymore, now that it receives the response without the MTOM header.

              And here I thought I was going to have to create a potentially long-lived Subversion branch while I worked through this. Whew! I'm ready to commit this code to the trunk after I write a few more tests.

              Arjen, you really know your stuff AND you are always so helpful! Thanks once again for looking at this!