[jbossws-issues] [JBoss JIRA] Updated: (JBWS-3222) Resuscitate JBossWS command line tools on AS7

[Richard Opalka (JIRA)]

     [ https://issues.jboss.org/browse/JBWS-3222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

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.


> Resuscitate JBossWS command line tools on AS7
> ---------------------------------------------
>
>                 Key: JBWS-3222
>                 URL: https://issues.jboss.org/browse/JBWS-3222
>             Project: JBoss Web Services
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: jbossws-cxf, jbossws-native
>            Reporter: Alessio Soldano
>            Assignee: Richard Opalka
>             Fix For: jbossws-native-4.0,  jbossws-cxf-4.0
>
>
> ---
> 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