Re: Tomcat 5.5 caseSensitive=false and work dir problem

[Jesse Klaasse <je...@indicia.nl>]

I have implemented the "all lowercase" filter solution, which does the job
nicely. However, there is still one issue.. <jsp:forward>s don't go through
the filter chain, so when the forward page contains uppercase characters, a
file is created in the work dir with the uppercase character(s) in it. Then,
when a normal request via the browser is done to the same forward page,
Tomcat throws a NoClassDefFound exception because of a "wrong name" of the
temp file.

As an example, we have two jsp's:
- pageA.jsp (with a jsp:forward to pageB.jsp)
- pageB.jsp

Now, when we do this:
- request pageA.jsp in the browser (two temp files are created in the work
dir, pagea_jsp.class (lowercase 'a' because of the filter) and
pageB_jsp.class)
- request pageB.jsp in the browser -> NoClassDefFound exception because
Tomcat is looking for pageb_jsp.class

I think Leon's suggested mapper solution would solve this problem for the
most part, but a mapper which is actually a complete file system tree seems
rather disk/cpu intensive to me. 

Can anyone think of another solution for the <jsp:forward> problem in this
case?


Leon Rosenberg-3 wrote:
> 
> On Mon, May 26, 2008 at 3:59 PM, Jesse Klaasse <Je...@indicia.nl>
> wrote:
>>
>> Only thing I can think of now is to write a servlet filter which
>> converts all request URLs to lowercase.. But I am kind of hoping for a
>> more elegant solution.
> 
> Personally I find your solution elegant :-)
> It would be maybe even more 'elegant' if you map your lowercase url
> via some mapping to the real name of the jsp internally, like:
> 
> request EcHoSesSion -> Filter = echosession -> Mapper = EchoSession.jsp
> Of course the mapper has to be configured (or browse the file system)
> to determine the jsps real name. Alternatively you could rename all
> your jsps to lowercase and forget about the mapper. The advantage of
> the mapper (or the internal case-sensitivity) is that you webapp
> remains working on non-windows platforms... just in case, remember:
> write once, run anywhere :-)
> 
-- 
View this message in context: http://www.nabble.com/Tomcat-5.5-caseSensitive%3Dfalse-and-work-dir-problem-tp17472465p17816552.html
Sent from the Tomcat - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

Re: Tomcat 5.5 caseSensitive=false and work dir problem

[Christopher Schultz <ch...@christopherschultz.net>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jesse,

Jesse Klaasse wrote:
| I have implemented the "all lowercase" filter solution, which does the job
| nicely. However, there is still one issue.. <jsp:forward>s don't go
through
| the filter chain, so when the forward page contains uppercase
characters, a
| file is created in the work dir with the uppercase character(s) in it.

They do go through the filter chain if you configure them properly.

Section 6.2.5 of the servlet specification states:

"
SRV.6.2.5 Filters and the RequestDispatcher

New since version 2.4 of the Java Servlet specification is the ability
to configure filters to be invoked under request dispatcher forward()
and include() calls. By using the new <dispatcher> element in the
deployment descriptor, the developer can indicate for a filter-mapping
whether he would like the filter to be applied to requests when:

1. The request comes directly from the client. This is indicated by a
<dispatcher> element with value REQUEST, or by the absence of any
<dispatcher> elements.

2. The request is being processed under a request dispatcher
representing the Web component matching the <url-pattern> or
<servlet-name> using a forward() call. This is indicated by a
<dispatcher> element with value FORWARD.

3. The request is being processed under a request dispatcher
representing the Web component matching the <url-pattern> or
<servlet-name> using an include() call. This is indicated by a
<dispatcher> element with value INCLUDE.

4. The request is being processed with the error page mechanism
specified in “Error Handling” on page 69 to an error resource matching
the <url-pattern>. This is indicated by a <dispatcher> element with the
value ERROR.

5. Or any combination of 1, 2, 3, or 4 above.
"

Note that <dispatcher> elements are children of the <filter-mapping>
element, and you can specify multiple dispatchers like this:

<filter-mapping>
~  <filter-name>myFilter</filter-name>
~  <url-pattern>/*</url-pattern>
~  <dispatcher>REQUEST</dispatcher>
~  <dispatcher>INCLUDE</dispatcher>
~  <dispatcher>FORWARD</dispatcher>
</filter-mapping>

Hope that helps,
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkhSlC4ACgkQ9CaO5/Lv0PBMGwCdFUIF4WUDMCcFmmLR3+cD9Dtw
UX4AnA+t2sSNxXZKRl/ALtK+eM1Q0Fd3
=YbQX
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org