Hi Joe, I'm not sure exactly what your query is but the setup I have is a "/" and a "/hal" Context. The Filter I am using to direct any requests to "/" to "/hal" lives in the WEB-INF/classes dir of the "/" context.
In my case I used the Tomcat default dir of "../webapps/ROOT" for the "/" docBase. Further. the configuration for the Filter and the URL pattern to fire it is in the web.xml file in that same WEB-INF dir. I do use "/*" as the URL pattern, but remember that these URL patterbs are relative to the Context the web.xml file is in. i.e. webapps/ROOT/WEB_INF/web.xml URL pattern of "/*" matches http://myserver/* webapps/hal/WEB_INF/web.xml URL pattern of "/*" matches http://myserver/hal/* Sorry if I've missed your point. Regards, Chris > > Shapira, Yoav wrote: > > >Howdy, > >A javax.servlet.Filter is one nice clean way. > > > > > Apologies if this is dumb q: Googling the jakarta site and > reading the > tomcat o'reilly have left me confused on this. > > Isn't the filter part of web app? From jakarta: > > > Filters are configured in the deployment descriptor of a web > > application > > And in o'reilly the filter and filter-mappnig tags are > discussed in the > web.xml section. > Doesn't this raise a namespace issue? If your servlet-mapping is to > /foo, then a filter on /* seems like it will either never > fire, or else > be ambiguous with other /* filters in other web apps (such as > the /bar > webapp, with it's own /* filter). > > The original poster had a /hal context and a / context. Does > the filter > solution require the / context to remain? Or is that unneeded? > > thanks for any unconfusion, > -joe > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
