—
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.