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]

Reply via email to