tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: Jakarta ISAP Redirector
Date Thu, 14 Jun 2012 08:15:53 GMT
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 [] 
> 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.port=3305

The above configuration looks fine, provided that the IP address "" 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 

> 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

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.

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:
For additional commands, e-mail:

View raw message