DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9205>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9205

org.apache.velocity.util.StringUtils.chop(String s, int i, String eol) assumes too 
much about EOL string

           Summary: org.apache.velocity.util.StringUtils.chop(String s, int
                    i, String eol) assumes too much about EOL string
           Product: Velocity
           Version: 1.3-rc1
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: Major
          Priority: Other
         Component: Source
        AssignedTo: [EMAIL PROTECTED]
        ReportedBy: [EMAIL PROTECTED]


I'm running Velocity with Texen under WinXP/cygwin/SunJDK1.3.1_02-b02

When I try to generate my pages, I get the following exception:

org.apache.velocity.exception.MethodInvocationException: Invocation of 
method 'chop' in  class org.apache.velocity.util.StringUtils threw exception 
class java.lang.ArrayIndexOutOfBoundsException : null

I've traced this back to the source code and found out that the reason for 
this exception is most probably the fact that Velocity assumes that the 
templates it is working with are written with the same EOL combination that is 
the default for the platform that it is running on.

So, to give you an example, I have templates that have Unix-style linebreaks 
in them and I'm executing Velocity on Windows machine with those templates. 
This breaks the whole thing down.

Workaround? Convert your linebreaks or replace your chop method with this:
    public static String chop(String s, int i, String eol)
    {
        char[] sa = s.toCharArray();
        int length = sa.length;
        length -= i;
        return new String(sa, 0, length);
    }
This will of course break the system, if you have windows-style linebreaks.

So, maybe you can come up with some more elegant fix for this problem? :-)

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to