tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Curwen" <mi...@gb-im.com>
Subject RE: Retrieving the context path from a standalone class
Date Wed, 07 Jan 2004 19:10:50 GMT
I think I agree with Kent. I've felt his pain, and I've done much the
same thinking on this very 'gap' in the spec/API.
 
When I do my thinking about this topic, I tend to start moving along
these lines:

the request is for a fully formed URL
the URL includes protocol, server (port), context path, resource,
querystring.

What's *interesting* about a request is all of that.

What's *scoped* to the request is only the resource requested and the
querystring. 

Because once we're in that resource, and accessing the Request object,
we're already *in* the context. We're well past the server. But methods
exist to pull this other information from the Request object, because
after all, it's interesting, and sometimes useful.
But hey.. the Context.  That's the *same* for every single request. For
every single possible valid request, the Context is the same. It starts
to sound like a runtime constant. That starts to make me think the scope
should be 'one up'. 
The context is scoped to an application. It *is* the application.
Therefore, it ought to be available through that object as well.

Let me turn this around for a bit.. is there anything fundamentally
*wrong* with having this information (the context path) *also* available
in the ServletContext. I think that's where both Kent and I start to
feel a bit 'left out in the cold' with the current spec. Sometimes we
want to do things with a context *outside the context of a
HttpServletRequest*. That may be against the spirit of what web apps are
supposed to be. But would its inclusion start breaking webapps
everywhere? (no, I think).  Will it's inclusion encourage programmers to
start building bad apps (no, I think.)


> -----Original Message-----
> From: Shapira, Yoav [mailto:Yoav.Shapira@mpi.com] 
> Sent: Wednesday, January 07, 2004 8:09 AM
> To: Tomcat Users List
> Subject: RE: Retrieving the context path from a standalone class
> 
> 
> 
> 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
> 
> 
> 
> This e-mail, including any attachments, is a confidential 
> business communication, and may contain information that is 
> confidential, proprietary and/or privileged.  This e-mail is 
> intended only for the individual(s) to whom it is addressed, 
> and may not be saved, copied, printed, disclosed or used by 
> anyone else.  If you are not the(an) intended recipient, 
> please immediately delete this e-mail from your computer 
> system and notify the sender.  Thank you.
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org


Mime
View raw message