Hi Thomas, commons-logging is used in many Turbine classes, but - in conf/test commons-logging.properties has been removed, may be before 2008? - Turbine initialization is done with log4j as default
To be consistent again I would suggest, that in pom.xml the test resource should be replaced with the existing Log4j.properties. Secondly the jcl dependency should be removed/excluded, as commons logging calls are now delegated to jcl-over-slf4j. I think, we should for now just reflect this consistently. To support different logging frameworks (logback, log4j, other frameworks), this should be done may be in a fulcrum-log component? Best regards, Georg Von: Thomas Vandahl <[email protected]> An: Turbine Developers List <[email protected]> Datum: 22.03.2015 12:41 Betreff: Re: Concerning Releases / Settings Hi Georg, On 19.03.15 20:09, Georg Kallidis wrote: > Hi list, > > concerning upcoming releases of Turbine: > > - Turbine parent release should be either done without voting or not - we still have not concluded IMO or have we? I think, it should be released this year to enable up-to-date releases (including current reference to Apache parent pom, ..). I thought I proposed a lazy consensus vote and nobody objected. > > - The next Turbine RC is waiting for Torque 4.1 (which is not yet released), right? It should have the scheduler removed or replaced. What are the other goals for this release or the release after this? May be, we should make a clear cut and explicitely support only Java 8? If we decide to do so, the same should be true for the Fulcrum components to be consistent. Should we do it by allowing 1.x releases (Java 5) and 2.x (Java 8)? And Http/2-support is coming (in browsers is and in Java 9).. I started to do some work on the scheduler. It's supposed to use fulcrum-quartz when it's ready but I face some backward compatibility issues (ScheduledJob is a module) > - Logging: Turbine Trunk had log4j as logging framework and has currently slf4j with default log4j, cft.http://www.slf4j.org/legacy.html. This should conform with Avalog default logging behaviour. May be logback would be even better instead of log4j (same for the Fulcrum components)? But log4j 2.x would be an alternative, too. I am happy with each one of them. Which way we should go? My view: As Fulcrum components are Avalon services by (current) definition, they should use Avalon logging only. All components I touched have been modified to use Avalon logging if at all possible and unless some dependency pulls in log4j or similar. Turbine is supposed to use commons-logging for the time being. I'm completely aware that the manual initialization of log4j in the Turbine class contradicts with this statement and my suggestion would be to get rid of that special handling. If logging in a certain environment were an issue, it would be no big deal to create a simple logging stub on our own that can be attached to different logging backends. Many frameworks do this. Bye, Thomas. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
