Yes Steve, you are right, this is not a complete solution, but it is simple,
and will reduce the pain at least for a while. In the example that you gave,
the new encoding will save about 50 chars (four for each '/') so you can add
6 or 7 Very's to the path. This is a low risk patch can be squeezed to the
next maintenance release of 3.X.X.

A more general solution will require getting deeper into the code. For
example, the server could save the jsp classes in a directory tree that
matches the jsp path. This way, the limit will not be on the overall path
length but only the length of a single item in the path.

Tal

> -----Original Message-----
> From: Steve Downey [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, January 18, 2001 12:33 PM
> To: '[EMAIL PROTECTED]'
> Subject: RE: Patch for bug 330
>
>
> I suspect that this won't fix the underlying problem. The class name
> includes the path and makes it too easy to overflow the filename
> limit. For
> example:
>
> /jsp/snp/a/very/very/very/very/very/very/deeply/nested/snoop.jsp
>
> will not compile, while
>
> /jsp/snp/a/very/very/very/very/very/deeply/nested/snoop.jsp
>
> (with one less very) will.
>
> The one that works gets translated in the current scheme (On NT 2000, jdk
> 1.3, Tomcat standalone) to
> _0002fjsp_0002fsnp_0002fa_0002fvery_0002fvery_0002fvery_0002fvery_
> 0002fvery_
> 0002fdeeply_0002fnested_0002fsnoop_0002ejspsnoop.class
> in the tomcat\work\localhost_8080%2Fexamples directory.
>
> Compacting the mangling will allow a few more 'verys' to be
> translated, but
> it is still broken.
>
>
>
> -----Original Message-----
> From: Tal Dayan [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, January 18, 2001 3:06 PM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: Patch for bug 330
>
>
> Hi Costin,
>
> Here is our patch for bug 330,  Priority: high, Severity
> serious.(http://znutar.cortexity.com/BugRatViewer/ShowReport/330).
>
> Having this patch included the official release of 3.X.X will make Tomcat
> usable for us since we could not port our application from WebSphere to
> Tomcat 3.2.1 because of this problem.
>
> To apply the patch, all you need to do is to replace the method
> mangleChar()
> in JspCompiler.java with the new code that is included at the end of this
> message.
>
> BTW, the file CommandLineCompiler also has a similar mangleChar()
> method. I
> am not sure when this is used but you may want to consolidate the two.
>
> The new encoding has two forms, a short one and a general one.
> The short one
> is used for few common chars such as '_' and '/' and '/'. This
> encoding maps
> into a two char string of the form '_' <l> where <l> is a non hex
> char (g-z)
> (e.g. '_' --> '__', '.' --> '_p' etc). It is a more compact, 'readable'
> (e.g. the 'p' in '.'-->'_p' stands for 'period') and is more
> efficient since
> it does not create any object.
>
> The general form is used for the rest of the chars, including
> Unicode's. It
> is of variable length and for most of the common chars (e.g.
> ASCII) it will
> result in a shorter encoding than the one currently used. This
> encoding uses
> the form '_' <hex-rep> 'x' where <hex_rep> is a variable length hex
> representation of the numeric value of the char (e.g. "_f4x", "_123ax").
>
> Please review the patch and 'squeeze' it to the next maintenance
> release of
> 3.X.X.
>
> Thanks,
>
> Tal
>
>
>
> -------- new code ------
>
>     /*
>      * Encode special chars using a representation that contains only
>      * simple chars that can be used in class names (digits, letters,
>      * and '_').
>      */
>     private static final String mangleChar(char ch) {
>
>         if(ch == File.separatorChar) {
>           ch = '/';
>         }
>
>         /*
>          * Use a compact and more readable encoding for few common chars.
>          *
>          * Note: the char we append after the '_' should not be hex digit
>          * to avoid ambiguity with the general encoding we perform for the
> rest of
>          * the chars.
>          */
>         if (ch == '_')
>         {
>           return "__";  // underscore
>         }
>
>         if (ch == '-')
>         {
>           return "_m";  // minus
>         }
>
>         if (ch == '.')
>         {
>           return "_p";  // period
>         }
>
>         if (ch == '/')
>         {
>           return "_s";  // seperator
>         }
>
>         /*
>          * Encode the general case. We encode the char as follows
>          *
>          * '_' <hex-rep> 'x'
>          *
>          * Where h is <hex-rep> is a variable length Hexadecimal
>          * represnetation of the numeric value
>          * of the char as returned by IntegertoHexString().
>          */
>         return "_" + Integer.toHexString(ch) + "x";
>     }
>
> -------- old code
>
>     private static final String mangleChar(char ch) {
>
>         if(ch == File.separatorChar) {
>           ch = '/';
>       }
>       String s = Integer.toHexString(ch);
>       int nzeros = 5 - s.length();
>       char[] result = new char[6];
>       result[0] = '_';
>       for (int i = 1; i <= nzeros; i++)
>           result[i] = '0';
>       for (int i = nzeros+1, j = 0; i < 6; i++, j++)
>           result[i] = s.charAt(j);
>       return new String(result);
>     }
>
>
> > -----Original Message-----
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> > Sent: Tuesday, January 16, 2001 11:40 AM
> > To: [EMAIL PROTECTED]
> > Subject: Re: Proposed name encoding patch
> >
> >
> > It's worth to mention that both JSP encoding and work dir encoding are
> > resolved/improved in 3.3 - and the code can be easily ported back /
> > reused.
> >
> > I'll take a look at both patches and try to integrate them into
> 3.3 also (
> > what is not covered already )
> >
> > --
> > Costin
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, email: [EMAIL PROTECTED]
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
> <><><><><><><><><><><><><><><><><><><><><>This electronic mail
> transmission
> may contain confidential information and is intended only for the
> person(s)
> named.  Any use, copying or disclosure by any other person is strictly
> prohibited.  If you have received this transmission in error,
> please notify
> the sender via e-mail. <><><><><><><><><><><><><><><><><><><><><>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to