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 using Netbeans nightly build (200807221016), still i am having problem in building and running the wsit client. Please see the reproducible steps and also screenshots. *Reproducable steps --------------------------* 1)create a Web Service as given in the user doc "https://metro.dev.java.net/guide/Creating_a_Web_Service.html#ahibp" 2)Now create wsit client to access this web service.To create client do the following as given in the user doc "https://metro.dev.java.net/guide/Creating_a_Client_to_Consume_a_WSIT_Enabled_Web_Service.html#wsit_example_with_nb-creating_wsit_client" a) Choose File?New Project, select Web Application from the Web category and click Next. b) Name the project, for example, CalculatorWSServletClient, and click Next. Then click Finish. c) Right-click the CalculatorWSServletClient node and select New?Web Service Client. d) Select the WSDL URL option. e) Cut and paste the URL of the web service that you want the client to consume into the WSDL URL field. f) Provide service url in the url text box, click finish. e.g http://localhost:8080/CalculatorApplication/CalculatorWSService?wsdl *Warning Message ** Build is sucessful after this step but you will get "Warning message box" which shows illegalStateException. See "Sceenshot1.png" g)Right-click the CalculatorWSServletClient project node and choose New?Servlet. h)Name the servlet ClientServlet, specify the package name, for example, org.me.calculator.client and click Finish. Servlet is generated but i see ClassNotFoundException in Server Log after this step. *Serverlog* ============================================================================= Cannot load org.me.calculator.client.ClientServlet reason : org.me.calculator.client.ClientServlet java.lang.ClassNotFoundException: org.me.calculator.client.ClientServlet at com.sun.enterprise.loader.EJBClassLoader.findClassData(EJBClassLoader.java:741) at com.sun.enterprise.loader.EJBClassLoader.findClass(EJBClassLoader.java:631) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at com.sun.enterprise.deployment.annotation.impl.ModuleScanner.getElements(ModuleScanner.java:174) at com.sun.enterprise.deployment.archivist.Archivist.processAnnotations(Archivist.java:405) at com.sun.enterprise.deployment.archivist.Archivist.readAnnotations(Archivist.java:346) at com.sun.enterprise.deployment.archivist.Archivist.readDeploymentDescriptors(Archivist.java:318) at com.sun.enterprise.deployment.archivist.Archivist.open(Archivist.java:213) at com.sun.enterprise.deployment.archivist.ApplicationArchivist.openArchive(ApplicationArchivist.java:763) at com.sun.enterprise.deployment.archivist.ApplicationArchivist.openArchive(ApplicationArchivist.java:744) at com.sun.enterprise.deployment.backend.Deployer.loadDescriptors(Deployer.java:349) at com.sun.enterprise.deployment.backend.ModuleDeployer.loadDescriptors(ModuleDeployer.java:423) at com.sun.enterprise.deployment.backend.WebModuleDeployer.deploy(WebModuleDeployer.java:157) at com.sun.enterprise.deployment.backend.ModuleDeployer.doRequestFinish(ModuleDeployer.java:179) at com.sun.enterprise.deployment.phasing.J2EECPhase.runPhase(J2EECPhase.java:191) at com.sun.enterprise.deployment.phasing.DeploymentPhase.executePhase(DeploymentPhase.java:108) at com.sun.enterprise.deployment.phasing.PEDeploymentService.executePhases(PEDeploymentService.java:919) at com.sun.enterprise.deployment.phasing.PEDeploymentService.deploy(PEDeploymentService.java:279) at com.sun.enterprise.deployment.phasing.PEDeploymentService.deploy(PEDeploymentService.java:788) at com.sun.enterprise.management.deploy.DeployThread.deploy(DeployThread.java:187) at com.sun.enterprise.management.deploy.DeployThread.run(DeployThread.java:223) Cannot load org.me.calculator.client.ClientServlet reason : org.me.calculator.client.ClientServlet java.lang.ClassNotFoundException: org.me.calculator.client.ClientServlet at com.sun.enterprise.loader.EJBClassLoader.findClassData(EJBClassLoader.java:718) at com.sun.enterprise.loader.EJBClassLoader.findClass(EJBClassLoader.java:631) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at com.sun.enterprise.deployment.annotation.impl.ModuleScanner.getElements(ModuleScanner.java:174) at com.sun.enterprise.deployment.annotation.impl.AnnotationProcessorImpl.process(AnnotationProcessorImpl.java:127) at com.sun.enterprise.deployment.archivist.Archivist.processAnnotations(Archivist.java:445) at com.sun.enterprise.deployment.archivist.Archivist.readAnnotations(Archivist.java:346) at com.sun.enterprise.deployment.archivist.Archivist.readDeploymentDescriptors(Archivist.java:318) at com.sun.enterprise.deployment.archivist.Archivist.open(Archivist.java:213) at com.sun.enterprise.deployment.archivist.ApplicationArchivist.openArchive(ApplicationArchivist.java:763) at com.sun.enterprise.deployment.archivist.ApplicationArchivist.openArchive(ApplicationArchivist.java:744) at com.sun.enterprise.deployment.backend.Deployer.loadDescriptors(Deployer.java:349) at com.sun.enterprise.deployment.backend.ModuleDeployer.loadDescriptors(ModuleDeployer.java:423) at com.sun.enterprise.deployment.backend.WebModuleDeployer.deploy(WebModuleDeployer.java:157) at com.sun.enterprise.deployment.backend.ModuleDeployer.doRequestFinish(ModuleDeployer.java:179) at com.sun.enterprise.deployment.phasing.J2EECPhase.runPhase(J2EECPhase.java:191) at com.sun.enterprise.deployment.phasing.DeploymentPhase.executePhase(DeploymentPhase.java:108) at com.sun.enterprise.deployment.phasing.PEDeploymentService.executePhases(PEDeploymentService.java:919) at com.sun.enterprise.deployment.phasing.PEDeploymentService.deploy(PEDeploymentService.java:279) at com.sun.enterprise.deployment.phasing.PEDeploymentService.deploy(PEDeploymentService.java:788) at com.sun.enterprise.management.deploy.DeployThread.deploy(DeployThread.java:187) at com.sun.enterprise.management.deploy.DeployThread.run(DeployThread.java:223) deployed with moduleid = CalculatorWSServletClient =========================================================================== i)To make the servlet the entry point to your application, right-click the CalculatorWSServletClient project node, choose Properties, click Run, type /ClientServlet in the Relative URL field, and click OK. j)If ClientServlet.java is not already open in the Source Editor, open it. k)In the Source Editor, remove the line that comments out the body of the processRequest method. l)Add some empty lines in processRequest method. m)Right-click in one of the empty lines that you added, then choose Web Service Client Resources?Call Web Service Operation. n)The Select Operation to Invoke dialog box appears and click ok. o)do the rquired change p)save and run the client. *I See the error in Server log and browser shows 500 error.See "Screenshot3.png" Server Log* ========================================================================================== deployed with moduleid = CalculatorWSServletClient Class [ org/me/calculator/CalculatorWS ] not found. Error while loading [ class org.me.calculator.client.ClientServlet ] Error in annotation processing: java.lang.NoClassDefFoundError: org/me/calculator/CalculatorWS deployed with moduleid = CalculatorWSServletClient PWC1412: WebModule[/CalculatorWSServletClient] ServletContext.log():PWC1409: Marking servlet ClientServlet as unavailable StandardWrapperValve[ClientServlet]: PWC1382: Allocate exception for servlet ClientServlet java.lang.NoClassDefFoundError: org/me/calculator/CalculatorWS at java.lang.Class.getDeclaredConstructors0(Native Method) at java.lang.Class.privateGetDeclaredConstructors(Class.java:2389) at java.lang.Class.getConstructor0(Class.java:2699) at java.lang.Class.newInstance0(Class.java:326) at java.lang.Class.newInstance(Class.java:308) at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1132) at org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:832) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:197) at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:271) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:202) at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632) at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577) at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:94) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:206) at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632) at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:571) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1080) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:150) at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632) at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:571) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1080) at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:272) at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.invokeAdapter(DefaultProcessorTask.java:637) at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.doProcess(DefaultProcessorTask.java:568) at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.process(DefaultProcessorTask.java:813) at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.executeProcessorTask(DefaultReadTask.java:341) at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:263) at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:214) at com.sun.enterprise.web.portunif.PortUnificationPipeline$PUTask.doTask(PortUnificationPipeline.java:380) at com.sun.enterprise.web.connector.grizzly.TaskBase.run(TaskBase.java:265) at com.sun.enterprise.web.connector.grizzly.ssl.SSLWorkerThread.run(SSLWorkerThread.java:106) Caused by: java.lang.ClassNotFoundException: org.me.calculator.CalculatorWS at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1498) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) ... 33 more ===============================================================================================
Created attachment 65336 [details] Sceenshot1
Created attachment 65337 [details] Sceenshot3
I don't see anything specific to WSIT in this report, thus reassigning.
Looks like the servlet creation failed in the web project. Investigating more. Reporter, please, give us the GlassFish version you used there.
I suppose the GlassFish V2 was used there - according to the tutorial.
Glassfish Version and build : 9.1_02 (build b04-fcs) jdk version : jdk1.6.0_05
can you attach also IDE log, please? The exception can be the same as is in issue 141250 (which has nothing to do with web services) or issue 138642...
where i can get IDE log?
The log file for the IDE is located as follows: $HOME\.netbeans\$release_num\var\log\message.log You can also open this file from the IDE Tools menu by choosing Tools > IDE Log File.(*) (*) http://wiki.netbeans.org/VwpFaq_LogFiles
Created attachment 65348 [details] log file
thanks. The exception is already tracked in issue 138642
There are actually 2 issues there ; The first issue is related to recent "Deploy on Change" feature (that can be switched off in Project Properties. See issue 141317. However this doesn't breaks any functionality, I think. The second issue is pretty serious: JAX-WS2.1 Client stub and other java artefacts generated from wsdl are not included to war file. I'm working on that issue now.
This is the result of investigation: Web Services support generates jaxws-build.xml files with some targets(see the example): "wsimport-client-XXX" target: generates JAX-WS artifacts (java sources) to build/generated/wsimport/client directory "wsimport-client-compile" target - uses IDE compiler to compile java artifacts into build/web/WEB-INF/classes we set up some dependencies, e.g. "-do-compile" and "-do-compile-single" depend on wsimport-client-compile "Build" and "Clean&Build" actions work properly. "Run" action removes the content of build/web/WEB-INF/classes directory and re-compiles only the source roots to this directory (doesn't call wsimport-client-compile) - that is the problem of this issue. It's a result of recent "Deploy on Save" feature implementation. Moving this issue to web project. Please, either fix the issue or suggest what other dependencies should be set up in build-impl.xml to protect jax-ws artifacts in build/web/WEB-INF/classes directory from removal (Run action removes entirely the content, of that directory and, re-compiles only the sources).
The workaround for now is to switch off the "Deploy on Change" feature in Web application -> Project properties -> Run section.
The problem is not only in web application. Run action removes all JAX-WS/JAXB artifacts that were generated to build/web/WEB-INF/classes (web project) or to build/classes (J2SE Project).
What build are you using? I modified the overridden javac task not to clear the build dir (should only clear .class files) last Friday.
I reproduced this behavior today with Milan on build from 23 July timestamp 100325.
Ah. Seems to be mixture of several problems. One of them is that the SourceForBinaryQuery is still wrong - it does not return the generated source root for build/classes (and dist.jar). Two subproblems here: the JaxWsSourceForBinaryQueryImpl does not answer the query for build/classes (for J2SE Project), and LookupMergerSupport.createSFBLookupMerger actually will not merge anything, it will simply use the first answer. I am attaching patches for these two problems. When this is fixed, the web service clients should work for Web Projects (I was not able to follow the steps to reproduce, so I am not completely sure). Tomas, Milos and Milan, could you please review the patches. I would like to integrate in 24 hours. A few more tweaks will be necessary to make it nice. More work will be needed for J2SE projects.
Created attachment 65467 [details] Patch for JaxWsSourceForBinaryQueryImpl.java
Created attachment 65468 [details] Patch for LookupMergerSupport
Thank You. I am testing the patches now.
The patches you sent helped in J2SE Project. Unfortunately in web project it didn't. - I added JaxWsSourceForBinaryQueryImpl instance into web project lookup - then I noticed, unlike in J2SE project, the method LookupMergerSupport.SFBIMerged.findSourceRoots(URL binaryRoot) was not called. I applied the patch for JaxWsSourceForBinaryQueryImpl, and added JaxWsSourceForBinaryQueryImpl instance to web and ejb project lookup. Here is the diff (JaxWsSourceForBinaryQueryImpl) : http://hg.netbeans.org/main?cmd=changeset;node=25d553fdf5ca and LookupProvider for web/ejb: http://hg.netbeans.org/main?cmd=changeset;node=99b7616ccf39 Please try to look why the LookupMerger for SourceForBinaryQueryImplementation is not working in web project. (I don't exactly know how is the project's Run action related to SourceForBinaryQueryImplementation LookupMerger).
mkuchtiak: maybe web projects don't use the LookupMergerSupport.SFBIMerged factory method and have their own impl of the merger implementation?
to mkleint: Web project uses the same LookupMerger<SourceForBinaryQueryImplementation> than J2SEProject: private Lookup createLookup(AuxiliaryConfiguration aux, ClassPathProviderImpl cpProvider) { Lookup base = Lookups.fixed(new Object[] { ... LookupMergerSupport.createSFBLookupMerger(), ... Problem is that Run action doesn't invoke it, unlike in J2SEProject.
*** Issue 141150 has been marked as a duplicate of this issue. ***
The problem with WebProjects seems to be that they do not have JAXWSClientSupport in their lookup, so the JaxWsSourceForBinaryQueryImpl does not work for them. When I have added the JAXWSCS to the Web Project lookup (simply putting "apiJAXWSClientSupport," at line 489 of WebProject.java), the SourceForBinaryQuery started to work correctly. When experimenting, please make sure to call "Clean" before "Run" (the content of .../classes is filled only once, so if the content of .../classes becomes broken, it may not correct automatically). 99b7616ccf39 seems bogus to me - the meaning of the call to Lookups.fixed is (IMO): create a lookup with two items, one will be an object array and the second one the SFBQI. I am going to correct this, hope you won't mind.
Honza, in issue 141091 I'm claiming that JaxWsSourceForBinaryQueryImpl is wrong by returning always a result - it should return a result only if a file in question is a class generated by WS. But you say in this issue that it is OK and that it is project's SFBQ merger which is wrong by not merging results properly. I'm fine going with that but I would want to emphasize that we are changing behaviour here and we should be quite careful about that as it may have consequences. Re. "JAXWSClientSupport not in WebProject's lookup" - WS guys maintain this part of code so it's up to them
The SFBQ itself needs (IMO) to return all source roots that were used to produce the given binary root. For J2SE Project with web services, build/classes contains classes that originate in src/, build/generated/wsimport/client/ (and possibly other) source roots and therefore the SFBQ should return them all. So the LookupMerger for SFBQ needs to merge the results correctly IMO. I think that the web service provider should ideally answer only when the webservices are enabled (and only to build/classes and dist.jar), but this is a different, much smaller and more difficult problem (it is difficult to listen on "null" :-) ), so I propose to leave this out for now. I am going to add the better merging into the SFBQ LookupMerger, which should solve the immediate problem described in issue #141091 if I understand it correctly. May take a little while, I am experiencing platform8 vs. platform9 problems :-(.
I have improved the merging capabilities of the LookupMerger: http://hg.netbeans.org/main?cmd=changeset;node=9815505bc632
Did the latest fixes in the code have any effect on this issue?
JAXWSClientSupport still needs to be added to WebProject's lookup, right? Up to Milan to fix.
One another change in JaxWsSourceForBinaryQueryImpl. JAXWSClientSupport instance was incorrectly retriewed from the project. Fix: http://hg.netbeans.org/main?cmd=changeset;node=8f025f57321e Now the problem is almost fixed (except of combination Clean && Run in J2SE Project) My suggestion is to close this issue and open another one with lower priority.
I will file a new issue for the J2SE Project problems, closing this one for now.
Verified in NetBeans IDE Dev (Build 200809220201).