A filter can trap all requests before the servlet is invoked. Thats why I
like them better for this situation (in the root webapp). You can use a
filter to rewrite the request to another context with the same code as you
would do it with a servlet. (Via a cross context forward)
-Tim
Leon Rosenberg wrote:
thanks tim.
What is the benefit of using Filter instead of servlet?
The only thing I see, is that I can reconfigure it without changing
the web.xml and therefore without restarting the server. Anything
else?
I wanted to keep this functionallity out of the root webapp, not to
save the server from a restart, but to keep the release process
simplier. It's quite easy to release a one servlet webapp, as to
release our root webapp with all the tagging, testing and so.
But I think, I have no other choice :-)
Btw. can I rewrite url with a filter, so that the request goes to
another webapp?
regards
Leon
On 11/15/05, Tim Funk <[EMAIL PROTECTED]> wrote:
If the servlet is that simple. I would
1) rewrite it as a filter
2) Put it in the root webapp
3) Map the filter to all requests
4) Use a config file to handle all your mappings
5) make the filter smart enough to re-read the config file
(servletContext.getResourceAsStream()) to detect changes so you don't have to
restart the webapp. Timing on how often to detect for changes is your call.
6) Done
If you can keep the config file used by the filter as a file outside of the
webapp root - then you can replace the config file without touching the webapp.
-Tim
Leon Rosenberg wrote:
asking again...
any ideas, anyone?
thanx
leon
On 11/15/05, Leon Rosenberg <[EMAIL PROTECTED]> wrote:
Hi,
I have following situation:
Business wishes (God knows why) to have a proxy proxying 6 different
context's on our server and fetching context from another server:
http://ourserver/foo/bla.html (internally fetched from )
http://anotherserver/ourname/foo/bla.html
http://ourserver/bar/bla.html -> http://anotherserver/ourname/bar/bla.html
...and so on.
I wrote a small webapp (1 servlet, 1 url-fetcher) which maps the
context and path, fetches the content of the url and delivers it to
the user. Let's say it's xxx webapp. I didn't want to make a copy of
it for any of foo,bar, etc context's, so I droped following xml files
into my $catalina_home/conf/Catalina/localhost:
foo.xml with content:
<Context path="/foo" docBase="xxx"/>,
bar.xml with content:
<Context path="/bar" docBase="xxx"/>,
and so on, for each context.
Everything is working fine, except, that the webapp is loaded once per
context which makes 6 times for now and probably 60 in half year. I
think it's a waste of resources and am searching for another solution.
Note that I already have a ROOT webapp (otherwise I'd place it under
root with servlet mapping instead of contexts) which I'd like not to
touch, because of different release cycles of both applications.
What is the best strategy to achieve my goal (having multiple context
mappings to one instantiated webapp) ?
Virtual hosts?
URL Rewriting Filter in ROOT webapp?
Something else?
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
