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.
Summary: | Wsit client creation not working using Netbeans nightly build(200807221016) | ||
---|---|---|---|
Product: | javaee | Reporter: | anand_mishra <anand_mishra> |
Component: | Web Project | Assignee: | Jan Lahoda <jlahoda> |
Status: | VERIFIED FIXED | ||
Severity: | blocker | CC: | dkonecny, jeff_rubinoff, jglick, jlahoda, mgrebac, mkleint, mkuchtiak, phejl, pjiricka, tzezula |
Priority: | P1 | ||
Version: | 6.x | ||
Hardware: | Sun | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: | |
Attachments: |
Sceenshot1
Sceenshot3 log file Patch for JaxWsSourceForBinaryQueryImpl.java Patch for LookupMergerSupport |
Description
anand_mishra
2008-07-23 09:56:37 UTC
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). |