tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian <>
Subject Re: Distinct servlets for different domains in one web application
Date Mon, 29 Jun 2015 05:56:37 GMT

On 28.06.2015 23:11, André Warnier wrote:
> Christian wrote:
>> Mark,
>> On 28.06.2015 19:58, Mark Eggers wrote:
>>> Hash: SHA1
>>> Christian,
>>> On 6/28/2015 9:01 AM, Christian wrote:
>>>> Hello all,
>>>> is it somehow possible to create a web application with multiple
>>>> servlets that are registered to different domains for the same url
>>>> paths using tomcat 8? I already crawled through the catalina code
>>>> that is responsible for the servlet selection and didn't find
>>>> anything that would allow this. But this doesn't mean that it
>>>> isn't possible at all. As far as I know, java configuration for
>>>> servlet registration doesn't allow passing domain names. But maybe
>>>> there is an option within context.xml.
>>>> I want to create a web application that has different domains for
>>>> the application itself and its management site. Both parts should
>>>> run at the context root, at different domains. The application
>>>> needs a shared (spring-)context in which the application's beans
>>>> are stored.
>>>> Regards, Christian
>>> I'm not quite sure what your after. Sharing Spring beans across
>>> contexts and domains sounds like there's an underlying requirement I
>>> don't understand.
>> ok, I'll try to explain, as aliases won't do what I need.
>> It's an application that can be configured via an admin interface. 
>> The admin interface is one part of the webapp.
>> The main application is accessible via The admin 
>> interface needs access to the beans within the main application (e. 
>> g. to create tenants that live in context scope), that's why I 
>> created just one webapp with two dispatcher servlets.
>> One dispatcher servlet is responsible for the admin interface and one 
>> for the main application. Until now I make tomcat select them by 
>> using a context path for the admin interface.
>> But this is redundant, because the admin interface needs to be 
>> accessed via instead of just 
>> I would like to map to the admin 
>> servlet and to the main applications dispatcher servlet.
>> At a later stage, might be used for other admin 
>> tasks that must be accessible by users registered on the main site. 
>> But /admin is already shadowed.
>> Hopefully I could explain my problem a little better.
> Yes, that is much clearer.
> Honestly without having really figured out the details of your 
> explanation, I would nevertheless point you in 2 directions for that 
> kind of thing :
> a) use an Apache httpd front-end proxy, and use the httpd proxying 
> and/or URL rewriting capabilities to do what you want

thanks for your suggestion! The application anyway needs a reverse proxy 
/ ssl gateway, because tomcat isn't capable of doing TLS with SNI. Your 
proposed solution seems appropriate, although I have to figure out how 
to cleanly generate the correct urls within the application.


> or
> b) use the built-in Rewrite Valve of Tomcat 8 
> (, or if you are 
> at a lower Tomcat version, use the add-on URLRewrite Filter 
> (
> A Valve is a Tomcat-specific component, so that solution is generally 
> non-portable to another servlet container.  The others (httpd 
> front-end or the URLRewriteFilter (a servlet filter)) are portable.
> Personally, in this case, and considering that you want to do 
> different things depending on the hostname used to access Tomcat, I 
> would go the httpd front-end route, with 2 VirtualHosts at the httpd 
> level, proxying to a single Host at the Tomcat level (but in one case, 
> after modifying the URL).
> That's because I think that trying to do this at the Tomcat level only 
> may give you headaches in terms of self-referential URLs returned by 
> your application.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message