[ https://issues.jboss.org/browse/JBWS-3222?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated JBWS-3222: ---------------------------------- Summary: Test failures due to WS scripts currently unavailable on AS7 (was: Test failures due to WS scripts currently available on AS7) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBWS-3222?page=com.atlassian.jira.plugin.... ] Richard Opalka updated JBWS-3222: --------------------------------- Description: --- Command line tools decisions: --- Since JBossAS 7 there are just two JBossWS command line tools provided: - wsprovide.sh(.bat) - wsconsume.sh(.bat) We decided to don't provide wsrunclient.sh(.bat) & wstools.sh(.bat) anymore. --- Command line tools architecture: --- Both wsprovide.sh(.bat) & wsconsume.sh(.bat) are taking advantages of jboss modules modular system. The main benefit here is low memory footprint. And how these tools work? We defined - org.jboss.ws.tools.wsconsume - org.jboss.ws.tools.wsprovide modules that are defining Class to be used for tool instantiation. These command line impl. classes are loading org.jboss.as.webservices.server.integration JBoss module internally and are associating it with TCCL. Then tools are executed. --- Integration specialities --- There are also some hidden classpath tricks there: ad1) Both CXF and Native are using Javac compiler internally and this compiler is looking for java.endorsed.dirs property before execution. Because of this we needed to add the following section to both wsconsume.sh(.bat) & wsprovide.sh(.bat): -Djava.endorsed.dirs=$JBOSS_HOME/modules/com/sun/xml/bin/main:$JBOSS_HOME/modules/javax/xml/ws/api/main ad2) Another integration trick was to include $JAVA_HOME/lib/tools.jar on the wsconsume.sh(.bat) classpath and to define com.sun.tools.javac module in Native. This is because Native wsconsume tool is using javac from Java's tools.jar library internally, which is not available in default "system" module. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBWS-3222?page=com.atlassian.jira.plugin.... ] Richard Opalka updated JBWS-3222: --------------------------------- Description: --- Command line tools decisions: --- Since JBossAS 7 there are just two JBossWS command line tools provided: - wsprovide.sh(.bat) - wsconsume.sh(.bat) We decided to don't provide wsrunclient.sh(.bat) & wstools.sh(.bat) anymore. --- Command line tools architecture: --- Both wsprovide.sh(.bat) & wsconsume.sh(.bat) are taking advantages of jboss modules modular system. The main benefit here is low memory footprint. And how these tools work? We defined - org.jboss.ws.tools.wsconsume - org.jboss.ws.tools.wsprovide modules that are defining Class to be used for tool instantiation. These command line impl. classes are loading org.jboss.as.webservices.server.integration JBoss module internally and are associating it with TCCL. Then tools are executed. --- Integration specialities --- There are also some hidden classpath tricks there: ad1) Both CXF and Native are using Javac compiler internally and this compiler is looking for java.endorsed.dirs property before execution. Because of this we needed to add the following section to both wsconsume.sh(.bat) & wsprovide.sh(.bat): -Djava.endorsed.dirs=$JBOSS_HOME/modules/com/sun/xml/bin/main:$JBOSS_HOME/modules/javax/xml/ws/api/main ad2) Another integration trick was to include $JAVA_HOME/lib/tools.jar on the wsconsume.sh(.bat) classpath and to define com.sun.tools.javac module in Native. This is because Native wsconsume tool is using javac from Java's tools.jar library internally, which is not available in default "system" module. was: --- Command line tools decisions: --- Since JBossAS 7 there are just two JBossWS command line tools provided: - wsprovide.sh(.bat) - wsconsume.sh(.bat) We decided to don't provide wsrunclient.sh(.bat) & wstools.sh(.bat) anymore. --- Command line tools architecture: --- Both wsprovide.sh(.bat) & wsconsume.sh(.bat) are taking advantages of jboss modules modular system. The main benefit here is low memory footprint. And how these tools work? We defined - org.jboss.ws.tools.wsconsume - org.jboss.ws.tools.wsprovide modules that are defining Class to be used for tool instantiation. These command line impl. classes are loading org.jboss.as.webservices.server.integration JBoss module internally and are associating it with TCCL. Then tools are executed. --- Integration specialities --- There are also some hidden classpath tricks there: ad1) Both CXF and Native are using Javac compiler internally and this compiler is looking for java.endorsed.dirs property before execution. Because of this we needed to add the following section to both wsconsume.sh(.bat) & wsprovide.sh(.bat): -Djava.endorsed.dirs=$JBOSS_HOME/modules/com/sun/xml/bin/main:$JBOSS_HOME/modules/javax/xml/ws/api/main ad2) Another integration trick was to include $JAVA_HOME/lib/tools.jar on the wsconsume.sh(.bat) classpath and to define com.sun.tools.javac module in Native. This is because Native wsconsume tool is using javac from Java's tools.jar library internally, which is not available in default "system" module. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBWS-3222?page=com.atlassian.jira.plugin.... ] Richard Opalka updated JBWS-3222: --------------------------------- Description: --- Command line tools decisions: --- Since JBossAS 7 there are just two JBossWS command line tools provided: - wsprovide.sh(.bat) - wsconsume.sh(.bat) We decided to don't provide wsrunclient.sh(.bat) & wstools.sh(.bat) anymore. --- Command line tools architecture: --- Both wsprovide.sh(.bat) & wsconsume.sh(.bat) are taking advantages of jboss modules modular system. The main benefit here is low memory footprint. And how these tools work? We defined - org.jboss.ws.tools.wsconsume - org.jboss.ws.tools.wsprovide modules that are defining Class to be used for tool instantiation. These command line tools are using the defining class loader and they're associating it with TCCL. Then tools are executed using that TCCL. --- Integration specialities --- There are also some hidden classpath tricks there: ad1) Both CXF and Native are using Javac compiler internally and this compiler is looking for java.endorsed.dirs property before execution. Because of this we needed to add the following section to both wsconsume.sh(.bat) & wsprovide.sh(.bat): -Djava.endorsed.dirs=$JBOSS_HOME/modules/com/sun/xml/bin/main:$JBOSS_HOME/modules/javax/xml/ws/api/main ad2) Another integration trick was to include $JAVA_HOME/lib/tools.jar on the wsconsume.sh(.bat) classpath and to define com.sun.tools.javac module in Native. This is because Native wsconsume tool is using javac from Java's tools.jar library internally, which is not available in default "system" module. was: --- Command line tools decisions: --- Since JBossAS 7 there are just two JBossWS command line tools provided: - wsprovide.sh(.bat) - wsconsume.sh(.bat) We decided to don't provide wsrunclient.sh(.bat) & wstools.sh(.bat) anymore. --- Command line tools architecture: --- Both wsprovide.sh(.bat) & wsconsume.sh(.bat) are taking advantages of jboss modules modular system. The main benefit here is low memory footprint. And how these tools work? We defined - org.jboss.ws.tools.wsconsume - org.jboss.ws.tools.wsprovide modules that are defining Class to be used for tool instantiation. --- Integration specialities --- There are also some hidden classpath tricks there: ad1) Both CXF and Native are using Javac compiler internally and this compiler is looking for java.endorsed.dirs property before execution. Because of this we needed to add the following section to both wsconsume.sh(.bat) & wsprovide.sh(.bat): -Djava.endorsed.dirs=$JBOSS_HOME/modules/com/sun/xml/bin/main:$JBOSS_HOME/modules/javax/xml/ws/api/main ad2) Another integration trick was to include $JAVA_HOME/lib/tools.jar on the wsconsume.sh(.bat) classpath and to define com.sun.tools.javac module in Native. This is because Native wsconsume tool is using javac from Java's tools.jar library internally, which is not available in default "system" module. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira