2

I am trying to migrate from velocity 1.7 where I use LogChute interface. In my current implementation I have used the log method to get the velocity log level and comparing our own log level. Please see the code below.

@Override
public void log(int level, String message) {
    LogLevel projLevel = null;
    switch ( level )
    {
       case LogChute.DEBUG_ID:
          projLevel = LogLevel.DEBUG ;
          break ;

       case LogChute.INFO_ID:
          projLevel = LogLevel.INFO ;
          break ;

       case LogChute.WARN_ID:
          projLevel = LogLevel.WARNING ;
          break ;

       case LogChute.ERROR_ID:
          projLevel = LogLevel.ERROR ;
          break ;

       default:
          projLevel = LogLevel.ERROR ;
          break ;
    }

    if (Log.canLog(projLevel, Const.VELOCITY_LOGGER))
    {
       Log.log(projLevel, Const.VELOCITY_LOGGER, getClass(), message,
          null);
    }

}

Based on apache velocity 2.0 documentation the LogChute is deprecated and the apache velocity is using SLF4J for logging. So, I tried to use SLF4j-API and SLF4J bindings as SLF4J Simple Logger and WebApp SLF4J Logger but unable to utilize the class as I need to compare the velocity log levels with our custom log levels. All these needs to happened during runtime.

For current velocity configuration, I am following the below configuration this is same as custom class which is invoked based on 1.7 velocity configuration as services.VelocityService.runtime.log.logsystem.class=our.package.xclassName.

Here's the link for documentation(https://velocity.apache.org/engine/1.7/developer-guide.html#configuring-logging)

These all are removed in 2.0 version.

Can someone help me on this. I am trying to upgrade the velocity.

  • If you could clairfy your question (2nd and 3rd paragraphs) and make it painfully obvious what the issue is, that would make it easier for us to help identify the problem and solve your problem :) – dwb Jan 11 '21 at 21:25
  • Hey @dantechguy, my problem is with the version upgrade of apache velocity, previously I have used the version of 1.7 in which the LogChute interface and I have implemented and written above code, with the help of this I am able to get the Velocity level logs. So, I am trying to use 2.0 velocity version this documentation mentioned to use SLF4J and bindings. So, I am trying to use Simple Logger but this class is a singleton and not able to extend and utilize this object. So, I need a similar code to run it. The third paragraph is configuration to fetch this class which is in 1.7 version – TechEnthusiastic Jan 11 '21 at 22:18

1 Answers1

0

Basically, you want to be able to dynamically set the log level. Maybe you should change your slf4j binding from slf4j-api to logback, see this question.

If you want to stick to slf4j-simple, maybe you can try giving Velocity a custom slf4j logger instance (not tested):

public class MyCustomLogger extends org.slf4j.SimpleLogger
{
    public MyCustomLogegr(String name) { super(name); }

    protected boolean isLevelEnabled(int logLevel)
    {
        LogLevel projLevel = null;
        switch ( level )
        {
           case LogChute.DEBUG_ID:
              projLevel = LogLevel.DEBUG ;
              break ;
           case LogChute.INFO_ID:
              projLevel = LogLevel.INFO ;
              break ;
           case LogChute.WARN_ID:
              projLevel = LogLevel.WARNING ;
              break ;
           case LogChute.ERROR_ID:
              projLevel = LogLevel.ERROR ;
              break ;
           default:
              projLevel = LogLevel.ERROR ;
              break ;
        }
        return Log.canLog(projLevel, Const.VELOCITY_LOGGER);
    }
}

Then, you must give this logger to Velocity:

VelocityEngine velocity = new VelocityEngine();
// ... other configurations
velocity.setProperty("runtime.log.instance", new MyCustomLogger());
velocity.initialize();
Claude Brisson
  • 4,085
  • 1
  • 22
  • 30
  • Thanks for the information.@Claude Brisson But the thing is org.slf4j.impl.SimpleLogger constructor is having no Modifier and the object is not accessible outside the slf4j-simple package. I have tried WebApp SLF4J Logger as well and this binding is also a singleton and the object is not accessible outside the package. – TechEnthusiastic Jan 13 '21 at 01:28
  • What about forking slf4j-simple or webapp-slf4j-logger to have public constructors? – Claude Brisson Jan 13 '21 at 15:52
  • I will check on that by contacting our team. I tried using SimpleLoggerFactory and get the instance of SimpleLogger but not able to get the method isLevelEnabled. – TechEnthusiastic Jan 13 '21 at 17:22
  • Anyhow, the overall philosophy of slf4j is to have static loggers. You should check with your team the pertinence of keeping such a runtime behavior. – Claude Brisson Jan 13 '21 at 17:43