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 <a...@ice-sa.com> wrote: >>> >>>> Caldarale, Charles R wrote: >>>> >>>>> From: André Warnier [mailto:a...@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-unsubscr...@tomcat.apache.org >>>> For additional commands, e-mail: users-h...@tomcat.apache.org >>>> >>>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
