I have a purchased webapp running on TC 4.1.30. For this webapp and the versions
before
I developed a filtering servlet (years ago), which filtered the Outputstream of
one (ServletA) of the included webapp servlets
(ServletA, ServletB, ServletC, ..) using following mappings and /or contexts:
1) purchased webapp:
context ROOT "/"
servlet mappings
"/servlet/pathA" mapped to ServletA
"/servlet/pathB" mapped to ServletB
....
+ "/servlet/XpathA" mapped to ServletA
2) filtering webapp:
context "/servlet/pathA"
servlet mapping
"/" mapped to own FilteringServlet
requests to "/servlet/pathA" forwarded and filtered to
"/servlet/XpathA"
the filtering is done by forwarding the request using a URLConnection.
(This was the only technique which I could get running for the 1. version
on a former Netscape webserver.
This allows also debugging the filter on my development PC/IDE,
while using the production webapp)
The only modification I had to do in the purchased webapp was the additional
servlet mapping
"/servlet/XpathA" mapped to ServletA
This technique had also the comfortable secondary effect that in case of trouble
the filtering could be disabled/removed on the fly just by simply undeploying
the filtering webapp.
This version worked perfect for me.
Now I am migrating to the current version of the purchased webapp using the
recommended TC 5.0.30.
1) purchased webapp:
context path "/app"
servlet mappings
"/servlet/pathA" mapped to ServletA
"/servlet/pathB" mapped to ServletB
....
+ "/servlet/XpathA" mapped to ServletA
The purchased webapp without filtering works as it should.
I am also trying to deploy my filtering servlet:
2) filtering webapp:
context "/app/servlet/pathA"
servlet mapping
"/" mapped to own FilteringServlet
requests to "/app/servlet/pathA" forwarded and filtered to
"/app/servlet/XpathA"
But this does not function as expected because this tomcat version (container?
DefaultServlet?)
immediately redirects any "/app/servlet/pathA" requests to "/app/servlet/pathA/"
but this breaks the relative paths in the html code, so this filtering is
broken/unusable.
How could that redirect be suppressed/avoided?
(also undeploying the context "/app/servlet/pathA" does not remove the filtering
as expected,
it seems to make the path "/app/servlet/pathA" and so the purchased webapp
unusable: error 50x)
So how to migrate the filtering ?
Of course I would like to do as little as possible.
I also want to avoid Valves as this ist TC/version specific.
I would also avoid a (servlet API) filter,
which has to be added to the context of the purchased webapp,
i.e. intermixing own code into the /app context
..
Ok the simplest migration I can imagine
which could function could be:
1) purchased webapp:
see above
servlet mappings:
....
+ "/servlet/XpathA" mapped to ServletA
+ "/servlet/XpathB" mapped to ServletB
...
2) filtering webapp:
context path "/app/servlet"
servlet mapping
"/" mapped to own FilteringServlet
requests to "/app/servlet/pathA" forwarded and filtered to
"/app/servlet/XpathA"
requests to "/app/servlet/pathB" forwarded and NOT filtered
to "/app/servlet/XpathB"
....
Any other ideas, insights, suggestions?
Thanks Karl-Heinz
___________________________________________________________
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
