Thanks for your input Shapira and Mike . . . don't get me wrong, I don't
want the servlet spec to change unless it really is wrong in this regard. If
it isn't then I want to know the correct way to deal with the problem.
Sorry for my confusion about the recommended ServletRequestListener solution
- it stems from the fact that this interface was introduced in the 2.4 API.
I am using Tomcat 4.1 which, I understand, only supports the 2.3 API. I
would need Tomcat 5 for such a solution but it is certainly nice to know.
So let's consider the RequestDispatcher. As I mentioned, it is easy enough
for me to get an appropriate instance of RequestDispatcher. The problem is,
in order to include the response, I need an instance of ServletRequest and
ServletResponse:
public void RequestDispatcher.include(ServletRequest request,
ServletResponse response) throws . . .
I obviously don't have these in my indexing class. I considered rolling my
own but how would I implement the getContextPath() method in
HttpServletRequest? I'd be going around in circles.
So what about the ServletContext.getResource(String) option? Well, I tried
this and it returns a URL such as:
jndi:/localhost/CONTEXT_PATH/FOLDER1/FOLDER2/NAME.jsp
However, as you'd expect, reading this URL yields the contents of the JSP
rather than the results of executing the JSP. I figured I could somehow
easily translate this URL into a http URL. I looked at the URL(URL context,
String spec) URL constructor but it does not help because of the changing of
protocols.
Of course, I could simply replace the "jndi:/" with "http://" and then
insert the correct port number - which I have as an env entry :-( - but I'm
not convinced this is a good idea either.
The only thing I didn't understand in your email was the comment re docBase.
I'm not sure what this is - in particular, are you talking HTML document
base or some other mechanism - can you enlighten me?
Actually I just thought of another argument for supplying deployment
information to the developer - feel free to shoot me down. In my web app I
have a filter called ProtocolFilter. It simply switches the client in and
out of SSL as specified by filter options. In order to perform the switch,
the ports must be known. I currently have these ports defined as env entries
so that the filter (and other code) can pick them up. How else could I
possibly do this?
Thanks again,
Kent
Howdy,
>[kb] OK, but how can my app be agnostic of the context path if I need
to do
>things like dynamically construct URLs? Why does the need to request a
>resource in the same web app constitute a design flaw? Surely this is a
>fairly common requirement . . . how else would I index dynamic
resources?
>Also, if the web app should be completely agnostic of the context path,
why
>does the HttpServletRequest interface define a method to retrieve it?
The getContextPath method is there primarily to address HTML
restrictions (links). Other ways to access dynamic resources revolve
around using the docBase as your reference, not the server root, and
include the RequestDispatcher calls and ServletContext#getResource
calls. Both of these are agnostic of the context path as far as the
application developer is concerned, which is good design.
As you already mentioned, you can hack around this in various ugly ways,
e.g. including the context path as a context-param in web.xml. This is
an easy out many people take. But since you said you wanted to know the
clean approach, and I was glad to hear that, I'm trying to explain that
approach and the reasoning behind it.
>[kb] Not entirely sure what you mean here. Are you saying I should
write a
>servlet that also implements ServletContextListener? If so, how do I
No, that's not what I meant. I meant exactly what I said, I'll try it
again without spaces when referring to servlet API classes: make your
ServletContextListener also a ServletRequestListener. You will get
notified when the first request comes in. At that time, you grab the
context path and store it so that your other classes can retrieve it
without needing an HttpServletRequest object.
A filter is also a possible solution, and there are several others.
Both the filter and the approach above will run the indexing on the
first request, which is not what you want. (Although it's trivial to
tie a wget request to the server startup script). Perhaps you can
modify your existing indexing class to use ServletContext#getResource
calls rather than whatever you're using now that requires the context
path.
Yoav Shapira
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@(protected)
For additional commands, e-mail: tomcat-user-help@(protected)
