Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (477)
Games in Android Showcase (107)
games submitted by our members
Games in WIP (535)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Logging in Xith3D  (Read 1868 times)
0 Members and 1 Guest are viewing this topic.
Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Posted 2005-04-05 02:39:55 »

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.


Offline Yuri Vl. Gushchin

Senior Member




Speak Java!


« Reply #1 - Posted 2005-04-05 08:18:28 »

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

Yuri Vl. Gushchin
JProof Group
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #2 - Posted 2005-04-05 22:38:24 »

Quote

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


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 Smiley

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

malloc will be first against the wall when the revolution comes...
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #3 - Posted 2005-04-05 22:42:49 »

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 Smiley.

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).

malloc will be first against the wall when the revolution comes...
Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Reply #4 - Posted 2005-04-05 23:52:54 »

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.

Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Reply #5 - Posted 2005-04-08 03:17:55 »

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.

Offline arne

Senior Member




money is the worst drug- we should not let it rule


« Reply #6 - Posted 2005-04-08 08:52:58 »

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

:: JOODE :: Xith3d :: OdeJava ::
Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Reply #7 - Posted 2005-04-08 08:55:17 »

that is exactly how it will be Smiley

Cheers,

Will.

Offline Matthias

Senior Member


Medals: 3
Projects: 1


TWL - Themable Widget Library


« Reply #8 - Posted 2005-04-09 06:18:38 »

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

JGO Coder


Medals: 1


http://t-machine.org


« Reply #9 - Posted 2005-04-09 13:26:55 »

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


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 Smiley

malloc will be first against the wall when the revolution comes...
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Goliat

Junior Member





« Reply #10 - Posted 2006-07-08 12:05:14 »

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
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

E.R. Fleming (9 views)
2014-07-29 03:07:13

E.R. Fleming (4 views)
2014-07-29 03:06:25

pw (38 views)
2014-07-24 01:59:36

Riven (39 views)
2014-07-23 21:16:32

Riven (26 views)
2014-07-23 21:07:15

Riven (28 views)
2014-07-23 20:56:16

ctomni231 (59 views)
2014-07-18 06:55:21

Zero Volt (50 views)
2014-07-17 23:47:54

danieldean (42 views)
2014-07-17 23:41:23

MustardPeter (44 views)
2014-07-16 23:30:00
HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54

HotSpot Options
by Roquen
2014-05-06 15:03:10

Escape Analysis
by Roquen
2014-04-29 22:16:43

Experimental Toys
by Roquen
2014-04-28 13:24:22
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!