| Bug with recursive jsp includes (HttpServletRequestAdapter)??? [message #87140] |
Fri, 27 April 2007 09:18  |
Eclipse User |
|
|
|
Hi,
I'm running my web application with equinox in a servlet container (tomcat
5.5). For jsp support, I'm using the incubator bundle
'org.eclipse.equinox.jsp.jasper' (JspServlet is mapped with "*.jsp" and
all resources are mapped with "/").
Now, it seems that the JspServlet is unable to resolve recursive jsp
includes, that means for instance, if the jsp page "a.jsp" includes
"b.jsp" it works well, but if "b.jsp" includes "c.jsp" additionally, than
it doesn't work anymore -> "c.jsp" is then managed as a resource and shown
(source) in the browser.
I debugged the request (the include chain) and in this case the path_info
attribute is always "b.jsp/c.jsp" -> since this pattern (alias) is not
registered, it's treated as a resource.
The problem is that the HttpServletRequestAdaptor (incubator bundle
'org.eclipse.equinox.http.servlet') in the getAttribute() method doesn't
handle the include path info correctly:
} else if
(attributeName.equals(HttpServletRequestAdaptor.INCLUDE_PATH _INFO_ATTRIBUTE))
{
String pathInfo = (String)
super.getAttribute(HttpServletRequestAdaptor.INCLUDE_PATH_IN FO_ATTRIBUTE);
if (alias.equals("/")) { //$NON-NLS-1$
return pathInfo;
}
return pathInfo.substring(alias.length()); // HERE IS THE BUG!!!
}
Tomcat constructs the include path info in the
JspRuntimeLibrary.getContextRelativePath() and for that, it compares the
attribute result with pathInfo == null and NOT with pathInfo.length() == 0
-> so I changed (patched) the HttpServletRequestAdaptor as follows and the
includes worked fine:
} else if
(attributeName.equals(HttpServletRequestAdaptor.INCLUDE_PATH _INFO_ATTRIBUTE))
{
String pathInfo = (String)
super.getAttribute(HttpServletRequestAdaptor.INCLUDE_PATH_IN FO_ATTRIBUTE);
if (alias.equals("/")) { //$NON-NLS-1$
return pathInfo;
}
/*
* PATCH:
* Tomcat compares result by (pathInfo == null)
* -> see JspRuntimeLibrary.getContextRelativePath()!
* Otherwise, jsp includes won't work correctly!
*/
String attr = pathInfo.substring(alias.length());
if(attr.length() == 0)
attr = null;
return attr;
//return pathInfo.substring(alias.length()); // Equinox Version
}
Does anyone knows about this issue (bug), or do I missed something for the
jsp includes???
thx,
teos
|
|
|
| Re: Bug with recursive jsp includes (HttpServletRequestAdapter)??? [message #87173 is a reply to message #87140] |
Fri, 27 April 2007 10:25  |
| Eclipse User |
|
|
|
Hi teos,
The jsp components have graduated out of the incubator. Please get the jsp
components from the main eclipse depot.
I tried this multi-level include use-case and it seems to work correctly for
me.
-Simon
"teos" <sasa.teofanovic@gmx.at> wrote in message
news:ce6b9ac7408ecd75146f0dd6c6f1dd01$1@www.eclipse.org...
> Hi,
>
> I'm running my web application with equinox in a servlet container (tomcat
> 5.5). For jsp support, I'm using the incubator bundle
> 'org.eclipse.equinox.jsp.jasper' (JspServlet is mapped with "*.jsp" and
> all resources are mapped with "/").
> Now, it seems that the JspServlet is unable to resolve recursive jsp
> includes, that means for instance, if the jsp page "a.jsp" includes
> "b.jsp" it works well, but if "b.jsp" includes "c.jsp" additionally, than
> it doesn't work anymore -> "c.jsp" is then managed as a resource and shown
> (source) in the browser.
>
> I debugged the request (the include chain) and in this case the path_info
> attribute is always "b.jsp/c.jsp" -> since this pattern (alias) is not
> registered, it's treated as a resource.
>
> The problem is that the HttpServletRequestAdaptor (incubator bundle
> 'org.eclipse.equinox.http.servlet') in the getAttribute() method doesn't
> handle the include path info correctly:
>
> } else if
> (attributeName.equals(HttpServletRequestAdaptor.INCLUDE_PATH _INFO_ATTRIBUTE))
> {
> String pathInfo = (String)
> super.getAttribute(HttpServletRequestAdaptor.INCLUDE_PATH_IN FO_ATTRIBUTE);
> if (alias.equals("/")) { //$NON-NLS-1$
> return pathInfo;
> }
> return pathInfo.substring(alias.length()); // HERE IS THE BUG!!!
> }
>
> Tomcat constructs the include path info in the
> JspRuntimeLibrary.getContextRelativePath() and for that, it compares the
> attribute result with pathInfo == null and NOT with pathInfo.length() ==
> 0 -> so I changed (patched) the HttpServletRequestAdaptor as follows and
> the includes worked fine:
>
> } else if
> (attributeName.equals(HttpServletRequestAdaptor.INCLUDE_PATH _INFO_ATTRIBUTE))
> {
> String pathInfo = (String)
> super.getAttribute(HttpServletRequestAdaptor.INCLUDE_PATH_IN FO_ATTRIBUTE);
> if (alias.equals("/")) { //$NON-NLS-1$
> return pathInfo;
> }
>
> /*
> * PATCH:
> * Tomcat compares result by (pathInfo == null) * -> see
> JspRuntimeLibrary.getContextRelativePath()!
> * Otherwise, jsp includes won't work correctly!
> */
> String attr = pathInfo.substring(alias.length());
> if(attr.length() == 0)
> attr = null;
> return attr;
>
> //return pathInfo.substring(alias.length()); // Equinox Version
>
> }
>
> Does anyone knows about this issue (bug), or do I missed something for the
> jsp includes???
>
> thx,
> teos
>
>
>
>
>
|
|
|
| Re: Bug with recursive jsp includes (HttpServletRequestAdapter)??? [message #87248 is a reply to message #87173] |
Mon, 30 April 2007 03:47 |
| Eclipse User |
|
|
|
Hi Simon,
I'm using the following server side equinox bundles to run my webapp:
- org.eclipse.equinox.http.registry (1.0.0.qualifier) -> CVS:
/MANIFEST.MF/1.7/Mon Sep 25 20:33:03 2006//
- org.eclipse.equinox.http.servlet (1.0.0.qualifier) -> CVS:
/MANIFEST.MF/1.2/Tue Sep 26 13:13:19 2006//
- org.eclipse.equinox.jakarta.commons.el (1.0.0) -> CVS:
/MANIFEST.MF/1.1/Fri Jun 9 19:40:30 2006//
- org.eclipse.equinox.jasper (5.5.17.qualifier) -> CVS:
/MANIFEST.MF/1.3/Thu Oct 19 21:25:38 2006//
- org.eclipse.equinox.jsp.jasper (1.0.0.qualifier) -> CVS:
/MANIFEST.MF/1.2/Fri Oct 20 04:50:28 2006//
As you can see the CVS information from the manifest files, these bundles
are from last - perhaps to old and buggy? I'll get the newest ones and try
it again!
thx,
teos
|
|
|
Powered by
FUDForum. Page generated in 0.22037 seconds
Home