tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "George Sexton" <gsex...@mhsoftware.com>
Subject RE: Wild Card Aliases - Help Following Source Code
Date Fri, 22 Apr 2005 22:38:10 GMT
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:wbarker@wilshire.com] 
> 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" <gsexton@mhsoftware.com>
> 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: tomcat-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
> >
> >
> 
> 
> 
> 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: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org


Mime
View raw message