Top-posting (as I am doing here : writing every response at the top of the message), makes
it difficult for others to follow the flow of the conversation.
Better to put your responses under the question or paragraph to which they
relate.
See below.
DeMarco, Alex wrote:
I have 4 servers all configured the same way.. Locally the call works fine yet
remotely I get an iis 404....
- Alex
-----Original Message-----
From: DeMarco, Alex [mailto:alex.dema...@suny.edu]
Sent: Wednesday, June 13, 2012 8:45 PM
To: Tomcat Users List
Subject: RE: Jakarta ISAP Redirector
Yes I have looked in the log file and set it debug. There are no errors logged.
My uriworkermap has this:
/myapp=DTS_Submission
/myapp/*=DTS_Submission
My Workers file has:
worker.list=DTS_Submission
worker.DTS_Submission.type=ajp13
worker.DTS_Submission.host=xxx.xxx.xxx.xxx
worker.DTS_Submission.port=3305
The above configuration looks fine, provided that the IP address "xxx.xxx.xxx.xxx" is
really the IP address of the Tomcat host, as IIS sees it.
If I am locally on the box (with a local host entry that maps to the same IIS
site on that box) it works fine.
However, from my desktop I get a page could not be found... However, it says
it can't find http://myurl:80/jakarta/isapi_redirect.dll
It would never find this resource, unless :
- either you do have a subdirectory "jakarta" in your IIS document space
- or you have a isapi_redirect mapping which maps this URL to Tomcat, and tomcat has a
webapp named "jakarta"
And even if it found it there, it would then return the dll to the browser. That is
certainly not what you want.
Do you understand the above paragraph, really ? It is important, because if you do not
understand that, then it will be very difficult to help you here.
And anyway, why are you giving this as an example ? it is totally irrelevant. In the
uriworkermap that you list above, you are mapping URI's starting with "/myapp". You are
not mapping URI's starting with "/jakarta" or anything else, so why would you expect this
to be relevant ?
I have double and triple checked my config.
From my desktop this works:
your desktop where ? be precise, please. Try not to force us to guess at each
step.
http://myurl/myapp/services/mywebservice?wsdl
By "myurl" you mean the hostname, yes ?
(then say so, plase. The URL is the whole thing
"http://myurl/myapp/services/mywebservice?wsdl";.)
but this fails
http:// myurl/myapp/services?wsdl
What is that space there ? if it is really there, then no wonder it fails.
And /how/ does it fail ? "it fails" doesn't mean anything, technically
speaking.
but when on the local sever everything works. I see no errors in the log.
It's like IIS is stopping the request??
Very carefully said : yes, it looks that way. Why, I have no idea. But at this point it
does not look as if it has anything to do with the isapi_redirector.
With the configuration which you show above, and as far as only isapi_redirector is
concerned, all the URI's that (after the hostname part) start with "/myapp", should be
forwarded by IIS and isapi_redirector to Tomcat, and the isapi_redirector log should show
that.
It would be very strange if something at (or before) the IIS level was allowing URI's like
"http://myurl/myapp/services/mywebservice"; to go through, but was blocking URI's like
"http://myurl/myapp/services";. But only you know what is in the configuration of that
server, its firewall, etc..
Maybe "services" is something defined somewhere in IIS, and directed somewhere else (or
forbidden) ?
You need to design a test setup in which you can check this systematically.
For example :
Under the IIS wwwroot, create a sub-directory /myapp/, and put some document test.html
there. Then with your browser, try to access http://yourhost/myapp/test.html. And note
the result.
Then create a sub-directory wwwroot/myapp/services/, put a document test2.html there, and
try to access it, and note the result.
etc..
Do this both from a browser on a separate workstation, and from a browser running on the
IIS host itself. Then compare the results, and also look in the isapi_redirector logs.
And then think.
The answer is somewhere in the configuration of the browser, the network, the host, IIS,
isapi_redirector or Tomcat. We do not have access to those things; but you do. You must
make a list of what could be happening, and then design tests to rule out one or the other
possibility. When you are left with only one, then that is the answer.
And stop top-posting.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
