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.
We have a webservice that uses JAX-WS with GF 3.1. When we try to build in NB, we get the following error: Created dir: /export/home/chaase/tut-ws/javaeetutorial/trunk/examples/case-studies/dukes-forest/dukes-store/build/generated-sources/jax-ws /export/home/chaase/tut-ws/javaeetutorial/trunk/examples/case-studies/dukes-forest/dukes-store/nbproject/jaxws-build.xml:23: taskdef class com.sun.tools.ws.ant.WsImport cannot be found using the classloader AntClassLoader[/var/opt/home/jdk1.6.0_23/lib/tools.jar] To get past this error we need to use Tools->Options, click Miscellaneous, and in the Ant tab use Add Jar/ZIP to locate and add the libraries webservices-tools.jar and webservices-rt.jar in the directory <nbhome>/enterprise/modules/ext/metro/. Then the error goes away. NB should be able to find these jars on its own.
First of all : this is not a P2 bug because nothing broken. The problem can be easily fixed via extending classpath with required library. Please provide exact steps to reproduce . I'm not able to reproduce it with new project created from scratch and new web service. There is a dialog on the final stage of WS creation . This dialog asks about metro 2.0 library usage . The latter library contains all required Jars. One can refuse Metro library usage and as result jars will be not added into classpath. So this is user decision. But from the description I see mention of WsImport task. This task is used only when WS is created based on WSDL file. In the latter case one don't need a Metro library to build the project. Path to WsImport class task definition is configured via property j2ee.platform.wsimport.classpath. This property value equals to jars inside NB installation directory and you don't need to have these jars in the classpath. Metro library is required only in runtime. I can't reproduce the scenario with WS from wsdl either. I'm able to create WS from wsdl and it is imported without a problem. All works fine. I can suggest that your project has not been created in the NB IDE. Probably you get it externally from somewhere. In this case this project is just invalid and this is not an issue of NB. Probably this is issue of javaee tutorial examples. So please file this issue against this tutorial , not NB.
One more thing for notion : property value "j2ee.platform.wsimport.classpath" is equal to property value of NB property "libs.jaxws21.classpath". The latter property is JAX-WS 2.2 library . You can find it via "Tools"->"Libraries" main menu items. This library contains jars with WsImport task definition. This is not Metro library and you don't need actually webservices-tools.jar and webservices-rt.jar. JAX-WS library contains jaxws22/jaxws-rt.jar and jaxws22/jaxws-tools.jar. WsImport is defined in the jaxws-tools.jar.
We will look into providing further information, but we would like to say, first: 1) We ARE the javeetutorial team that is filing this bug. 2) We always create our projects in NetBeans. 3) It is very misleading to have a property named "libs.jaxws21.classpath" that supposedly points to the JAX-WS 2.2 library. That was one of the things that threw us off after we created the project. We knew we wanted the 2.2 libraries, but the classpath said 2.1 so we figured we needed some other way to get to the actual 2.2 libraries. At the very least, the property should be renamed.
I'm not an original author neither of the WS code nor library name. I'm just a responsible person who supports and proceed development of this area. So I don't know exactly why this property has this name. I can just suggest that it could be a for a backward compatibility with projects created with older version of NB bundled with old library version. Anyway this property is hidden inside ant build script and user don't need to know about it. This is implementation detail. It is important that it is resolved to correct library with appropriate jars.
Created attachment 106176 [details] application with webservices problem I'm attaching a file containing the three main components of this application, which is not yet complete: events, dukes-payment, and dukes-store. The events project contains a POJO. It needs to be built first, because dukes-payment and dukes-store use it. The webservice is in dukes-payment. The component for which compilation fails is dukes-store, which contains a web service reference to dukes-payment but is not itself a web service. It should be able to access the jars in glassfish-3.1-b43/glassfish/modules -- the wsimport tool seems to be in webservices-osgi.jar.
We seem to have solved the problem. In the zip file, you may notice that the dukes-store/nbproject/project.properties file contains some very odd Java EE classpath properties. The developer who is creating this app has used several different versions of NetBeans, and we don't know how he got this. j2ee.platform.classpath=\ ${libs.Java-EE-GlassFish-v3.classpath} j2ee.platform.embeddableejb.classpath=${j2ee.server.home}/lib/embedded/glassfish -embedded-static-shell.jar j2ee.platform.jwsdp.classpath=\ ${libs.Java-EE-GlassFish-v3.wsjwsdp} j2ee.platform.wscompile.classpath=\ ${libs.Java-EE-GlassFish-v3.wscompile} j2ee.platform.wsgen.classpath=\ ${libs.Java-EE-GlassFish-v3.wsgenerate} j2ee.platform.wsimport.classpath=\ ${libs.Java-EE-GlassFish-v3.wsimport} j2ee.platform.wsit.classpath=\ ${libs.Java-EE-GlassFish-v3.wsinterop} Anyway, we copied in the classpaths from another project -- j2ee.platform.classpath=${j2ee.server.home}/modules/jersey-core.jar:${j2ee.server.home}/modules/endorsed/webservices-api-osgi.jar:${j2ee.server.home}/modules/jaxrpc-api-osgi.jar:${j2ee.server.home}/modules/bean-validator.jar:${j2ee.server.home}/modules/jersey-client.jar:${j2ee.server.home}/modules/javax.servlet.jsp.jstl.jar:${j2ee.server.home}/modules/javax.mail.jar:${j2ee.server.home}/modules/javax.security.jacc.jar:${j2ee.server.home}/modules/javax.persistence.jar:${j2ee.server.home}/modules/javax.transaction.jar:${j2ee.server.home}/modules/javax.ejb.jar:${j2ee.server.home}/modules/jersey-multipart.jar:${j2ee.server.home}/modules/javax.management.j2ee.jar:${j2ee.server.home}/modules/jettison.jar:${j2ee.server.home}/modules/mimepull.jar:${j2ee.server.home}/modules/jackson-core-asl.jar:${j2ee.server.home}/modules/endorsed/javax.annotation.jar:${j2ee.server.home}/modules/jersey-json.jar:${j2ee.server.home}/modules/jackson-jaxrs.jar:${j2ee.server.home}/modules/jackson-mapper-asl.jar:${j2ee.server.home}/modules/javax.enterprise.deploy.jar:${j2ee.server.home}/modules/endorsed/jaxb-api-osgi.jar:${j2ee.server.home}/modules/jsf-api.jar:${j2ee.server.home}/modules/javax.servlet.jsp.jar:${j2ee.server.home}/modules/javax.servlet.jar:${j2ee.server.home}/modules/jstl-impl.jar:${j2ee.server.home}/modules/jersey-gf-server.jar:${j2ee.server.home}/modules/javax.jms.jar:${j2ee.server.home}/modules/weld-osgi-bundle.jar:${j2ee.server.home}/modules/javax.resource.jar:${j2ee.server.home}/modules/jsf-impl.jar:${j2ee.server.home}/modules/javax.security.auth.message.jar j2ee.platform.embeddableejb.classpath=${j2ee.server.home}/lib/embedded/glassfish-embedded-static-shell.jar j2ee.platform.wscompile.classpath=${j2ee.server.home}/modules/webservices-osgi.jar j2ee.platform.wsgen.classpath=${j2ee.server.home}/modules/webservices-osgi.jar:${j2ee.server.home}/modules/endorsed/webservices-api-osgi.jar:${j2ee.server.home}/modules/jaxb-osgi.jar:${j2ee.server.home}/modules/endorsed/jaxb-api-osgi.jar:${j2ee.server.home}/modules/javax.ejb.jar j2ee.platform.wsimport.classpath=${j2ee.server.home}/modules/webservices-osgi.jar:${j2ee.server.home}/modules/endorsed/webservices-api-osgi.jar:${j2ee.server.home}/modules/jaxb-osgi.jar:${j2ee.server.home}/modules/endorsed/jaxb-api-osgi.jar:${j2ee.server.home}/modules/javax.ejb.jar j2ee.platform.wsit.classpath= And we no longer have to bundle any NB jars.
OK. Thanks.