Hi Craig,
Yes, that's exactly the problem I've grappling with, how to get the
context-relative path that is appropriate for that uri in its context path.
I understand your point about the other context not having any of the
request attributes or such in the invoked servlet/jsp, but this is livable.
My case is simple- I'm trying to include a hit counter. I don't need any
parameters from the request, I just need the counter servlet to be invoked.
I would normally just have the shtml files served by apache, which will
process the SSI's without issue, but I've implemented an "invisible" hit
counter using servlet filters, which is why i want tomcat to serve the
files.
So even with the risks and limitations of ssi's via tomcat, I still believe
that it should be possible, and that the servletcontext should be able to
provide the one missing piece of information (instead of making an assumtion
as to convention....), its base path, to make this programmatically possible
from within the SsiInvoker.
But here is something strange- even if I put the servlet into the same
application as the shtml file, the SSI still does not work! I looked into
the class org.apache.catalina.util.ssi.SsiInclude and it is preventing this-
before the RequestDispatcher is called, it does a check which eliminates
serving servlet resources:
if (SsiMediator.servletContext.getResource(path) != null)
So I figure when I remove this check, everything should work fine. But when
I decompiled the class and commented out this line, the SSI still failed,
which tells me that there is *something*
inside the SsiInvoker implementation prevents a dispatch to a servlet in any
case! As a test I wrote my own simple JSP page that did a dispatch to my
included servlet and it worked fine, so I conclude that its something inside
the SsiInvoked servlet.
In any case, it should be a simple fix for Tomcat4 to at least allow SSI's
of servlets in the same webapp. And I will request, as you suggested, that
the next servlet api allows servletContext to provide its base path so that
future versions can dispatch to servlets and resources in other web
applications as well.
Thanks for your help and comments!
-Richard
----- Original Message -----
From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
To: "Tomcat Users List" <[EMAIL PROTECTED]>
Sent: Wednesday, January 09, 2002 2:02 AM
Subject: Re: howto get the context path from a ServletContext?
>
>
> On Wed, 9 Jan 2002, Richard Sand wrote:
>
> > Date: Wed, 9 Jan 2002 00:33:31 +0100
> > From: Richard Sand <[EMAIL PROTECTED]>
> > Reply-To: Tomcat Users List <[EMAIL PROTECTED]>
> > To: Tomcat Users List <[EMAIL PROTECTED]>
> > Subject: Re: howto get the context path from a ServletContext?
> >
> > I've concluded that there is no way to do this- how absurd! I can get a
> > context to a uri in another application, but there is no way to dispatch
to
> > it because the context won't tell me what its base path is!!
> >
> > Isn't this a design oversight in the servlet 2.3 api? In other words,
why
> > shouldn't I be able to take in a uri, find its corresponding context,
and
> > dispatch to it??
> >
> > Basically this leaves no way to do server-side includes across
applications
> > in servlet2.3, which from my understanding is the entire point of the
> > dispatch mechanism in the first place! If I want a chain of servlets
> > processing my request, why shouldn't i be able to specify the servlet by
its
> > server-root uri, instead of using two separate parameters (context base
and
> > uri)?
> >
> > Any comments?
> >
>
> If you know what to pass as an argument to ServletContext.getContext(),
> then you already know the context path, right? It's the first part of the
> URL that you pass in.
>
> To do cross-context includes, you need the entire (server-relative) URI to
> get the right ServletContext, then a *context-relative* path to get the
> include. Assume you've got the "foreign" path "/othercontext/menu.jsp":
>
> ServletContext context =
> getServletContext().getContext("/othercontext/menu.jsp");
> RequestDispatcher rd = context.getRequestDispatcher("/menu.jsp");
> rd.include(request, response);
>
> There's a variety of ways to approch splitting this up, including an
> arbitrary rule that the context path is the part up to (but not including
> the second slash), to passing in the context path part as a servlet
> initialization parameter, to ...
>
> > Very frustrating.
> >
>
> You've got a couple more gotchas to watch out for, even after you get the
> path stuff squared away:
>
> * Many containers (including Tomcat by default) disable the ability to
> access other contexts for security reasons. In Tomcat 4, set the
> "crossContext" attribute of the <Context> element to true.
>
> * The included servlet or JSP page is *not* going to be able to see any
> of the request or session attributes that were created from classes
> loaded by the calling webapp's class loader.
>
> The latter issue, IMHO, makes cross-context includes not very useful in
> the majority of situations.
>
> > The only way i can see to do this in tomcat is to override the
> > org.apache.catalina.core.ApplicationContext and
ApplicationContextFascade to
> > make a public method getBasePath to return the same variable. Does
anyone
> > else agree that this should be part of the next servlet spec?
> >
>
> If you believe this to be the case, the appropriate mechanism to express
> it is to the feedback email address on the servlet spec:
>
> [EMAIL PROTECTED]
>
> > -Richard
> >
>
> Craig McClanahan
>
>
> --
> To unsubscribe: <mailto:[EMAIL PROTECTED]>
> For additional commands: <mailto:[EMAIL PROTECTED]>
> Troubles with the list: <mailto:[EMAIL PROTECTED]>
>
>
--
To unsubscribe: <mailto:[EMAIL PROTECTED]>
For additional commands: <mailto:[EMAIL PROTECTED]>
Troubles with the list: <mailto:[EMAIL PROTECTED]>
