Re: Distinct servlets for different domains in one web application

[Christian <cm...@famiru.de>]

Chris,

thanks for your brief description of the different options.

On 30.06.2015 19:38, Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Christian,
>
> On 6/28/15 12:01 PM, Christian wrote:
>> 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?
> Yes, but it has nothing to do with Tomcat: you have to do the work
> yourself.
>
>> 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.
> Right: this isn't something that the spec requires, and it's usually
> not something that the server would get involved with. But, as I said,
> you can do it yourself; you have all the tools you need.
>
>> 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.
> Nope.
>
>> 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.
> If you want to support more than one (DNS) domain, you'll need to make
> sure that your application is deployed into a <Host> that is either
> the default <Host>, or one that matches all of the domains you want to
> use. Fortunately, Tomcat comes pre-configured with a single, default
> <Host> that does just that. You have nothing to do but drop your WAR
> file into webapps/ and let it auto-deploy.
>
> That's where Tomcat pretty much stops being involved, and you get to
> do the rest of the work.
>
> You mentioned that you had two servlets, and you want one to handle
> everything to one domain, and the other servlet handles the other
> stuff. For the sake of argument, I'll call those domains
> management.app.com and everythingelse.app.com.
>
> Let's assume you have these two servlets defined in web.xml:
>
>    <servlet>
>      <servlet-name>ApplicationServlet</servlet-name>
>      <servlet-class>com.app.ApplicationServlet</servlet-class>
>    </servlet>
>    <servlet>
>      <servlet-name>ManagementServlet</servlet-name>
>      <servlet-class>com.app.ManagementServlet</servlet-class>
>    </servlet>
>
> ... and you have them mapped:
>
>    <servlet-mapping>
>      <servlet-name>ApplicationServlet</servlet-name>
>      <url-pattern>/app</url-pattern>
>    </servlet-mapping>
>
>    <servlet-mapping>
>      <servlet-name>ManagementServlet</servlet-name>
>      <url-pattern>/manage</url-pattern>
>    </servlet-mapping>
>
> If you want, I suppose you could map the ApplicationServlet to /. It
> doesn't really matter.
>
> At this point, anyone visiting your application could hit either of
> the two mapped URL patterns to get to either servlet.
>
> Let's assume that all you want to do is make sure that the management
> servlet is only available when you use the management.app.com domain
> name. Write a Filter that detects the domain name and throws you out
> if it's not "management.app.com". Map this filter to "/manage" and you
> are done.

That's something I already do (with little variation). The missing step 
is just to beautify the URLs.

> Or, if you'd like for any request to any URL to go to either /app or
> /manage, then you'll want to write a Filter that does something like thi
> s:
>
>    public void doFilter(...)
>    {
>        String domain = // ...
>        if("".equals(domain))
>          application.getNamedDispatcher("ManagementServlet")
>                     .forward(request, response);
>        else
>          application.getNamedDispatcher("ApplicationServlet")
>                     .forward(request, response);
>    }
>
> Map this Filter to "/" and let it handle everything. Make sure you
> don't map it to FORWARD requests, or you'll end up with infinite
> recursion.
>
> You'll need to grab the ServletContext in the Filter's init() method
> and keep it around (as "application").
>
> At this point, you can even remove the <servlet-mapping> elements from
> your web.xml: users will have to access the application through your
> Filter no matter what.

I already tried an approach with a filter using getRequestDispatcher but 
ran into issues with spring-security. One needs to hook up 
forward-requests for the security filter. My conclusion of this approach 
was, that it works, but a second roundtrip through tomcat is an 
overkill, especially with the ugly configuration issues that arise 
within spring-security.
I need to find out if it behaves the same way with getNamedDispatcher.

> Hope that helps,

Yes it does - at least because you confirmed my assumption that there is 
no way to map a servlet to a domain name and tomcat doesn't provide a 
proprietary way to do so.

Thankful regards,

Christian


> - -chris
> -----BEGIN PGP SIGNATURE-----
> Comment: GPGTools - http://gpgtools.org
>
> iQIcBAEBCAAGBQJVktP7AAoJEBzwKT+lPKRYEtAP/0PlUEpG+4A7d7LzDkHsFi/N
> 6Hsqayn8aBL6pSXMuCBhDgmzj6JnxZ2ZrzevhksYxLLtlyhJjrhTE0VdwtASz4nH
> mepVKvbaRJZ3KCeupDlTLI+YF9BRlPvUEwSuq2FW2kzH4eu7XFJ2GmoZ0HQ2xPqy
> MxQ/fkLb4HZKxnF7QVAa3FrnzuINQteEp6LCOxV7ONQMU2/s/iO/JuY/LOqTHeUQ
> 5M2mIIZPtdJa26QDEoAjn+dxaWU00Cl/whobrPOX/On7wVt9DZOxic15u7jWqixV
> XukZe4HqFI5RQop3PtODD+BzoUY02evs15TVl7tqLkmxQreH5ZBd5Q7BEfX7I69S
> KP/AQYG5cSEenNrgApVe/ikFg4C3A0rn60dHviO+8grn5SDgLXQC/50+16Tjv6ix
> 3L1qBgyD2QD4DKj9Piv/GGZqrxJoi+ubaOtTn0keWBeJ3v+gYRxMxHJ8Gww3kSW5
> NpGTSfl0mbQJCGXeBG9wPLyPRsXLLz1x3uW8z+YFr+GBYpEezEwHvRhDum/VEWd9
> UeavOdcJlj2805ZUdMi6JX4FiRKX8TO6rR8LNCes/OhzbUorj19AvKSvAKh/+14J
> hnvnyN3IcHjwl1oPOeSSH+Y0hxYkP3qolFGA8MRAJ2VVFDuP51DNqHNz0MySn5NS
> 9UyWgIqFzKXO/s/tiiPZ
> =tNIx
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org