tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier ...@ice-sa.com>
Subject Re: The best place for implementing context specific behavior?
Date Wed, 24 Jun 2009 22:23:58 GMT
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


Mime
View raw message