Logging in Xith3D

Engines, Libraries and Tools Xith3D Forums
#1

I propose we move to the apache commons logging API.

This is a lightweight logging abstraction layer which allows the developer to chose to what logging API the calls are passed. It can work with log4j, and automatically configures itself to use whatever logging API is present in the classpath.

More info: http://jakarta.apache.org/commons/logging/
Code Example

Soon I will move the Odejava project onto this API to remove the log4j dependancy. Xith3D doesn’t have a log4j dependancy, but it would be better if it used this interface so that the developer’s could more easily integrate Xith3D log statements into their own logging system.

Cheers,

Will.

#2

Hi,

Does it make sense to improve abstraction layer inside Xith3D such a way to be configurable which implementation of logging to use? In production build I do not need any logging, so I’d like to detach logging from my app at all.

Yuri

#3

Yes. Many people will not only want but need logging in a production API - the main logging API’s (log4j and java-logging) were both specifically designed NOT to be removed from production builds.

However, it might be worth guarding EVERY single logging call in xith with a boolean if test, as discussed in the performance sections (IIRC it was Mark Thornton who reported success using this to dynamically compile-out logging at runtime - personally, I’ve been using it for years to be able in extremis to make builds which compile-out logging, e.g. when I don’t trust the logging API :slight_smile:

OTOH, if you’re not stupid, then the logging API’s really are very fast.

#4

PS having recently (ish) integrated a 3rd party java library that used a “foreign” logging system, but where you could instantiate a vendor-supplied Log4JLogger at startup which caused it to insert it’s logging statements directly into the main log4j logging tree, I can attest that self-integrating 3rd party API’s are fscking fantastic :).

In that case, I believe they had separate micro wrappers for the different API’s; I’m not sure why they werne’t using jakarta commons (IIRC, vaguely, because of some problems they’d had trying to use it? or maybe just their dev preceded it - I don’t know what, but do have enough evidence from the other apache java projects to cause me to distrust it too, until proven robust/reliable/complete).

#5

Perhaps we should have a DEBUG constant like blar*3 suggests so that all of the debugging calls can be trashed at compile time if desired (then the logging commons .jar wouldn’t even be needed at runtime).

My suggestion is not really to add a lot more log statements, but more move the current ones onto a system where the developer can easily get the messages into their system. I would however convert all current System.out calls. Since Xith3D is middlewhere, I think that the ability to send Xith3D log messages into the developer’s logging setup would be a good feature. Jakarta-Commons Logging seems like a very professional package which can achieve this.

Blar*3, it certainly does sound a lot similar to the jakarta commons logging, and I’d be surprised if he couldn’t configure it, it is as simple as having log4j in your class path and it automatically configures itself!

Will.

#6

Is anyone vetoing this proposal?

As it stands, I am planning to convert all exisiting log and System.out statements in Xith3D to use the Jakarta commons logging system which allows developers to chose what log API is used (if any). I believe this is a superior approach to that currently used and will improve Xith3D.

I will also wrap all statements inside statements such as:

if (ExampleClass.DEBUG) {
log.debug(“example message”);
}

So they can be compiled out if desired (currently this isn’t possible).

Unless there are any objections, I will start work on this in a day or two.

Cheers,

Will.

#7

+1 but make it so, that not so experienced programmers (like me) don’t have to bother about it.

#8

that is exactly how it will be :slight_smile:

Cheers,

Will.

#9

Why not just use java.util.Logger ? I had no problems in my previous projects with it.

#10

[quote]Why not just use java.util.Logger ? I had no problems in my previous projects with it.
[/quote]
Because:

  • it’s badly designed
  • it’s missing core features
  • most people don’t use it (mainly because it’s incompatible with the existing systems they used for years before Sun got around to badly cloning the existing systems)
  • it has NO ability at all to plugin other logging systems

The last two points tend to be key, especially when you’re writing middleware, where you don’t want to say to everyone who uses your software “yes, you have a perfectly good logging system but if you want to use my stuff you have to rewriter every single one of your classfiles”.

This tends to lead to middleware software getting a bad reception and not being used by many people :slight_smile:

#11

just a quick request:
can anyone please change a line in CanvasPeerImpl?
274: ps = new PrintStream(new FileOutputStream(new File(“c:/opengl.log”)), true);

reason: there is no “c:/” on unix based systems … i guess it would be ok to change this to new File(“opengl.log”) … this would place the log file into the working directory … or to create a public static string containing the location

-> Flo