This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 178738 - wsgen fails to generate WSDL
Summary: wsgen fails to generate WSDL
Status: RESOLVED WORKSFORME
Alias: None
Product: webservices
Classification: Unclassified
Component: JAX-WS (show other bugs)
Version: 6.x
Hardware: PC Linux
: P2 normal (vote)
Assignee: Milan Kuchtiak
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-12-16 08:47 UTC by korb
Modified: 2010-11-17 13:25 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description korb 2009-12-16 08:47:48 UTC 
I have two projects, one is a web service and the other is the web service consumer. Because I am working on my development machine, I do not want to grab the WSDL from a "localhost" URL in the consumer project as that will contain the URL in the WSDL, and then I'll have to hack the WSDL to get it out of there.

Instead, I load it from a file, and to generate the file, in my web service project I expand the "Web Services" category in the Projects pane, right click on my service, and select the "Generate and Copy WSDL..." operation. I then drill down in the chooser that pops up and save it in my service project's web/WEB-INF/wsdl folder, which I can then use as the source of the WSDL in my consumer project.

The first few times I used the "Generate and Copy" operation, it worked just fine (second and subsequent invocations even prompted me for overwrite verification on the WSDL and schema files). However, eventually one of my invocations resulted in the error message "The WSDL was not generated. View the Output window for details on the generation error." In the output tab, it said that the wsgen command line that was executed as this (I added the new-line escapes to make it more readable):

wsgen -classpath \
/usr/lib/jvm/java-6-sun-1.6.0.16/lib/tools.jar:\
/projects/MyWS/build/web/WEB-INF/classes:\
/projects/MyWS/${j2ee.platform.wsgen.classpath}:\
/opt/netbeans-6.8/ide12/modules/ext/jaxb/activation.jar:\
/opt/netbeans-6.8/ide12/modules/ext/jaxb/api/jaxb-api.jar:\
/opt/netbeans-6.8/ide12/modules/ext/jaxb/jaxb-impl.jar:\
/opt/netbeans-6.8/ide12/modules/ext/jaxb/jaxb-xjc.jar:\
/opt/netbeans-6.8/ide12/modules/ext/jaxb/api/jsr173_api.jar:\
/opt/netbeans-6.8/java3/modules/ext/jaxws22/FastInfoset.jar:\
/opt/netbeans-6.8/java3/modules/ext/jaxws22/gmbal-api-only.jar:\
/opt/netbeans-6.8/java3/modules/ext/jaxws22/http.jar:\
/opt/netbeans-6.8/java3/modules/ext/jaxws22/api/jaxws-api.jar:\
/opt/netbeans-6.8/java3/modules/ext/jaxws22/jaxws-rt.jar:\
/opt/netbeans-6.8/java3/modules/ext/jaxws22/jaxws-tools.jar:\
/opt/netbeans-6.8/java3/modules/ext/jaxws22/api/jsr181-api.jar:\
/opt/netbeans-6.8/java3/modules/ext/jaxws22/api/jsr250-api.jar:\
/opt/netbeans-6.8/java3/modules/ext/jaxws22/management-api.jar:\
/opt/netbeans-6.8/java3/modules/ext/jaxws22/mimepull.jar:\
/opt/netbeans-6.8/java3/modules/ext/jaxws22/policy.jar:\
/opt/netbeans-6.8/java3/modules/ext/jaxws22/api/saaj-api.jar:\
/opt/netbeans-6.8/java3/modules/ext/jaxws22/saaj-impl.jar:\
/opt/netbeans-6.8/java3/modules/ext/jaxws22/stax-ex.jar:\
/opt/netbeans-6.8/java3/modules/ext/jaxws22/streambuffer.jar:\
/opt/netbeans-6.8/java3/modules/ext/jaxws22/woodstox.jar:\
/opt/logging-log4j-current/dist/lib/log4j-1.2.13.jar \
 -d /projects/MyWS/build/generated-sources/jax-ws \
 -Xendorsed -keep -wsdl \
 -r /projects/MyWS/build/generated-sources/jax-ws/resources \
 -s /projects/MyWS/build/generated-sources/jax-ws \
 -verbose memberdb.ws.MemberDbWS


There was also a stack trace that looked like this:

java.lang.ExceptionInInitializerError
        at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
        at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
        at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
        at java.lang.Class.newInstance0(Class.java:355)
        at java.lang.Class.newInstance(Class.java:308)
        at javax.xml.soap.FactoryFinder.newInstance(FactoryFinder.java:59)
        at javax.xml.soap.FactoryFinder.find(FactoryFinder.java:137)
        at javax.xml.soap.FactoryFinder.find(FactoryFinder.java:170)
        at javax.xml.soap.SAAJMetaFactory.getInstance(SAAJMetaFactory.java:79)
        at javax.xml.soap.MessageFactory.newInstance(MessageFactory.java:148)
        at com.sun.xml.ws.api.SOAPVersion.<init>(SOAPVersion.java:176)
        at com.sun.xml.ws.api.SOAPVersion.<clinit>(SOAPVersion.java:82)
        at com.sun.xml.ws.api.BindingID.<clinit>(BindingID.java:335)
        at com.sun.tools.ws.wscompile.WsgenOptions.validateBinding(WsgenOptions.java:252)
        at com.sun.tools.ws.wscompile.WsgenOptions.validateEndpointClass(WsgenOptions.java:247)
        at com.sun.tools.ws.wscompile.WsgenOptions.validate(WsgenOptions.java:214)
        at com.sun.tools.ws.wscompile.WsgenTool.run(WsgenTool.java:122)
        at com.sun.tools.ws.ant.WsGen2.execute(WsGen2.java:525)
        at com.sun.istack.tools.ProtectedTask.execute(ProtectedTask.java:55)
        at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288)
        at sun.reflect.GeneratedMethodAccessor508.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
        at org.apache.tools.ant.Task.perform(Task.java:348)
        at org.apache.tools.ant.Target.execute(Target.java:357)
        at org.apache.tools.ant.Target.performTasks(Target.java:385)
        at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1337)
        at org.apache.tools.ant.Project.executeTarget(Project.java:1306)
        at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
        at org.apache.tools.ant.Project.executeTargets(Project.java:1189)
        at org.apache.tools.ant.module.bridge.impl.BridgeImpl.run(BridgeImpl.java:278)
        at org.apache.tools.ant.module.run.TargetExecutor.run(TargetExecutor.java:498)
        at org.netbeans.core.execution.RunClassThread.run(RunClassThread.java:151)
Caused by: java.lang.IllegalArgumentException: com.sun.xml.internal.messaging.saaj.soap.LocalStrings != com.sun.xml.messaging.saaj.soap.LocalStrings
        at java.util.logging.Logger.getLogger(Logger.java:314)
        at com.sun.xml.messaging.saaj.soap.SAAJMetaFactoryImpl.<clinit>(SAAJMetaFactoryImpl.java:52)
        ... 35 more


Note the wsgen command line the unexpanded variable in the third entry in the classpath: "/projects/MyWS/${j2ee.platform.wsgen.classpath}". I am guessing that this variable was at some point defined, and then became undefined, and it appears as though NB executes the wsgen command in a shell and the shell is choking on the unexpanded variable (I jumped to this conclusion because if I copy/paste that same command into a Linux shell window and try to run it, I get the error message "ksh: : bad substitution", but if I simply delete that unexpanded variable from the command, wsgen completes successfully in the shell window).

If I manually edit my nbproject/private/private.properties and add "j2ee.platform.wsgen.classpath=", then the wsgen command will run to completion, and the WSDL will be generated (although I do still get the same ugly stack trace, so my hack of private.properties is probably not the "right" work-around).

Java version is:
java version "1.6.0_16"
Java(TM) SE Runtime Environment (build 1.6.0_16-b01)
Java HotSpot(TM) 64-Bit Server VM (build 14.2-b01, mixed mode)

My web server is the Sun Java System Web Server 7.0 (and I have that plugin installed) though if I switch to Tomcat for my project, the same wsgen error happens.
Comment 1 korb 2009-12-16 08:52:33 UTC 
Clarification: it is *not* the undefined j2ee.platform.wsgen.classpath that is causing the problem. I just ran the "Generate and Copy" operation again, and this time it succeeded, and the variable was still not expanded. However, no stack trace this time.
Comment 2 korb 2009-12-16 09:23:40 UTC 
An additional data point: when I run wsgen at the command line, I am actually getting the 2.1.6 RI version of wsgen, rather than the 2.2 version that is included in NB 6.8:

164$ wsgen -version 
JAX-WS RI 2.1.6 in JDK 6
Comment 3 Milan Kuchtiak 2009-12-17 07:32:58 UTC 
Excuse me, may be I am wrong, but there is no "com.sun.tools.ws.ant.WsGen" task in JDK. What's there - it's the JAXB api and JAX-WS api.

What Netbeans does - it's hiding the JAXB/JAX-WS api packages (contained in JDK) and uses those distributed with Netbeans in NB_HOME/java3/modules/ext/jaxws22/api or NB_HOME/ide12/modules/ext/jaxb/api

To reproduce the issue, I need to have some example module. Can you please create some example and attach that example to this issue (zip file).

Do you use some old project (created in earlier versions of Netbeans), or a web application created in Netbeans 6.8 ?

Note:
I haven't checked Sun Java System Web Server 7.0, but I tested both GlassFish V2 and V3.
BTW, Netbeans uses the WsGen ant task that taken from J2EE Server.
(see the j2ee.platform.wsgen.classpath property in private.properties)
For Tomcat case (Tomcat doesn't contain JAX-WS jars normally) wsgen is taken from project's classpath. In this case user needs to have JAX-WS library on project's classpath.

Every time you change the server the content of the "j2ee.platform.wsgen.classpath" property should change.
Comment 4 Denis Anisimov 2010-11-17 13:25:16 UTC 
No response from the user.

Closing.