tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Mast <>
Subject Re: The best place for implementing context specific behavior?
Date Thu, 25 Jun 2009 14:12:28 GMT
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
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

On Thu, Jun 25, 2009 at 6:23 AM, André Warnier <> wrote:

> Caldarale, Charles R wrote:
>> From: André Warnier []
>>> 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:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message