Bug 999223

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.

Aleks, please attach HelloWorld.wsdl too
...
  <wsdl:import namespace="http://wsi/helloworld" location="HelloWorld.wsdl">
    </wsdl:import>
...

Created attachment 788813 [details]
HelloWorld.wsdl

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.

Aleks, attach please HelloWorldWSService_schema1.xsd too.
...
<import namespace="http://wsi/helloworld" schemaLocation="HelloWorldWSService_schema1.xsd"/>
...

Created attachment 788817 [details]
HelloWorldWSService_schema1.xsd

sorry, attaching

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.

[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)

It's probably related to JVM installation as you mentioned in comment 9.

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

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

[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

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.

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.lab.eng.bos.redhat.com
root.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 ~]#

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.

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.

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

OK, this will be fixed in EAP 6.2.

Verified on ER3.1 RPM distribution. RPM automated tests updated to check running wsconsume without target version works by default.

*** Bug 924334 has been marked as a duplicate of this bug. ***

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,

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.

Thanks again Alessio.

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