LoggingSystem or exchange logging facility on deploy time

Hello everyone!



After a quick search the forums for “logging”, I only found some topics regarding turning logging off. Seems that not many people bother using logging or are happy with the integrated logging system shipping with the JRE. Me is not.  :frowning:



It’d be cool, if jME would either allow overriding the logging facility used by some fancy encapsulation (like done with the dependency to LWJGL) or use an implementation neutral facility like SLF4J. The latter case would only add a small bunch of classes to the library dependencies, but enable the user of jME to choose the logging system he’s happier with. The point is, I’d like to configure logging only in one place/file and the more engines/tools “listen” to my single (level/file output) configuration … well, that’s good.  :slight_smile:



Cheers,

Sor



PS1: More reasons using SLF4J see SLF4J FAQ

PS2: Yes, I volunteer in providing a patch against current CVS HEAD … :wink:

Personally I believe using Java logging is much better because it doesn't create additional dependencies.  Further, if you want to use SLF4J you can connect it to the Java logging system, there's no reason why you can't do that.

Actually, I do like the idea of an abstracted logging system. Frankly, our logging system sucks as it is now. If you can put together a bit more of your design and present it, I'd like to hear it.

Is there anything the built-in logging system can't do that you want it to?



I've done some very powerful logging using the Java logging system and apart from nifty features I find it fully capable.  Logging systems that are more featureful like log4j can be plugged into the built-in logging to accomplish more complicated feats as well.



I guess my question is, what specifically do we gain with a new logging system?

I'd agree with darkfrog - throwing away the current LoggingSystem and replace it with jdk stuff would be really fine.

My comment was more about our usage of logging sucks currently more than anything else. So, yes, this wouldn't really help in that regard. However, I've had a number of people request support for log4j, if the one built into the jdk allows for you to plug these others in, then all the better.

The apache commons logging stuff is nice, it's just an abstraction layer, the actuall logging is handled underneath. By default it uses the java logging logging framework, if log4j is in the cp then it uses that. I use it all the time.



Just to throw something else in there :slight_smile:



Endolf

I mainly use log4j, and have apache commons logging included because I use sometimes other apache libs. It's interesting that some apache projects are using SLF4J, I'm going to check that out. Thanks for the link :slight_smile:

i agree to mojo that the current use of logging in jme is poor. i like log4j, but i'm not sure how the apache license affects its usage with jme. also i'm not sure about how SLF4J affects logging performance.  :?

It's late here, so short answer only, I'll go into detail tomorrow and present a detailed idea/scatch, how to port the 394 references in current CVS HEAD.



SLF4J is "the" successor of JCL and Logback "replaces" LOG4J. IIRC, all 4 projects are related (founded by?) Ceki G

JGN uses the java.util.logging system and I've got various other projects that use java.util.logging as well.  I have yet to see anything that I couldn't do with it (granted sometimes it takes writing some code yourself to make it happen).  Also, most other logging systems have the ability to work with java.util.logging now as well.  Further, it keeps us from adding yet another dependency to jME.



I wouldn't necessarily be opposed to having a factory in jME that defaults to java.util.logging and can be swapped out by other developers when they want to use something else?  Yes, I know this can be done with SLF4J, but what I'm talking about is a single factory class added and an interface that it returns with a default implementation pointing to java.util.logging.  Then you could use SLF4J, java.util.logging, log4j, or Bob's Logging Utility, it doesn't matter.

Just another voice chiming in here to say that when writing your suggestion up, please remember we can not include any other project explicitly unless it is also BSD.  If you want to use an Apache product, for example, we should write up a logging interface that would allow you to plug in apache's logger without us actually needing it to compile, etc.

Hello again!


renanse said:
... please remember we can not include any other project explicitly unless it is also BSD.


Will this do? BSD is not mentioned explicitley, but its included in the comment: "It is deemed compatible with virtually all types of licenses, commercial or otherwise." Copied from here: http://slf4j.org/license.html
From the license point-of-view, it's not related to Apache/Jakarta in any way.

darkfrog said:

I wouldn't necessarily be opposed to having a factory in jME that defaults to java.util.logging and can be swapped out by other developers when they want to use something else?  Yes, I know this can be done with SLF4J, but what I'm talking about is a single factory class added and an interface that it returns with a default implementation pointing to java.util.logging.  Then you could use SLF4J, java.util.logging, log4j, or Bob's Logging Utility, it doesn't matter.


Yeah, that's what I meant with: "allow overriding the logging facility used by some fancy encapsulation (like done with the dependency to LWJGL)" in my initial post. That'd be cool. Half way, but cool.

I do understand if you're not content with adding another (LWJGL is number one, JOGG/Vorbis next, JInput another one) dependency to jME. The user of this engine already has to satisfy LWJGL class- and library path needs, in default mode. I'm truly a coder, who likes the idea, that all projects would only refer to JRE foundation classes, but there's not only gold in there. And because only something is shipped with the JRE, its not always the best solution for your tasks. E.g. AWT/Swing vs. SWT, various concurrency libs, javax-OpenGL bindings vs. LWJGL... only to enumerate some.

So why re-invent the wheel, when others already spent hours in balancing the wheel? Or on topic, why introduce and maintain an own interface/factory pair, if SLF4J does just this (and more) for you? If you're used to the logging APIs provided JCL or Log4j, you're instantly familiar with the SLF4J interface(s). Used to JUL logging? No problem, it's still water they're cooking with. :wink:

If the devteam opts for SLF4J, I'd propose these steps:

Step 1: Don't break existing code and let others see the upcoming change
Make the LoggingSystem class a single point of logging for all com.jme.* and com.jmex.* and all examples/tests. I'd deprecate the "jul.Logger getLogger()" method and replace it by 4 methods, namely "debug(...)", "info(...)", "warn(...)" and "error(...)". All references to the old "getLogger()" method will be replaced by a call to one of the four. Why not FATAL and TRACE? See http://slf4j.org/faq.html#fatal

The LoggingSystem class will the in turn drop the dependecy to JUL and delegate to a SLF4J Logger named: "jme"

Add the slf4j-api-1.3.0.jar and the default implementation using JUL logging slf4j-jdk14-1.3.0.jar into the lib/ folder and classpath.

Step 2: Break existing code and let others adopt to the change made
Replace deprecated "jul.Logger getLogger()" in LoggingSystem by "org.slf4j.Logger getLogger()".

Step 3: Obtain "jme" logger
Replace method calls introduced in step 1 (LoggingSystem.debug/info/warn/error) by LoggingSystem.getLogger().debug/info/warn/error(...) if the single "jme" Logger okay.

Step 4: Fainer grained way to obtain loggers
Replace, where wanted, the calls to LoggingSystem.getLogger() from step 3 by a class/instance logger named like the class it's used in, e.g. "com.jme.scene.Node":

(static) final org.slf4j.Logger logger = org.slf4j.LoggerFactory.getLogger(Node.class);


Now, we arrived here: http://slf4j.org/manual.html

What do you think?
Sor

Little footnote to the LWJGL devteam (Matzon, princec, elias, spasi et al) reading here: SLF4J and LWJGL? :wink:



Sor

I'm using SLF4J in my project!  I give switching to that in JME a big



+1



vote, for all that it counts for.  I found it because I'm using Apache MINA, which also uses SLF4J.

I'm sorry to have missed these replies!  I like the proposed steps.  What do the other devs think?

I still think the java.util.Logging system is the right way to go and the users can connect other systems to it if they want to use something like SLF4J or Log4J.

darkfrog said:

I still think the java.util.Logging system is the right way to go and the users can connect other systems to it if they want to use something like SLF4J or Log4J.


Darkfrog, please enlight and show me how. A little hint would do. Here http://java.sun.com/javase/6/docs/technotes/guides/logging/index.html I couldn't find an answer. I'd be glad, if I could redirect all JUL logging to SLF4J.

Cheers,
Sor

Take a look at:

http://java.sun.com/javase/6/docs/api/java/util/logging/Handler.html



On a Logger you can invoke addHandler and pass your own custom implementation that makes calls to whatever logging system you want.  However, I believe that Log4J and SLF4J already provide a custom handler you can just pass to it and use.

Ouch - gonna be mighty inefficient.



Suggest a threaded caching mechansim that uses batches