Bug 999223 - wsconsume.sh fails with the default target version - 2.2
wsconsume.sh fails with the default target version - 2.2
Status: CLOSED CURRENTRELEASE
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: Web Services (Show other bugs)
6.1.1
Unspecified Unspecified
unspecified Severity unspecified
: ER3
: ---
Assigned To: Alessio Soldano
Rostislav Svoboda
Russell Dickenson
: Reopened
: 924334 (view as bug list)
Depends On: 1006789
Blocks:
  Show dependency treegraph
 
Reported: 2013-08-20 19:09 EDT by Aleksandar Kostadinov
Modified: 2013-12-15 11:23 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
In previous versions of JBoss EAP, it was found that WSConsume failed to compile JAXWS 2.2 level sources when OpenJDK version 1.6 was used. This has been resolved in this release.
Story Points: ---
Clone Of:
Environment:
RHEL6 / OpenJDK (rhel-2.3.10.4.el6_4-x86_64)
Last Closed: 2013-12-15 11:23:06 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
error output (2.93 KB, text/plain)
2013-08-20 19:09 EDT, Aleksandar Kostadinov
no flags Details
HelloWorldWSService.wsdl (1.85 KB, application/xml)
2013-08-20 19:12 EDT, Aleksandar Kostadinov
no flags Details
HelloWorld.wsdl (2.04 KB, application/wsdl+xml)
2013-08-21 06:42 EDT, Aleksandar Kostadinov
no flags Details
HelloWorldWSService_schema1.xsd (1.44 KB, application/xml)
2013-08-21 06:55 EDT, Aleksandar Kostadinov
no flags Details

  None (edit)
Description Aleksandar Kostadinov 2013-08-20 19:09:21 EDT
Created attachment 788668 [details]
error output

wsconsume.sh fails to generate artifacts for target version 2.2

Target 2.1 works without any errors. I think there must be something broken because the openjdk java version installed on the system is 1.7 so as far as I'm reading it should be coming with jax-ws 2.2

Attaching a sample wsdl and command output when using target 2.2. Basically the issue is identical to bug 924334 but it is about openjdk 1.6

I am thinking that correct behavior should mean for the script to either automatically choose the version available on the system, choose a version depending on jvm version or set endorsed dir such that both versions work on all systems.

The last solution is best in case it is technically possible.

btw I am wondering when did the wsconsume.sh script disappear? Was this intentionally removed in AS7/EAP6?
Comment 1 Aleksandar Kostadinov 2013-08-20 19:12:25 EDT
Created attachment 788669 [details]
HelloWorldWSService.wsdl

In any case though I think the script should work without an error when executed without --target parameter. If not technically possible to "just work" with both versions on all JVMs, then it is acceptable to fail when the wrong version is selected by user.
Comment 4 Rostislav Svoboda 2013-08-21 06:38:36 EDT
Aleks, please attach HelloWorld.wsdl too
...
  <wsdl:import namespace="http://wsi/helloworld" location="HelloWorld.wsdl">
    </wsdl:import>
...
Comment 5 Aleksandar Kostadinov 2013-08-21 06:42:25 EDT
Created attachment 788813 [details]
HelloWorld.wsdl
Comment 6 Rostislav Svoboda 2013-08-21 06:44:42 EDT
I took random wsdl from WS TS and it passed 
[rsvoboda@steve 611ER6]$ jboss-eap-6.1/bin/wsconsume.sh -t 2.1 --package=org.jboss.soa.esb.samples.quickstart.ws_i --output=output/client --source=output/client -k /home/rsvoboda/TESTING/backward/stack-cxf/modules/testsuite/cxf-spring-tests/src/test/resources/jaxws/cxf/jms/META-INF-as7/wsdl/HelloWorldService.wsdl
Could not find log4j.xml configuration, logging to console.

Loading FrontEnd jaxws21 ...
Loading DataBinding jaxb ...
wsdl2java -frontend jaxws21 -compile -exsh false -p org.jboss.soa.esb.samples.quickstart.ws_i -d /home/rsvoboda/TESTING/611ER6/output/client -verbose -classdir /home/rsvoboda/TESTING/611ER6/output/client -allowElementReferences file:/home/rsvoboda/TESTING/backward/stack-cxf/modules/testsuite/cxf-spring-tests/src/test/resources/jaxws/cxf/jms/META-INF-as7/wsdl/HelloWorldService.wsdl
wsdl2java - Apache CXF 2.6.8.redhat-6

[rsvoboda@steve 611ER6]$ jboss-eap-6.1/bin/wsconsume.sh --package=org.jboss.soa.esb.samples.quickstart.ws_i --output=output/client --source=output/client -k /home/rsvoboda/TESTING/backward/stack-cxf/modules/testsuite/cxf-spring-tests/src/test/resources/jaxws/cxf/jms/META-INF-as7/wsdl/HelloWorldService.wsdl
Could not find log4j.xml configuration, logging to console.

Loading FrontEnd jaxws ...
Loading DataBinding jaxb ...
wsdl2java -compile -exsh false -p org.jboss.soa.esb.samples.quickstart.ws_i -d /home/rsvoboda/TESTING/611ER6/output/client -verbose -classdir /home/rsvoboda/TESTING/611ER6/output/client -allowElementReferences file:/home/rsvoboda/TESTING/backward/stack-cxf/modules/testsuite/cxf-spring-tests/src/test/resources/jaxws/cxf/jms/META-INF-as7/wsdl/HelloWorldService.wsdl
wsdl2java - Apache CXF 2.6.8.redhat-6

Will check Aleks's scenario now.
Comment 7 Rostislav Svoboda 2013-08-21 06:47:31 EDT
Aleks, attach please HelloWorldWSService_schema1.xsd too.
...
<import namespace="http://wsi/helloworld" schemaLocation="HelloWorldWSService_schema1.xsd"/>
...
Comment 8 Aleksandar Kostadinov 2013-08-21 06:55:13 EDT
Created attachment 788817 [details]
HelloWorldWSService_schema1.xsd

sorry, attaching
Comment 9 Aleksandar Kostadinov 2013-08-21 06:56:52 EDT
btw make sure to use the java version specified above like in normal RHEL6 installation without any touch to environment like JAVA_HOME or whatever. It might be related to jvm installation.
Comment 10 Rostislav Svoboda 2013-08-21 07:35:10 EDT
[rsvoboda@steve 611ER6]$ jboss-eap-6.1/bin/wsconsume.sh -package=org.jboss.soa.esb.samples.quickstart.ws_i --output=output/client --source=output/client -k  HelloWorldWSService.wsdl 
Could not find log4j.xml configuration, logging to console.

Loading FrontEnd jaxws ...
Loading DataBinding jaxb ...
wsdl2java -compile -exsh false -p ackage=org.jboss.soa.esb.samples.quickstart.ws_i -d /home/rsvoboda/TESTING/611ER6/output/client -verbose -classdir /home/rsvoboda/TESTING/611ER6/output/client -allowElementReferences file:/home/rsvoboda/TESTING/611ER6/HelloWorldWSService.wsdl
wsdl2java - Apache CXF 2.6.8.redhat-6

[rsvoboda@steve 611ER6]$ jboss-eap-6.1/bin/wsconsume.sh -t 2.2 -package=org.jboss.soa.esb.samples.quickstart.ws_i --output=output/client --source=output/client -k  HelloWorldWSService.wsdl 
Could not find log4j.xml configuration, logging to console.

Loading FrontEnd jaxws ...
Loading DataBinding jaxb ...
wsdl2java -compile -exsh false -p ackage=org.jboss.soa.esb.samples.quickstart.ws_i -d /home/rsvoboda/TESTING/611ER6/output/client -verbose -classdir /home/rsvoboda/TESTING/611ER6/output/client -allowElementReferences file:/home/rsvoboda/TESTING/611ER6/HelloWorldWSService.wsdl
wsdl2java - Apache CXF 2.6.8.redhat-6

[rsvoboda@steve 611ER6]$ java -version
java version "1.6.0_45"
Java(TM) SE Runtime Environment (build 1.6.0_45-b06)
Java HotSpot(TM) 64-Bit Server VM (build 20.45-b01, mixed mode)
Comment 11 Rostislav Svoboda 2013-08-21 07:38:35 EDT
It's probably related to JVM installation as you mentioned in comment 9.
Comment 12 Rostislav Svoboda 2013-08-21 07:41:13 EDT
[rsvoboda@steve 611ER6]$ export JAVA_HOME=/usr/lib/jvm/java-openjdk
[rsvoboda@steve 611ER6]$ export PATH=$JAVA_HOME/bin:$PATH
[rsvoboda@steve 611ER6]$ java -version
java version "1.7.0_25"
OpenJDK Runtime Environment (fedora-2.3.12.1.fc17-x86_64)
OpenJDK 64-Bit Server VM (build 23.7-b01, mixed mode)

And wsconsume command was executed without problem too. I have F17.
Comment 13 Rostislav Svoboda 2013-08-21 09:35:29 EDT
Ifo from test machine where Aleks found his problem

[root@dev126 ws_i]# export JAVA_HOME=/root/jdk1.7.0_25/
[root@dev126 ws_i]# export PATH=$JAVA_HOME/bin:$PATH
[root@dev126 ws_i]# java -version
java version "1.7.0_25"
Java(TM) SE Runtime Environment (build 1.7.0_25-b15)
Java HotSpot(TM) 64-Bit Server VM (build 23.25-b01, mixed mode)
[root@dev126 ws_i]# /usr/share/jbossas/bin/wsconsume.sh --package=org.jboss.soa.esb.samples.quickstart.ws_i --output=output/client --source=output/client -k  output/service/HelloWorldWSService.wsdl 
Could not find log4j.xml configuration, logging to console.

Loading FrontEnd jaxws ...
Loading DataBinding jaxb ...
wsdl2java -compile -exsh false -p org.jboss.soa.esb.samples.quickstart.ws_i -d /root/ws_i/output/client -verbose -classdir /root/ws_i/output/client -allowElementReferences file:/root/ws_i/output/service/HelloWorldWSService.wsdl
wsdl2java - Apache CXF 2.6.6-redhat-3

So it's definitely problem in JDK in that machine
Comment 14 Rostislav Svoboda 2013-08-21 09:41:13 EDT
[root@dev126 ws_i]# jboss-eap-6.1/bin/wsconsume.sh --package=org.jboss.soa.esb.samples.quickstart.ws_i --output=output/client --source=output/client -k  output/service/HelloWorldWSService.wsdl 
Could not find log4j.xml configuration, logging to console.

Loading FrontEnd jaxws ...
Loading DataBinding jaxb ...
wsdl2java -compile -exsh false -p org.jboss.soa.esb.samples.quickstart.ws_i -d /root/ws_i/output/client -verbose -classdir /root/ws_i/output/client -allowElementReferences file:/root/ws_i/output/service/HelloWorldWSService.wsdl
wsdl2java - Apache CXF 2.6.8.redhat-6

Aleks noticed difference Apache CXF 2.6.8.redhat-6  vs.  Apache CXF 2.6.6-redhat-3

So local RPM based installation is EAP 610 GA based
Comment 15 Aleksandar Kostadinov 2013-08-21 16:14:33 EDT
I think that some comments above might be easily misread and thus the bug was closed as NOTABUG.

Unfortunately there *is* a bug. I don't know if it is a problem in the openjdk shipped with RHEL6 or it is a bug in the classpath/endorsed libs or whatever but the fact is that in a standard RHEL6 machine the script is not working properly as I explain in my original report.

To be sure I did a respin of my test machine with a clean RHEL6 installation. I didn't install any additional packages except ant and subversion so I can prepare the test sample. I also installed EAP in /root/jboss-eap-6.1

Still error persists with the latest available version of openjdk in RHEL6. Alessio, I'll drop you a mail with conneciton details so you can login to the machine and see for yourself.

If you still believe the issue is in the jvm installation then please do not close as NOTABUG. Instead move it to the openjdk RHEL6 package or alternatively just let me know so I can do it.

Regards.
Comment 16 Alessio Soldano 2013-08-22 04:56:35 EDT
The installation of the JDK looks a bit broken to me. The EAP tools will end up using the same compiler that's used by javac, so I assume that's the reason why jaxws 2.2 level sources can't be compiled on that machine.

alessio@localhost ~ $ ssh root@dev126.mw.lab.eng.bos.redhat.com
root@dev126.mw.lab.eng.bos.redhat.com's password: 
Last login: Thu Aug 22 04:37:06 2013 from vpn1-4-121.ams2.redhat.com
[root@dev126 ~]# javac -version
javac 1.6.0_24
[root@dev126 ~]# java -version
java version "1.7.0_09-icedtea"
OpenJDK Runtime Environment (rhel-2.3.4.1.el6_3-x86_64)
OpenJDK 64-Bit Server VM (build 23.2-b09, mixed mode)
[root@dev126 ~]#
Comment 17 Aleksandar Kostadinov 2013-08-22 12:04:52 EDT
Nice catch!

I looked at the machine and it seems that it has openjdk 1.7 jre and openjdk 1.6 jre/jdk installed. I used alternatives to select 1.6 to be used for java as well javac. But trying out when both java and javac point at 1.6, the script fails in the same way.

If I install 1.7 as both java and javac, then the script is working good. So it seems like the problem is that with jdk 1.6 the script is not working by default.

I think that a fix would mean to make it work with 1.6 as well 1.7 when target is not specified. When target is specified it is ok for the script to fail if the web service can't compile for the given jax-ws target.

What I can't understand is why java 1.6 downloaded from oracle web site is working for Rosta. From what I'm reading java 1.6 should come with jax-ws 2.1. Could that be also caused by javac 1.7 being used although java 1.6 is used?

For your reference the commands that are used:
> alternatives --config java
> alternatives --config javac
> yum install java-1.7.0-openjdk-devel

P.S. It is totally normal to have two JDKs installed on the machine. This is allowed by Red Hat RPM so must be a supported configuration. I agree though that having mismatching java and javac can cause some troubles especially if javac is newer than java.
Comment 18 Alessio Soldano 2013-08-22 13:09:54 EDT
OK, I've some updates. I agree a mixed configuration is not good (javac 1.6, java 1.7), while a proper conf should work by default. I have multiple versions of JDKs from different vendors on my system too, of course ;-)

So I've downloaded the same JBoss EAP 6.1.1.ER7 you're using and tested locally:
 - JDK 1.7 (Oracle) -> no problem
 - JDK 1.7 (openjdk) -> no problem
 - JDK 1.6 (Oracle) -> no problem
 - JDK 1.6 (IBM) -> no problem

I've hence zipped the openjdk 1.6 that's on your machine and copied on mine; tried with it and I can reproduce the problem. I'll try debugging locally to understand what's happening.
Comment 19 Alessio Soldano 2013-08-23 13:11:03 EDT
Update: I've debugged this locally and figured out the problem, which was more subtle then expected. So, I actually partially forgot that we modified the compilation mechanism of classes generated by wsconsume a bit in JBossWS 4.1.3/4.2; there an explanation at [1], but the short story is that we wanted to be independent from the currently endorsed java version. So, we filter classes being passed to the java compiler and reset the classloader for those requiring a specific version of jaxws/jaxb (we set the proper JBoss Module classloader, namely the one for module org.jboss.ws.jaxws-client module).
Now, the problem looks to be that different JDK have different implementation of the javax.tool.FileObject#getName() method and return different string. We are using them for properly filtering classes and the values returned on OpenJDK are basically breaking our code.
I've fixed this upstream, see [2]. On Monday I'll figure out what to do for EAP 6.1, either default to JAXWS 2.1 target in the tools or port the fix.

[1] http://jbossws.blogspot.it/2013/01/jax-ws-tools-and-java-compiler-api.html
[2] https://issues.jboss.org/browse/JBWS-3697
Comment 20 Alessio Soldano 2013-08-27 03:26:50 EDT
OK, this will be fixed in EAP 6.2.
Comment 22 Aleksandar Kostadinov 2013-10-07 10:05:04 EDT
Verified on ER3.1 RPM distribution. RPM automated tests updated to check running wsconsume without target version works by default.
Comment 25 Petr Kremensky 2013-11-21 04:13:09 EST
*** Bug 924334 has been marked as a duplicate of this bug. ***
Comment 26 Scott Mumford 2013-12-01 18:29:59 EST
If I am understanding the commit attached to JBWS-3697, it seems like code was added to CXFConsumerImpl.java to allow getting a useable class name from the OpenJDK objName strings. Is this correct? (It's probably not, given my very limited understanding of Java code)

This seems at odds with the last para of the description on that ticket which may suggest that the filtering mechanism was to be disabled (quote: "This is currently basically disabling the mechanism...").

Since it's so close to the 6.2 GA, I'm requesting a draft release note text be added to the Doc Text field above that outlines what the problem was (in as simple language as possible, and how it was corrected for this release)

Thanks for any assistance, Alessio,
Comment 27 Alessio Soldano 2013-12-02 08:29:55 EST
Scott,
your understanding of the fix above is pretty much correct.

The text you quoted from JBWS-3697 is about the consequences of the bug.

To me, a release note for this BZ should simply be as follows:
"WSConsume fails with compile JAXWS 2.2 level sources when the OpenJDK 1.6 is used. The fix solves the problem."
Anything more is a low level tech detail on how the Java Compiler API is used within JBossWS and Apache CXF to control source code generation and compile.
Comment 28 Scott Mumford 2013-12-02 21:32:21 EST
Thanks again Alessio.

I framed your suggestion as per ECS conventions and have marked this for inclusion in the Release Notes.

Note You need to log in before you can comment on or make changes to this bug.