tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pid...@pidster.com>
Subject Re: The best place for implementing context specific behavior?
Date Thu, 25 Jun 2009 15:33:43 GMT
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


Mime
View raw message