tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: deploy application in new service in tomcat
Date Fri, 08 Feb 2013 13:23:11 GMT
Anil Goyal -X (anigoyal - Aricent Technologies at Cisco) wrote:
> Hi.
> On this list, the convention is to not "top post".
> Put your answers either in-line, in the text, or at the end.
> That is much easier for others to follow the conversation in a logical order.
> Anil Goyal -X (anigoyal - Aricent Technologies at Cisco) wrote:
>> Thanks for the reply Andre.....
>> Let me explain you in detail.
>> Let's suppose we have two applications App1.war and App2.war, deployed in webapps
of tomcat.
>> Now I want only App2 to listen additionally on a separate connector port(lets suppose
8181)  along with port 8080 to which it is already listen.
>> But I want App1 to listen only on port 8080 not on port 8181.
>> So what I did, I create a new service in tomcat with name 'catalina_new' and appBase='webapps_new'
and I add a connector port 8181 in this.
>> Now I deploy my App2.war in webapps_new.
>> So after restart the tomcat, I am able to make App2 to listen on port 8080 as well
as port 8181(since App2.war is present in both webapps and webapps_new), and App1 is listen
on only port 8080.
>> Till now, everything was fine.
>> Now I do not want to have a separate appBase for service 
>> 'catalina_new', means I want appBase='webapps' for service 'catalina_new' as well
So by doing this change, my App1 also starts listen on port 8181 which is not required.
>> So what can I do to make only App2 to listen on new port under new service with 'appBase=webapps'

>> Hope you understand my query now!
> I do understand, approximately.  But honestly, your way of thinking about this is different
from mine, and I have some trouble following your idea.
> This may also be because my knowledge of the inner workings of Tomcat is limited, and
I am not even sure that what you are currently doing is even supposed to work.
> In my understanding, what is "listening" on a given port is not a webapp, it is Tomcat.
> Tomcat accepts a connection on one of the ports that it is listening to, through one
of the Connector elements of that Tomcat.
> (Until now, the webapps are not involved at all) Then Tomcat allocates this connection
to a Thread, to process the HTTP request which has been written by the client to that connection.
> Then the Thread reads the HTTP request line sent by the client, and the HTTP request
header lines.
> (Until now, the webapps are not involved at all) Then the Thread reads the "Host:" header
line in that request, and determines to which <Host> this request is addressed.  Then
the Thread loads the appropriate configuration for that <Host>, before processing the
request any further.
> (Until now, the webapps are still not involved at all)
> *Now* the Thread knows that for this <Host>, the active applications are located
somewhere, and it knows to which "context path" each application should be answering.
> So *now* the Thread can call the appropriate webapp and give it the incoming request
to process.
> So *now* one of the active webapps is involved.
> And at this point, it could be any webapp that is active within that <Host>.
> What I am trying to say, is that the selection of the port on which a request comes in
is not controlled by the webapp, and cannot be.  It is done much earlier in the cycle, and
depends only on to which port the client connects and sends his request on.
> At the moment Tomcat accepts such a request, it does not know yet neither the <Host>,
nor the webapp within the <Host>, which this client wants.  And it cannot at that point
decide to accept or refuse this request depending on which webapp it will ultimately go to,
because it does not know that yet.
> I must confess that I do not really know if your idea of doing this by having 2 <Service>
elements in Tomcat may or may not provide a way to overcome this.
> But to me, at this point, the idea seems a bit strange.
> To say the truth, I don't even know if your basic idea to restrict the access to a webapp
based on which port the request comes in, makes really sense for what your basic issue is.
> But if that is really the issue, then I would do this on the base of a servlet filter
configured for that webapp.
> You could probably use the urlrewrite filter ( for that,
which would be much easier than your current setup.
>> The flow that you explain is absolutely fine and even I have the same flow in my
mind as well.
> As you know there is one param 'deployIgnore' in Host Configuration. Can't we use that
one for that.
> As I already explained you earlier that the case is regarding the two services in tomcat
pointing to same appBase.  If we add connector port lets suppose 8080 in service 1 and 8181
in service 2 then what will happen if I hit the url
> http://ip-address:8080/App1
> http://ip-address:8080/App2
> http://ip-address:8181/App1
> http://ip-address:8181/App2
> It will give 200 Ok response in all the cases .
> Now what if with port 8181, I want to access App1 only means now what I want is
> http://ip-address:8080/App1  should be 200OK
> http://ip-address:8080/App2 should be 200OK
> http://ip-address:8181/App1 should be 200OK
> http://ip-address:8181/App2 should be 404 Error
> To achieve this, what I want to do in server.xml of tomcat.
> How can I achieve that App1 should be accessible from both the ports 8080 and 8181, App2
should be accessible from 8080 not 8181.
> I think we can add deployIgnore="App2" in Host configuration of new service in server.xml
to make App2 not accessible at new port 8181 
> What you suggest??
I will repeat what I said before : I think the way that you are thinking about this (with

the second <Service>) is too complicated, and may trigger side-effects that you do not
What I would do is :
- use a normal Tomcat installation, with one Service etc..
- deploy your webapp1 and webapp2 applications normally
- however, in webapp2, add a servlet filter (urlrewritefilter), and in that filter you 
/can/ test on which port the request came in, and then return a 404 error if it is not the

port that you want.

The additional advantage is that this kind of setup is totally standard for a java servlet

container, and servlet filters are standard for all servlet containers. So this 
configuration would be totally portable.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message