Thanks for the pointer. I'm with you on not putting a REGEX in every call. My implementation for my software stores the resolved host name matches in a hashtable for fast access. It's only when a new host name shows up that it does a REGEX.
George Sexton MH Software, Inc. http://www.mhsoftware.com/ Voice: 303 438 9585 > -----Original Message----- > From: Bill Barker [mailto:[EMAIL PROTECTED] > Sent: Friday, April 22, 2005 12:18 PM > To: Tomcat Developers List > Subject: Re: Wild Card Aliases - Help Following Source Code > > Host mapping is done by o.a.t.u.http.mapper.Mapper. > > This is critical-path stuff, so I'd likely be -1 to adding > regexp here, > unless it was optional and off by default. > > ----- Original Message ----- > From: "George Sexton" <[EMAIL PROTECTED]> > To: "'Tomcat Developers List'" <tomcat-dev@jakarta.apache.org> > Sent: Friday, April 22, 2005 9:38 AM > Subject: Wild Card Aliases - Help Following Source Code > > > > I'm hoping someone can help me follow the source code. I'd > like to lok at > > adding a feature, but I keep getting turned around when I > try to follow > the > > object hierarchy.b b > > > > Basically what I want to do is add wild-card aliases. > > > > I have a web calendar application. At a customer request, I > have added a > > feature that allows one instance of my application to > display different > sets > > of calendars to users depending upon the host name that is > used to hit the > > site. Internally, my application uses a different GUEST > user based on the > > host name presented. > > > > Since we host this particular customer, it would be really > nice if we > could > > set it up so that any requests for domain.xxx, regardless > of the rest of > the > > host name would be forwarded to his application. > > > > We host about 45 people on this machine so going with a > dedicated IP and > > making that host the default host that IP address won't > really work. Each > > customer that we host has their own unique virtual host. So > far, Tomcat is > > handling this really well. We are not using Apache as a > front-end, and > would > > really rather not. Adding apache would double our > administration effort > for > > deploying hosts. > > > > Adding wild-card virtual host aliases would neatly solve > this problem. > > > > Where I'm having a problem understanding the source, is > determining how > the > > correct host is picked to forward the request into. If I > could understand > > the flow I could probably sort out how to add support for > this and submit > it > > as a patch. > > > > The implementation I used within my application is, I think pretty > efficient > > and doesn't add a lot of overhead. Basically, internally the steps I > follow > > are: > > > > Lookup the host name in a Hashmap. > > > > Is this a new virtual host? > > > > No, return the associated user. > > > > Yes, this is new > > > > get the list of virtual host names > > > > iterate over the list trying a string match > > and regular expression match for each > > configured entry. > > > > When a match is found, sort the user name > > in the hash table, using the host name as > > the key. > > > > If no match is found, return the default name. > > > > Return the correct user. > > > > > > This implementation lets me only go through the pain of > trying to do a > > string or regular expression match the first type a new host name is > > presented. > > > > > > > > > > > > George Sexton > > MH Software, Inc. > > http://www.mhsoftware.com/ > > Voice: 303 438 9585 > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > This message is intended only for the use of the person(s) > listed above as the intended recipient(s), and may contain > information that is PRIVILEGED and CONFIDENTIAL. If you are > not an intended recipient, you may not read, copy, or > distribute this message or any attachment. If you received > this communication in error, please notify us immediately by > e-mail and then delete all copies of this message and any attachments. > > In addition you should be aware that ordinary (unencrypted) > e-mail sent through the Internet is not secure. Do not send > confidential or sensitive information, such as social > security numbers, account numbers, personal identification > numbers and passwords, to us via ordinary (unencrypted) e-mail. > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
