I'd certainly be interested in a patch to allow pattern matching in the host mapper, as long as the code was smart about using direct string compares when no patterns are specified (to avoid slowing down all requests by regexp processing).
Note that Tomcat already loads jakarta-regexp for use in the RemoteAddrValve and RemoteHostValve filters. If you need regexp patterns, that would be a convenient choice because no additional dependencies would be created. Craig On Thu, 29 Nov 2001, Daniel Rall wrote: > Date: Thu, 29 Nov 2001 13:33:17 -0800 > From: Daniel Rall <[EMAIL PROTECTED]> > Reply-To: Tomcat Developers List <[EMAIL PROTECTED]> > To: Tomcat Users List <[EMAIL PROTECTED]> > Subject: Re: Emulating JServ's session.topleveldomain with Catalina > > "Craig R. McClanahan" <[EMAIL PROTECTED]> writes: > > > On Sat, 24 Nov 2001, Daniel Rall wrote: > > > >> "Craig R. McClanahan" <[EMAIL PROTECTED]> writes: > >> > >> > On Wed, 21 Nov 2001, Daniel Rall wrote: > >> > > >> >> Using Tomcat 4.0.1, is there any way to emulate JServ's > >> >> session.topleveldomain context configuration? > >> >> > >> >> # Set the domain= header that gets sent with the cookie. This is > >> >> # entirely optional > >> >> # Default: null > >> >> # this is needed when we vhost to avoid multiple login > >> >> session.topleveldomain=.foo.com > >> >> > >> >> I would like all requests to the set of virtual hosts represented by > >> >> the glob *.foo.com to share the same session ID. > >> > > >> > Unfortunately, implementing this functionality would violate the Servlet > >> > spec's requirements about sessions being scoped to a single > >> > ServletContext. Even if you were willing to do this, you're going to run > >> > into lots of technical problems due to the fact that each webapp is loaded > >> > by it's own classloader -- trying to access a session attribute loaded > >> > from a different webapp will throw ClassNotFoundException errors at you. > >> > >> I wasn't clear enough in my original query -- I don't want to scope > >> one session to multiple contexts, but to a single context accessed by > >> multiple host names which correspond to the same physical host (the > >> default host in server.xml). > > > > This is still illegal based on the same rule - each virtual host has its > > own set of webapps. Tomcat 4 is built on this assumption. > > Using the distinction you mention below, the host name used in the > request is merely a host alias (rather than a virtual host). > > > One way to work around it (with Tomcat 4) would be to use the "host > > aliasing" capability, where you say that a set of host names really refer > > to the same virtual host. This was primarily intended to deal with cases > > like "company.com" and "www.company.com" resolving to the same app, but > > could actually be used for more than that. Check out the <Alias> > > directive (in server.xml). > > Thanks for suggesting a work around, Craig (I'm only concerned with > Tomcat 4 ATM =). > > Reviewing the implementation of the <Alias> directive in > StandardEngineMapper and FastEngineMapper, it appears that only > literal mappings are provided for (i.e. wildcards are not allowed > supported). > > I have a requirement of supporting addition of host alias mappings at > run-time, but neither see a way to reload server.xml nor have much of > a desire to modify it from servlet code. Is there another way to > handle this situation? If not, would the Catalina developers be > amenable to a patch which adds wildcard capability to the host alias > feature? Would regex or file system-style globs be preferred (I lean > towards the latter)? If this is undesirable, what are my options > (i.e. can I configure my Engine entry in server.xml to use a custom > Mapper)? > > > Thanks, Daniel > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
