You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Nathan Potter <np...@opendap.org> on 2011/10/17 18:47:58 UTC
JspServlet - Unexpected behavior, possible bug...
Greetings,
I am new to this list and I apologize in advance if this has been
covered (although searching the archives did not lead me to a related
thread):
In my web application I need to utilize the JSP servlet, but I need to
use a different servlet mapping:
<servlet-mapping>
<servlet-name>jsp</servlet-name>
<url-pattern>/jsp/*</url-pattern>
</servlet-mapping>
This mapping works great, but I have noticed an odd thing:
- If I request a URL that references an existing JSP it works.
http://localhost:8080/test/jsp/index.jsp
- If I request a URL that references a file that does not exist I get
a 404 error, as expected.
http://localhost:8080/test/jsp/doesnotexist
- If I request a URL (with a trailing "/" character) that references
an existing directory within the the JSP servlet's purview. I get a
404 error (which seems reasonable).
http://localhost:8080/test/jsp/foo
- BUT, If I request a URL (without a trailing slash) that references
an existing directory within the the JSP servlet's purview, I get an
HTTP status 500 (Internal Server Error).
http://localhost:8080/test/jsp/foo
I think this is incorrect behavior.
When I do the same experiment with the default servlet I get an empty
directory, but no error.
I looked at the Tomcat code referenced by the stack trace:
org.apache.jasper.JasperException: File "/jsp/foo" not found
org
.apache
.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:
51)
org
.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java:
409)
org
.apache.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java:
116)
org.apache.jasper.compiler.JspUtil.getInputStream(JspUtil.java:851)
org
.apache
.jasper
.xmlparser.XMLEncodingDetector.getEncoding(XMLEncodingDetector.java:108)
org
.apache
.jasper
.compiler
.ParserController.determineSyntaxAndEncoding(ParserController.java:348)
org
.apache.jasper.compiler.ParserController.doParse(ParserController.java:
207)
org
.apache
.jasper
.compiler.ParserController.parseDirectives(ParserController.java:120)
org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:180)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:354)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:334)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:321)
org
.apache
.jasper.JspCompilationContext.compile(JspCompilationContext.java:592)
org
.apache
.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:328)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:
313)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:260)
javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
And I can see that in JspServlet in lines 312 - 316:
try {
wrapper.service(request, response, precompile);
} catch (FileNotFoundException fnfe) {
handleMissingResource(request, response, jspUri);
}
The call is being serviced. Unfortunately when this problem occurs a
"JasperException" is throw, not a FileNotFoundException and the
handleMissingResource() path way is skipped....
Any thoughts? It strikes me that this situation is one that can easily
be incurred by a type in the URL and so I don't that that an HTTP
staus of 500 should be returned in this situation.
Thanks,
Nathan
= = =
Nathan Potter ndp at opendap.org
OPeNDAP, Inc. +1.541.231.3317
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: JspServlet - Unexpected behavior, possible bug...
Posted by Nathan Potter <np...@opendap.org>.
On Oct 17, 2011, at 6:08 PM, Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Nathan,
>
> On 10/17/2011 4:53 PM, Nathan Potter wrote:
>> On Oct 17, 2011, at 1:07 PM, Christopher Schultz wrote:
>>
>>> I'd be interested to see what else happened. It looks like
>>> JspServlet is trying to compile the directory. The "file" (the
>>> directory) *does* exist, so you don't get a
>>> FileNotFoundException. This seems like an edge case that the
>>> JspServlet wasn't designed to handle.
>>
>> Exactly. It tries to open the resource (in the case a directory) as
>> a stream and that's when it errors into a JasperException .
>
> No, it doesn't cause an error to open the stream: the stream comes
> back null and Tomcat interprets that as an error: just not the one you
> expected (JasperException instead of FileNotFoundException).
Well the pint I was making was that it wasn't the one that
org.apache.jasper.servlet.JspServlet was expecting, thus causing the
500 response.
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk6c0XkACgkQ9CaO5/Lv0PD+fQCfWi3oonLEgvY9P/iD2hDJW7Fs
> hKEAn1czpFZF2j7pwldKrz1bl8CcJBMG
> =gRHl
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
= = =
Nathan Potter ndp at opendap.org
OPeNDAP, Inc. +1.541.231.3317
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: JspServlet - Unexpected behavior, possible bug...
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Nathan,
On 10/17/2011 4:53 PM, Nathan Potter wrote:
> On Oct 17, 2011, at 1:07 PM, Christopher Schultz wrote:
>
>> I'd be interested to see what else happened. It looks like
>> JspServlet is trying to compile the directory. The "file" (the
>> directory) *does* exist, so you don't get a
>> FileNotFoundException. This seems like an edge case that the
>> JspServlet wasn't designed to handle.
>
> Exactly. It tries to open the resource (in the case a directory) as
> a stream and that's when it errors into a JasperException .
No, it doesn't cause an error to open the stream: the stream comes
back null and Tomcat interprets that as an error: just not the one you
expected (JasperException instead of FileNotFoundException).
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk6c0XkACgkQ9CaO5/Lv0PD+fQCfWi3oonLEgvY9P/iD2hDJW7Fs
hKEAn1czpFZF2j7pwldKrz1bl8CcJBMG
=gRHl
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: JspServlet - Unexpected behavior, possible bug...
Posted by Nathan Potter <np...@opendap.org>.
On Oct 17, 2011, at 1:07 PM, Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Nathan,
>
> On 10/17/2011 12:47 PM, Nathan Potter wrote:
>> - BUT, If I request a URL (without a trailing slash) that
>> references an existing directory within the the JSP servlet's
>> purview, I get an HTTP status 500 (Internal Server Error).
>> http://localhost:8080/test/jsp/foo
>>
>> I think this is incorrect behavior.
>>
>> When I do the same experiment with the default servlet I get an
>> empty directory, but no error.
>>
>> I looked at the Tomcat code referenced by the stack trace:
>> org.apache.jasper.JasperException: File "/jsp/foo" not found
>> org
>> .apache
>> .jasper
>> .compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:51)
>>
>>
>> org
>> .apache
>> .jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java:409)
>>
>>
>> org
>> .apache
>> .jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java:116)
>>
>>
>> org.apache.jasper.compiler.JspUtil.getInputStream(JspUtil.java:851)
>>
>>
> org
> .apache
> .jasper
> .xmlparser.XMLEncodingDetector.getEncoding(XMLEncodingDetector.java:
> 108)
>>
>> org
>> .apache
>> .jasper
>> .compiler
>> .ParserController.determineSyntaxAndEncoding(ParserController.java:
>> 348)
>>
>>
>> org
>> .apache
>> .jasper.compiler.ParserController.doParse(ParserController.java:207)
>>
>>
>> org
>> .apache
>> .jasper
>> .compiler.ParserController.parseDirectives(ParserController.java:120)
>>
>>
>> org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:180)
>>
>>
> org.apache.jasper.compiler.Compiler.compile(Compiler.java:354)
>> org.apache.jasper.compiler.Compiler.compile(Compiler.java:334)
>> org.apache.jasper.compiler.Compiler.compile(Compiler.java:321)
>> org
>> .apache
>> .jasper.JspCompilationContext.compile(JspCompilationContext.java:592)
>>
>>
>> org
>> .apache
>> .jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:328)
>>
>>
>> org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:
>> 313)
>>
>> org.apache.jasper.servlet.JspServlet.service(JspServlet.java:260)
>> javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
>>
>> And I can see that in JspServlet in lines 312 - 316:
>>
>> try { wrapper.service(request, response, precompile); } catch
>> (FileNotFoundException fnfe) { handleMissingResource(request,
>> response, jspUri); }
>>
>> The call is being serviced. Unfortunately when this problem occurs
>> a "JasperException" is throw, not a FileNotFoundException and the
>> handleMissingResource() path way is skipped....
>>
>> Any thoughts? It strikes me that this situation is one that can
>> easily be incurred by a type in the URL and so I don't that that an
>> HTTP staus of 500 should be returned in this situation.
>
> I'd be interested to see what else happened. It looks like JspServlet
> is trying to compile the directory. The "file" (the directory) *does*
> exist, so you don't get a FileNotFoundException. This seems like an
> edge case that the JspServlet wasn't designed to handle.
Exactly. It tries to open the resource (in the case a directory) as a
stream and that's when it errors into a JasperException
>
> So, I'd bet that this is a bug, but nobody cares but you. :)
>
> What version are you using? The numbers don't match 7.0.x trunk, but I
> was able to trace-through the call stack to here in JspUtils.java:
>
> public static InputStream getInputStream(String fname, JarFile
> jarFile,
> JspCompilationContext ctxt, ErrorDispatcher err)
> throws JasperException, IOException {
>
> inputStream in = null;
>
> if (jarFile != null) {
> String jarEntryName = fname.substring(1, fname.length());
> ZipEntry jarEntry = jarFile.getEntry(jarEntryName);
> if (jarEntry == null) {
> err.jspError("jsp.error.file.not.found", fname);
> }
> in = jarFile.getInputStream(jarEntry);
> } else {
> in = ctxt.getResourceAsStream(fname);
> }
>
> if (in == null) {
> err.jspError("jsp.error.file.not.found", fname);
> }
>
> return in;
> }
>
> Looks like the null-checks here cause the problem you're seeing.
>
> Either the JAR file containing the resource can't find a ZipEntry or
> the ServletContext can't load a resource from the (disk, WAR, etc.).
>
> ZipEntry returns null when asked for an input stream (that is, no
> exception is thrown) for a directory, as does ServletContext.
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk6ciukACgkQ9CaO5/Lv0PCa2ACbBJIyTIt0hscpDhIRwaUI5MGl
> S+4AnA9uGxXHJlP0bnxUASZLoWiZyHzy
> =klJI
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
= = =
Nathan Potter ndp at opendap.org
OPeNDAP, Inc. +1.541.231.3317
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: JspServlet - Unexpected behavior, possible bug...
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Nathan,
On 10/17/2011 12:47 PM, Nathan Potter wrote:
> - BUT, If I request a URL (without a trailing slash) that
> references an existing directory within the the JSP servlet's
> purview, I get an HTTP status 500 (Internal Server Error).
> http://localhost:8080/test/jsp/foo
>
> I think this is incorrect behavior.
>
> When I do the same experiment with the default servlet I get an
> empty directory, but no error.
>
> I looked at the Tomcat code referenced by the stack trace:
> org.apache.jasper.JasperException: File "/jsp/foo" not found
> org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:51)
>
>
> org.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java:409)
>
>
> org.apache.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java:116)
>
>
> org.apache.jasper.compiler.JspUtil.getInputStream(JspUtil.java:851)
>
>
org.apache.jasper.xmlparser.XMLEncodingDetector.getEncoding(XMLEncodingDetector.java:108)
>
> org.apache.jasper.compiler.ParserController.determineSyntaxAndEncoding(ParserController.java:348)
>
>
> org.apache.jasper.compiler.ParserController.doParse(ParserController.java:207)
>
>
> org.apache.jasper.compiler.ParserController.parseDirectives(ParserController.java:120)
>
>
> org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:180)
>
>
org.apache.jasper.compiler.Compiler.compile(Compiler.java:354)
> org.apache.jasper.compiler.Compiler.compile(Compiler.java:334)
> org.apache.jasper.compiler.Compiler.compile(Compiler.java:321)
> org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:592)
>
>
> org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:328)
>
>
> org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:313)
>
> org.apache.jasper.servlet.JspServlet.service(JspServlet.java:260)
> javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
>
> And I can see that in JspServlet in lines 312 - 316:
>
> try { wrapper.service(request, response, precompile); } catch
> (FileNotFoundException fnfe) { handleMissingResource(request,
> response, jspUri); }
>
> The call is being serviced. Unfortunately when this problem occurs
> a "JasperException" is throw, not a FileNotFoundException and the
> handleMissingResource() path way is skipped....
>
> Any thoughts? It strikes me that this situation is one that can
> easily be incurred by a type in the URL and so I don't that that an
> HTTP staus of 500 should be returned in this situation.
I'd be interested to see what else happened. It looks like JspServlet
is trying to compile the directory. The "file" (the directory) *does*
exist, so you don't get a FileNotFoundException. This seems like an
edge case that the JspServlet wasn't designed to handle.
So, I'd bet that this is a bug, but nobody cares but you. :)
What version are you using? The numbers don't match 7.0.x trunk, but I
was able to trace-through the call stack to here in JspUtils.java:
public static InputStream getInputStream(String fname, JarFile
jarFile,
JspCompilationContext ctxt, ErrorDispatcher err)
throws JasperException, IOException {
inputStream in = null;
if (jarFile != null) {
String jarEntryName = fname.substring(1, fname.length());
ZipEntry jarEntry = jarFile.getEntry(jarEntryName);
if (jarEntry == null) {
err.jspError("jsp.error.file.not.found", fname);
}
in = jarFile.getInputStream(jarEntry);
} else {
in = ctxt.getResourceAsStream(fname);
}
if (in == null) {
err.jspError("jsp.error.file.not.found", fname);
}
return in;
}
Looks like the null-checks here cause the problem you're seeing.
Either the JAR file containing the resource can't find a ZipEntry or
the ServletContext can't load a resource from the (disk, WAR, etc.).
ZipEntry returns null when asked for an input stream (that is, no
exception is thrown) for a directory, as does ServletContext.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk6ciukACgkQ9CaO5/Lv0PCa2ACbBJIyTIt0hscpDhIRwaUI5MGl
S+4AnA9uGxXHJlP0bnxUASZLoWiZyHzy
=klJI
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: JspServlet - Unexpected behavior, possible bug...
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Konstantin,
On 10/18/2011 11:13 AM, Konstantin Kolinko wrote:
> I think it is OK to file a bug report for this issue.
Reported against 7.0 trunk (where it is also reproducible), including
simple test case.
https://issues.apache.org/bugzilla/show_bug.cgi?id=52051
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk6d1TMACgkQ9CaO5/Lv0PDsmACglT2Xu8TU86mHzpXV5ZKqJAWu
0NIAmgNiyLXLZ/E10JkOHhCa10KuGDqI
=hbBp
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: JspServlet - Unexpected behavior, possible bug...
Posted by Konstantin Kolinko <kn...@gmail.com>.
2011/10/18 Nathan Potter <np...@opendap.org>:
>
> On Oct 18, 2011, at 6:50 AM, Konstantin Kolinko wrote:
>
>> 2011/10/17 Nathan Potter <np...@opendap.org>:
>>>
>>>
>>> Greetings,
>>>
>>> I am new to this list and I apologize in advance if this has been covered
>>> (although searching the archives did not lead me to a related thread):
>>>
>>> In my web application I need to utilize the JSP servlet, but I need to
>>> use a
>>> different servlet mapping:
>>>
>>> <servlet-mapping>
>>> <servlet-name>jsp</servlet-name>
>>> <url-pattern>/jsp/*</url-pattern>
>>> </servlet-mapping>
>>>
>>>
>>> This mapping works great, but I have noticed an odd thing:
>>>
>>> - If I request a URL that references an existing JSP it works.
>>> http://localhost:8080/test/jsp/index.jsp
>>>
>>> - If I request a URL that references a file that does not exist I get a
>>> 404
>>> error, as expected.
>>> http://localhost:8080/test/jsp/doesnotexist
>>>
>>>
>>> - If I request a URL (with a trailing "/" character) that references an
>>> existing directory within the the JSP servlet's purview. I get a 404
>>> error
>>> (which seems reasonable).
>>> http://localhost:8080/test/jsp/foo
>>>
>>> - BUT, If I request a URL (without a trailing slash) that references an
>>> existing directory within the the JSP servlet's purview, I get an HTTP
>>> status 500 (Internal Server Error).
>>> http://localhost:8080/test/jsp/foo
>>>
>>> I think this is incorrect behavior.
>>>
>>> When I do the same experiment with the default servlet I get an empty
>>> directory, but no error.
>>>
>>> I looked at the Tomcat code referenced by the stack trace:
>>> org.apache.jasper.JasperException: File "/jsp/foo" not found
>>>
>>>
>>> org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:51)
>>>
>>>
>>> org.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java:409)
>>>
>>>
>>> org.apache.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java:116)
>>> org.apache.jasper.compiler.JspUtil.getInputStream(JspUtil.java:851)
>>>
>>>
>>> org.apache.jasper.xmlparser.XMLEncodingDetector.getEncoding(XMLEncodingDetector.java:108)
>>>
>>>
>>> org.apache.jasper.compiler.ParserController.determineSyntaxAndEncoding(ParserController.java:348)
>>>
>>>
>>> org.apache.jasper.compiler.ParserController.doParse(ParserController.java:207)
>>>
>>>
>>> org.apache.jasper.compiler.ParserController.parseDirectives(ParserController.java:120)
>>> org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:180)
>>> org.apache.jasper.compiler.Compiler.compile(Compiler.java:354)
>>> org.apache.jasper.compiler.Compiler.compile(Compiler.java:334)
>>> org.apache.jasper.compiler.Compiler.compile(Compiler.java:321)
>>>
>>>
>>> org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:592)
>>>
>>>
>>> org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:328)
>>>
>>> org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:313)
>>> org.apache.jasper.servlet.JspServlet.service(JspServlet.java:260)
>>> javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
>>> And I can see that in JspServlet in lines 312 - 316:
>>> try {
>>> wrapper.service(request, response, precompile);
>>> } catch (FileNotFoundException fnfe) {
>>> handleMissingResource(request, response, jspUri);
>>> }
>>> The call is being serviced. Unfortunately when this problem occurs a
>>> "JasperException" is throw, not a FileNotFoundException and the
>>> handleMissingResource() path way is skipped....
>>>
>>> Any thoughts? It strikes me that this situation is one that can easily be
>>> incurred by a type in the URL and so I don't that that an HTTP staus of
>>> 500
>>> should be returned in this situation.
>>>
>>
>> What exactly x.y.z Tomcat version is that?
>
>
> 6.0.33
>
I think it is OK to file a bug report for this issue.
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: JspServlet - Unexpected behavior, possible bug...
Posted by Nathan Potter <np...@opendap.org>.
On Oct 18, 2011, at 6:50 AM, Konstantin Kolinko wrote:
> 2011/10/17 Nathan Potter <np...@opendap.org>:
>>
>>
>> Greetings,
>>
>> I am new to this list and I apologize in advance if this has been
>> covered
>> (although searching the archives did not lead me to a related
>> thread):
>>
>> In my web application I need to utilize the JSP servlet, but I need
>> to use a
>> different servlet mapping:
>>
>> <servlet-mapping>
>> <servlet-name>jsp</servlet-name>
>> <url-pattern>/jsp/*</url-pattern>
>> </servlet-mapping>
>>
>>
>> This mapping works great, but I have noticed an odd thing:
>>
>> - If I request a URL that references an existing JSP it works.
>> http://localhost:8080/test/jsp/index.jsp
>>
>> - If I request a URL that references a file that does not exist I
>> get a 404
>> error, as expected.
>> http://localhost:8080/test/jsp/doesnotexist
>>
>>
>> - If I request a URL (with a trailing "/" character) that
>> references an
>> existing directory within the the JSP servlet's purview. I get a
>> 404 error
>> (which seems reasonable).
>> http://localhost:8080/test/jsp/foo
>>
>> - BUT, If I request a URL (without a trailing slash) that
>> references an
>> existing directory within the the JSP servlet's purview, I get an
>> HTTP
>> status 500 (Internal Server Error).
>> http://localhost:8080/test/jsp/foo
>>
>> I think this is incorrect behavior.
>>
>> When I do the same experiment with the default servlet I get an empty
>> directory, but no error.
>>
>> I looked at the Tomcat code referenced by the stack trace:
>> org.apache.jasper.JasperException: File "/jsp/foo" not found
>>
>>
>> org
>> .apache
>> .jasper
>> .compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:51)
>>
>>
>> org
>> .apache
>> .jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java:409)
>>
>>
>> org
>> .apache
>> .jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java:116)
>>
>> org.apache.jasper.compiler.JspUtil.getInputStream(JspUtil.java:851)
>>
>>
>> org
>> .apache
>> .jasper
>> .xmlparser.XMLEncodingDetector.getEncoding(XMLEncodingDetector.java:
>> 108)
>>
>>
>> org
>> .apache
>> .jasper
>> .compiler
>> .ParserController.determineSyntaxAndEncoding(ParserController.java:
>> 348)
>>
>>
>> org
>> .apache
>> .jasper.compiler.ParserController.doParse(ParserController.java:207)
>>
>>
>> org
>> .apache
>> .jasper
>> .compiler.ParserController.parseDirectives(ParserController.java:120)
>>
>> org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:180)
>> org.apache.jasper.compiler.Compiler.compile(Compiler.java:354)
>> org.apache.jasper.compiler.Compiler.compile(Compiler.java:334)
>> org.apache.jasper.compiler.Compiler.compile(Compiler.java:321)
>>
>>
>> org
>> .apache
>> .jasper.JspCompilationContext.compile(JspCompilationContext.java:592)
>>
>>
>> org
>> .apache
>> .jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:328)
>>
>>
>> org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:
>> 313)
>> org.apache.jasper.servlet.JspServlet.service(JspServlet.java:
>> 260)
>> javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
>> And I can see that in JspServlet in lines 312 - 316:
>> try {
>> wrapper.service(request, response, precompile);
>> } catch (FileNotFoundException fnfe) {
>> handleMissingResource(request, response, jspUri);
>> }
>> The call is being serviced. Unfortunately when this problem occurs a
>> "JasperException" is throw, not a FileNotFoundException and the
>> handleMissingResource() path way is skipped....
>>
>> Any thoughts? It strikes me that this situation is one that can
>> easily be
>> incurred by a type in the URL and so I don't that that an HTTP
>> staus of 500
>> should be returned in this situation.
>>
>
> What exactly x.y.z Tomcat version is that?
6.0.33
>
> Best regards,
> Konstantin Kolinko
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
= = =
Nathan Potter ndp at opendap.org
OPeNDAP, Inc. +1.541.231.3317
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: JspServlet - Unexpected behavior, possible bug...
Posted by Konstantin Kolinko <kn...@gmail.com>.
2011/10/17 Nathan Potter <np...@opendap.org>:
>
>
> Greetings,
>
> I am new to this list and I apologize in advance if this has been covered
> (although searching the archives did not lead me to a related thread):
>
> In my web application I need to utilize the JSP servlet, but I need to use a
> different servlet mapping:
>
> <servlet-mapping>
> <servlet-name>jsp</servlet-name>
> <url-pattern>/jsp/*</url-pattern>
> </servlet-mapping>
>
>
> This mapping works great, but I have noticed an odd thing:
>
> - If I request a URL that references an existing JSP it works.
> http://localhost:8080/test/jsp/index.jsp
>
> - If I request a URL that references a file that does not exist I get a 404
> error, as expected.
> http://localhost:8080/test/jsp/doesnotexist
>
>
> - If I request a URL (with a trailing "/" character) that references an
> existing directory within the the JSP servlet's purview. I get a 404 error
> (which seems reasonable).
> http://localhost:8080/test/jsp/foo
>
> - BUT, If I request a URL (without a trailing slash) that references an
> existing directory within the the JSP servlet's purview, I get an HTTP
> status 500 (Internal Server Error).
> http://localhost:8080/test/jsp/foo
>
> I think this is incorrect behavior.
>
> When I do the same experiment with the default servlet I get an empty
> directory, but no error.
>
> I looked at the Tomcat code referenced by the stack trace:
> org.apache.jasper.JasperException: File "/jsp/foo" not found
>
> org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:51)
>
> org.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java:409)
>
> org.apache.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java:116)
> org.apache.jasper.compiler.JspUtil.getInputStream(JspUtil.java:851)
>
> org.apache.jasper.xmlparser.XMLEncodingDetector.getEncoding(XMLEncodingDetector.java:108)
>
> org.apache.jasper.compiler.ParserController.determineSyntaxAndEncoding(ParserController.java:348)
>
> org.apache.jasper.compiler.ParserController.doParse(ParserController.java:207)
>
> org.apache.jasper.compiler.ParserController.parseDirectives(ParserController.java:120)
> org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:180)
> org.apache.jasper.compiler.Compiler.compile(Compiler.java:354)
> org.apache.jasper.compiler.Compiler.compile(Compiler.java:334)
> org.apache.jasper.compiler.Compiler.compile(Compiler.java:321)
>
> org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:592)
>
> org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:328)
>
> org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:313)
> org.apache.jasper.servlet.JspServlet.service(JspServlet.java:260)
> javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
> And I can see that in JspServlet in lines 312 - 316:
> try {
> wrapper.service(request, response, precompile);
> } catch (FileNotFoundException fnfe) {
> handleMissingResource(request, response, jspUri);
> }
> The call is being serviced. Unfortunately when this problem occurs a
> "JasperException" is throw, not a FileNotFoundException and the
> handleMissingResource() path way is skipped....
>
> Any thoughts? It strikes me that this situation is one that can easily be
> incurred by a type in the URL and so I don't that that an HTTP staus of 500
> should be returned in this situation.
>
What exactly x.y.z Tomcat version is that?
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: JspServlet - Unexpected behavior, possible bug...
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Christopher Schultz [mailto:chris@christopherschultz.net]
> Subject: Re: JspServlet - Unexpected behavior, possible bug...
> On 10/17/2011 2:29 PM, Ann Ramsey wrote:
> > we figured it out - thank you
> What was the problem?
It appears Ms Ramsey is completely clueless concerning use of mailing lists...
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
Re: JspServlet - Unexpected behavior, possible bug...
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Ann,
On 10/17/2011 2:29 PM, Ann Ramsey wrote:
> we figured it out - thank you
What was the problem? This isn't tech support: this is a community of
volunteers and users. How about helping them out and explaining what
went wrong so others can figure it out in the future?
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk6cgqEACgkQ9CaO5/Lv0PBeUgCfZoxXT9aJeS2NoZ6Q2aKCd0Fm
xX0An3saUAY3FW+37V5FaNXZyHUbCjEs
=7MOk
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] JspServlet - Unexpected behavior, possible bug...
Posted by "Mark H. Wood" <mw...@IUPUI.Edu>.
In addition to enriching the community (which helps *you* when we all
treat it as the norm) and helping out others who may come along with
similar problems, explaining how you worked it out gives you a chance
to show how clever you were. :-)
--
Mark H. Wood, Lead System Programmer mwood@IUPUI.Edu
Asking whether markets are efficient is like asking whether people are smart.
Re: [OT] JspServlet - Unexpected behavior, possible bug...
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Ann,
On 10/17/2011 4:01 PM, Ann Ramsey wrote:
> Honestly, I'm just using another person's login. We don't really
> have an IT guy, so I don't understand all the responses. I really
> appreciate everyone responding though. You guys are very nice to
> respond!
It looks like you think every message is about your topic. This is a
multi-topic, high-volume mailing list. Be aware that other people are
discussing other things.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk6ciyQACgkQ9CaO5/Lv0PCstQCggjMnFIi/fjMj/sourXTCBKfL
3nUAn0YQ6d5T69zckHMOmxU1dFM81Qkm
=DQvP
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: JspServlet - Unexpected behavior, possible bug...
Posted by Ann Ramsey <an...@gmail.com>.
Honestly, I'm just using another person's login. We don't really have an IT
guy, so I don't understand all the responses. I really appreciate everyone
responding though. You guys are very nice to respond!
Regards,
Ann
On Mon, Oct 17, 2011 at 2:55 PM, Nathan Potter <np...@opendap.org> wrote:
>
>
> Does that mean that you figured out what I was talking about or how to
> correct/adjust the behavior?
>
> I'm just curious if I did find a minor issue...
>
>
>
> Nathan
>
>
>
> On Oct 17, 2011, at 11:29 AM, Ann Ramsey wrote:
>
> we figured it out - thank you
>>
>> On Mon, Oct 17, 2011 at 1:14 PM, Caldarale, Charles R <
>> Chuck.Caldarale@unisys.com> wrote:
>>
>> From: Nathan Potter [mailto:npotter@opendap.org]
>>>> Subject: JspServlet - Unexpected behavior, possible bug...
>>>>
>>>
>>> In my web application I need to utilize the JSP servlet, but
>>>> I need to use a different servlet mapping:
>>>> <servlet-mapping>
>>>> <servlet-name>jsp</servlet-**name>
>>>> <url-pattern>/jsp/*</url-**pattern>
>>>> </servlet-mapping>
>>>>
>>>
>>> Before going any further, please explain why you think you need to do
>>> that.
>>> (I.e., what's the actual requirement?)
>>>
>>> - Chuck
>>>
>>>
>>> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
>>> MATERIAL and is thus for use only by the intended recipient. If you
>>> received
>>> this in error, please contact the sender and delete the e-mail and its
>>> attachments from all computers.
>>>
>>>
>>> ------------------------------**------------------------------**
>>> ---------
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.**apache.org<us...@tomcat.apache.org>
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>>
>>>
> = = =
> Nathan Potter ndp at opendap.org
> OPeNDAP, Inc. +1.541.231.3317
>
>
>
>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.**apache.org<us...@tomcat.apache.org>
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
RE: JspServlet - Unexpected behavior, possible bug...
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Nathan Potter [mailto:npotter@opendap.org]
> Subject: Re: JspServlet - Unexpected behavior, possible bug...
> Does that mean that you figured out what I was talking about or how to
> correct/adjust the behavior?
No, but hopefully Ms Ramsey will now stop polluting the mailing list. Let's go back to my original question:
> In my web application I need to utilize the JSP servlet, but
> I need to use a different servlet mapping:
> <servlet-mapping>
> <servlet-name>jsp</servlet-name>
> <url-pattern>/jsp/*</url-pattern>
> </servlet-mapping>
Before going any further, please explain why you think you need to do that. (I.e., what's the actual requirement?)
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: JspServlet - Unexpected behavior, possible bug...
Posted by Nathan Potter <np...@opendap.org>.
Does that mean that you figured out what I was talking about or how to
correct/adjust the behavior?
I'm just curious if I did find a minor issue...
Nathan
On Oct 17, 2011, at 11:29 AM, Ann Ramsey wrote:
> we figured it out - thank you
>
> On Mon, Oct 17, 2011 at 1:14 PM, Caldarale, Charles R <
> Chuck.Caldarale@unisys.com> wrote:
>
>>> From: Nathan Potter [mailto:npotter@opendap.org]
>>> Subject: JspServlet - Unexpected behavior, possible bug...
>>
>>> In my web application I need to utilize the JSP servlet, but
>>> I need to use a different servlet mapping:
>>> <servlet-mapping>
>>> <servlet-name>jsp</servlet-name>
>>> <url-pattern>/jsp/*</url-pattern>
>>> </servlet-mapping>
>>
>> Before going any further, please explain why you think you need to
>> do that.
>> (I.e., what's the actual requirement?)
>>
>> - Chuck
>>
>>
>> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE
>> PROPRIETARY
>> MATERIAL and is thus for use only by the intended recipient. If you
>> received
>> this in error, please contact the sender and delete the e-mail and
>> its
>> attachments from all computers.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
= = =
Nathan Potter ndp at opendap.org
OPeNDAP, Inc. +1.541.231.3317
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: JspServlet - Unexpected behavior, possible bug...
Posted by Ann Ramsey <an...@gmail.com>.
we figured it out - thank you
On Mon, Oct 17, 2011 at 1:14 PM, Caldarale, Charles R <
Chuck.Caldarale@unisys.com> wrote:
> > From: Nathan Potter [mailto:npotter@opendap.org]
> > Subject: JspServlet - Unexpected behavior, possible bug...
>
> > In my web application I need to utilize the JSP servlet, but
> > I need to use a different servlet mapping:
> > <servlet-mapping>
> > <servlet-name>jsp</servlet-name>
> > <url-pattern>/jsp/*</url-pattern>
> > </servlet-mapping>
>
> Before going any further, please explain why you think you need to do that.
> (I.e., what's the actual requirement?)
>
> - Chuck
>
>
> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
> MATERIAL and is thus for use only by the intended recipient. If you received
> this in error, please contact the sender and delete the e-mail and its
> attachments from all computers.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: JspServlet - Unexpected behavior, possible bug...
Posted by Nathan Potter <np...@opendap.org>.
On Oct 17, 2011, at 6:36 PM, Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Nathan,
>
> On 10/17/2011 9:21 PM, Nathan Potter wrote:
>> No, but if you assign a servlet to "/" or "/*" it gets call
>> foreverything before anything starting with "*". Basically starts
>> with "/" trumps starts with "*" when applying url patterns.
>
> If I'm reading that right (read it 5 or 6 times to just be sure I thin
> I understand it), you are saying that:
>
> a. Mapping Tomcat's DefaultServlet to "/" and
> b. Mapping Tomcat's JSP Servlet to "*.jsp"
>
> will result in DefaultServlet serving all content, and the JSP servlet
> never running.
Almost. When I map our servlet to "/*". Then we see the problem.
>
> Since that's the default configuration described above and JSPs and
> static content certainly do work properly under the default
> configuration, I must (still) be reading that incorrectly.
>
>> But this is the point. Look at the stack trace. The error is coming
>> from the Jasper JspServlet - my code is not being called. The
>> JspServlet is getting tapped to respond to the request URL
>> http://localhost:8080/contextName/admin
>
> So there is no redirect going on? Obviously, redirects don't show in
> stack traces...
I brought all the tomcat code into my IDE and set break points and all
that - my code is not accessed.
>
>>> It looks like you haven't done that. But, if you haven't, then
>>> why does the JSP servlet get invoked? You mapped it to
>>> "/admin/*", not to "/admin"...
>>
>> That's the question isn't it....
>
> You didn't post the entire stack trace, so it's hard to tell.
I haven't been able to figure out how to get that to appear in the
Tomcat log. I use the logback log4j package and I have turned on
logging and added appenders fro org.apache and turned it up to all and
I haven't gotten any output...
>
>>> Let's see the change you made. It might not work under all
>>> circumstances.
>>
>> Oh I'm sure it won't. It's a work around, not a patch by any
>> means. Here's the important part:
>>
>> public class JspServlet extends
>> org.apache.jasper.servlet.JspServlet {
>>
>> public void service(HttpServletRequest request,
>> HttpServletResponse response) throws IOException, ServletException
>> {
>>
>> String jspUri = request.getServletPath();
>>
>> String pathInfo = request.getPathInfo(); if (pathInfo != null) {
>> jspUri += pathInfo; } String realPath =
>> context.getRealPath(jspUri);
>>
>> File f = new File(realPath);
>
> Oh, yeah, that definitely won't work: calling getRealPath isn't
> reliable because you can't guarantee a "real" filesystem supporting
> the webapp. It would be better to call ServletContext.getResource() or
> something like that.
>
>>> if(f.exists() && f.isDirectory()) {
>
> Without a java.io.File, this is of course impossible.
>
> Any fix should probably be applied in JspUtils.getInputStream. I'm not
> a big fan of throwing FileNotFoundException for things that aren't
> java.io.File objects (ignoring the Java API's behavior :) but I wonder
> if a subclass of JasperException could be used in these situations.
>
> In the case of the ZipEntry, you can ask a ZipEntry if it's a
> directory: if so, maybe an even more explicit exception could be
> thrown. When a ZipEntry isn't involved (e.g. serving directly off the
> filesystem where the URI results in an attempt to get a stream for a
> directory), it's less clear what to do other than throwing a
> JasperFileNotFoundException or whatever.
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk6c2AAACgkQ9CaO5/Lv0PDdowCgiXGwX0c523f/jzgH7psJD761
> Fb8An2V4nhD7xFbKfkdxl75jxTvtPrSn
> =cLPU
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
= = =
Nathan Potter ndp at opendap.org
OPeNDAP, Inc. +1.541.231.3317
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: JspServlet - Unexpected behavior, possible bug...
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Nathan,
On 10/17/2011 9:21 PM, Nathan Potter wrote:
> No, but if you assign a servlet to "/" or "/*" it gets call
> foreverything before anything starting with "*". Basically starts
> with "/" trumps starts with "*" when applying url patterns.
If I'm reading that right (read it 5 or 6 times to just be sure I thin
I understand it), you are saying that:
a. Mapping Tomcat's DefaultServlet to "/" and
b. Mapping Tomcat's JSP Servlet to "*.jsp"
will result in DefaultServlet serving all content, and the JSP servlet
never running.
Since that's the default configuration described above and JSPs and
static content certainly do work properly under the default
configuration, I must (still) be reading that incorrectly.
> But this is the point. Look at the stack trace. The error is coming
> from the Jasper JspServlet - my code is not being called. The
> JspServlet is getting tapped to respond to the request URL
> http://localhost:8080/contextName/admin
So there is no redirect going on? Obviously, redirects don't show in
stack traces...
>> It looks like you haven't done that. But, if you haven't, then
>> why does the JSP servlet get invoked? You mapped it to
>> "/admin/*", not to "/admin"...
>
> That's the question isn't it....
You didn't post the entire stack trace, so it's hard to tell.
>> Let's see the change you made. It might not work under all
>> circumstances.
>
> Oh I'm sure it won't. It's a work around, not a patch by any
> means. Here's the important part:
>
> public class JspServlet extends
> org.apache.jasper.servlet.JspServlet {
>
> public void service(HttpServletRequest request,
> HttpServletResponse response) throws IOException, ServletException
> {
>
> String jspUri = request.getServletPath();
>
> String pathInfo = request.getPathInfo(); if (pathInfo != null) {
> jspUri += pathInfo; } String realPath =
> context.getRealPath(jspUri);
>
> File f = new File(realPath);
Oh, yeah, that definitely won't work: calling getRealPath isn't
reliable because you can't guarantee a "real" filesystem supporting
the webapp. It would be better to call ServletContext.getResource() or
something like that.
>> if(f.exists() && f.isDirectory()) {
Without a java.io.File, this is of course impossible.
Any fix should probably be applied in JspUtils.getInputStream. I'm not
a big fan of throwing FileNotFoundException for things that aren't
java.io.File objects (ignoring the Java API's behavior :) but I wonder
if a subclass of JasperException could be used in these situations.
In the case of the ZipEntry, you can ask a ZipEntry if it's a
directory: if so, maybe an even more explicit exception could be
thrown. When a ZipEntry isn't involved (e.g. serving directly off the
filesystem where the URI results in an attempt to get a stream for a
directory), it's less clear what to do other than throwing a
JasperFileNotFoundException or whatever.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk6c2AAACgkQ9CaO5/Lv0PDdowCgiXGwX0c523f/jzgH7psJD761
Fb8An2V4nhD7xFbKfkdxl75jxTvtPrSn
=cLPU
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: JspServlet - Unexpected behavior, possible bug...
Posted by Nathan Potter <np...@opendap.org>.
On Oct 17, 2011, at 6:41 PM, Caldarale, Charles R wrote:
>> From: Nathan Potter [mailto:npotter@opendap.org]
>> Subject: Re: JspServlet - Unexpected behavior, possible bug...
>
>> by default servlet I mean the servlet mapped to "/" or "/*"
>
> And right there is your terminology problem. The default servlet is
> the one mapped to "/"; anything mapped to "/*" is _not_ the default
> servlet, but due to servlet spec rules, it will receive all
> otherwise unmatched requests, since "/*" is a longer string than
> "/"; the default servlet will never see any requests in this case.
OK, I guess I wasn't clear on the details of this. That precisely fits
the behaviors I have been seeing.
>
>> Having both means that you the same page here:
>> context/
>> and here:
>> context/hyrax/
>> Which has been the expected behavior.
>
> Assuming that the word left out of the first sentence is "see" (or
> equivalent), the "/hyrax" mapping is still redundant; removing it
> will still get a match due to "/*" for the hyrax servlet.
That's true - but the webapp will not return the same page as context/
I realize that this is truly perverse, but the idea is that you get
the same exact page both an contex/ and context/hyrax/ the reason you
don't is because the hyrax servlet returns pages that allow the user
to browse a directed graph of holdings. When you leave out the /hyrax/
* mapping then the url that ends in context/ will return the top of
these holdings ("/"in a relative sense), and the url that ends in
context/hyrax/ will return the holdings (if they exisit) for the top
level collection called hyrax ("/hyrax/"). The desired result is for
both context/ and context/hyrax/ to return the exact same page, the
top ("/") of the hyrax servlets holdings.
>
>> No, but if you assign a servlet to "/" or "/*" it gets call
>> foreverything before anything starting with "*".
>
> Not true; "/*" will beat "*.jsp", but "/" does not beat "*.jsp".
> Check the rules in the spec.
I did in fact read the spec. but I guess I didn't fully get this bit.
>
> Maybe we need to see all of your servlet mappings in your web.xml.
>
> - Chuck
>
>
> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE
> PROPRIETARY MATERIAL and is thus for use only by the intended
> recipient. If you received this in error, please contact the sender
> and delete the e-mail and its attachments from all computers.
>
= = =
Nathan Potter ndp at opendap.org
OPeNDAP, Inc. +1.541.231.3317
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: JspServlet - Unexpected behavior, possible bug...
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Nathan Potter [mailto:npotter@opendap.org]
> Subject: Re: JspServlet - Unexpected behavior, possible bug...
> by default servlet I mean the servlet mapped to "/" or "/*"
And right there is your terminology problem. The default servlet is the one mapped to "/"; anything mapped to "/*" is _not_ the default servlet, but due to servlet spec rules, it will receive all otherwise unmatched requests, since "/*" is a longer string than "/"; the default servlet will never see any requests in this case.
> Having both means that you the same page here:
> context/
> and here:
> context/hyrax/
> Which has been the expected behavior.
Assuming that the word left out of the first sentence is "see" (or equivalent), the "/hyrax" mapping is still redundant; removing it will still get a match due to "/*" for the hyrax servlet.
> No, but if you assign a servlet to "/" or "/*" it gets call
> foreverything before anything starting with "*".
Not true; "/*" will beat "*.jsp", but "/" does not beat "*.jsp". Check the rules in the spec.
Maybe we need to see all of your servlet mappings in your web.xml.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: JspServlet - Unexpected behavior, possible bug...
Posted by Nathan Potter <np...@opendap.org>.
On Oct 17, 2011, at 6:00 PM, Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Nathan,
>
> On 10/17/2011 4:50 PM, Nathan Potter wrote:
>> Historically, the servlet that I am working with has been the
>> default servlet. Tomcat's default servlet was used to serve docs
>> from a subdirectory of the context dir, and everything else was
>> dynamically generated by the default servlet. JSP was never used so
>> no there was no issue there.
>
> I'm guessing that "the default servlet" really has at least two
> meanings above.. it's not at all clear what you're talking about.
Oh sorry, by default servlet I mean the servlet mapped to "/" or "/*"
in the web application. I've been trying to say the "tomcat default
servlet" if I mean org.apache.catalina.servlets.DefaultServlet. I'll
try to more more explicit.
>
>> A new feature has been added to the web application that requires
>> JSP. But because an alternative default servlet is defined, this
>> disables the use of the JspServlet using the *.jsp url-pattern in
>> the servlet mapping. (This may be caused by a failure to properly
>> implement the alternate default servlet?? I don't know how to
>> tell.)
>
> Wait, what? Changing the default servlet un-maps the JSP servlet?
> Something must be wrong with your configuration.
>
>> What I thought to do was:
>>
>> <servlet-mapping> <servlet-name>hyrax</servlet-name>
>> <url-pattern>/*</url-pattern> <url-pattern>/hyrax/*</url-pattern>
>> </servlet-mapping>
>
> FYI those two mappings are redundant: /* includes /hyrax/*. A "*"
> doesn't mean "anything but a /", it indicates that anything that
> starts with "/hyrax/" should be mapped to the "hyrax" servlet. URL
> mappings in web.xml aren't as expressive as just about anyone would
> like them to be. Specifically, they are neither simple globs nor are
> they regular expressions.
You would think that they would be redundant but in fact the server
behaves differently if you use them both.
Having both means that you the same page here:
context/
and here:
context/hyrax/
Which has been the expected behavior.
>
>> <servlet-mapping> <servlet-name>jsp</servlet-name>
>> <url-pattern>/jsp/*</url-pattern>
>> <url-pattern>/admin/*</url-pattern>
>> <url-pattern>/error/*</url-pattern> </servlet-mapping>
>
> What's wrong with the default, which is "/*.jsp" for the JSP servlet?
> Do you have files with the .jsp extension that you need served without
> actually invoking the JSP servlet?
No, but if you assign a servlet to "/" or "/*" it gets call
foreverything before anything starting with "*". Basically starts with
"/" trumps starts with "*" when applying url patterns.
>
>> Which worked, but when accessing the URL:
>>
>> http://localhost:8080/myContext/admin
>>
>> I would get back a 500 error.
>
> So don't do that :)
:)
>
>> And:
>>
>> http://localhost:8080/myContext/admin/
>>
>> Would return the (index.jsp) welcome page.
>
> I would have expected an error, same as above.
index.jsp is in the welcome-file-list and apparently the JspServlet is
good with that.
>
>> Now, one might argue that the first URL should 404, or one might
>> argue that it should redirect to the 2nd URL. But I think it's a
>> tough argument to make that it should return a 500 error.
>
> If you implemented your default servlet in the same way that Tomcat's
> is done, then a redirect from /admin -> /admin/ will occur.
It is sort of like tomcat but different.
But this is the point. Look at the stack trace. The error is coming
from the Jasper JspServlet - my code is not being called. The
JspServlet is getting tapped to respond to the request URL http://localhost:8080/contextName/admin
> It looks
> like you haven't done that. But, if you haven't, then why does the JSP
> servlet get invoked? You mapped it to "/admin/*", not to "/admin"...
That's the question isn't it....
>
>> And I didn't see anywhere in the documentation that said you
>> SHOULDN'T use the JSP Servlet this way...
>>
>> I wrote a work around by subclassing
>> org.apache.jasper.servlet.JspServlet and wrapping/overriding the
>> service() method with a check for the directory w/o the trailing
>> slash condition and returning a redirect when it happens and
>> passing the call down to super.service() when it doesn't. That
>> works great, but I figured the 500 error wasn't a desired behavior
>> so I wrote in to the list about it, as the documentation at Tomcat
>> home indicated that all bug reports should begin here.
>
> Let's see the change you made. It might not work under all
> circumstances.
Oh I'm sure it won't. It's a work around, not a patch by any means.
Here's the important part:
public class JspServlet extends org.apache.jasper.servlet.JspServlet {
public void service(HttpServletRequest request,
HttpServletResponse response) throws IOException, ServletException {
String jspUri = request.getServletPath();
String pathInfo = request.getPathInfo();
if (pathInfo != null) {
jspUri += pathInfo;
}
String realPath = context.getRealPath(jspUri);
File f = new File(realPath);
if(f.exists() && f.isDirectory()) {
String contextPath = context.getContextPath();
StringBuilder redirectUrl = new
StringBuilder().append(contextPath).append(jspUri).append("/");
response.sendRedirect(redirectUrl.toString());
//super.service(request, response);
//response.sendError(HttpServletResponse.SC_NOT_FOUND);
}
else
super.service(request, response);
}
)
Thanks for your helpful response.
Nathan
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk6cz5AACgkQ9CaO5/Lv0PAs0ACfUhNocwUmqavtJ8ilBn5QZPBT
> kscAnjRDeapkGccOE4MvsWVqoteuN7wK
> =IgYU
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
= = =
Nathan Potter ndp at opendap.org
OPeNDAP, Inc. +1.541.231.3317
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: JspServlet - Unexpected behavior, possible bug...
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Nathan,
On 10/17/2011 4:50 PM, Nathan Potter wrote:
> Historically, the servlet that I am working with has been the
> default servlet. Tomcat's default servlet was used to serve docs
> from a subdirectory of the context dir, and everything else was
> dynamically generated by the default servlet. JSP was never used so
> no there was no issue there.
I'm guessing that "the default servlet" really has at least two
meanings above.. it's not at all clear what you're talking about.
> A new feature has been added to the web application that requires
> JSP. But because an alternative default servlet is defined, this
> disables the use of the JspServlet using the *.jsp url-pattern in
> the servlet mapping. (This may be caused by a failure to properly
> implement the alternate default servlet?? I don't know how to
> tell.)
Wait, what? Changing the default servlet un-maps the JSP servlet?
Something must be wrong with your configuration.
> What I thought to do was:
>
> <servlet-mapping> <servlet-name>hyrax</servlet-name>
> <url-pattern>/*</url-pattern> <url-pattern>/hyrax/*</url-pattern>
> </servlet-mapping>
FYI those two mappings are redundant: /* includes /hyrax/*. A "*"
doesn't mean "anything but a /", it indicates that anything that
starts with "/hyrax/" should be mapped to the "hyrax" servlet. URL
mappings in web.xml aren't as expressive as just about anyone would
like them to be. Specifically, they are neither simple globs nor are
they regular expressions.
> <servlet-mapping> <servlet-name>jsp</servlet-name>
> <url-pattern>/jsp/*</url-pattern>
> <url-pattern>/admin/*</url-pattern>
> <url-pattern>/error/*</url-pattern> </servlet-mapping>
What's wrong with the default, which is "/*.jsp" for the JSP servlet?
Do you have files with the .jsp extension that you need served without
actually invoking the JSP servlet?
> Which worked, but when accessing the URL:
>
> http://localhost:8080/myContext/admin
>
> I would get back a 500 error.
So don't do that :)
> And:
>
> http://localhost:8080/myContext/admin/
>
> Would return the (index.jsp) welcome page.
I would have expected an error, same as above.
> Now, one might argue that the first URL should 404, or one might
> argue that it should redirect to the 2nd URL. But I think it's a
> tough argument to make that it should return a 500 error.
If you implemented your default servlet in the same way that Tomcat's
is done, then a redirect from /admin -> /admin/ will occur. It looks
like you haven't done that. But, if you haven't, then why does the JSP
servlet get invoked? You mapped it to "/admin/*", not to "/admin"...
> And I didn't see anywhere in the documentation that said you
> SHOULDN'T use the JSP Servlet this way...
>
> I wrote a work around by subclassing
> org.apache.jasper.servlet.JspServlet and wrapping/overriding the
> service() method with a check for the directory w/o the trailing
> slash condition and returning a redirect when it happens and
> passing the call down to super.service() when it doesn't. That
> works great, but I figured the 500 error wasn't a desired behavior
> so I wrote in to the list about it, as the documentation at Tomcat
> home indicated that all bug reports should begin here.
Let's see the change you made. It might not work under all circumstances.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk6cz5AACgkQ9CaO5/Lv0PAs0ACfUhNocwUmqavtJ8ilBn5QZPBT
kscAnjRDeapkGccOE4MvsWVqoteuN7wK
=IgYU
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: JspServlet - Unexpected behavior, possible bug...
Posted by Nathan Potter <np...@opendap.org>.
Chris et al.,
Thanks having a careful look at the 500 status thing. I realize that
our application is not using Tomcat in the "usual" manner, and that
this unusual use does not a use case make. So the fact that you're
willing to consider fixing it is much appreciated.
I'll keep looking at urlrewritefilter as a way to mitigate the issue.
Thanks,
Nathan
On Oct 18, 2011, at 12:10 PM, Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Nathan,
>
> At this point, all discussion is academic because you sound like you
> are stuck with what you've got. I would recommend fixing the apparent
> bugs in your replacement default servlet, but I don't get to make
> requirements decisions on your project :)
>
> On 10/17/2011 11:29 PM, Nathan Potter wrote:
>> I seem to be exploring the set of all possible mapping
>> permutations.
>>
>> When you change the mapping to "/" from "/*" the methods
>> HttpServletRequest.getPathInfo() and
>> HttpServletRequest.getPathTranslated() change their output from a
>> useful string to null.
>
> You shouldn't be using getPathTranslated, anyway, as there is no
> guarantee that a physical file system actually exists.
> getPathTranslated uses getPathInfo and returns null when there is no
> "path info", so the behavior of these methods are kind of locked-
> together.
>
> getPathInfo will return everything after the servlet path. When using
> "/*" I have no idea what the servlet path will be, especially when you
> also have "/hyrix/*" or whatever mapped to the same URL. Technically,
> the servlet maps in two ways -- I would expect the longest path-match
> to be selected first (as spec requires it) so you get the behavior of
> /foo and /hyrox/foo being essentially the same request. I have no idea
> why you'd want that behavior, but hey, it's your webapp.
>
> If you use "/" as the url-pattern, the servlet will get requests that
> don't match anything else. It's *not* a prefix mapping, it's a default
> mapping. I'm not surprised that getPathInfo goes to null when you use
> it, since the entire URI ends up being the "servlet path" and there's
> nothing else left-over for the path info.
>
> I'm curious as to why you are using getPathInfo in the first place.
> Are you or are you not serving static content? Are you expecting to
> look for resources on the filesystem? I still don't really understand
> why Tomcat's DefaultServlet doesn't meet your needs. If all you really
> need is /hyrix/* to look like /*, then that can be done with
> server-side forwarding using something like URLRewrite (as suggested
> by another poster at some point).
>
>> Additionally the HttpServletRequest.getServletPath() method which
>> has somewhat different semantics when the mapping is "/" rather
>> than "/*".
>
> Yes. Essentially, getServletPath and getPathInfo will slice-up the
> request URI in different ways depending upon the url-mapping you have
> given it in web.xml.
>
>> The web application uses all three of those methods and not very
>> flexible in the way that it does so.
>
> That's a shame.
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk6dzxIACgkQ9CaO5/Lv0PBRWACfSfLiV2R9tucSrTYEgiGEEfPD
> 3vcAnj3pfStK9lADJVMfiLOlWzlclK4J
> =2Aqs
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
= = =
Nathan Potter ndp at opendap.org
OPeNDAP, Inc. +1.541.231.3317
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: JspServlet - Unexpected behavior, possible bug...
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Nathan,
At this point, all discussion is academic because you sound like you
are stuck with what you've got. I would recommend fixing the apparent
bugs in your replacement default servlet, but I don't get to make
requirements decisions on your project :)
On 10/17/2011 11:29 PM, Nathan Potter wrote:
> I seem to be exploring the set of all possible mapping
> permutations.
>
> When you change the mapping to "/" from "/*" the methods
> HttpServletRequest.getPathInfo() and
> HttpServletRequest.getPathTranslated() change their output from a
> useful string to null.
You shouldn't be using getPathTranslated, anyway, as there is no
guarantee that a physical file system actually exists.
getPathTranslated uses getPathInfo and returns null when there is no
"path info", so the behavior of these methods are kind of locked-together.
getPathInfo will return everything after the servlet path. When using
"/*" I have no idea what the servlet path will be, especially when you
also have "/hyrix/*" or whatever mapped to the same URL. Technically,
the servlet maps in two ways -- I would expect the longest path-match
to be selected first (as spec requires it) so you get the behavior of
/foo and /hyrox/foo being essentially the same request. I have no idea
why you'd want that behavior, but hey, it's your webapp.
If you use "/" as the url-pattern, the servlet will get requests that
don't match anything else. It's *not* a prefix mapping, it's a default
mapping. I'm not surprised that getPathInfo goes to null when you use
it, since the entire URI ends up being the "servlet path" and there's
nothing else left-over for the path info.
I'm curious as to why you are using getPathInfo in the first place.
Are you or are you not serving static content? Are you expecting to
look for resources on the filesystem? I still don't really understand
why Tomcat's DefaultServlet doesn't meet your needs. If all you really
need is /hyrix/* to look like /*, then that can be done with
server-side forwarding using something like URLRewrite (as suggested
by another poster at some point).
> Additionally the HttpServletRequest.getServletPath() method which
> has somewhat different semantics when the mapping is "/" rather
> than "/*".
Yes. Essentially, getServletPath and getPathInfo will slice-up the
request URI in different ways depending upon the url-mapping you have
given it in web.xml.
> The web application uses all three of those methods and not very
> flexible in the way that it does so.
That's a shame.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk6dzxIACgkQ9CaO5/Lv0PBRWACfSfLiV2R9tucSrTYEgiGEEfPD
3vcAnj3pfStK9lADJVMfiLOlWzlclK4J
=2Aqs
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: JspServlet - Unexpected behavior, possible bug...
Posted by Nathan Potter <np...@opendap.org>.
On Oct 17, 2011, at 6:02 PM, Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Nathan,
>
> On 10/17/2011 8:56 PM, Nathan Potter wrote:
>> I don't see how to do it without using a rewrite rule for every
>> thing in the top level collection of URL's. I think if you try to
>> rewrite the root of the context that it's going to disable other
>> services you have running.
>
> Note that Tomcat maps DefaultServlet to "/" and not to "/*". You could
> try that mapping to see if the JSP stuff clears up. You really
> shouldn't need to re-map *.jsp.
I seem to be exploring the set of all possible mapping permutations.
When you change the mapping to "/" from "/*" the methods
HttpServletRequest.getPathInfo() and
HttpServletRequest.getPathTranslated() change their output from a
useful string to null. Additionally the
HttpServletRequest.getServletPath() method which has somewhat
different semantics when the mapping is "/" rather than "/*".
The web application uses all three of those methods and not very
flexible in the way that it does so.
Nathan
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk6c0A8ACgkQ9CaO5/Lv0PB12ACgl9m85VUJg0V8p29xBPNtSitD
> Y9AAoI0aBURjb3cxlL23uwpI6s7HxNUQ
> =wytw
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
= = =
Nathan Potter ndp at opendap.org
OPeNDAP, Inc. +1.541.231.3317
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: JspServlet - Unexpected behavior, possible bug...
Posted by Nathan Potter <np...@opendap.org>.
On Oct 17, 2011, at 6:02 PM, Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Nathan,
>
> On 10/17/2011 8:56 PM, Nathan Potter wrote:
>> I don't see how to do it without using a rewrite rule for every
>> thing in the top level collection of URL's. I think if you try to
>> rewrite the root of the context that it's going to disable other
>> services you have running.
>
> Note that Tomcat maps DefaultServlet to "/" and not to "/*". You could
> try that mapping to see if the JSP stuff clears up. You really
> shouldn't need to re-map *.jsp.
That breaks a bunch of other stuff because of the changes in the
responses to methods in HttpServletRequest.
:(
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk6c0A8ACgkQ9CaO5/Lv0PB12ACgl9m85VUJg0V8p29xBPNtSitD
> Y9AAoI0aBURjb3cxlL23uwpI6s7HxNUQ
> =wytw
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
= = =
Nathan Potter ndp at opendap.org
OPeNDAP, Inc. +1.541.231.3317
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: JspServlet - Unexpected behavior, possible bug...
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Nathan,
On 10/17/2011 8:56 PM, Nathan Potter wrote:
> I don't see how to do it without using a rewrite rule for every
> thing in the top level collection of URL's. I think if you try to
> rewrite the root of the context that it's going to disable other
> services you have running.
Note that Tomcat maps DefaultServlet to "/" and not to "/*". You could
try that mapping to see if the JSP stuff clears up. You really
shouldn't need to re-map *.jsp.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk6c0A8ACgkQ9CaO5/Lv0PB12ACgl9m85VUJg0V8p29xBPNtSitD
Y9AAoI0aBURjb3cxlL23uwpI6s7HxNUQ
=wytw
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: JspServlet - Unexpected behavior, possible bug...
Posted by Nathan Potter <np...@opendap.org>.
On Oct 17, 2011, at 7:44 PM, Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Chuck,
>
> On 10/17/2011 10:11 PM, Caldarale, Charles R wrote:
>>> From: Nathan Potter [mailto:npotter@opendap.org] Subject: Re:
>>> JspServlet - Unexpected behavior, possible bug...
>>
>>> I don't see how to do it without using a rewrite rule for every
>>> thing in the top level collection of URL's.
>>
>> You only need to have the filter invoked when the true
>> DefaultServlet would have been, so it would handle only otherwise
>> unmatched requests. Use the <servlet-name> element rather than
>> <url-pattern> inside the <filter-mapping>, specifying "default" as
>> the value. Leave the hyrax servlet mapped to "/hyrax/*" (and
>> possibly "/hyrax"), the DefaultServlet at "/", the JspServlet at
>> "*.jsp", and have the filter adjust the path only if it's something
>> you want hyrax to process.
>
> I'm not entirely sure, but that may require Nathan to explicitly
> define define Tomcat's DefaultServlet in his own web.xml file. I seem
> to recall having to explicitly define the JspServlet for certain
> things (maybe just for init-params).
>
> Nathan, if you try to use <servlet-name>default</servlet-name> in your
> <filter-mapping> and Tomcat throws an exception or just doesn't see
> like it's working, try explicitly defining (and mapping) Tomcat's
> DefaultServlet in your own web.xml.
OK thanks!
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk6c6CUACgkQ9CaO5/Lv0PAV2wCfYHSe9Wnk+fQMxiMTIi9+zw1+
> 5EoAnj9tzaFSnw4iqLLvE42gkPPp4TPo
> =ZblJ
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
= = =
Nathan Potter ndp at opendap.org
OPeNDAP, Inc. +1.541.231.3317
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: JspServlet - Unexpected behavior, possible bug...
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Chuck,
On 10/17/2011 10:11 PM, Caldarale, Charles R wrote:
>> From: Nathan Potter [mailto:npotter@opendap.org] Subject: Re:
>> JspServlet - Unexpected behavior, possible bug...
>
>> I don't see how to do it without using a rewrite rule for every
>> thing in the top level collection of URL's.
>
> You only need to have the filter invoked when the true
> DefaultServlet would have been, so it would handle only otherwise
> unmatched requests. Use the <servlet-name> element rather than
> <url-pattern> inside the <filter-mapping>, specifying "default" as
> the value. Leave the hyrax servlet mapped to "/hyrax/*" (and
> possibly "/hyrax"), the DefaultServlet at "/", the JspServlet at
> "*.jsp", and have the filter adjust the path only if it's something
> you want hyrax to process.
I'm not entirely sure, but that may require Nathan to explicitly
define define Tomcat's DefaultServlet in his own web.xml file. I seem
to recall having to explicitly define the JspServlet for certain
things (maybe just for init-params).
Nathan, if you try to use <servlet-name>default</servlet-name> in your
<filter-mapping> and Tomcat throws an exception or just doesn't see
like it's working, try explicitly defining (and mapping) Tomcat's
DefaultServlet in your own web.xml.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk6c6CUACgkQ9CaO5/Lv0PAV2wCfYHSe9Wnk+fQMxiMTIi9+zw1+
5EoAnj9tzaFSnw4iqLLvE42gkPPp4TPo
=ZblJ
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: JspServlet - Unexpected behavior, possible bug...
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Nathan Potter [mailto:npotter@opendap.org]
> Subject: Re: JspServlet - Unexpected behavior, possible bug...
> So is the idea to identify to the filter: "These are the things for
> the org.apache.catalina.servlets.DefaultServlet" and then send
> everything else to Hyrax? Can it be configured like that?
Yes, the UrlRewriteFilter is extremely flexible.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: JspServlet - Unexpected behavior, possible bug...
Posted by Nathan Potter <np...@opendap.org>.
On Oct 17, 2011, at 7:11 PM, Caldarale, Charles R wrote:
>> From: Nathan Potter [mailto:npotter@opendap.org]
>> Subject: Re: JspServlet - Unexpected behavior, possible bug...
>
>> I don't see how to do it without using a rewrite rule for
>> every thing in the top level collection of URL's.
>
> You only need to have the filter invoked when the true
> DefaultServlet would have been, so it would handle only otherwise
> unmatched requests.
> Use the <servlet-name> element rather than <url-pattern> inside the
> <filter-mapping>, specifying "default" as the value. Leave the
> hyrax servlet mapped to "/hyrax/*" (and possibly "/hyrax"), the
> DefaultServlet at "/", the JspServlet at "*.jsp", and have the
> filter adjust the path only if it's something you want hyrax to
> process.
So is the idea to identify to the filter: "These are the things for
the org.apache.catalina.servlets.DefaultServlet" and then send
everything else to Hyrax? Can it be configured like that?
>
> - Chuck
>
>
> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE
> PROPRIETARY MATERIAL and is thus for use only by the intended
> recipient. If you received this in error, please contact the sender
> and delete the e-mail and its attachments from all computers.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
= = =
Nathan Potter ndp at opendap.org
OPeNDAP, Inc. +1.541.231.3317
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: JspServlet - Unexpected behavior, possible bug...
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Nathan Potter [mailto:npotter@opendap.org]
> Subject: Re: JspServlet - Unexpected behavior, possible bug...
> I don't see how to do it without using a rewrite rule for
> every thing in the top level collection of URL's.
You only need to have the filter invoked when the true DefaultServlet would have been, so it would handle only otherwise unmatched requests. Use the <servlet-name> element rather than <url-pattern> inside the <filter-mapping>, specifying "default" as the value. Leave the hyrax servlet mapped to "/hyrax/*" (and possibly "/hyrax"), the DefaultServlet at "/", the JspServlet at "*.jsp", and have the filter adjust the path only if it's something you want hyrax to process.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: JspServlet - Unexpected behavior, possible bug...
Posted by Nathan Potter <np...@opendap.org>.
On Oct 17, 2011, at 5:38 PM, Caldarale, Charles R wrote:
>> From: Nathan Potter [mailto:npotter@opendap.org]
>> Subject: Re: JspServlet - Unexpected behavior, possible bug...
>
>> A new feature has been added to the web application that requires
>> JSP. But because an alternative default servlet is defined, this
>> disables the use of the JspServlet using the *.jsp url-pattern in
>> the servlet mapping.
>
> O.k., now I think I understand the problem: the servlet spec
> requires matching of "/*" before "*.jsp", so hyrax sees the JSP
> requests as well as the ones it should get. But rather than try
> remapping the JSP servlet, perhaps something like the
> UrlRewriteFilter (http://www.tuckey.org/urlrewrite/) might be more
> appropriate. You could set the mapping for hyrax to just "/hyrax/
> *" (removing "/*") and configure the filter to redirect or forward
> appropriate requests to the /hyrax path.
I don't see how to do it without using a rewrite rule for every thing
in the top level collection of URL's. I think if you try to rewrite
the root of the context that it's going to disable other services you
have running.
The problem is that you're rewriting "/context/" to "/context/hyrax"
so stuff that was being served from things other than the default
servlet (hyrax) such as "/docs" are going to get rewritten too. I
don't see how a rewrite rule can avoid that
For example - I have a servlet mapped to the url-pattern "/gateway/*",
and previously it's URL was http:/localhost:8080/contextName/gateway
if we rewrite /contextName/ -> /contextName/hyrax then the old gateway
url will be getting serviced here: http:/localhost:8080/contextName/
hyrax/gateway
Am I mistaken in this?
Nathan
> Everything else could remain unchanged.
>
> - Chuck
>
>
> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE
> PROPRIETARY MATERIAL and is thus for use only by the intended
> recipient. If you received this in error, please contact the sender
> and delete the e-mail and its attachments from all computers.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
= = =
Nathan Potter ndp at opendap.org
OPeNDAP, Inc. +1.541.231.3317
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: JspServlet - Unexpected behavior, possible bug...
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Nathan Potter [mailto:npotter@opendap.org]
> Subject: Re: JspServlet - Unexpected behavior, possible bug...
> A new feature has been added to the web application that requires
> JSP. But because an alternative default servlet is defined, this
> disables the use of the JspServlet using the *.jsp url-pattern in
> the servlet mapping.
O.k., now I think I understand the problem: the servlet spec requires matching of "/*" before "*.jsp", so hyrax sees the JSP requests as well as the ones it should get. But rather than try remapping the JSP servlet, perhaps something like the UrlRewriteFilter (http://www.tuckey.org/urlrewrite/) might be more appropriate. You could set the mapping for hyrax to just "/hyrax/*" (removing "/*") and configure the filter to redirect or forward appropriate requests to the /hyrax path. Everything else could remain unchanged.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: JspServlet - Unexpected behavior, possible bug...
Posted by Nathan Potter <np...@opendap.org>.
Chuck,
I may not NEED to do it. It's just what I figured out to do.
Historically, the servlet that I am working with has been the default
servlet. Tomcat's default servlet was used to serve docs from a
subdirectory of the context dir, and everything else was dynamically
generated by the default servlet. JSP was never used so no there was
no issue there.
A new feature has been added to the web application that requires JSP.
But because an alternative default servlet is defined, this disables
the use of the JspServlet using the *.jsp url-pattern in the servlet
mapping. (This may be caused by a failure to properly implement the
alternate default servlet?? I don't know how to tell.)
Attempting to change back to the Tomcat default servlet will cause a
change in the URL scheme of the web application, at least to the best
of my understanding (because our servlet would now be mapped to some /
name/* pattern). Our installed user base will not accept a new
version of product that requires all their URLs will to be different.
This is probably even true w.r.t. changing the context name, but
that's an installation decision not a mandate.
So all this brings me to say that the need is for my servlet to be the
default servlet and I need JSP to work.
What I thought to do was:
<servlet-mapping>
<servlet-name>hyrax</servlet-name>
<url-pattern>/*</url-pattern>
<url-pattern>/hyrax/*</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>jsp</servlet-name>
<url-pattern>/jsp/*</url-pattern>
<url-pattern>/admin/*</url-pattern>
<url-pattern>/error/*</url-pattern>
</servlet-mapping>
Which worked, but when accessing the URL:
http://localhost:8080/myContext/admin
I would get back a 500 error.
And:
http://localhost:8080/myContext/admin/
Would return the (index.jsp) welcome page.
Now, one might argue that the first URL should 404, or one might argue
that it should redirect to the 2nd URL. But I think it's a tough
argument to make that it should return a 500 error.
And I didn't see anywhere in the documentation that said you SHOULDN'T
use the JSP Servlet this way...
I wrote a work around by subclassing
org.apache.jasper.servlet.JspServlet and wrapping/overriding the
service() method with a check for the directory w/o the trailing slash
condition and returning a redirect when it happens and passing the
call down to super.service() when it doesn't. That works great, but I
figured the 500 error wasn't a desired behavior so I wrote in to the
list about it, as the documentation at Tomcat home indicated that all
bug reports should begin here.
N
On Oct 17, 2011, at 11:14 AM, Caldarale, Charles R wrote:
>> From: Nathan Potter [mailto:npotter@opendap.org]
>> Subject: JspServlet - Unexpected behavior, possible bug...
>
>> In my web application I need to utilize the JSP servlet, but
>> I need to use a different servlet mapping:
>> <servlet-mapping>
>> <servlet-name>jsp</servlet-name>
>> <url-pattern>/jsp/*</url-pattern>
>> </servlet-mapping>
>
> Before going any further, please explain why you think you need to
> do that. (I.e., what's the actual requirement?)
>
> - Chuck
>
>
> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE
> PROPRIETARY MATERIAL and is thus for use only by the intended
> recipient. If you received this in error, please contact the sender
> and delete the e-mail and its attachments from all computers.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
= = =
Nathan Potter ndp at opendap.org
OPeNDAP, Inc. +1.541.231.3317
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: JspServlet - Unexpected behavior, possible bug...
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Nathan Potter [mailto:npotter@opendap.org]
> Subject: JspServlet - Unexpected behavior, possible bug...
> In my web application I need to utilize the JSP servlet, but
> I need to use a different servlet mapping:
> <servlet-mapping>
> <servlet-name>jsp</servlet-name>
> <url-pattern>/jsp/*</url-pattern>
> </servlet-mapping>
Before going any further, please explain why you think you need to do that. (I.e., what's the actual requirement?)
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org