Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: pass (nike.apache.org: domain of p@pidster.com designates
 87.106.82.221 as permitted sender)
Received-SPF: neutral (s15243851.onlinehome-server.info: 78.86.122.68 is
 neither permitted nor denied by domain of pidster.com)
 client-ip=78.86.122.68; envelope-from=p@pidster.com; helo=Phoenix.config;
Message-ID: <4A4392A4.1010202@pidster.com>
Date: Thu, 25 Jun 2009 16:07:16 +0100
From: Pid <p@pidster.com>
Reply-To: p@pidster.com
Organization: Pid Inc
User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302)
MIME-Version: 1.0
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: The best place for implementing context specific behavior?
References: <f5af14000906241108w7e2d7f94r9ea4eea359ce7b3c@mail.gmail.com>
	 <4A42943A.1080307@ice-sa.com>
	 <f5af14000906241413ne24e9cbg21c559905bfbbef0@mail.gmail.com>
	 <4A42A77E.8040706@ice-sa.com>
	 <0AAE5AB84B013E45A7B61CB66943C1722947D7C626@USEA-EXCH7.na.uis.unisys.com>
	 <4A435017.4080407@ice-sa.com>
 <f5af14000906250712q6a0fa5dbwbb308e8e55220154@mail.gmail.com>
In-Reply-To: <f5af14000906250712q6a0fa5dbwbb308e8e55220154@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

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