howto get the context path from a ServletContext?
Is there a way to figure out the context path from a given ServletContext? I'm inside one context and am trying to dispatch to a resource in another context based upon the absolute URI (in other words, a uri relative to the server root). I can get the proper servlet context as follows: nextContext = thisServletContext.getContext(dispatch_to_this_uri); but then I cannot figure out how to do a dispatch to the uri because I don't know how to strip off the context path from the front of the URI! I have a feeling I'm asking a really stupid question, but I'm going blind from looking at the servlet 2.3 javadoc for so long! Can anyone help? Thanks! Best regards, Richard
Re: howto get the context path from a ServletContext?
Is getContextPath() possibly what you're looking for? It's found in the HttpServletRequest interface. At 07:23 PM 1/8/2002 +0100, you wrote: Is there a way to figure out the context path from a given ServletContext? I'm inside one context and am trying to dispatch to a resource in another context based upon the absolute URI (in other words, a uri relative to the server root). I can get the proper servlet context as follows: nextContext = thisServletContext.getContext(dispatch_to_this_uri); but then I cannot figure out how to do a dispatch to the uri because I don't know how to strip off the context path from the front of the URI! I have a feeling I'm asking a really stupid question, but I'm going blind from looking at the servlet 2.3 javadoc for so long! Can anyone help? Thanks! Best regards, Richard -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
Re: howto get the context path from a ServletContext?
No because I don't have a Request. In other words, the request object I have is from the current servlet-context, but when I do nextContext=currentContext.getContext(nexturi), all I have about this other context is the context object itself and the server-root-relative URI for some resource somewhere within the new context. Thanks! -Richard - Original Message - From: Mark [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Sent: Tuesday, January 08, 2002 7:33 PM Subject: Re: howto get the context path from a ServletContext? Is getContextPath() possibly what you're looking for? It's found in the HttpServletRequest interface. At 07:23 PM 1/8/2002 +0100, you wrote: Is there a way to figure out the context path from a given ServletContext? I'm inside one context and am trying to dispatch to a resource in another context based upon the absolute URI (in other words, a uri relative to the server root). I can get the proper servlet context as follows: nextContext = thisServletContext.getContext(dispatch_to_this_uri); but then I cannot figure out how to do a dispatch to the uri because I don't know how to strip off the context path from the front of the URI! I have a feeling I'm asking a really stupid question, but I'm going blind from looking at the servlet 2.3 javadoc for so long! Can anyone help? Thanks! Best regards, Richard -- 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]
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? Very frustrating. 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? -Richard - Original Message - From: Richard Sand [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Sent: Tuesday, January 08, 2002 7:43 PM Subject: Re: howto get the context path from a ServletContext? No because I don't have a Request. In other words, the request object I have is from the current servlet-context, but when I do nextContext=currentContext.getContext(nexturi), all I have about this other context is the context object itself and the server-root-relative URI for some resource somewhere within the new context. Thanks! -Richard - Original Message - From: Mark [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Sent: Tuesday, January 08, 2002 7:33 PM Subject: Re: howto get the context path from a ServletContext? Is getContextPath() possibly what you're looking for? It's found in the HttpServletRequest interface. At 07:23 PM 1/8/2002 +0100, you wrote: Is there a way to figure out the context path from a given ServletContext? I'm inside one context and am trying to dispatch to a resource in another context based upon the absolute URI (in other words, a uri relative to the server root). I can get the proper servlet context as follows: nextContext = thisServletContext.getContext(dispatch_to_this_uri); but then I cannot figure out how to do a dispatch to the uri because I don't know how to strip off the context path from the front of the URI! I have a feeling I'm asking a really stupid question, but I'm going blind from looking at the servlet 2.3 javadoc for so long! Can anyone help? Thanks! Best regards, Richard -- 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] -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
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]
Re: howto get the context path from a ServletContext?
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
