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

        Cott Lang created issue -
        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.
        Mark Thomas made changes -
        Field Original Value New Value
        Workflow jira [ 12463979 ] Default workflow, editable Closed status [ 12551627 ]
        Mark Thomas made changes -
        Workflow Default workflow, editable Closed status [ 12551627 ] jira [ 12552246 ]
        Georg Kallidis made changes -
        Comment [ may be this is related. The definition in TR.properties of the velocity log is

        services.VelocityService.runtime.log=/log/velocity.log

        If using as VelocityService the default class org.apache.turbine.services.velocity.TurbineVelocityService

        you find in the method createVelocityProperties(..) (which is called when initializing) a condition:

        if (!key.endsWith(RESOURCE_LOADER_PATH) {... continue }

        and only after pathes are resolved relative to the web-app.

        If you consider this, then e.g defining runtime.log as above you end up (in may case) with a log in C:/log/velocity.log.

        ]

          People

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

            Dates

            • Created:
              Updated:

              Development