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.
Several Java classes are not generated when creating a web service from the attached wsdl: no error messages are generated, and it is not clear why the classes are not generated
Created attachment 28561 [details] sample wsdl
The java classes not being generated is more of a JWSDP issue so we'll have to file that one with them. But there is a NetBeans bug wrt/ to this issue as well: The service name is "NMIStandingDataResponse", but due to name space conflicts, the java class for the service name becomes "NMIStandingDataResponse_Service". Unfortunately, the IDE code to anticipate the server name is incorrect and doesn't add the _Service portion, causing the WSDL to never synchronize with the registry. BTW: A temporary workaround for this is to go into the WSDL and change the service name to _Service. Just make sure you change it back before production (or modify the build script to package the original - that could be a bit tricky), or find a way to truely rename the actual service.
I have another simple case: I'll attach two wsdls, good.wsdl and bad.wsdl: good generates properly, bad doesn't. The only difference is in the name of the element: MYResponse in good, XmlInterfaceResponse in bad
Created attachment 28585 [details] class not generated for this
Created attachment 28586 [details] this wsdl generates ok
Both the "good" and "bad" wsdls from David generate properly in NB5.5 (wsimport). The NMIStandingDataResponse.wsdl produces a "uniqueness constraint violation" from wsimport. I verified this by running wsimport on this wsdl outside of the IDE, from the command line. Peter W, did we open a bug on jwsdp on this? Can we now close this bug?
I don't think I entered a bug for JWSDP about the bad class generation. (That probably means none was opened.) OTOH, assuming it's fixed in JAX-WS, they'll probably say fixed in later release, won't patch in older one. I thnk it should be filed anyway. Rico, can you do that?
Regarding the "uniqueness constraint violation" from wsimport when using NMIStandingDataResponse.wsdl, Vivek Pandey offered this explanation: ------------------------------------------------------------------------------ This error is due to the fact that the Response operation qualifies for wrapper style and the local name for wrapper child for request and response are the same. Since the wrapper child does not qualify for INOUT, wsimport finds that the in parameter and OUT parameter (appears as holder) have then same name and fails. Since you can't have a java signature such as echo(int foo, String foo); ---------------------------------------------------------------------------------- This can be fixed by customizing the wsdl and turning off the wrapper style in the method generation. This is not possible in NB because the error is encountered when the wsdl is being parsed for the first time at creation time where customization is not yet possible. In future releases we may want to provide customization capability at creation time. Now, since both the "good" and "bad" wsdls from David generate properly in NB 5.5, I am closing this as "WORKSFORME". David, if you don't agree, kindly reopen.
Well, bottom line is (correct me if I'm wrong), a valid wsdl fails in nb, regardless of the reason. So this is a problem that needs to be addressed, right? Thanks and regards, David
This will require an enhancement in the Create Web Service (from wsdl) wizard. The enhancement will allow the user to customize the wsdl at web service creation time. This will probably be another page in the wizard. Currently, our facility allows customization only after the web service has been created. I suggest we change this into an RFE.
Change to RFE makes sense. Thanks.
I thought we discussed this some time ago and the result was that we should allow creation of web service from wizard and then user should be able to customize and regenerate correctly? Or am I missing something?
Yes, and that is the current design. However, there are cases like this (hopefully these are corner cases) where wsimport fails because by default, wsimport uses wrapper style in generation and there are wsdls that do not qualify for wrapper style. Hence, customization is needed at web service creation time (i.e., the first time the client is generated from wsimport), otherwise generation will fail.
Changed the Summary
Closing as duplicate of http://www.netbeans.org/issues/show_bug.cgi?id=77248 *** This issue has been marked as a duplicate of 77248 ***