Uploaded image for project: 'JBoss Web Services'
  1. JBoss Web Services
  2. JBWS-3824

"Input line is too long" when running wsprovide in fork mode on Windows

XMLWordPrintable

      When running the tools in fork mode on Windows OS, we can end up building a command line which is too long.
      We should prevent this by using a pathing jar solution, similarly to what Surefire plugin does (a jar with manifest pointing to the actual dependency jars).

            [JBWS-3824] "Input line is too long" when running wsprovide in fork mode on Windows

            Alessio Soldano added a comment -

            Actually, I went ahead and did as you wrote in last comment, thanks.
            This should now be fixed; I'll have someone with Windows test this.

            Alessio Soldano added a comment - Actually, I went ahead and did as you wrote in last comment, thanks. This should now be fixed; I'll have someone with Windows test this.

            Alessio Soldano added a comment -

            Yes, please

            Alessio Soldano added a comment - Yes, please

            r searls added a comment -

            Assuming no other code outside this archive is using UrlUtils, it can be removed, along with
            the following code replacement.

            Do you want me to check-in the code changes?

            — src/main/java/org/jboss/ws/plugins/tools/AbstractToolsMojo.java (revision 19440)
            +++ src/main/java/org/jboss/ws/plugins/tools/AbstractToolsMojo.java (working copy)
            @@ -200,7 +200,8 @@
            for ( String el : classPath )

            { // NOTE: if File points to a directory, this entry MUST end in '/'. - cp += UrlUtils.getURL(new File(el)).toExternalForm() + " "; + File elFile = new File(el); + cp += elFile.toURI().toURL().toExternalForm() + " "; }

            r searls added a comment - Assuming no other code outside this archive is using UrlUtils, it can be removed, along with the following code replacement. Do you want me to check-in the code changes? — src/main/java/org/jboss/ws/plugins/tools/AbstractToolsMojo.java (revision 19440) +++ src/main/java/org/jboss/ws/plugins/tools/AbstractToolsMojo.java (working copy) @@ -200,7 +200,8 @@ for ( String el : classPath ) { // NOTE: if File points to a directory, this entry MUST end in '/'. - cp += UrlUtils.getURL(new File(el)).toExternalForm() + " "; + File elFile = new File(el); + cp += elFile.toURI().toURL().toExternalForm() + " "; }

            Alessio Soldano added a comment -

            I've reviewed the code a bit, fixed few minor things and have a question: given we do not run on JDK 1.4 or lesser (actually, JDK 1.7+ is required), can you confirm we still need the code in the UrlUtils class you added for this jira? Perhaps that class can be simplified under the JDK 1.7 use assumption?

            Alessio Soldano added a comment - I've reviewed the code a bit, fixed few minor things and have a question: given we do not run on JDK 1.4 or lesser (actually, JDK 1.7+ is required), can you confirm we still need the code in the UrlUtils class you added for this jira? Perhaps that class can be simplified under the JDK 1.7 use assumption?

            r searls added a comment -

            Code added to generate manifest-only jar file for both wsprovide and wsconsume.
            Subversion: Committed revision 19436.
            repo: https://svn.jboss.org/repos/jbossws/projects/plugins/maven/jaxws-tools/trunk

            r searls added a comment - Code added to generate manifest-only jar file for both wsprovide and wsconsume. Subversion: Committed revision 19436. repo: https://svn.jboss.org/repos/jbossws/projects/plugins/maven/jaxws-tools/trunk

            Alessio Soldano added a comment -

            Right, that's it. Yes, the "Manifest-Only Jar" is whatwe should default to, I'm fine even without the system property option.

            Alessio Soldano added a comment - Right, that's it. Yes, the "Manifest-Only Jar" is whatwe should default to, I'm fine even without the system property option.

            r searls added a comment -

            I found this [1] description of what SureFire is doing with, a pathing jar solution, See section, "Manifest-Only Jar". SureFire provides a configuration property, useSystemClassLoader,
            for enabling and disabling this. Do you want a similar option provided in our plugin as well?

            [1] http://docs.codehaus.org/display/MAVENUSER/Classloading+and+Forking+under+Maven+Surefire

            So then the wsprovide cmd line we would generate would look something like this
            java2ws -s /home/rsearls/projects/jbws3824/target/wsprovide/java
            -classdir /home/rsearls/projects/jbws3824/target/classes
            -d /home/rsearls/projects/jbws3824/target/wsprovide/resources
            -verbose -wsdl
            -cp SOME.jar
            -wrapperbean -createxsdimports org.jboss.test.ws.plugins.tools.wsprovide.TestEndpoint

            r searls added a comment - I found this [1] description of what SureFire is doing with, a pathing jar solution, See section, "Manifest-Only Jar". SureFire provides a configuration property, useSystemClassLoader, for enabling and disabling this. Do you want a similar option provided in our plugin as well? [1] http://docs.codehaus.org/display/MAVENUSER/Classloading+and+Forking+under+Maven+Surefire So then the wsprovide cmd line we would generate would look something like this java2ws -s /home/rsearls/projects/jbws3824/target/wsprovide/java -classdir /home/rsearls/projects/jbws3824/target/classes -d /home/rsearls/projects/jbws3824/target/wsprovide/resources -verbose -wsdl -cp SOME.jar -wrapperbean -createxsdimports org.jboss.test.ws.plugins.tools.wsprovide.TestEndpoint

            Alessio Soldano added a comment -

            Still, if you want to work on this, go ahead. We can ask someone with a Windows box to test the implementation. What I'd expect is basically the same solution used by Surefire plugin, which is the same regardless of the OS in use.

            Alessio Soldano added a comment - Still, if you want to work on this, go ahead. We can ask someone with a Windows box to test the implementation. What I'd expect is basically the same solution used by Surefire plugin, which is the same regardless of the OS in use.

            r searls added a comment -

            I don't have a Windows machine to test and debug against.

            r searls added a comment - I don't have a Windows machine to test and debug against.

              rsearls r searls
              rhn-support-asoldano Alessio Soldano
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Created:
                Updated:
                Resolved: