Velocity
  1. Velocity
  2. VELOCITY-527

Name of template truncated in error messages

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Invalid
    • Affects Version/s: 1.5
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None
    • Environment:
      Windows XP Pro SP2, JDK 1.5

      Description

      Following was posted to mailing list:

      On 3/9/07, Will Glass-Husain <wglasshusain@gmail.com> wrote:
      > Ouch. Always hate that first bug report after a new release!
      >
      > Would you mind please creating a JIRA issue at:
      > http://issues.apache.org/jira
      >
      > On 3/9/07, Michael Giroux <mlgiroux@gmail.com> wrote:
      > > I just upgraded to Velocity 1.5. A key feature for me is the new
      > > functionality to include filename, line and column in error messages.
      > > When I was testing this feature with a faulty template, I discovered
      > > that the filename is being truncated. In the error message below, the
      > > actual file name should be "business-service-interface.vm" It appears
      > > the parser truncated at the first "-".
      > >
      > >
      > > java.lang.Exception: Encountered "#else" at line 51, column 33 of business
      > > Was expecting one of: ...
      > >
      > >
      > > Michael:
      > >
      > > ---------------------------------------------------------------------
      > > To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
      > > For additional commands, e-mail: user-help@velocity.apache.org
      > >
      > >
      >
      >
      > –
      > Forio Business Simulations
      >
      > Will Glass-Husain
      > wglass@forio.com
      > www.forio.com
      >
      > ---------------------------------------------------------------------
      > To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
      > For additional commands, e-mail: user-help@velocity.apache.org
      >
      >

        Activity

        Hide
        Claude Brisson added a comment -

        Velocity 1.5 should now use a org.apache.velocity.exception.ParseErrorException instead of the generic java.lang.Exception.

        Are you sure there isn't some old velocity.jar hidden somewhere in a shared classpath entry?

        If it's really Velocity 1.5, could you please attach the full stacktrace ?

        Show
        Claude Brisson added a comment - Velocity 1.5 should now use a org.apache.velocity.exception.ParseErrorException instead of the generic java.lang.Exception. Are you sure there isn't some old velocity.jar hidden somewhere in a shared classpath entry? If it's really Velocity 1.5, could you please attach the full stacktrace ?
        Hide
        Michael Giroux added a comment -

        When you fix this, would you please add the current physical file location to the error message?
        I'm using velocity 1.5 and getting error messages that give line numbers that are incorrect. For example, I'm getting an error that I have a #foreach at line 40 and something else is expected. Unfortunately, I do not have one vm file with a #foreach at line 40, so the line number is wrong. if I had the file offset, I could at least use a hex editor or other tool to position to that location to figure out wher ethe error really is.

        In my specific case, the column numbe reported is 30, and as far as I can tell, the #foreach with the greatest indentation is at column 16, so it seems the error message column # is being influenced by whitespace processing as well.

        Show
        Michael Giroux added a comment - When you fix this, would you please add the current physical file location to the error message? I'm using velocity 1.5 and getting error messages that give line numbers that are incorrect. For example, I'm getting an error that I have a #foreach at line 40 and something else is expected. Unfortunately, I do not have one vm file with a #foreach at line 40, so the line number is wrong. if I had the file offset, I could at least use a hex editor or other tool to position to that location to figure out wher ethe error really is. In my specific case, the column numbe reported is 30, and as far as I can tell, the #foreach with the greatest indentation is at column 16, so it seems the error message column # is being influenced by whitespace processing as well.
        Hide
        Michael Giroux added a comment -

        OK, first let me say I'm sorry about the last remark. The issue here is that the error message suggested (to me) that the file name was 'business' something. In fact, the file name was actually session-facade.vm so this JIRA is not just about file name truncation, but having the wrong file name all together.

        Next, I added the comment before I did a refresh so I did not see the post by Claude. I'll do better next time.

        Finally, as I was collecting the full trace for Claude, I discovered that the code (that would be code I inherited, but no excuses, it's my code) is catching the exception and rethrowing a java.lang.Exception. I'll correct my code to display the original stack trace and post it soon.

        Show
        Michael Giroux added a comment - OK, first let me say I'm sorry about the last remark. The issue here is that the error message suggested (to me) that the file name was 'business' something. In fact, the file name was actually session-facade.vm so this JIRA is not just about file name truncation, but having the wrong file name all together. Next, I added the comment before I did a refresh so I did not see the post by Claude. I'll do better next time. Finally, as I was collecting the full trace for Claude, I discovered that the code (that would be code I inherited, but no excuses, it's my code) is catching the exception and rethrowing a java.lang.Exception. I'll correct my code to display the original stack trace and post it soon.
        Hide
        Michael Giroux added a comment -

        I modified my code to include the original ParseErrorException as cause. The actual exception is shown here.

        In this case, the actual file name is 'session-facade-object.vm' so for purposes of this JIRA, we still have an issue.

        In addition, the column number reported as 17 is not exactly correct. The #set line has two leading TAB characters, so I'm not sure if this should be column 2 or 8, but certainly not 17. Given whitespace issues, and use of TAB characters, it might not be possible to get column correct in any circumstance.

        Caused by: org.apache.velocity.exception.ParseErrorException: Encountered "#set" at line 273, column 17 of business
        Was expecting one of:
        "[" ...
        "{" ...
        <STRING_LITERAL> ...
        "true" ...
        "false" ...
        <INTEGER_LITERAL> ...
        <FLOATING_POINT_LITERAL> ...
        <IDENTIFIER> ...
        "{" ...

        at org.apache.velocity.app.VelocityEngine.evaluate(VelocityEngine.java:311)
        at com.bull.eclipse.businesslayer.core.FileProducer.generate(FileProducer.java:649)
        ... 51 more

        Show
        Michael Giroux added a comment - I modified my code to include the original ParseErrorException as cause. The actual exception is shown here. In this case, the actual file name is 'session-facade-object.vm' so for purposes of this JIRA, we still have an issue. In addition, the column number reported as 17 is not exactly correct. The #set line has two leading TAB characters, so I'm not sure if this should be column 2 or 8, but certainly not 17. Given whitespace issues, and use of TAB characters, it might not be possible to get column correct in any circumstance. Caused by: org.apache.velocity.exception.ParseErrorException: Encountered "#set" at line 273, column 17 of business Was expecting one of: "[" ... "{" ... <STRING_LITERAL> ... "true" ... "false" ... <INTEGER_LITERAL> ... <FLOATING_POINT_LITERAL> ... <IDENTIFIER> ... "{" ... at org.apache.velocity.app.VelocityEngine.evaluate(VelocityEngine.java:311) at com.bull.eclipse.businesslayer.core.FileProducer.generate(FileProducer.java:649) ... 51 more
        Hide
        Nathan Bubna added a comment -

        If you are using VelocityEngine.evaluate(...), then you should look at FileProducer.java line 649 to start to trace the source of the wrong file name. the evaluate() methods have nothing to do with Files. they only take Strings, InputStreams or Readers. I believe the "logTag" parameter is what is being treated as the file name.

        This may also have something to do with the column and line numbers being off...

        Show
        Nathan Bubna added a comment - If you are using VelocityEngine.evaluate(...), then you should look at FileProducer.java line 649 to start to trace the source of the wrong file name. the evaluate() methods have nothing to do with Files. they only take Strings, InputStreams or Readers. I believe the "logTag" parameter is what is being treated as the file name. This may also have something to do with the column and line numbers being off...
        Hide
        Michael Giroux added a comment -

        Good catch. I see in the code that the all calls to evaluate pass "business". I'll fix that to be the actual file name.

        Thanks for all the quick response. It appears this may be a non-bug.

        Show
        Michael Giroux added a comment - Good catch. I see in the code that the all calls to evaluate pass "business". I'll fix that to be the actual file name. Thanks for all the quick response. It appears this may be a non-bug.
        Hide
        Nathan Bubna added a comment -

        cool. find out anything more about the line & column numbers? i'm not really familiar with the parser code, but it seems to me that those numbers ought to still work when parsing from a String, InputStream, or Reader. can you tell if there are any alterations to the template content between the file you're looking at in your system and the String/InputStream/Reader that is passed to evaluate()?

        Show
        Nathan Bubna added a comment - cool. find out anything more about the line & column numbers? i'm not really familiar with the parser code, but it seems to me that those numbers ought to still work when parsing from a String, InputStream, or Reader. can you tell if there are any alterations to the template content between the file you're looking at in your system and the String/InputStream/Reader that is passed to evaluate()?
        Hide
        Michael Giroux added a comment -

        Retested after changing my code to pass a file name to evaluate() and sure enough, the full file name is now displayed in the ParseErrorException.

        Thanks for all the help. Glad this wasn't a bug.

        Show
        Michael Giroux added a comment - Retested after changing my code to pass a file name to evaluate() and sure enough, the full file name is now displayed in the ParseErrorException. Thanks for all the help. Glad this wasn't a bug.
        Hide
        Will Glass-Husain added a comment -

        You might consider using the FileResourceLoader (or one of the other resource loaders) instead of Velocity.evaluate(). There's a huge performance benefit due to the use of caching. (assuming you are repeatedly evaluating the files).

        Show
        Will Glass-Husain added a comment - You might consider using the FileResourceLoader (or one of the other resource loaders) instead of Velocity.evaluate(). There's a huge performance benefit due to the use of caching. (assuming you are repeatedly evaluating the files).
        Hide
        Nathan Bubna added a comment -

        Resolving this as not a bug for now. If we turn out to actually have issues with incorrect line/column numbers, we can re-open and re-name this one or open a new issue.

        Show
        Nathan Bubna added a comment - Resolving this as not a bug for now. If we turn out to actually have issues with incorrect line/column numbers, we can re-open and re-name this one or open a new issue.

          People

          • Assignee:
            Unassigned
            Reporter:
            Michael Giroux
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development