Jetty
  1. Jetty
  2. JETTY-1429

jetty-maven-plugin depends on jetty-runner which causes problems with IBM JDK

    Details

    • Type: Story Story
    • Status: Resolved Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None
    • Number of attachments :
      0

      Description

      I have such scenario:

      • IBM JDK + WebSphere Client, which must contain JTA classes
      • jetty-maven-plugin 8.0.0.v20110901 with configuration as described in http://docs.codehaus.org/display/MAVENUSER/Maven+and+Integration+Testing
      • WAR being run in Jetty uses javax.jta.UserTransaction
      • problems at runtime, because WebSphere's Client implementation of the above loaded javax.jta.UserTransaction from system class loader and Jetty loaded it from jetty-runner's embedded classes from JTA.

      The problem is either:

      • jetty-runner has embeded classes from it's maven dependencies ("thanks to" maven-dependency-plugin:unpack-dependencies, or
      • (as Jesse McConnell kindly explained) jetty-maven-plugin's dependency on jetty-runner which was added recently.

      IBM's JDK is not for kids, but after several hours everything worked fine, when I've removed javax.transaction.* classes from jetty-runner-8.0.0.v20110901.jar.

      regards
      Grzegorz Grzybek

        Issue Links

          Activity

          Hide
          Joakim Erdfelt added a comment -

          Seems impossible to download the IBM JVM for standard x86 systems.
          Using this as starting point - http://www.ibm.com/developerworks/java/jdk/linux/download.html
          Then when I try to access the JVM's it requires an IBM ID Login, which itself is seemingly impossible to register/create/signup for online.

          Is there another way to obtain the IBM JVM's?

          Show
          Joakim Erdfelt added a comment - Seems impossible to download the IBM JVM for standard x86 systems. Using this as starting point - http://www.ibm.com/developerworks/java/jdk/linux/download.html Then when I try to access the JVM's it requires an IBM ID Login, which itself is seemingly impossible to register/create/signup for online. Is there another way to obtain the IBM JVM's?
          Hide
          Grzegorz Grzybek added a comment -

          I'm afraid not - you have to get your IBM ID. That's IBM
          There are two (at least) registration options. The other is "partner ID", which will allow you to download all IBM Software - e.g. "IBM WebSphere Application Server 7 Network Deployment Supplements CD 1 of 2" which contains what my problem was - "WebSphere Application Client".

          Because there is more politics than technology in the process of getting your own copy of "WebSphere Application Client" (hereinafter referred to as WAC ), here's my deep technological analysis:

          • my POM contains jetty-maven-plugin:run-war execution during pre-integration-test phase
          • Maven is being run with JAVA_HOME set to WAC's JDK (almost standard JDK)
          • MAVEN_OPTS configure java.ext.dirs which extend system class loader with about 400 MB of JARs from WAC - e.g. prehistoric AspectJ, Axis2 in SNAPSHOT version, servlet-api 2.5 and WebSphere specific classes.
          • among these classes are all JavaEE APIs (I had to replace servlet-api and jsp-api with the ones provided by Jetty). The critical are javax.transaction.*
          • WAR is standard WAR which starts Spring Context
          • The critical point during Spring Context's refresh is obtaining "jta/usertransaction" from JNDI using InitialContext configured with WAC specific properties (imagine that - it's not that easy, because WAR's being started in Jetty with "plus" config, which contains it's own JNDI)
          • the object obtained from remote JNDI is WAC's implementation of javax.transation.UserTransaction.
          • Here the problems begin:
            • object acquired from JNDI's implements javax.transation.UserTransaction loaded by system (java.ext.dirs) class loader
            • Spring has detected org.springframework.transaction.jta.JtaTransactionManager's constructor which takes javax.transation.UserTransaction but loaded by Jetty's classloader from ... jetty-runner jar
            • type mismatch occurs
            • WAR fails to start

          (to make things more complicated, please note, that my WAR not only needs WebSphere's transaction manager from remote JNDI, it also needs Jetty's global datasource using differently parameterized InitialContext).

          So - I've traced down the problem - http://search.maven.org/remotecontent?filepath=org/mortbay/jetty/jetty-runner/8.0.0.v20110901/jetty-runner-8.0.0.v20110901.pom uses maven-dependency-plugin:unpack-dependencies to pack all dependencies into the JAR.

          If only the dependencies were not contained in the JAR and the runner relied on the dependent JAR being present on classpath by means of standard Maven dependency resolution, everything would work - I could just include dependency to jetty-runner in my jetty-maven-plugin with the exclusion of javax.transaction:jta. Now I had to manually remove these classes from jetty-runner JAR in my local Maven repository.

          I hope I've explained my problem quite well

          So - using IBM's JDK is a tiny part of the problem - you would also need: remote WAS, local WAC, remote usertransaction and remote EJBs

          regards
          Grzegorz Grzybek

          Show
          Grzegorz Grzybek added a comment - I'm afraid not - you have to get your IBM ID. That's IBM There are two (at least) registration options. The other is "partner ID", which will allow you to download all IBM Software - e.g. "IBM WebSphere Application Server 7 Network Deployment Supplements CD 1 of 2" which contains what my problem was - "WebSphere Application Client". Because there is more politics than technology in the process of getting your own copy of "WebSphere Application Client" (hereinafter referred to as WAC ), here's my deep technological analysis: my POM contains jetty-maven-plugin:run-war execution during pre-integration-test phase Maven is being run with JAVA_HOME set to WAC's JDK (almost standard JDK) MAVEN_OPTS configure java.ext.dirs which extend system class loader with about 400 MB of JARs from WAC - e.g. prehistoric AspectJ, Axis2 in SNAPSHOT version, servlet-api 2.5 and WebSphere specific classes. among these classes are all JavaEE APIs (I had to replace servlet-api and jsp-api with the ones provided by Jetty). The critical are javax.transaction.* WAR is standard WAR which starts Spring Context The critical point during Spring Context's refresh is obtaining "jta/usertransaction" from JNDI using InitialContext configured with WAC specific properties (imagine that - it's not that easy, because WAR's being started in Jetty with "plus" config, which contains it's own JNDI) the object obtained from remote JNDI is WAC's implementation of javax.transation.UserTransaction . Here the problems begin: object acquired from JNDI's implements javax.transation.UserTransaction loaded by system ( java.ext.dirs ) class loader Spring has detected org.springframework.transaction.jta.JtaTransactionManager 's constructor which takes javax.transation.UserTransaction but loaded by Jetty's classloader from ... jetty-runner jar type mismatch occurs WAR fails to start (to make things more complicated, please note, that my WAR not only needs WebSphere's transaction manager from remote JNDI, it also needs Jetty's global datasource using differently parameterized InitialContext ). So - I've traced down the problem - http://search.maven.org/remotecontent?filepath=org/mortbay/jetty/jetty-runner/8.0.0.v20110901/jetty-runner-8.0.0.v20110901.pom uses maven-dependency-plugin:unpack-dependencies to pack all dependencies into the JAR. If only the dependencies were not contained in the JAR and the runner relied on the dependent JAR being present on classpath by means of standard Maven dependency resolution, everything would work - I could just include dependency to jetty-runner in my jetty-maven-plugin with the exclusion of javax.transaction:jta . Now I had to manually remove these classes from jetty-runner JAR in my local Maven repository. I hope I've explained my problem quite well So - using IBM's JDK is a tiny part of the problem - you would also need: remote WAS, local WAC, remote usertransaction and remote EJBs regards Grzegorz Grzybek
          Jan Bartel made changes -
          Field Original Value New Value
          Assignee Jan Bartel [ janb ]
          Hide
          Jan Bartel added a comment -

          There are a couple things we need to fix here:

          1. the jetty maven plugin should not depend on jetty-runner jar AND other jars directly as the classes are all duplicated
          2. to fix 1., we should not depend on only the jetty-runner jar because it includes all the classes directly inside it, so people cannot then use the plugin <dependency> mechanism to affect the plugin's classpath

          We should be able to write a simple new main class for the forked plugin to use that starts jetty up instead.

          Show
          Jan Bartel added a comment - There are a couple things we need to fix here: 1. the jetty maven plugin should not depend on jetty-runner jar AND other jars directly as the classes are all duplicated 2. to fix 1., we should not depend on only the jetty-runner jar because it includes all the classes directly inside it, so people cannot then use the plugin <dependency> mechanism to affect the plugin's classpath We should be able to write a simple new main class for the forked plugin to use that starts jetty up instead.
          Jan Bartel made changes -
          Link This issue relates to JETTY-991 [ JETTY-991 ]
          Jan Bartel made changes -
          Status Open [ 1 ] In Progress [ 3 ]
          Hide
          Jan Bartel added a comment -

          A new implementation of the JettyRunForkedMojo has been checked in to jetty @ codehaus head.

          Please see the comments on issue JETTY-991 for feedback that we would like to obtain on running jetty in a forked manner.

          thanks
          Jan

          Show
          Jan Bartel added a comment - A new implementation of the JettyRunForkedMojo has been checked in to jetty @ codehaus head. Please see the comments on issue JETTY-991 for feedback that we would like to obtain on running jetty in a forked manner. thanks Jan
          Jan Bartel made changes -
          Status In Progress [ 3 ] Resolved [ 5 ]
          Resolution Fixed [ 1 ]
          Hide
          Grzegorz Grzybek added a comment -

          Thanks for quick response!
          Commit 364fd9b229f24b47167776def4e3727175b21ff8 is all I needed
          I'll look at JETTY-991 now.
          regards
          Grzegorz Grzybek

          Show
          Grzegorz Grzybek added a comment - Thanks for quick response! Commit 364fd9b229f24b47167776def4e3727175b21ff8 is all I needed I'll look at JETTY-991 now. regards Grzegorz Grzybek

            People

            • Assignee:
              Jan Bartel
              Reporter:
              Grzegorz Grzybek
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: