Velocity
  1. Velocity
  2. VELOCITY-719

Unwritable velocity.log appears to cause Velocity initialization to fail, leaving velocity dead and useless.

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 1.6.2
    • Fix Version/s: None
    • Component/s: Engine
    • Labels:
      None

      Description

      When we upgraded to 1.6.2 from 1.5.0, we began experiencing failures:

      Caused by: java.lang.NullPointerException
      at org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:1400)
      at org.apache.velocity.runtime.RuntimeSingleton.getTemplate(RuntimeSingleton.java:326)
      at org.apache.velocity.app.Velocity.mergeTemplate(Velocity.java:352)

      We eventually traced this back to Log4JChute attempting to create velocity.log in an unwritable $CWD.

      I realize you may or may not consider this a bug, as you may wish to have the system fail if it can't log. However, I couldn't even find any output indicating the initial failure to create velocity.log causing Velocity to fail to initialize.

      On a related note, is it possible to change the runtime.log default to BLANK so that velocity defaults to using a pre-existing log4j config if it exists?

      Although it's certainly an established tradition at this point, It seems a little backward to default to creating it's own log4j configuration - and a google search on velocity.log produces a very large number of people dealing with the problem of Velocity trying to create a velocity.log somewhere that doesn't work.

        Activity

        Hide
        Nathan Bubna added a comment -

        This exception is secondary. It looks to me like the log initialization threw an exception that prevented resourceManager initialization, which they gave you this NPE when you tried to access a resource. Do you have the exception/stack from the log's failure to initialize? I don't see any way for the resourceManager to be null (as your exception indicates), unless initializeLog() threw an exception and you swallowed it and continued on.

        We could consider changing the default value of runtime.log to blank in 2.0, but not before due to the need for backward compatibility. I'd also quibble that vast majority of those complaints about velocity.log are from pre-1.5 versions of Velocity. I've put extensive work into improving the log facilities in the last 4 years.

        Show
        Nathan Bubna added a comment - This exception is secondary. It looks to me like the log initialization threw an exception that prevented resourceManager initialization, which they gave you this NPE when you tried to access a resource. Do you have the exception/stack from the log's failure to initialize? I don't see any way for the resourceManager to be null (as your exception indicates), unless initializeLog() threw an exception and you swallowed it and continued on. We could consider changing the default value of runtime.log to blank in 2.0, but not before due to the need for backward compatibility. I'd also quibble that vast majority of those complaints about velocity.log are from pre-1.5 versions of Velocity. I've put extensive work into improving the log facilities in the last 4 years.

          People

          • Assignee:
            Unassigned
            Reporter:
            Cott Lang
          • Votes:
            1 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:

              Development