On Tue, 2002-09-17 at 20:52, Shawn Bayern wrote: > On 17 Sep 2002, Craig Longman wrote: > > > when you include a file via c:insert that actually maps to another > > servlet, it appears that the request object (in tomcat 4.1.10 at > > least) doesn't reflect any of the actual request being delivered. > > i'm a little confused as to what i can do now. > > Unless I'm misunderstanding your question, this sounds like the right > behavior. The relevant specification is actually the Servlet > specification (section SRV.8.2), though see JSTL 1.0 section 7.4 for the > specification of <c:import>.
hm. i only had the jstl and jsp specs. thanks, i'll try and find the
servlet spec.
> > however, when this url is invoked via a <c:import url="/mapper/file">,
> > all of the information retrievable via the request object refer to the
> > 'wrapping' request, to the jsp page contains the c:import. the
> > parameters passed are available, but don't show up in the query string
> > (because the query string is for the containing jsp page).
>
> I don't see any query string in the example; did you mean to write
> /mapper?file-to-get? I'm not sure, from your description, what is being
> lost.
>
> If you need to pass parameters directly, you can use the <c:param> tag as
> a subtag of <c:import>. Otherwise, I think I'd need a little more
> information to help.
the parameters i refer to are, in fact, passed via <c:param>. so, the
relevant jsp file portion looks like:
<c:import url="/mapper/testfile">
<c:param name="name1" value="${lookup1}"/>
</c:import>
in the mapper servlet, i can do a request.getParameter( "name1" ) and
get whatever value lookup1 contained. but if i do a
request.getQueryString(), it returns blank. also, i have no way of
extracting the 'testfile' information, it is simply lost; a call to
request.getRequestURI(), .getRequestURL() and .getServletPath() will
return references to the calling page (debug.jsp in this case). i guess
i could just turn the filename into a parameter also.
it just a bit disconcerting, i'm going to have to be very careful about
calling existing servlets as they will quite possibly break as well as
handling (possibly special handling) of cases where a servlet is called
either directly or imported. this might not be the case with a
cross-context servlet, and probably not the case with an absolute url,
i'll have to test. but then there is extra overhead in using those
types of connections also.
thanks.
--
CraigL->Thx();
Be Developer ID: 5852
signature.asc
Description: This is a digitally signed message part
