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 5/30 IDE dialy build with JDK 5.0, SDK build 4 on Win XP Fail to execute the deployed achived webservice project, got the following error message when using the appclient to execute the Steps to recreate: (1) Create the achived project for the attached webservice file jaxrpc-simple.ear (2) Deploy the archived project (3) Use the following two steps to run the app, the run fails. I tried to deploy the original .ear file which is in the j2ee1.4 sample, then run it, it worked fine. So it indicates the archived project get error some where. asadmin get-client-stubs -u admin --appname jaxrpc-simple . (the above step gets .jar file to the current directory) appclient -client jaxrpc-simpleClient.jar (the above step run the app client) -------- Error message from appclient output ----------- appclient -client jaxrpc-simpleClient.jar May 30, 2006 5:52:25 PM com.sun.xml.messaging.saaj.soap.MessageImpl identifyCont entType SEVERE: SAAJ0537: Invalid Content-Type. Could be an error message instead of a S OAP message java.rmi.RemoteException: HTTP transport error: com.sun.xml.messaging.saaj.SOAPE xceptionImpl: Invalid Content-Type:text/html. Is this an error message instead o f a SOAP response?; nested exception is: HTTP transport error: com.sun.xml.messaging.saaj.SOAPExceptionImpl: Inva lid Content-Type:text/html. Is this an error message instead of a SOAP response? at samples.webservices.jaxrpc.simple.HelloIF_Stub.sayHello(HelloIF_Stub. java:87) at samples.webservices.jaxrpc.simple.HelloClient.main(Unknown Source) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at com.sun.enterprise.util.Utility.invokeApplicationMain(Utility.java:23 2) at com.sun.enterprise.appclient.MainWithModuleSupport.<init>(MainWithMod uleSupport.java:329) at com.sun.enterprise.appclient.Main.main(Main.java:180) Caused by: HTTP transport error: com.sun.xml.messaging.saaj.SOAPExceptionImpl: I nvalid Content-Type:text/html. Is this an error message instead of a SOAP respon se? at com.sun.xml.rpc.client.http.HttpClientTransport.invoke(HttpClientTran sport.java:165) at com.sun.xml.rpc.client.StreamingSender._send(StreamingSender.java:113 ) at samples.webservices.jaxrpc.simple.HelloIF_Stub.sayHello(HelloIF_Stub. java:70) ... 8 more
Created attachment 30684 [details] j2ee1.4 sample app
I'd mark this INVALID, because this is "proxy issue" (Ethereal or eg. tcpmon (tcpmon.dev.java.net) can be used for prove). Running the client with following (or similar) command should help: appclient -J-Dhttp.proxyHost=... -J-Dhttp.proxyPort=... -client jaxrpc-simpleClient.jar
Created attachment 30716 [details] good xml
Created attachment 30717 [details] bad xml
Jungi: But the app client isn't being run from inside netbeans.... I think this is an issue in the sun dd editor/processing. The editor/configuration manager has added content to the sun-web.xml that seems to be causing this issue. I have tried to edit the content out, but haven't been able to. If I change the sun-web-app.servlet.webservice-endpoint.endpoint-address-uri from "HelloIF" (the value that was generated) to "simple", the app works.
How did you get two web service endpoints into the same sun-web.xml? I tried this, using the attached EAR, and after editing, there is only one, which is correct. Certainly two of them is bogus.
I originally had just one, also. I tried to comment it out, but when I saved the file, I got an entry with two endpoint thingies...
forgot to update cvs with fix that will make it possible to get to the point I was at. Sorry.
Vince: the command I've suggested was for running outside of the IDE (running of appclient from the IDE is handled a little bit differently then from the outside). I'm not saying that the issue cannot be anywhere else, but usually (= according to my experience), when similar stacktrace/exception appears, it means that client cannot connect webservice (and that's "usually" - from my experience - due to incorrect proxy settings)
There is no default configuration for the web service endpoint so the configuration code added one. The configuration it added is wrong though for this type of port configuration becuase it uses wsdl-port configuraion rather than service-endpoint-interface and endpointURI. Oops, we'll have to fix that.
Some of the prior conclusions are wrong. Here's the problem: There is code in the plugin to automatically configure the endpointAddressUri field in sun-web.xml or sun-ejb-jar.xml for a web service that does not have any explicity port configuration. Setting this field affects the URL for the soap:address element for this port in the WSDL file for the service. If the client is always generated from the newly published WSDL file, this isn't a big deal. However, if the client is generated from a non-published or previously published (before the change to endpointAddressUri) WSDL file, then the code generated for the client will be generated to access the wrong address. In this example, there is a preexisting WSDL file shared between the web service and client modules that uses a different address for the service/port than would be used based on our generated endpoint address value. After consulting with Vijay, I'm decided to remove the code that auto-configures the endpoint address in sun-???.xml. It's just plain wrong. IIRC, it was added toward the end of the NB 4.1 dev cycle to normalize the service address between web and ejb hosted services and also to bypass examining the WSDL file directly for this address because we didn't have a decent WSDL model. If a client or a client project needs information on the service/port address, they should use a published WSDL file and consult it directly.
Fixed. http://serverplugins.netbeans.org/source/browse/serverplugins/sun/sunddui/src/org/netbeans/modules/j2ee/sun/share/configbean/WebServiceDescriptor.java?r1=1.4.2.2.2.6&r2=1.4.2.2.2.7
In 8/21 build, I was able to deploy the achived webservice project and ran it. Thanks for the fix !