Bug 57542

Created attachment 21423 [details]
WSDL to test

Created attachment 21425 [details]
Exception from Test Operation. I had to attach it as GIF, because Ctrl+C copy it without CRLF.

This is in messages.log:

6.4.2005 14:59:38 com.sun.xml.messaging.saaj.soap.MessageImpl identifyContentType
SEVERE: SAAJ0537: Invalid Content-Type. Could be an error message instead of a
SOAP message
6.4.2005 14:59:38 com.sun.xml.messaging.saaj.soap.MessageImpl <init>
SEVERE: SAAJ0535: Unable to internalize message

Both appserver and web service are running. When I create own ws client it works
without problems.

I have next observation. When I got this exception, I remembered URL of my web
service used for registration. I exited IDE and started IDE with new userdir. I
registered AppServer and only added Web Service to the Web Service Registry - I
used remembered URL. I invoked Test Operation and it worked! I exited IDE and
started IDE with previous (first) userdir and invoked Test Operation - it still
didn't worked. I exited IDE and returned back to IDE with second userdir. I
invoked Test Operation and now it threw exception. I deleted it from Web Service
Registry and added again and then it worked. 

When I did all of these, appserver was running and I didn't change anything, I
didn't redeployed any application. So Test Operation worked in one IDE and
didn't worked in another so it might be a bug in IDE and not in appserver.

Based on the bug description, this is what I think -- I'll confirm or update
once I've been able to investigate exactly which of these cases it is.

Looking at it right now -- if the bug is what I think it is, there are two ways
to interpret it:

A) The registry cannot expose two distinct WSDL's that refer to the same service
name -- cannot be fixed for 4.1.  Rave cheated to handle this case, we can't.

B) The "New Service From WSDL" option does not take the service name as
specified by the user (e.g. "GoogleService1") and use it in the WSDL.  In this
bug report, if this had happened, I would expect the actual service names should
have been different and the cause is something else -- I'm investigating this
right now.

If the reason is (A), then there is nothing we can fix here for 4.1 -- too hard
and disruptive. 

Ok, I actually investigated this problem.  Forget my first hypothesis.

The two services (one each in two webapps) do maintain the distinct name
(GoogleWebService1, GoogleWebService2) in each project.  And actually, I was
able to follow the steps as written and have no problem testing either service
after creating them and adding them to the registry.

I was able to test both successfully.  I was able to shutdown the IDE and
restart, start the server, and retest both clients successfully without
redeploy.  This was all on Windows XP.

Shutting down the IDE, removing the user directory, restarting, reinstalling and
starting the appserver and re-adding both web services to the registry also
produced working clients in test mode.

The only thing I can possibly think of, and I don't see how it could apply to
such strict steps, is if you did this on a laptop, shut down the computer,
restarted on a different port (such as switching to VPN from home).  Then the
WSDL files that built the existing clients would have the wrong IP address and
would not work.  But the clean userdir option should fix that, because in that
case, the services are re-added.

This bug sounds like a dup of a bug that I believe was finally closed as "cannot
reproduce".  In that report, I made the suggestion to the reporter to do the
following:

On the machine that reproduces this problem do this:

When a particular service works, go the browser with the WSDL URL, download it
and attach it to the bug report as the "working WSDL".  Next, go through the
tests to make the client not work.  Now go back to the browser, give it WSDL URL
again and download the WSDL a second time.  Attach it as "non-working WSDL" or
if the service is not working, add that comment to the report.  You can also
check to see if the WSDL files compare the same (they should, but may not, which
could help identify the problem.)

For this report, I'd expect 4 wsdls (2 each working and non-working) to be attached.

Please respond to query for more info (last paragraph in previous comment) or
close this as WORKSFORME.

I neither restarted IDE not computer. I haven't restarted appsever.

I compared WSDL when web service was working and then when "wasn't" working and
they are identical. Then I paralelly started second instance of IDE with new
userdir, registered same appserver and added webservice created in first IDE to
Web Service Registry (by WSDL URL). Here Test Operation worked so web service
*is* working and only can't be executed from first IDE. 

My colleague wasn't able to reproduce this issue too so maybe it's again one of
issues which I am the only one who can reproduce it.

This seems to be linked to an env issue...
What is so special about your config or computer?
Can you attach ide and server logs, any other info that would be different than
our systems?

just found http://forum.java.sun.com/thread.jspa?threadID=482307&tstart=135,
maybe it can be helpful

Hi all, I am able to reproduce this issue on my NTB with Linux OS, message.log
is attached.

Created attachment 21500 [details]
NB message log

We've just test this little bit more and here is our result:

for the steps described above:
 - we can reproduce this on notebooks (2x winXP, 1x linux)

 - we cannot reproduce this on desktops (1x winXP, 1x Mac)


additional steps:
 - test websvc, which runs on notebook, on desktop => SAAJ0535 as above

 - test websvc, which runs on desktop, on notebook => successfull

Is it conceivable that the IP address or name of the computer would have changed
between when the service worked and when it did not?  This might explain some of
the connection refused messages (though the other SOAP errors are still
unexplained.)

Also, is that a clean log, in that it was empty prior to attempting the steps in
this issue and all the errors therein were accumulated only by performing these
steps (once)?  I ask because there are an awful lot of errors in there -- do you
know what the action was that caused the first few errors to be recorded.

Created attachment 21531 [details]
IDE log

Created attachment 21532 [details]
server.log

IP and name is same for all the time of the test. One difference between desktop
and notebook is DNS name. My notebook's name is libor-nb, but because I get IP
from DHCP, my name in DNS is general, e.g. d-eprg05-75-195, so name libor-nb is
not working outside my computer.

Libor, Petr Blaha and I did VNC session where they demonstrated this behavior to
me.  It appears that on machines where this situation occurs, it is easy to get
into an invalid state where no clients work and once such a state is
encountered, the only way to fix it is to delete the user directory and start
over (probably deleting just the websvc subdirectory of the user directory will
work, but we did not test this.)

I examined the client jars that were created and then failed to work and they
appear fine.  I still do not have a clue as to what the problem is, though on
systems where this happens, test mode appears irretrievably broken once it happens.

I will discuss this with the JAXRPC team to try to get a better understanding of
the actual failure.

*** Issue 52685 has been marked as a duplicate of this issue. ***

Comments from JAXRPC team:

This is an error from SAAJ. This usually happens when the server responds with a
non-soap message, usually it is a standard web page error.  You should use a
network sniffer to see what the server is sending back.  My guess is that the
client is not sending the request to the proper address.  - Doug

Looks like the exception is coming from SAAJ, due to parsing of http headers or
SOAP  message(incorrect). There should be CAUSE messages in the full exception
stack trace. Without the complete stack trace, it's difficult say where exactly
SAAJ failed.  - Jitu

I'm not able to reproduce on my notebook.

According to Doug (JAXRPC team) and also help for this error message, this is
likely related to malformed SOAP data.

I enabled HTTP monitor on the application server to see if I could at least
indirectly view SOAP packets through that.  The HTTP POST request from <Test
Operation> shows up, but I was unable to retrieve the raw data for the message.
 This may simply be how HTTPMonitor works, or maybe I was using it incorrectly.

I think that in order to solve this problem we will need to determine exactly
what is wrong with the communication in the cases where it fails.

The HTTP Monitor won't be much helpful since it can't display message body as
raw data yet.

A network sniffer like www.ethereal.com would definitely do much better job in
this case.

We have it! It's caused by proxy. If I turn on proxy, Test Operation doesn't
work at all.

When proxy is turned off, HTTP request is "POST /WS1/NewWebService1 HTTP/1.1"
and it works. When proxy is turned on, HTTP request is "POST
http://localhost.czech.sun.com:8080/WS1/NewWebService1 HTTP/1.1" and proxy
server has no idea about localhost.czech.sun.com. On another computer there is
correct hostname instead of localhost, "POST
http://libor-nb.czech.sun.com:8080/WS1/NewWebService1 HTTP/1.1", but because IP
is obtained dynamically from DHCP, libor-nb.czech.sun.com is not assigned to my
IP and it doesn't work too.

So it works when proxy is on only if two conditions are fulfilled: 
1. there is correct host name in query
2. computer has static IP addres

It can be solved by not using proxy for localhost and use localhost and not
hostname in request.

Created attachment 21657 [details]
TCP dump when proxy is turned on

Great to know why!!!
When you say proxy, it is the proxy settings of the IDE itself?

That's great that you found the problem.  We should be able to craft a solution
from that.  This prompts a new question though:  Why does it work the first time?

On a machine that could reproduce this, during the course of the test, no proxy
settings or server settings are ever changed.  Yet Test Operation works for the
first client until the second web application is deployed.  This seems very odd
to me.

Yes, we are speaking about proxy in IDE, avalaible here Tools | Update Center |
Proxy Configuration.
Answer to Peter's question:
The first We sesrice worked since was created from local file, then we created
second web service from URL. Therefore, we should set up proxy before generation
second web service.

Moving to Prague for finalization (release note or other appropriate action).

Setting the RELNOTE keyword.

This was discussed more today in Prague, and we think the behavior could be
improved by adding the local machine (as localhost, 127.0.0.1 and real name) to
http.nonProxyHosts. Will attempt to fix after RC1.

Showstopper, raising priority to P1.

Attaching a fix that fixes this problem on Libor's machine.

The problem is that for some specific machine configurations, Java does not
correctly resolve the machine name, so the name is something like
localhost.czech.sun.com. When deploying the web service, appserver enters the
actual URL into the WSDL file as:

<soap:address location="http://localhost.czech.sun.com:8080/WebApp/WS" ... />

Next, when the web service registry in the IDE then tries to connect to this
URL, the Java HTTP client uses the proxy set by the IDE, and the proxy can
naturally not resolve the above machine name, so it returns HTTP error 500. This
then demonstrates itself as the exception.

The IDE used to have a way to set hosts for which proxy should not be contated
(the http.nonProxyHosts system property). This code is in
core/src/org/netbeans/core/IDESettings.java, but it looks like during recent
changes this code was deactivated (revision 1.63). So the code is to set
http.nonProxyHosts again, while also extending the value of this property to
include the host name for localhost is these weird machine configurations (like
Libor's machine).

QE verified that the attached patch resolves this problem.

Jesse and Jirka R., can you please review the patch, before it it put into the
trunk? Thanks.

Created attachment 21712 [details]
Patch for IDESettings (against both trung and release41 branch)

Looks OK to me but it is Jirka who would know better.

Shouldn't the launcher try to detect the machine's proxy exclusions, too, for
use in autodetect mode? E.g. I see that core/launcher/unix/nbexec checks the
gconf keys /system/proxy/mode, /system/http_proxy/host, and
/system/http_proxy/port, yet it ignores /system/http_proxy/ignore_hosts, which
looks like what we want.

The fix is reasonable to me and the patch is correct. Please, apply it. I'll
attached the patch which allows to read ignoreHosts from system (on unix). IMHO
this fix in not needed in NB4.1, I'll change in later in main trunk. Thanks for
patch.

Created attachment 21715 [details]
patch reads IgnoreHost property from OS settings on unix

Fixed in trunk.

Checking in IDESettings.java;
/cvs/core/src/org/netbeans/core/IDESettings.java,v  <--  IDESettings.java
new revision: 1.66; previous revision: 1.65
done

verified on trunk on continuous build 20050419-1321

Fixed also in the release41 branch.

Checking in IDESettings.java;
/cvs/core/src/org/netbeans/core/IDESettings.java,v  <--  IDESettings.java
new revision: 1.65.6.1; previous revision: 1.65
done

verified in release41