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.
I am trying to import the FedEx WSDL files for rates, tracking, etc, and these files can be retrieved from fedex.com by creating an account for their technical services. Anyways, when right clicking on a project and choosing to create a new web service client with any WSDL, as of today 2008-09-06, I get an Ant script using an attribute xnocompile on the wsimport task, and I get an error message that the task "doesn't support the xnocompile attribute". I click on the error message which takes me to the Ant script, and I can remove the attribute and the service client can then be generated successfully. This is in the latest dailies I'm building from the main repository. The Ant script task failing is: <target name="wsimport-client-TrackService_v2" depends="wsimport-init"> <wsimport xnocompile="true" sourcedestdir="${build.generated.dir}/wsimport/client" destdir="${build.generated.dir}/wsimport/client" wsdl="${basedir}/xml-resources/web-service-references/TrackService_v2/wsdl/TrackService_v2.wsdl" wsdlLocation="file:/home/wade/local/projects/cltractor/FedEx/webservice/TrackService_v2.wsdl" catalog="catalog.xml" extension="true" verbose="true"> <produces dir="${build.generated.dir}/wsimport/client/com/fedex/ws/track/v2" includes="TrackService_v2.java" casesensitive="no"/> </wsimport> </target>
I should note that different actions in the project will put xnocompile back into the script, so it is very difficult to use. Luckily I only have 4 WSDLs in this project, but if I had many more then it would be very hard to manage, so I set it to a P2.
well, we cannot do much without knowing details about your project/environment - what JDK/target server/JDK of target server, what project type, do you use your own metro dist or IDE/server one? The truth is that we should expose this attribute to the user in edit ws attrs -> wsimport options dialog to easily get rid of it if not needed
>well, we cannot do much without knowing details about your project/environment - >what JDK/target server/JDK of target >server, what project type, do you use your own metro dist or IDE/server one? JDK 1.6u7, no target server as it is a separate Java Class Library project because of the way web service client generation makes the generated classes disposable by placing them in the build folder, which makes it hard to use them in the project they are generated inside, and I need them accessible in a swing application and a web application.
Created attachment 69221 [details] FedEx RateService WSDL
I have attached one of the WSDLs used in the project which should help with testing though this doesn't seem WSDL specific.
thanks for additional info, Wade. Java class library + JDK6u7 - that's the important part for us. One more question to be answered - is there IDE bundled JAX-WS library in project libraries of the java lib project? It looks like it isn't since IDE contains JAX-WS 2.1.3 (or 2.1.4?) where -Xnocompile is supported and JDK6u7 contains JAX-WS 2.1.1 where the option isn't supported.
I went back to the project, added the libraries to it from the IDE, and I put xnocompile back into the ant script. It still failed. I think the lower level Java classes are used instead of the libraries. I guess the only way to work around that might be to update JAX-WS in the JDK? Will placing the libraries in the ext folder do that? Does JAX-WS work as extension overrides? Anyways, no, the JAX-WS libraries were not in the project, but it didn't seem to matter anyways with JDK6. This shows some of the issues which I have written to different Sun folks about the JDK trying to be a kitchen sink, including the different servers which do the same thing, including libraries in their core libraries as it makes it very hard to use newer versions in applications and projects and use newer server or JDK versions which are stuck with static versions of libraries which are still evolving. I get there are reasons to include them, but what a pain. Anyways, that must be the problem. I guess the WS client logic updating the ant script should try to determine what attributes to use based on whether the attribute is supported in the wsimport Ant tasks class com.sun.tools.ws.ant.WsImport. Thanks.
The best way to avoid these problems is to copy all jars from : netbeans_home/java2/modules/ext/jaxws21/api netbeans_home/ide10/modules/ext/jaxb/api into java_home/jre/lib/endorsed (create that directory if missing) or specify java.endorsed.dirs system property. See the link about running JAX-WS on JDK1.6: https://jax-ws.dev.java.net/nonav/2.1.3/docs/ReleaseNotes.html#Running_on_top_of_JDK_6 -xnocompile is used all the time in J2SE application, since the java platform set up in project is used to re-compile JAX-WS artifacts, which is not necessarily the same the IDE is running on.
Would it make sense for NB to define an endorsed directory when it runs? I'm trying to figure out how NB will be able to handle JDK 6 without folks running into the issue when using it. It seems JDK 6 will be used soon as it took a while for folks to move to JDK 5 for production environments, and this issue will be more common at that point. Maybe at a minimum when a WS client is generated the IDE could recognize the issue and tell the user how to fix it with some type of message.
Looking why a different version of wscompile is used instead of one located in ${libs.jaxws21.classpath}
I am sorry, I cannot reproduce the issue. - Running IDE in JDK1.6.0_07 - created J2SE Library - created WS Client in J2SE library - everything works perfectly. Willing to understand the problem but need your help. Please, attach 3 things to understand the issue : attach jax-ws.xml(1) and jaxws-build.xml(2) from nbproject directory. Then, please insert one <echo> line just at the beginning of jaxws-build.xml (before wsimport taskdef) : <target name="wsimport-init" depends="init"> <mkdir dir="${build.generated.dir}/wsimport/client"/> <echo>JAX-WS 2.1: ${libs.jaxws21.classpath}</echo> <taskdef name="wsimport" classname="com.sun.tools.ws.ant.WsImport"> <classpath path="${libs.jaxws21.classpath}"/> </taskdef> </target> Then clean and build the project - and, finally, attach the text from output window (3)
Since you could not reproduce I tried it on Windows XP using JDK 1.6_10ea (the one I have on the computer), and it all seems to work correctly. I assume it would if I had 1.6_7 as well. I'll see if I can't figure out what the difference is. The other system is openSuSE 10.3 with 1.6_7. Anyways, I'll do some more digging, and I'll get those files from the other system attached sometime this evening. Thanks so much for looking into the issue.
OK, I have the problem identified. It is a result of different things. 1) The WS tooling doesn't check the classes to see what is supported in the available libraries. 2) The library name is used correctly in the build file, but this project was started in NB 6.1 and uses "Shared Libraries". The version of JAX-WS is an older version which doesn't have xnocompile support though the library name is exactly the same. It seems the tooling maybe should try to work around issues like this or at a minimum inform the user as to what might be happening and how to fix it. Too, it seems the shared library support needs to some how support resynchronizing the libraries in a shared directory with libraries from the current IDE ( a different issue entirely).
thanks Wade for your time you spent on this! This is really something we'll have to fix for 6.5....
btw: this was also mentioned on nbj2ee list for webapps: http://tinyurl.com/57u2fm
from Wadi (in a private conversation): "My glassfish version is glassfish-v2ur2"
I see, the shared libraries version (e.g. the version taken Netbeans 6.1) may be different than JAX-WS library bundled with IDE. I see few solutions here: Solution 1 - warn user to replace shared library by newer version, Solution 2 - detect JAX-WS library correctly (even if the one in shared libraries is different than one bundled with IDE Solution 3 - make xnocompile attribute optional (available to set/remove) May be both Solution 2 and 3 are achievable.
Made xnocompile option optional. Now the option can be set/removed in Edit WS Attributes dialog. Moreover, the option is not created if it's missing in old project type (created in 6.1) See the changeset: http://hg.netbeans.org/main?cmd=changeset;node=6675aa619a19
Integrated into 'main-golden', will be available in build *200809241401* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/6675aa619a19 User: mkuchtiak@netbeans.org Log: #146391: make wsimport:xnocompile attribute optional
Sorry, had to reopen after some testing. It looks like this is in main, but I think the problem is still there...at least when open a 6.1 project in 6.5 when it has libraries in a shared directory and the JAX-WS libraries are in the shared folder. Now, I could go into the attributes of the web service by right clicking on it and removing xnocompile to correct the issue without editing the Ant script by hand, but by default it broke when I first created the web service client in 6.5. Here is what I did. 1) Opened NB 6.1 and NB 6.5 (one I just built from main) 2) Create a Java Class library project in NB 6.1 and was sure to check "Use dedicated folder for storing libraries" 3) Add the JAX-* libraries to the project by going to properties->Libraries->Add Library->Import and holding down CTRL and selecting JAX* and clicking "Import Library" 4) I closed the project in NB 6.1 5) Opened it in NB 6.5 6) Right clicked on the project and chose New->Web Service Client 7) Selected by WSDL file from above (in the issue attachments) 8) Click finished 9) Was presented a xnocompile not supported error in the output window from Ant failing. The message from the output window which never makes it into the IDE log is below. init: wsimport-init: wsimport-client-transaction_processing: /home/wade/local/projects/WSTest6/nbproject/jaxws-build.xml:16: class com.sun.tools.ws.ant.WsImport2 doesn't support the "xnocompile" attribute. BUILD FAILED (total time: 0 seconds) So, from the look of the manifest from main the code should be checked into main. At around 14:00GMT/UTC I did an: hg pull -u ant inside my NB hg sources folder, and it pulled all the changesets, and this is the build of NB 6.5 I was using to test. This was repeatable.
Yes, that's correct. The problem is that J2SE project (Java class library) assumes the version of JAX-WS 2.1 library is the one bundled with IDE (that means 2.1.3) - not version located in shared libraries (in this case 2.1.2). The workaround for now is to remove xnocompile attribute in Edit WS Attributes dialog and re-build the project. I agree that the workaround isn't much comfortable. Better would be to detect JAX-WS 2.1 version correctly. Trying to find a way to detect tve version correctly. Note: I've implemented the Solution 3 - just for now.
Now, JAX-WS 2.1 library version is detected correctly providing JAX-WS library is on project classpath: http://hg.netbeans.org/main?cmd=changeset;node=adf0c5cf9b25 This is the solution nr.2 Thank You for cooperation.
Thanks. Little OT, but goes with why I used the project type. Maybe it is me, but it seems a Java Classpath library, at least the way the classes for a service/service client are generated in a volatile directory such as under build, is the best way to go. I tried to add a service client to my applications directly, and I apparently couldn't reference the classes from my project. I don't know if that was another issue not intended or not. Thanks again.
Integrated into 'main-golden', will be available in build *200809251401* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/adf0c5cf9b25 User: mkuchtiak@netbeans.org Log: #146391: detect JAX-WS version for J2SE Project from com/cun/xml/ws/util/version.properties