You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Jonathan Mast <jh...@gmail.com> on 2009/06/24 20:08:02 UTC
The best place for implementing context specific behavior?
I have a webapp that I would like to behave in a context (actually
host)-specific manner. Where is the best place to initialize the
context/host specific functionality?
Let me demonstrate what I'm talking about. Lets say I have a webapp Fruit
located in folder webapps/fruit.
I want to define:
apples.mysite.com
bananas.mysite.com
coconuts.mysite.com
etc ...
all of which point to webapps/fruit (these are hosts with a "/" context
pointing to "webapps/fruit" as the docBase, to be more precise).
When someone visits apples.mysite.com they see an apple, when they visit
bananas.mysite.com they see a banana, and so on.
Where in the fruit app is the best place for instance of Fruit to introspect
itself (basically look for what host name it is defined under) and prepare
accordingly?
I've looked into using Context Parameters in the server.xml declarations but
I would like to avoid this if possible b/c this functionally is more
elegantly determined through introspection (the web-app saying "what host do
i belong to?").
Of course I could always call request.getLocalName(), but that would be
inefficient as it would have to be invoked on every request.
I guess what I'm looking for someplace in the context initialization process
where i could hook into and do my stuff and have it apply to the entire
context throughout it's lifecycle. Can't seem to find it digging around the
javax.servlet.* javadocs.
thanks
Re: The best place for implementing context specific behavior?
Posted by Marcus Better <ma...@better.se>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Mark Thomas wrote:
> If all your requests are handled by a single host, you don't need the
> aliases.
Right. (Actually I do have a second virtual host on this server.)
Cheers,
Marcus
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkpDyrgACgkQXjXn6TzcAQmZ7gCg5RxX/9KIbABpnIZWrCOQ2Jt8
hBMAn0cc0fRCD9jKiiyjKoFS2EitsG7o
=gugO
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: The best place for implementing context specific behavior?
Posted by Mark Thomas <ma...@apache.org>.
Marcus Better wrote:
> First you can setup aliases in the Host, something like
>
> <Host name="mysite.com" appBase="fruit-webapps">
> <Alias>apples.mysite.com</Alias>
> <Alias>bananas.mysite.com</Alias>
> <Alias>coconuts.mysite.com</Alias>
> </Host>
If all your requests are handled by a single host, you don't need the
aliases.
Equally, if the host is the default host, you don't need the aliases.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: The best place for implementing context specific behavior?
Posted by Marcus Better <ma...@better.se>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jonathan Mast wrote:
> I have a webapp that I would like to behave in a context (actually
> host)-specific manner. Where is the best place to initialize the
> context/host specific functionality?
I implemented something very similar a few days ago.
> Let me demonstrate what I'm talking about. Lets say I have a webapp Fruit
> located in folder webapps/fruit.
> I want to define:
> apples.mysite.com
> bananas.mysite.com
> coconuts.mysite.com
> etc ...
> all of which point to webapps/fruit (these are hosts with a "/" context
> pointing to "webapps/fruit" as the docBase, to be more precise).
First you can setup aliases in the Host, something like
<Host name="mysite.com" appBase="fruit-webapps">
<Alias>apples.mysite.com</Alias>
<Alias>bananas.mysite.com</Alias>
<Alias>coconuts.mysite.com</Alias>
</Host>
Then install your webapp into "fruit-webapps/ROOT.war".
> Where in the fruit app is the best place for instance of Fruit to
> introspect itself (basically look for what host name it is defined under)
> and prepare accordingly?
In this setup there is only one webapp, so it cannot be done per webapp
context, or even per servlet instance.
> Of course I could always call request.getLocalName(), but that would be
> inefficient as it would have to be invoked on every request.
I check request.getServerName() in the main index.gsp (it's a Grails app)
and then put the result into the session. If you don't use sessions and have
more than one servlet, I guess you can do the check in a filter. I don't
think it's that inefficient.
Cheers,
Marcus
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkpDn84ACgkQXjXn6TzcAQkIHQCfXlSnQs/U8lsubWU+2TqYbLIR
WEwAoJkiWqfJ0gPRz3ltUj3OwldGN79N
=tIbH
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: The best place for implementing context specific behavior?
Posted by Mark Thomas <ma...@apache.org>.
Jonathan Mast wrote:
> Andre, its one single, physical app/docBase, mapped to multiple contexts
> (which happen to located on different virtual hosts). This is a
> requirement.
>
> The /META-INF/context.xml approach is ruled out by this requirement.
>
> My goal is to have a layer of code takes a the current host (eg.
> apples.mysite.com) looks it up in a database where it is linked to
> host-specific content. After this stage, the showFruit.jsp will display an
> Apple and so on.
>
>> - have your webapp (actually I guess, the first servlet) in it's init()
> code, get the hostname from getServerName() and
>> perform whatever setup it needs to. Then save this in an attribute of the
> ServletContext
>
> But where do I find this elusive init() method?
Use a context listener.
Other tips you might find useful:
- make sure each virtual host has its own work directory
- rename your app ROOT.war rather than fruit.war (or ROOT rather than
fruit if deployed as a dir) to prevent double deployment
- turn off unpackWARs for all the hosts if deploying as a WAR
Mark
>
> On Wed, Jun 24, 2009 at 5:01 PM, André Warnier <aw...@ice-sa.com> wrote:
>
>> Hi.
>>
>> I am one of the least Tomcat and Java qualified people that regularly lurk
>> on this forum, so don't take my word for any of what follows.
>> Let's say that I am just trying to apply what I think I have learned here.
>> And I am eager for contradiction, because it is said that this is how one
>> learns.
>>
>> Jonathan Mast wrote:
>>
>>> I have a webapp that I would like to behave in a context (actually
>>> host)-specific manner. Where is the best place to initialize the
>>> context/host specific functionality?
>>>
>>> Let me demonstrate what I'm talking about. Lets say I have a webapp Fruit
>>> located in folder webapps/fruit.
>>> I want to define:
>>> apples.mysite.com
>>> bananas.mysite.com
>>> coconuts.mysite.com
>>> etc ...
>>> all of which point to webapps/fruit (these are hosts with a "/" context
>>> pointing to "webapps/fruit" as the docBase, to be more precise).
>>>
>> appBase ?
>>
>>>
>> Do you mean all Hosts point to the *same physical* webapps/fruit, or does
>> each Host have its own copy in a separate directory ?
>>
>> When someone visits apples.mysite.com they see an apple, when they visit
>>> bananas.mysite.com they see a banana, and so on.
>>>
>>> Where in the fruit app is the best place for instance of Fruit to
>>> introspect
>>> itself (basically look for what host name it is defined under) and prepare
>>> accordingly?
>>>
>>> I've looked into using Context Parameters in the server.xml declarations
>>>
>> That would probably better be in a /META-INF/context.xml, no ?
>> (at least if these are distinct webapp/fruit)
>>
>> or see here for more complete info :
>> http://tomcat.apache.org/tomcat-6.0-doc/config/context.html
>>
>> but
>>
>>> I would like to avoid this if possible b/c this functionally is more
>>> elegantly determined through introspection (the web-app saying "what host
>>> do
>>> i belong to?").
>>>
>>> Of course I could always call request.getLocalName(),
>>>
>> I think you want getServerName(), or you'd always get the same DNS name/IP,
>> no matter wich virtual Host is called..
>>
>> but that would be
>>
>>> inefficient as it would have to be invoked on every request.
>>>
>>> I guess what I'm looking for someplace in the context initialization
>>> process
>>> where i could hook into and do my stuff and have it apply to the entire
>>> context throughout it's lifecycle. Can't seem to find it digging around
>>> the
>>> javax.servlet.* javadocs.
>>>
>>>
>> I reason as follows :
>> - a webapp is run by a thread
>> - a thread is started by a Connector
>> - I don't think that a thread is Host-specific, in the sense that it can
>> run one webapp for one Host, and the next instant run another webapp for
>> another Host.
>>
>> What I'm saying is that I am not sure that above the Request level, you
>> will find anything that is "Host-persistent" to keep your stuff in and
>> retrieve it (I mean for webapps shared by several Hosts, which is probably a
>> bad idea anyway).
>>
>> To this eager student thus, the correct way to do what I understand you
>> want to do, seems to be :
>> - have each Host have its own appBase (webapp dir), with in each a copy of
>> your (identical) webapp code "Fruit".
>> - have your webapp (actually I guess, the first servlet) in it's init()
>> code, get the hostname from getServerName() and perform whatever setup it
>> needs to. Then save this in an attribute of the ServletContext
>> - which should then be available at each subsequent execution of any
>> servlet composing the webapp
>>
>> Inspired by the Servlet Spec 2.5, section 2.3 Servlet lifecyle, 2.3.2
>> Initialization.
>>
>>
>> ---------------------------------------------------------------------
>> 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
Re: The best place for implementing context specific behavior?
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jonathan,
On 6/24/2009 5:13 PM, Jonathan Mast wrote:
> Andre, its one single, physical app/docBase, mapped to multiple contexts
> (which happen to located on different virtual hosts). This is a
> requirement.
>
> The /META-INF/context.xml approach is ruled out by this requirement.
If you need to have only a single deployed webapp to handle requests for
all of these different domain names, then your webapp will necessarily
have to detect the hostname being used /for each request/. This is not
terribly inefficient: it's just grabbing a header value.
This kind of thing smells like private-labeling. The best technique I
can think of is to sniff the hostname at the beginning of the request
(use a filter?) and stuff something into the request attributes that
represents the "profile" for that flavor of fruit (or private label).
Then, when rendering your pages, or making database connections or
whatever, reference the profile in the request attributes to make
decisions as to how things should go.
If request attributes aren't your thing (many reasons including "my
database code doesn't have access to the request", etc.), then you can
use ThreadLocal variables. Just remember to catch all exceptions in your
filter and /remove that damned profile object from the ThreadLocal/ or
you can have security and/or memory problems.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkpCovEACgkQ9CaO5/Lv0PC1+ACfXpjMl3TV7TMCt48/VzjYcngL
VRQAoMEiEtjZdGBeKYqxagBW4fyIDz69
=ydr2
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: The best place for implementing context specific behavior?
Posted by Pid <p...@pidster.com>.
André Warnier wrote:
> Pid wrote:
>>
>> If you're analyzing the host name per request and no other config is
>> required, just point it all at the default host. You may not need to
>> setup additional virtual hosts in server.xml.
>>
> I claim prior art on that one.
fair enough...
but the same thing did come up in another thread a few days ago. ;)
p
> "All of the above is predicated on the asumption that you really need to
> do this specific per-host initialisation ahead of time.
> If you don't, then you could use a single <Host> entry, pick up the
> hostname at request processing time, and do away with all the setup
> above. "
>
> ---------------------------------------------------------------------
> 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
Re: The best place for implementing context specific behavior?
Posted by André Warnier <aw...@ice-sa.com>.
Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Jonathan,
>
> On 6/26/2009 9:21 AM, Christopher Schultz wrote:
>> Don't use request.getLocalName: use request.getHeader("Server").
>
> Er... that should have been request.getHeader("Host").
>
.. which should really have been request.getServerName()...
(which is probably doing the same thing under the hood, but then maybe
not quite, considering that for HTTP header names, capitalisation
doesn't count. Ha.)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: The best place for implementing context specific behavior?
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jonathan,
On 6/26/2009 9:21 AM, Christopher Schultz wrote:
> Don't use request.getLocalName: use request.getHeader("Server").
Er... that should have been request.getHeader("Host").
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkpEy68ACgkQ9CaO5/Lv0PCZqQCeOmCtC/VWTb1Gygx5HVbo7fjw
MsMAn1nqeTCHNQ+gfWahEdAMg8JebpL+
=EtEh
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: The best place for implementing context specific behavior?
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jonathan,
On 6/25/2009 12:04 PM, Jonathan Mast wrote:
> Haha thanks, Andre, I'm not lost but it seems other people might be.
>
> I'm going to go ahead define separate hosts, although the <Alias> option
> mentioned might work, I don't know if it would preserve correctly the value
> returned by request.getLocalName() which is what I'm using for determining
> the host specific content, but if someone knows better than say so.
Don't use request.getLocalName: use request.getHeader("Server"). This
will avoid multiple copies of the webapp being deployed. It also might
be faster, as no DNS lookup needs to occur.
> The
> <Alias> element is kinda poorly documented on tomcat.apache.com, it only has
> a paragraph. Seems like a holdover from httpd configs....
That's because it's simple: you just put an alternative hostname into
the <Host> element so that it can match multiple hostnames without
having to have multiple <Host> elements.
I think you're making this all way more complicated than necessary.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkpEyzwACgkQ9CaO5/Lv0PCgbwCeLZpxRorULh4XxEcRe/L0QahM
uJ8AoKVAURPW6h4lYcZijdgq+wjODOQJ
=rwcz
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: The best place for implementing context specific behavior?
Posted by André Warnier <aw...@ice-sa.com>.
Jonathan Mast wrote:
> Haha thanks, Andre, I'm not lost but it seems other people might be.
>
> I'm going to go ahead define separate hosts, although the <Alias> option
> mentioned might work, I don't know if it would preserve correctly the value
> returned by request.getLocalName()
that's *wrong*, you should use request.getServerName().
getLocalName() will give you the name of the local "physical" machine,
as per the interface your server's Tomcat is Listening on.
(in other words, you will always get the same answer).
getServerName will give you the hostname that the client used in his
request, which is what you want.
which is what I'm using for determining
> the host specific content, but if someone knows better than say so. The
> <Alias> element is kinda poorly documented on tomcat.apache.com, it only has
> a paragraph. Seems like a holdover from httpd configs....
No it isn't. Using <Alias> or using another <Host> are two entirely
different animals.
Both will achieve the same if all you want to do is a getServerName() at
request time, but that's about all they have in common.
>
> On Thu, Jun 25, 2009 at 11:53 AM, André Warnier <aw...@ice-sa.com> wrote:
>
>> Jonathan,
>> if by now you are a bit lost in the various options related to the hostname
>> and why, just say so. I have a practised step-by-step explanation available.
>> It's all pretty standard HTTP/name-based virtual hosts stuff, but it has
>> many people confused.
>>
>>
>>
>> ---------------------------------------------------------------------
>> 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
Re: The best place for implementing context specific behavior?
Posted by Pid <p...@pidster.com>.
André Warnier wrote:
> Pid wrote:
>>
>> The Filter checks the domain name is suitable, /looks up a config object/
>> and drops it into the request attributes for use on the page.
>
> Ha ! I believe that this is exactly what Jonathan is (or was originally)
> looking for.
> Where is this "config object", and when and how is it being initialised ?
Right FIFTH attempt to send this email, (dodgy net & crashing mail
client - I am *not* shouting at my computer).
Short version:
It's a custom obj in a DB, it's got lists of CSS/Javascript file URLs,
some binary switches for turning on/off blocks of page content.
Use the serverName as a key in the DB & a suitable, thread-safe cache.
If the number of obj is small, preload the cache at Filter init().
p
> I'm continuing for myself right now, just to learn how to do this
> correctly.
> Suppose I do want to do something different in my (shared, common,
> whatever) webapp, depending on the "Host:" header of the request.
> And suppose this different thing I want to do, is a bit heavy, so I
> don't want to do it all at each request, I want to do some of that work
> ahead of time, and re-use it for each request afterward.
>
> But the requests come in unpredictable order, all to my same webapp, but
> one for "apples.company.com", and the following one for
> "bananas.company.com" etc.
> And when one comes in for "bananas", I want to retrieve what I had
> earlier prepared for "bananas", and not what I had prepared for "lemons".
> (In other words, I don't want a fruit salad, I want to enjoy each fruit
> separately).
>
> Where and how do I do that ?
>
>
> ---------------------------------------------------------------------
> 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
Re: The best place for implementing context specific behavior?
Posted by Alan Chaney <al...@compulsivecreative.com>.
Andre
André Warnier wrote:
> Pid wrote:
>>
>> The Filter checks the domain name is suitable, /looks up a config object/
>> and drops it into the request attributes for use on the page.
>
> Ha ! I believe that this is exactly what Jonathan is (or was originally)
> looking for.
> Where is this "config object", and when and how is it being initialised ?
>
One place to keep filter configuration information is as an attribute of
the ServletContext. This can be obtained with the
FilterConfig.getServletContext method. The FilterConfig object is a
parameter of the doFilter method of the Filter. (See
http://java.sun.com/javaee/5/docs/api/)
This works within any one web app.
> I'm continuing for myself right now, just to learn how to do this
> correctly.
> Suppose I do want to do something different in my (shared, common,
> whatever) webapp, depending on the "Host:" header of the request.
> And suppose this different thing I want to do, is a bit heavy, so I
> don't want to do it all at each request, I want to do some of that work
> ahead of time, and re-use it for each request afterward.
>
> But the requests come in unpredictable order, all to my same webapp, but
> one for "apples.company.com", and the following one for
> "bananas.company.com" etc.
> And when one comes in for "bananas", I want to retrieve what I had
> earlier prepared for "bananas", and not what I had prepared for "lemons".
> (In other words, I don't want a fruit salad, I want to enjoy each fruit
> separately).
You can write an object which handles the specific processing for each
host and then create a Map as the attribute in the ServletContext using
the host name as the key. At the start of each request in your Filter
you could retrieve the object by using the host name as the key, do
whatever host specific processing you need.
You can add a ContextListener in web.xml will will allow you to do any
servlet startup/shutdown operations.
There are other ways, but the above should work.
Regards
Alan Chaney
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: The best place for implementing context specific behavior?
Posted by André Warnier <aw...@ice-sa.com>.
Pid wrote:
>
> The Filter checks the domain name is suitable, /looks up a config object/
> and drops it into the request attributes for use on the page.
Ha ! I believe that this is exactly what Jonathan is (or was originally)
looking for.
Where is this "config object", and when and how is it being initialised ?
I'm continuing for myself right now, just to learn how to do this correctly.
Suppose I do want to do something different in my (shared, common,
whatever) webapp, depending on the "Host:" header of the request.
And suppose this different thing I want to do, is a bit heavy, so I
don't want to do it all at each request, I want to do some of that work
ahead of time, and re-use it for each request afterward.
But the requests come in unpredictable order, all to my same webapp, but
one for "apples.company.com", and the following one for
"bananas.company.com" etc.
And when one comes in for "bananas", I want to retrieve what I had
earlier prepared for "bananas", and not what I had prepared for "lemons".
(In other words, I don't want a fruit salad, I want to enjoy each fruit
separately).
Where and how do I do that ?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: The best place for implementing context specific behavior?
Posted by Pid <p...@pidster.com>.
Jonathan Mast wrote:
> Haha thanks, Andre, I'm not lost but it seems other people might be.
Seriously: skip the extra Hosts, skip the Aliases, just use the
defaultHost. I have a private label system in production right now that
does exactly this.
The Filter checks the domain name is suitable, looks up a config object
and drops it into the request attributes for use on the page.
There is only one Host defined, without a bunch of extra Aliases - it
relies on the defaultHost. It also means that you don't need to restart
the server for each additional subdomain.
p
> I'm going to go ahead define separate hosts, although the <Alias> option
> mentioned might work, I don't know if it would preserve correctly the value
> returned by request.getLocalName() which is what I'm using for determining
> the host specific content, but if someone knows better than say so. The
> <Alias> element is kinda poorly documented on tomcat.apache.com, it only has
> a paragraph. Seems like a holdover from httpd configs....
>
> On Thu, Jun 25, 2009 at 11:53 AM, André Warnier <aw...@ice-sa.com> wrote:
>
>> Jonathan,
>> if by now you are a bit lost in the various options related to the hostname
>> and why, just say so. I have a practised step-by-step explanation available.
>> It's all pretty standard HTTP/name-based virtual hosts stuff, but it has
>> many people confused.
>>
>>
>>
>> ---------------------------------------------------------------------
>> 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
Re: The best place for implementing context specific behavior?
Posted by Marcus Better <ma...@better.se>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jonathan Mast wrote:
> I'm going to go ahead define separate hosts, although the <Alias> option
> mentioned might work, I don't know if it would preserve correctly the
> value returned by request.getLocalName() which is what I'm using for
> determining the host specific content,
Are you using name-based or IP-based virtual hosting? In other words, do the
*.mysite.com hostnames all resolve to the same IP address?
Cheers,
Marcus
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkpDp4MACgkQXjXn6TzcAQkkgACgmzPtMKWGbsfZdE/uw/T4nzau
wT0AoIykK8dsDlM3Cp1b2a5VsUTWuX/g
=fKn8
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: The best place for implementing context specific behavior?
Posted by Jonathan Mast <jh...@gmail.com>.
Haha thanks, Andre, I'm not lost but it seems other people might be.
I'm going to go ahead define separate hosts, although the <Alias> option
mentioned might work, I don't know if it would preserve correctly the value
returned by request.getLocalName() which is what I'm using for determining
the host specific content, but if someone knows better than say so. The
<Alias> element is kinda poorly documented on tomcat.apache.com, it only has
a paragraph. Seems like a holdover from httpd configs....
On Thu, Jun 25, 2009 at 11:53 AM, André Warnier <aw...@ice-sa.com> wrote:
> Jonathan,
> if by now you are a bit lost in the various options related to the hostname
> and why, just say so. I have a practised step-by-step explanation available.
> It's all pretty standard HTTP/name-based virtual hosts stuff, but it has
> many people confused.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: The best place for implementing context specific behavior?
Posted by André Warnier <aw...@ice-sa.com>.
Jonathan,
if by now you are a bit lost in the various options related to the
hostname and why, just say so. I have a practised step-by-step
explanation available.
It's all pretty standard HTTP/name-based virtual hosts stuff, but it has
many people confused.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: The best place for implementing context specific behavior?
Posted by André Warnier <aw...@ice-sa.com>.
Pid wrote:
>
> If you're analyzing the host name per request and no other config is
> required, just point it all at the default host. You may not need to
> setup additional virtual hosts in server.xml.
>
I claim prior art on that one.
"All of the above is predicated on the asumption that you really need to
do this specific per-host initialisation ahead of time.
If you don't, then you could use a single <Host> entry, pick up the
hostname at request processing time, and do away with all the setup above. "
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: The best place for implementing context specific behavior?
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jonathan,
On 6/25/2009 11:21 AM, Jonathan Mast wrote:
> You misunderstood the issue at hand. The host name I'm detecting is not the
> that of the viewer of my site, but my site, so there must be different host
> virtualhosts setup.
Pid is right: you are sniffing the Host header supplied by the client
which /is/ the hostname of the server. There is no need to deploy
multiple copies of your own webapp, unless you want separate caches of
data or something like that.
If you deploy multiple instances, then you don't need to sniff the request!
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkpEyrIACgkQ9CaO5/Lv0PCNlwCglVbH8rQFVALyV6aJshLL/E8f
UocAni828WklGgN7i+GuUpoFWhNbU2ZY
=uJAA
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: The best place for implementing context specific behavior?
Posted by Pid <p...@pidster.com>.
Jonathan Mast wrote:
> You misunderstood the issue at hand. The host name I'm detecting is not the
> that of the viewer of my site, but my site, so there must be different host
> virtualhosts setup.
No, I don't think I did, but I was perhaps hasty and imprecise in the
terminology I used.
All requests for Hosts that do not match a specifically configured host,
will be directed to the one configured in the defaultHost field of the
Engine, in server.xml.
http://tomcat.apache.org/tomcat-6.0-doc/config/engine.html
If you do not configure additional hosts because you need separate work
dirs or some such, then you can skip the extra Host configs altogether.
p
> On Thu, Jun 25, 2009 at 11:07 AM, Pid <p...@pidster.com> wrote:
>
>> Jonathan Mast wrote:
>>> Chris, this is indeed a case of private labeling. My company has setup a
>>> site to which a major distributor wants to send traffic. As such they
>> are
>>> demanding custom advertising tags. The problem is that this site will
>> also
>>> be recieving traffic from other distribution channels, hence the need for
>>> unique hostnames and host-specific content. The host-specific content
>> will
>>> be plugged into adslots on the pages.
>>>
>>>> It's not clear to me that the OP wants separate instances of one webapp
>>> (one per host), or if he wants one instance of one webapp that services
>> all
>>> hosts. We really need that >clarified before any further suggestions can
>> be
>>> made.
>>> I want multiple instances of 1 webapp, think of the webapp as a class,
>> and
>>> the contexts as instances of that class. I'm almost certain that you
>> cannot
>>> have shared instances a of webapp across multiple contexts, or least at
>>> least not across multiple hosts.
>>>
>>> I'm probably just going to sniff each request, although inefficient, it
>> is
>>> the easiest to implement. Anyway the inefficiency is not very costly,
>> just
>>> a simple string lookup in a db, the results of which will be cached by
>> the
>>> lookupBean.
>> If you're analyzing the host name per request and no other config is
>> required, just point it all at the default host. You may not need to
>> setup additional virtual hosts in server.xml.
>>
>> p
>>
>>
>>
>>> On Thu, Jun 25, 2009 at 6:23 AM, André Warnier <aw...@ice-sa.com> wrote:
>>>
>>>> Caldarale, Charles R wrote:
>>>>
>>>>> From: André Warnier [mailto:aw@ice-sa.com]
>>>>>> Subject: Re: The best place for implementing context specific
>> behavior?
>>>>>> I believe (but we need a real expert here) that having multiple <Host>
>>>>>> entries sharing the same appBase is a receipe for problems.
>>>>>>
>>>>> It seems to work for most usages. As Mark pointed out, each <Host> or
>>>>> <Context> should have separate work directories to avoid conflicts with
>> temp
>>>>> files, JSPs, etc.
>>>>>
>>>>> If it is really just to have a single copy of the code on disk
>> however,
>>>>>> you may be able to get away with having multiple (differently named)
>>>>>> appBase attributes, but all symlinked to the same physical location
>>>>>>
>>>>> That will make no difference, since the underlying location is the same
>>>>> for all.
>>>>>
>>>>> I must say that I don't really understand the requirement, unless your
>>>>>> "fruit" webapp is really big (in disk size), or you have many
>> different
>>>>>> "fruit" hosts.
>>>>>>
>>>>> It's not clear to me that the OP wants separate instances of one webapp
>>>>> (one per host), or if he wants one instance of one webapp that services
>> all
>>>>> hosts. We really need that clarified before any further suggestions
>> can be
>>>>> made.
>>>>>
>>>>> Agreed.
>>>> But was is relatively clear is that, synthetically, he wants to do some
>>>> kind of relatively heavy intialisation that is hostname-dependent, and
>> would
>>>> rather not have to redo it at each new request.
>>>>
>>>> For example - but just as an example - open a connection with a
>> database,
>>>> and read a row of a table, the exact row being accessed being dependent
>> on
>>>> the hostname addressed in the request; then, in a manner depending on
>> the
>>>> data read, initialise some persistent object that could be accessed
>>>> subsequently by all servlets belonging to this webapp in this Host, for
>> the
>>>> lifetime of this webapp.
>>>>
>>>> So he would like to do this once (per hostname), and then be able at
>> each
>>>> request, to efficiently retrieve pointers to the appropriate "thing"
>> that
>>>> has been initialised once, from whichever servlet belongs to the webapp
>> and
>>>> is invoked in the context of this Host.
>>>>
>>>> What is also not clear yet, is if this initialisation could be done
>> once,
>>>> at Tomcat start, or would have to be redone if for instance the webapp
>> is
>>>> stopped and restarted, or unloaded and reloaded.
>>>> Or, if these are individual webapps per Host, if one of these
>> Host-specific
>>>> webapps must be able to be stopped/started independently of the other
>>>> Host-specific webapps.
>>>> Or, to which extent this overlaps the idea of a "session" (as I
>> understand
>>>> it however, it does not, and the initialisation is to be valid for all
>>>> subsequent requests to the same hostname, whether they belong to the
>> same
>>>> client session or not).
>>>>
>>>> To the above general requirement, for which possibly there would be
>> several
>>>> possible solutions, there is then an additional requirement added about
>>>> there being "a single webapp, or context, or whatever" which I do not
>> fully
>>>> understand, but which may be valid and restrict the choices available.
>>>>
>>>> That's how I see it anyway.
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: The best place for implementing context specific behavior?
Posted by Jonathan Mast <jh...@gmail.com>.
You misunderstood the issue at hand. The host name I'm detecting is not the
that of the viewer of my site, but my site, so there must be different host
virtualhosts setup.
On Thu, Jun 25, 2009 at 11:07 AM, Pid <p...@pidster.com> wrote:
> Jonathan Mast wrote:
> > Chris, this is indeed a case of private labeling. My company has setup a
> > site to which a major distributor wants to send traffic. As such they
> are
> > demanding custom advertising tags. The problem is that this site will
> also
> > be recieving traffic from other distribution channels, hence the need for
> > unique hostnames and host-specific content. The host-specific content
> will
> > be plugged into adslots on the pages.
> >
> >> It's not clear to me that the OP wants separate instances of one webapp
> > (one per host), or if he wants one instance of one webapp that services
> all
> > hosts. We really need that >clarified before any further suggestions can
> be
> > made.
> > I want multiple instances of 1 webapp, think of the webapp as a class,
> and
> > the contexts as instances of that class. I'm almost certain that you
> cannot
> > have shared instances a of webapp across multiple contexts, or least at
> > least not across multiple hosts.
> >
> > I'm probably just going to sniff each request, although inefficient, it
> is
> > the easiest to implement. Anyway the inefficiency is not very costly,
> just
> > a simple string lookup in a db, the results of which will be cached by
> the
> > lookupBean.
>
> If you're analyzing the host name per request and no other config is
> required, just point it all at the default host. You may not need to
> setup additional virtual hosts in server.xml.
>
> p
>
>
>
> > On Thu, Jun 25, 2009 at 6:23 AM, André Warnier <aw...@ice-sa.com> wrote:
> >
> >> Caldarale, Charles R wrote:
> >>
> >>> From: André Warnier [mailto:aw@ice-sa.com]
> >>>> Subject: Re: The best place for implementing context specific
> behavior?
> >>>>
> >>>> I believe (but we need a real expert here) that having multiple <Host>
> >>>> entries sharing the same appBase is a receipe for problems.
> >>>>
> >>> It seems to work for most usages. As Mark pointed out, each <Host> or
> >>> <Context> should have separate work directories to avoid conflicts with
> temp
> >>> files, JSPs, etc.
> >>>
> >>> If it is really just to have a single copy of the code on disk
> however,
> >>>> you may be able to get away with having multiple (differently named)
> >>>> appBase attributes, but all symlinked to the same physical location
> >>>>
> >>> That will make no difference, since the underlying location is the same
> >>> for all.
> >>>
> >>> I must say that I don't really understand the requirement, unless your
> >>>> "fruit" webapp is really big (in disk size), or you have many
> different
> >>>> "fruit" hosts.
> >>>>
> >>> It's not clear to me that the OP wants separate instances of one webapp
> >>> (one per host), or if he wants one instance of one webapp that services
> all
> >>> hosts. We really need that clarified before any further suggestions
> can be
> >>> made.
> >>>
> >>> Agreed.
> >> But was is relatively clear is that, synthetically, he wants to do some
> >> kind of relatively heavy intialisation that is hostname-dependent, and
> would
> >> rather not have to redo it at each new request.
> >>
> >> For example - but just as an example - open a connection with a
> database,
> >> and read a row of a table, the exact row being accessed being dependent
> on
> >> the hostname addressed in the request; then, in a manner depending on
> the
> >> data read, initialise some persistent object that could be accessed
> >> subsequently by all servlets belonging to this webapp in this Host, for
> the
> >> lifetime of this webapp.
> >>
> >> So he would like to do this once (per hostname), and then be able at
> each
> >> request, to efficiently retrieve pointers to the appropriate "thing"
> that
> >> has been initialised once, from whichever servlet belongs to the webapp
> and
> >> is invoked in the context of this Host.
> >>
> >> What is also not clear yet, is if this initialisation could be done
> once,
> >> at Tomcat start, or would have to be redone if for instance the webapp
> is
> >> stopped and restarted, or unloaded and reloaded.
> >> Or, if these are individual webapps per Host, if one of these
> Host-specific
> >> webapps must be able to be stopped/started independently of the other
> >> Host-specific webapps.
> >> Or, to which extent this overlaps the idea of a "session" (as I
> understand
> >> it however, it does not, and the initialisation is to be valid for all
> >> subsequent requests to the same hostname, whether they belong to the
> same
> >> client session or not).
> >>
> >> To the above general requirement, for which possibly there would be
> several
> >> possible solutions, there is then an additional requirement added about
> >> there being "a single webapp, or context, or whatever" which I do not
> fully
> >> understand, but which may be valid and restrict the choices available.
> >>
> >> That's how I see it anyway.
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> 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
>
>
Re: The best place for implementing context specific behavior?
Posted by Pid <p...@pidster.com>.
Jonathan Mast wrote:
> Chris, this is indeed a case of private labeling. My company has setup a
> site to which a major distributor wants to send traffic. As such they are
> demanding custom advertising tags. The problem is that this site will also
> be recieving traffic from other distribution channels, hence the need for
> unique hostnames and host-specific content. The host-specific content will
> be plugged into adslots on the pages.
>
>> It's not clear to me that the OP wants separate instances of one webapp
> (one per host), or if he wants one instance of one webapp that services all
> hosts. We really need that >clarified before any further suggestions can be
> made.
> I want multiple instances of 1 webapp, think of the webapp as a class, and
> the contexts as instances of that class. I'm almost certain that you cannot
> have shared instances a of webapp across multiple contexts, or least at
> least not across multiple hosts.
>
> I'm probably just going to sniff each request, although inefficient, it is
> the easiest to implement. Anyway the inefficiency is not very costly, just
> a simple string lookup in a db, the results of which will be cached by the
> lookupBean.
If you're analyzing the host name per request and no other config is
required, just point it all at the default host. You may not need to
setup additional virtual hosts in server.xml.
p
> On Thu, Jun 25, 2009 at 6:23 AM, André Warnier <aw...@ice-sa.com> wrote:
>
>> Caldarale, Charles R wrote:
>>
>>> From: André Warnier [mailto:aw@ice-sa.com]
>>>> Subject: Re: The best place for implementing context specific behavior?
>>>>
>>>> I believe (but we need a real expert here) that having multiple <Host>
>>>> entries sharing the same appBase is a receipe for problems.
>>>>
>>> It seems to work for most usages. As Mark pointed out, each <Host> or
>>> <Context> should have separate work directories to avoid conflicts with temp
>>> files, JSPs, etc.
>>>
>>> If it is really just to have a single copy of the code on disk however,
>>>> you may be able to get away with having multiple (differently named)
>>>> appBase attributes, but all symlinked to the same physical location
>>>>
>>> That will make no difference, since the underlying location is the same
>>> for all.
>>>
>>> I must say that I don't really understand the requirement, unless your
>>>> "fruit" webapp is really big (in disk size), or you have many different
>>>> "fruit" hosts.
>>>>
>>> It's not clear to me that the OP wants separate instances of one webapp
>>> (one per host), or if he wants one instance of one webapp that services all
>>> hosts. We really need that clarified before any further suggestions can be
>>> made.
>>>
>>> Agreed.
>> But was is relatively clear is that, synthetically, he wants to do some
>> kind of relatively heavy intialisation that is hostname-dependent, and would
>> rather not have to redo it at each new request.
>>
>> For example - but just as an example - open a connection with a database,
>> and read a row of a table, the exact row being accessed being dependent on
>> the hostname addressed in the request; then, in a manner depending on the
>> data read, initialise some persistent object that could be accessed
>> subsequently by all servlets belonging to this webapp in this Host, for the
>> lifetime of this webapp.
>>
>> So he would like to do this once (per hostname), and then be able at each
>> request, to efficiently retrieve pointers to the appropriate "thing" that
>> has been initialised once, from whichever servlet belongs to the webapp and
>> is invoked in the context of this Host.
>>
>> What is also not clear yet, is if this initialisation could be done once,
>> at Tomcat start, or would have to be redone if for instance the webapp is
>> stopped and restarted, or unloaded and reloaded.
>> Or, if these are individual webapps per Host, if one of these Host-specific
>> webapps must be able to be stopped/started independently of the other
>> Host-specific webapps.
>> Or, to which extent this overlaps the idea of a "session" (as I understand
>> it however, it does not, and the initialisation is to be valid for all
>> subsequent requests to the same hostname, whether they belong to the same
>> client session or not).
>>
>> To the above general requirement, for which possibly there would be several
>> possible solutions, there is then an additional requirement added about
>> there being "a single webapp, or context, or whatever" which I do not fully
>> understand, but which may be valid and restrict the choices available.
>>
>> That's how I see it anyway.
>>
>>
>>
>> ---------------------------------------------------------------------
>> 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
Re: The best place for implementing context specific behavior?
Posted by Jonathan Mast <jh...@gmail.com>.
Chris, this is indeed a case of private labeling. My company has setup a
site to which a major distributor wants to send traffic. As such they are
demanding custom advertising tags. The problem is that this site will also
be recieving traffic from other distribution channels, hence the need for
unique hostnames and host-specific content. The host-specific content will
be plugged into adslots on the pages.
>It's not clear to me that the OP wants separate instances of one webapp
(one per host), or if he wants one instance of one webapp that services all
hosts. We really need that >clarified before any further suggestions can be
made.
I want multiple instances of 1 webapp, think of the webapp as a class, and
the contexts as instances of that class. I'm almost certain that you cannot
have shared instances a of webapp across multiple contexts, or least at
least not across multiple hosts.
I'm probably just going to sniff each request, although inefficient, it is
the easiest to implement. Anyway the inefficiency is not very costly, just
a simple string lookup in a db, the results of which will be cached by the
lookupBean.
On Thu, Jun 25, 2009 at 6:23 AM, André Warnier <aw...@ice-sa.com> wrote:
> Caldarale, Charles R wrote:
>
>> From: André Warnier [mailto:aw@ice-sa.com]
>>> Subject: Re: The best place for implementing context specific behavior?
>>>
>>> I believe (but we need a real expert here) that having multiple <Host>
>>> entries sharing the same appBase is a receipe for problems.
>>>
>>
>> It seems to work for most usages. As Mark pointed out, each <Host> or
>> <Context> should have separate work directories to avoid conflicts with temp
>> files, JSPs, etc.
>>
>> If it is really just to have a single copy of the code on disk however,
>>> you may be able to get away with having multiple (differently named)
>>> appBase attributes, but all symlinked to the same physical location
>>>
>>
>> That will make no difference, since the underlying location is the same
>> for all.
>>
>> I must say that I don't really understand the requirement, unless your
>>> "fruit" webapp is really big (in disk size), or you have many different
>>> "fruit" hosts.
>>>
>>
>> It's not clear to me that the OP wants separate instances of one webapp
>> (one per host), or if he wants one instance of one webapp that services all
>> hosts. We really need that clarified before any further suggestions can be
>> made.
>>
>> Agreed.
> But was is relatively clear is that, synthetically, he wants to do some
> kind of relatively heavy intialisation that is hostname-dependent, and would
> rather not have to redo it at each new request.
>
> For example - but just as an example - open a connection with a database,
> and read a row of a table, the exact row being accessed being dependent on
> the hostname addressed in the request; then, in a manner depending on the
> data read, initialise some persistent object that could be accessed
> subsequently by all servlets belonging to this webapp in this Host, for the
> lifetime of this webapp.
>
> So he would like to do this once (per hostname), and then be able at each
> request, to efficiently retrieve pointers to the appropriate "thing" that
> has been initialised once, from whichever servlet belongs to the webapp and
> is invoked in the context of this Host.
>
> What is also not clear yet, is if this initialisation could be done once,
> at Tomcat start, or would have to be redone if for instance the webapp is
> stopped and restarted, or unloaded and reloaded.
> Or, if these are individual webapps per Host, if one of these Host-specific
> webapps must be able to be stopped/started independently of the other
> Host-specific webapps.
> Or, to which extent this overlaps the idea of a "session" (as I understand
> it however, it does not, and the initialisation is to be valid for all
> subsequent requests to the same hostname, whether they belong to the same
> client session or not).
>
> To the above general requirement, for which possibly there would be several
> possible solutions, there is then an additional requirement added about
> there being "a single webapp, or context, or whatever" which I do not fully
> understand, but which may be valid and restrict the choices available.
>
> That's how I see it anyway.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: The best place for implementing context specific behavior?
Posted by André Warnier <aw...@ice-sa.com>.
Caldarale, Charles R wrote:
>> From: André Warnier [mailto:aw@ice-sa.com]
>> Subject: Re: The best place for implementing context specific behavior?
>>
>> I believe (but we need a real expert here) that having multiple <Host>
>> entries sharing the same appBase is a receipe for problems.
>
> It seems to work for most usages. As Mark pointed out, each <Host> or <Context> should have separate work directories to avoid conflicts with temp files, JSPs, etc.
>
>> If it is really just to have a single copy of the code on disk however,
>> you may be able to get away with having multiple (differently named)
>> appBase attributes, but all symlinked to the same physical location
>
> That will make no difference, since the underlying location is the same for all.
>
>> I must say that I don't really understand the requirement, unless your
>> "fruit" webapp is really big (in disk size), or you have many different
>> "fruit" hosts.
>
> It's not clear to me that the OP wants separate instances of one webapp (one per host), or if he wants one instance of one webapp that services all hosts. We really need that clarified before any further suggestions can be made.
>
Agreed.
But was is relatively clear is that, synthetically, he wants to do some
kind of relatively heavy intialisation that is hostname-dependent, and
would rather not have to redo it at each new request.
For example - but just as an example - open a connection with a
database, and read a row of a table, the exact row being accessed being
dependent on the hostname addressed in the request; then, in a manner
depending on the data read, initialise some persistent object that could
be accessed subsequently by all servlets belonging to this webapp in
this Host, for the lifetime of this webapp.
So he would like to do this once (per hostname), and then be able at
each request, to efficiently retrieve pointers to the appropriate
"thing" that has been initialised once, from whichever servlet belongs
to the webapp and is invoked in the context of this Host.
What is also not clear yet, is if this initialisation could be done
once, at Tomcat start, or would have to be redone if for instance the
webapp is stopped and restarted, or unloaded and reloaded.
Or, if these are individual webapps per Host, if one of these
Host-specific webapps must be able to be stopped/started independently
of the other Host-specific webapps.
Or, to which extent this overlaps the idea of a "session" (as I
understand it however, it does not, and the initialisation is to be
valid for all subsequent requests to the same hostname, whether they
belong to the same client session or not).
To the above general requirement, for which possibly there would be
several possible solutions, there is then an additional requirement
added about there being "a single webapp, or context, or whatever" which
I do not fully understand, but which may be valid and restrict the
choices available.
That's how I see it anyway.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: The best place for implementing context specific behavior?
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: André Warnier [mailto:aw@ice-sa.com]
> Subject: Re: The best place for implementing context specific behavior?
>
> I believe (but we need a real expert here) that having multiple <Host>
> entries sharing the same appBase is a receipe for problems.
It seems to work for most usages. As Mark pointed out, each <Host> or <Context> should have separate work directories to avoid conflicts with temp files, JSPs, etc.
> If it is really just to have a single copy of the code on disk however,
> you may be able to get away with having multiple (differently named)
> appBase attributes, but all symlinked to the same physical location
That will make no difference, since the underlying location is the same for all.
> I must say that I don't really understand the requirement, unless your
> "fruit" webapp is really big (in disk size), or you have many different
> "fruit" hosts.
It's not clear to me that the OP wants separate instances of one webapp (one per host), or if he wants one instance of one webapp that services all hosts. We really need that clarified before any further suggestions can be made.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: The best place for implementing context specific behavior?
Posted by Marcus Better <ma...@better.se>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
André Warnier wrote:
> I believe (but we need a real expert here) that having multiple <Host>
> entries sharing the same appBase is a receipe for problems.
(Not that I'm an expert, but...) Fortunately it's not necessary in this
case. You can use a single Host and have several aliases (Alias element in
server.xml).
Cheers,
Marcus
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkpDmu4ACgkQXjXn6TzcAQloDACbBDE1NkfEEfu9/zEj32Lu3nA4
B58AoOq0Do9SAxWwmj862CStova5HvBM
=thZP
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: The best place for implementing context specific behavior?
Posted by André Warnier <aw...@ice-sa.com>.
Jonathan Mast wrote:
> Andre, its one single, physical app/docBase, mapped to multiple contexts
> (which happen to located on different virtual hosts). This is a
> requirement.
It seems to be a bad requirement then, see
http://tomcat.apache.org/tomcat-6.0-doc/virtual-hosting-howto.html
I believe (but we need a real expert here) that having multiple <Host>
entries sharing the same appBase is a receipe for problems.
If it is really just to have a single copy of the code on disk however,
you may be able to get away with having multiple (differently named)
appBase attributes, but all symlinked to the same physical location, see
below.
I must say that I don't really understand the requirement, unless your
"fruit" webapp is really big (in disk size), or you have many different
"fruit" hosts.
You can have this :
<Host name"apples.company.com" appBase="webapps-apples">
<Host name"pears.company.com" appBase="webapps-pears">
<Host name"lemons.company.com" appBase="webapps-lemons">
and then have
(CATALINA_BASE)/webapps-apples/ROOT/your webapp code
(CATALINA_BASE)/webapps-pears/ROOT/your webapp code
(CATALINA_BASE)/webapps-lemons/ROOT/your webapp code
and still, browsers would access your webapp by URLs like
http://apples.company.com
http://pears.company.com
http://lemons.company.com
and they would all get your same webapp
The above is if your want to make your "fruit" webapp be the default webapp.
Alternatively, you could have
<Host name"apples.company.com" appBase="webapps-apples">
<Host name"pears.company.com" appBase="webapps-pears">
<Host name"lemons.company.com" appBase="webapps-lemons">
and then have
(CATALINA_BASE)/webapps-apples/fruit/your webapp code
(CATALINA_BASE)/webapps-pears/fruit/your webapp code
(CATALINA_BASE)/webapps-lemons/fruit/your webapp code
and browsers would access your webapp by URLs like
http://apples.company.com/fruit
http://pears.company.com/fruit
http://lemons.company.com/fruit
and they would all get your same webapp
but in each case, during the deployment and initialisation of your
webapp, each of the "fruit" instances, during it's own init(), could
through getServerName() get its own Host's "name", and initialise
accordingly.
So, as per your requirement
http://apples.company.com/fruit would get an apple
http://pears.company.com/fruit would get a pear
If you absolutely want to save disk space, the each of "webapps-apples",
"webapps-pears" and "webapps-lemons", could be a symlink to
"webapps-00common", and the code could really be stored there.
Like :
(CATALINA_BASE)/webapps-00common/fruit/your webapp code
(CATALINA_BASE)/webapps-apples (link to 00common)
(CATALINA_BASE)/webapps-pears (link to 00common)
(CATALINA_BASE)/webapps-lemoms (link to 00common)
But I have no idea how Tomcat would react if, for instance, you did a
new deployment of your webapp (replace the files).
That's what I mean by "receipe for problems" above.
I think unless you really have many fruit, it's better to avoid that.
All of the above is predicated on the asumption that you really need to
do this specific per-host initialisation ahead of time.
If you don't, then you could use a single <Host> entry, pick up the
hostname at request processing time, and do away with all the setup above.
Don't forget the maxim : "Premature optimisation is the root of much evil".
How many "fruit" are we really talking about ?
>
> The /META-INF/context.xml approach is ruled out by this requirement.
There are alternatives to that, see here :
http://tomcat.apache.org/tomcat-6.0-doc/config/context.html
>
> My goal is to have a layer of code takes a the current host (eg.
> apples.mysite.com) looks it up in a database where it is linked to
> host-specific content. After this stage, the showFruit.jsp will display an
> Apple and so on.
>
>> - have your webapp (actually I guess, the first servlet) in it's init()
> code, get the hostname from getServerName() and
>> perform whatever setup it needs to. Then save this in an attribute of the
> ServletContext
>
> But where do I find this elusive init() method?
javax.servlet.Servlet
inherited by HttpServlet.
Here is an example :
http://java.sun.com/products/servlet/articles/tutorial/
>
> On Wed, Jun 24, 2009 at 5:01 PM, André Warnier <aw...@ice-sa.com> wrote:
>
>> Hi.
>>
>> I am one of the least Tomcat and Java qualified people that regularly lurk
>> on this forum, so don't take my word for any of what follows.
>> Let's say that I am just trying to apply what I think I have learned here.
>> And I am eager for contradiction, because it is said that this is how one
>> learns.
>>
>> Jonathan Mast wrote:
>>
>>> I have a webapp that I would like to behave in a context (actually
>>> host)-specific manner. Where is the best place to initialize the
>>> context/host specific functionality?
>>>
>>> Let me demonstrate what I'm talking about. Lets say I have a webapp Fruit
>>> located in folder webapps/fruit.
>>> I want to define:
>>> apples.mysite.com
>>> bananas.mysite.com
>>> coconuts.mysite.com
>>> etc ...
>>> all of which point to webapps/fruit (these are hosts with a "/" context
>>> pointing to "webapps/fruit" as the docBase, to be more precise).
>>>
>> appBase ?
>>
>>>
>> Do you mean all Hosts point to the *same physical* webapps/fruit, or does
>> each Host have its own copy in a separate directory ?
>>
>> When someone visits apples.mysite.com they see an apple, when they visit
>>> bananas.mysite.com they see a banana, and so on.
>>>
>>> Where in the fruit app is the best place for instance of Fruit to
>>> introspect
>>> itself (basically look for what host name it is defined under) and prepare
>>> accordingly?
>>>
>>> I've looked into using Context Parameters in the server.xml declarations
>>>
>> That would probably better be in a /META-INF/context.xml, no ?
>> (at least if these are distinct webapp/fruit)
>>
>> or see here for more complete info :
>> http://tomcat.apache.org/tomcat-6.0-doc/config/context.html
>>
>> but
>>
>>> I would like to avoid this if possible b/c this functionally is more
>>> elegantly determined through introspection (the web-app saying "what host
>>> do
>>> i belong to?").
>>>
>>> Of course I could always call request.getLocalName(),
>>>
>> I think you want getServerName(), or you'd always get the same DNS name/IP,
>> no matter wich virtual Host is called..
>>
>> but that would be
>>
>>> inefficient as it would have to be invoked on every request.
>>>
>>> I guess what I'm looking for someplace in the context initialization
>>> process
>>> where i could hook into and do my stuff and have it apply to the entire
>>> context throughout it's lifecycle. Can't seem to find it digging around
>>> the
>>> javax.servlet.* javadocs.
>>>
>>>
>> I reason as follows :
>> - a webapp is run by a thread
>> - a thread is started by a Connector
>> - I don't think that a thread is Host-specific, in the sense that it can
>> run one webapp for one Host, and the next instant run another webapp for
>> another Host.
>>
>> What I'm saying is that I am not sure that above the Request level, you
>> will find anything that is "Host-persistent" to keep your stuff in and
>> retrieve it (I mean for webapps shared by several Hosts, which is probably a
>> bad idea anyway).
>>
>> To this eager student thus, the correct way to do what I understand you
>> want to do, seems to be :
>> - have each Host have its own appBase (webapp dir), with in each a copy of
>> your (identical) webapp code "Fruit".
>> - have your webapp (actually I guess, the first servlet) in it's init()
>> code, get the hostname from getServerName() and perform whatever setup it
>> needs to. Then save this in an attribute of the ServletContext
>> - which should then be available at each subsequent execution of any
>> servlet composing the webapp
>>
>> Inspired by the Servlet Spec 2.5, section 2.3 Servlet lifecyle, 2.3.2
>> Initialization.
>>
>>
>> ---------------------------------------------------------------------
>> 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
Re: The best place for implementing context specific behavior?
Posted by Jonathan Mast <jh...@gmail.com>.
Andre, its one single, physical app/docBase, mapped to multiple contexts
(which happen to located on different virtual hosts). This is a
requirement.
The /META-INF/context.xml approach is ruled out by this requirement.
My goal is to have a layer of code takes a the current host (eg.
apples.mysite.com) looks it up in a database where it is linked to
host-specific content. After this stage, the showFruit.jsp will display an
Apple and so on.
> - have your webapp (actually I guess, the first servlet) in it's init()
code, get the hostname from getServerName() and
> perform whatever setup it needs to. Then save this in an attribute of the
ServletContext
But where do I find this elusive init() method?
On Wed, Jun 24, 2009 at 5:01 PM, André Warnier <aw...@ice-sa.com> wrote:
> Hi.
>
> I am one of the least Tomcat and Java qualified people that regularly lurk
> on this forum, so don't take my word for any of what follows.
> Let's say that I am just trying to apply what I think I have learned here.
> And I am eager for contradiction, because it is said that this is how one
> learns.
>
> Jonathan Mast wrote:
>
>> I have a webapp that I would like to behave in a context (actually
>> host)-specific manner. Where is the best place to initialize the
>> context/host specific functionality?
>>
>> Let me demonstrate what I'm talking about. Lets say I have a webapp Fruit
>> located in folder webapps/fruit.
>> I want to define:
>> apples.mysite.com
>> bananas.mysite.com
>> coconuts.mysite.com
>> etc ...
>> all of which point to webapps/fruit (these are hosts with a "/" context
>> pointing to "webapps/fruit" as the docBase, to be more precise).
>>
>
> appBase ?
>
>>
>>
> Do you mean all Hosts point to the *same physical* webapps/fruit, or does
> each Host have its own copy in a separate directory ?
>
> When someone visits apples.mysite.com they see an apple, when they visit
>> bananas.mysite.com they see a banana, and so on.
>>
>> Where in the fruit app is the best place for instance of Fruit to
>> introspect
>> itself (basically look for what host name it is defined under) and prepare
>> accordingly?
>>
>> I've looked into using Context Parameters in the server.xml declarations
>>
>
> That would probably better be in a /META-INF/context.xml, no ?
> (at least if these are distinct webapp/fruit)
>
> or see here for more complete info :
> http://tomcat.apache.org/tomcat-6.0-doc/config/context.html
>
> but
>
>> I would like to avoid this if possible b/c this functionally is more
>> elegantly determined through introspection (the web-app saying "what host
>> do
>> i belong to?").
>>
>> Of course I could always call request.getLocalName(),
>>
> I think you want getServerName(), or you'd always get the same DNS name/IP,
> no matter wich virtual Host is called..
>
> but that would be
>
>> inefficient as it would have to be invoked on every request.
>>
>> I guess what I'm looking for someplace in the context initialization
>> process
>> where i could hook into and do my stuff and have it apply to the entire
>> context throughout it's lifecycle. Can't seem to find it digging around
>> the
>> javax.servlet.* javadocs.
>>
>>
> I reason as follows :
> - a webapp is run by a thread
> - a thread is started by a Connector
> - I don't think that a thread is Host-specific, in the sense that it can
> run one webapp for one Host, and the next instant run another webapp for
> another Host.
>
> What I'm saying is that I am not sure that above the Request level, you
> will find anything that is "Host-persistent" to keep your stuff in and
> retrieve it (I mean for webapps shared by several Hosts, which is probably a
> bad idea anyway).
>
> To this eager student thus, the correct way to do what I understand you
> want to do, seems to be :
> - have each Host have its own appBase (webapp dir), with in each a copy of
> your (identical) webapp code "Fruit".
> - have your webapp (actually I guess, the first servlet) in it's init()
> code, get the hostname from getServerName() and perform whatever setup it
> needs to. Then save this in an attribute of the ServletContext
> - which should then be available at each subsequent execution of any
> servlet composing the webapp
>
> Inspired by the Servlet Spec 2.5, section 2.3 Servlet lifecyle, 2.3.2
> Initialization.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: The best place for implementing context specific behavior?
Posted by André Warnier <aw...@ice-sa.com>.
Hi.
I am one of the least Tomcat and Java qualified people that regularly
lurk on this forum, so don't take my word for any of what follows.
Let's say that I am just trying to apply what I think I have learned here.
And I am eager for contradiction, because it is said that this is how
one learns.
Jonathan Mast wrote:
> I have a webapp that I would like to behave in a context (actually
> host)-specific manner. Where is the best place to initialize the
> context/host specific functionality?
>
> Let me demonstrate what I'm talking about. Lets say I have a webapp Fruit
> located in folder webapps/fruit.
> I want to define:
> apples.mysite.com
> bananas.mysite.com
> coconuts.mysite.com
> etc ...
> all of which point to webapps/fruit (these are hosts with a "/" context
> pointing to "webapps/fruit" as the docBase, to be more precise).
appBase ?
>
Do you mean all Hosts point to the *same physical* webapps/fruit, or
does each Host have its own copy in a separate directory ?
> When someone visits apples.mysite.com they see an apple, when they visit
> bananas.mysite.com they see a banana, and so on.
>
> Where in the fruit app is the best place for instance of Fruit to introspect
> itself (basically look for what host name it is defined under) and prepare
> accordingly?
>
> I've looked into using Context Parameters in the server.xml declarations
That would probably better be in a /META-INF/context.xml, no ?
(at least if these are distinct webapp/fruit)
or see here for more complete info :
http://tomcat.apache.org/tomcat-6.0-doc/config/context.html
but
> I would like to avoid this if possible b/c this functionally is more
> elegantly determined through introspection (the web-app saying "what host do
> i belong to?").
>
> Of course I could always call request.getLocalName(),
I think you want getServerName(), or you'd always get the same DNS
name/IP, no matter wich virtual Host is called..
but that would be
> inefficient as it would have to be invoked on every request.
>
> I guess what I'm looking for someplace in the context initialization process
> where i could hook into and do my stuff and have it apply to the entire
> context throughout it's lifecycle. Can't seem to find it digging around the
> javax.servlet.* javadocs.
>
I reason as follows :
- a webapp is run by a thread
- a thread is started by a Connector
- I don't think that a thread is Host-specific, in the sense that it can
run one webapp for one Host, and the next instant run another webapp for
another Host.
What I'm saying is that I am not sure that above the Request level, you
will find anything that is "Host-persistent" to keep your stuff in and
retrieve it (I mean for webapps shared by several Hosts, which is
probably a bad idea anyway).
To this eager student thus, the correct way to do what I understand you
want to do, seems to be :
- have each Host have its own appBase (webapp dir), with in each a copy
of your (identical) webapp code "Fruit".
- have your webapp (actually I guess, the first servlet) in it's init()
code, get the hostname from getServerName() and perform whatever setup
it needs to. Then save this in an attribute of the ServletContext
- which should then be available at each subsequent execution of any
servlet composing the webapp
Inspired by the Servlet Spec 2.5, section 2.3 Servlet lifecyle, 2.3.2
Initialization.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org