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.

Bug 50103 - wsdl file for ws client is not checked
Summary: wsdl file for ws client is not checked
Status: VERIFIED FIXED
Alias: None
Product: webservices
Classification: Unclassified
Component: Code (show other bugs)
Version: 4.x
Hardware: PC Windows XP
: P2 blocker (vote)
Assignee: Martin Grebac
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-10-07 15:21 UTC by Lukas Jungmann
Modified: 2005-02-02 12:33 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
stackTrace (3.17 KB, text/plain)
2004-10-07 15:26 UTC, Lukas Jungmann
Details
DemoApp with WS, WS client and servlet (82.30 KB, application/octet-stream)
2004-10-07 15:28 UTC, Lukas Jungmann
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Lukas Jungmann 2004-10-07 15:21:35 UTC
nbbuild: 041007

1. create new WebApp
2. add WebService
3. add WebService Client
4. add Servlet
5. call WebService operation from servlet
6. run webapp
7. java.rmi.RemoteException

Test Method option on webservice works fine.
Comment 1 Lukas Jungmann 2004-10-07 15:26:29 UTC
Created attachment 18129 [details]
stackTrace
Comment 2 Lukas Jungmann 2004-10-07 15:28:02 UTC
Created attachment 18130 [details]
DemoApp with WS, WS client and servlet
Comment 3 Petr Blaha 2004-10-07 16:49:11 UTC
When I tried this web application on my PC I got same exception. Then
I call web service from other web project and this case is working OK.
Comment 4 Petr Blaha 2004-10-07 16:50:09 UTC
Maybe, this issue is related to case when you call web service from
same web application.
Comment 5 Roderico Cruz 2004-10-07 20:57:57 UTC
From the stack trace, you will get this error if the wsdl used in
creating the web service client is an incomplete wsdl, that is the
wsdl that does not have the actual URL of the deployed web service in
the app server. 
Here's how it works: when wscompile generates the wsdl, it will have
"REPLACE_WITH_ACTUAL_URL" as the SOAP address in the service portion
of the wsdl. When the web service is deployed in the JSR-109 enabled
app server, this value is replaced by the actual URL of the SOAP
address in the app server , e.g.,
http://localhost:8080/MyWebApp/MyWebService.
So to get this wsdl, deploy the web service first. The deploy process
will put this concrete wsdl in the build directory which you can then
use to create the web service client, and you will get past this error.
However, when I did this and ran the servlet, I get another error, an
IllegalArgumentException, so I'll keep on digging....
Comment 6 Petr Blaha 2004-10-13 10:40:24 UTC
Remove all issues from temporary component.
Comment 7 Lukas Jungmann 2004-12-06 19:00:11 UTC
Section's 7.1.2 and 7.1.4 of JSR-109 are very good reading. According
to that I have one comment to your description of how it works:

"So to get this wsdl, deploy the web service first. The deploy process
will put this concrete wsdl in the build directory which you can then
use to create the web service client, and you will get past this error."

If i understood mentioned sections in JSR-109 well then building of
project with web service creates wsdl file with string
"REPLACE_WITH_ACTUAL_URL" in the build directory and the deploy
process changes this string to some URL. This changed wsdl file (which
is the correct one) is placed in directory where this app is deployed
(something like
AS_HOME/domains/domain1/applications/j2ee-modules/<appname>).

So now i know that I've used bad wsdl file when i was creating
WebService client - as you said.

Is it possible to warn user that he wants to use "invalid" wsdl file
(in New Web Service Client dialog)?
Comment 8 _ pcw 2004-12-07 03:00:59 UTC
Yes it is possible, and this issue is on the table to be resolved in
some better way, including and beyond what you are suggesting.
Comment 9 Lukas Jungmann 2004-12-07 12:31:56 UTC
Due to discussion above the summary of this issue has been changed.
Comment 10 Martin Grebac 2005-01-11 13:29:42 UTC
I'll fix this for 4.1
Comment 12 Lukas Jungmann 2005-02-02 12:33:16 UTC
v. in 200502012121