hehe…nobody ever pays attention to the mention that it was hacked together and really old code… 
Okies - excused 
kidneybean said:
Okies - excused :D
There is no excuse for a darkfrog ;p
darkfrog said:
...
On a Logger you can invoke addHandler and pass your own...
Ah - thanks for the hint and the example. Hmm, now I only need a way to grab all Loggers an external library uses for attaching the custom handler. How to handle programmatically added loggers at runtime?
Sor
Endolf said:
kidneybean said:
Okies - excused :D
There is no excuse for a darkfrog ;p
So you've joined the bash-fest as well.....I guess welcome. :P
Well I don't really have anything to say on that matter, but I will anyway, since this seems to be a nice opportunity to check if I have at all understood what SLF4J can/can't do.
I think you might be looking at SLF4J from an unfortunate perspective, darkfrog: as far as I can see, it does not try to be a more powerful logging system which lets you do more and sexier stuff than JUL, but, on the contrary, it is an abstract layer providing a Factory Class to easily allow for switching of logging systems in a central point, for the main application and all external libraries (that make use of SLF4J). Imho, JUL should provide that, but it doesn't, so SLF4J is needed.
Does that make any sense?
darkfrog said:
So you've joined the bash-fest as well.....I guess welcome. :P
I'm sorry, I thought thats what these forums were for? :D
Endolf
hevee said:
Well I don't really have anything to say on that matter, but I will anyway, since this seems to be a nice opportunity to check if I have at all understood what SLF4J can/can't do.
I think you might be looking at SLF4J from an unfortunate perspective, darkfrog: as far as I can see, it does not try to be a more powerful logging system which lets you do more and sexier stuff than JUL, but, on the contrary, it is an abstract layer providing a Factory Class to easily allow for switching of logging systems in a central point, for the main application and all external libraries (that make use of SLF4J). Imho, JUL should provide that, but it doesn't, so SLF4J is needed.
Does that make any sense?
I disagree that SLF4J is a better option for the reasons mentioned above. Yes, it may give an advantage of being a little easier to attach other loggers onto, but I don't think it's all that complicated to accomplish the same task with JUL. Instead of continuing to disagree why don't you post some code proving your point.
darkfrog said:
[...] Instead of continuing to disagree why don't you post some code proving your point.
Look at the code snippet at http://slf4j.org/manual.html and the FAQ on that site. Speaking in froggy words: "nobody ever pays attention to the" ... links and reasons already posted.
If jME opted to use a bunch of loggers and patterns/features like logger hierachies, inherintance, etc... provided (intended?) by JUL (and SLF4J), there wasn't a single point like the SystemLogger class is now. Here in this case, I could attach my own handler (and remove already attached ones) easily, but what if some committer adds a "per-class-logger" module to jME? Now I am as the game programmer and user of jME forced to update my game code - as the JUL system is not used (configured) here.
I only can cite hevee and others: Imho, JUL should provide an abstract logging layer, but it doesn't, so SLF4J is needed.
Fact is, jME logging is ... in a kind of mess now. Here, you have a good chance to implement logging in much better way, let it be implemented by a volunteer and all of it at cost of a small (did I say small? replace it with tiny) dependcy.
Cheers,
Sor
darkfrog said:
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.
Yep, SLF4J's JUL adaptor here: http://slf4j.org/api/org/slf4j/impl/JDK14LoggerAdapter.html
At this point the only thing that matters is the user-side logging interface because it seems all implementations can plug in and override each other. Ease of customization doesn't matter to me because I'm going to write the code/set the config once and forget about it. The biggest Logger interface difference is that SLF4J supports Markers. I personally haven't used this interface but it sounds interesting enough for me to give it a shot. IMO the discussion should focus on whether Markers will have a positive enough impact in JME to offset the inclusion of the slf4j jars.
lazlohf said:
darkfrog said:
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.
Yep, SLF4J's JUL adaptor here: http://slf4j.org/api/org/slf4j/impl/JDK14LoggerAdapter.html
[...]
Wrong direction. This adaptor is a SLF4J Logger implementation that delegates to JUL. It doesn't extend java.util.logging.Logger(Handler). This adaptor would be "the default logger", that ships with jME ... and the end-user would note no difference to logging used now.
Cheers,
Sor
Well, from going to SLF4J's site and going through some of their information I don't really see an answer to my question still, "What advantages does it provide over JUL?". The only thing I saw close to this was:
Suppose that your CRM application uses log4j for its logging. However, one of your important clients request that logging be performed through JDK 1.4 logging. If your application is riddled with thousands of direct log4j calls, migration to JDK 1.4 would be a long and error-prone process. Had you been invoking SLF4J API instead of log4j, the migration could be completed in a matter of minutes instead of hours.
Well, that's a valid point if we were using log4j, but we're not. I don't believe it's going to be much more difficult to just create a custom handler to connect to log4j, SLF4J, or anything else you might want to use from JUL via a Handler. Perhaps I'm being dense here but I'm still not seeing any clear reason to use anything but JUL.
Does anyone have any serious problem with us using java.util.logging? Is there something you CAN'T do or anything that will make your life a lot harder by using it instead of SLF4J? SLF4J may be a cleaner solution, I bet that it probably is as far as configuration goes, but I don't like the idea of adding yet another dependency to jME especially when it is for something so trivial as logging. I especially think it's silly when Java has a built-in solution that will fulfill our needs.
Sormuras said:
lazlohf said:
Yep, SLF4J's JUL adaptor here: http://slf4j.org/api/org/slf4j/impl/JDK14LoggerAdapter.html
[...]
Wrong direction. This adaptor is a SLF4J Logger implementation that delegates to JUL. It doesn't extend java.util.logging.Logger(Handler). This adaptor would be "the default logger", that ships with jME ... and the end-user would note no difference to logging used now.
Cheers,
Sor
Doh! Yep I misunderstood, thought it implemented the JUL Logger interface and could be returned from LogManager. Well, I still think the main issue is SLF4J Markers vs yet-another-jar. As I mentioned, I'm going to give SLF4J a go in a small project I'm working on, but maybe it would be best to convert some of JME's code to SLF4J and post it here to see how it looks and feels.
lazlohf said:
Doh! Yep I misunderstood, thought it implemented the JUL Logger interface and could be returned from LogManager. [...]
If it were an interface... *sigh* ...we wouldn't discuss. I'll post some example code tomorrow and give up convincing darkfrog. For me, a "cleaner solution" is reason enough to go the cleaner way. Programming is art - i don't like bad art. Matter of taste?
Cheers,
Sor
to be sincere, at this stage i don't really care which api is used. while i agree that slf4j implements a very nice logging layer, i don't think that we should jump on it right away (additional dependency, code changes, no real need for such a layer - at least not for me). i'd be happy if logging (as in using logging at all) in general would improve in jme instead of using that lib. later on, this layer can still be added if necessary.
please don't take the jul -> SLF4J -> log4j(or something else) path because that's using 2 logging apis at the same time. it might be no big deal, but imho it's just ugly. so either jul as top api and nothing else beneath, or slf4j as top api and anything else beneath.
this is my very inexpert opinion.
Sormuras said:
If it were an interface... *sigh* ...we wouldn't discuss. I'll post some example code tomorrow and give up convincing darkfrog. For me, a "cleaner solution" is reason enough to go the cleaner way. Programming is art - i don't like bad art. Matter of taste?
In principal I agree, but in practice the only place it will really be "cleaner" is in the few lines of code that is actually creating a logging handler (which in most cases would be like 10 lines of code). However, if we go to straight SLF4J we then tightly couple jME in EVERY class to their API.
Example code is appreciated and if it makes a good enough case to make the change I'm all for it. I'm not the deciding factor though, so don't be too discouraged you can't seem to convince me. :P
Maybe I'm missing your point here DarkFrog, but SLF4J is a facade to allow people to choose their logging framework at "deployment time" as he says on the front page. From what you're saying, it sounds like you think that SLF4J stands on its own as a logging system. It does not. SLF4J requires using "JDK 1.4 style logging", Log4J, etc.
If JME were using SLF4J today, then someone who is more comfortable with Log4J could do a couple configuration changes and use that without changing any JME code. A valid reason to do that would be that you've built a game engine with something else, then decide to migrate it to JME. The game logic is all using whatever logging framework, and to unify things and make it easier to manage logs, you flip a switch and JME is now using the same logging framework you've already got. Granted, if you wrote your own stuff with SLF4J you also have the choice to move your logging over to what JME is using, but that just illustrates the main point.
One reason you mention not to use SLF4J is because then JME would be tightly tied to it's API. That is true, BUT developers would then not be tied to ANY logging system, they could choose. That's the beauty of the facade.
Another great point is that you don't have to switch all the code at once, it can be done piecemeal, and have it all still log via the current logging system.
Nothing to add, culli. 
I just assumed that SLF4J included some basic logging features.
I'm going to defer to other developers now, but I see coupling our logging directly to JUL to be a far better solution than SLF4J if only that we're tightly coupling to another API as opposed to tightly coupling to core Java. The only way that opinion will be changed is if someone can convince me that there's something that SLF4J provides feature-wise that necessitates its use over JUL.
But like I said, that's the last I'm interested in debating over this topic…other developers need to chime in with what they think we should do and I've made my opinion abundantly clear. 
Since DarkFrog apparently won't hear this…
darkfrog said:
The only way that opinion will be changed is if someone can convince me that there's something that SLF4J provides feature-wise that necessitates its use over JUL.
DarkFrog didn't respond to my point that someone developing a game with JME might NOT want to use JUL. I think that is an extemely useful thing to allow for. It's just like building JME in a way that abstracts it from a particular graphics engine so LWJGL or (eventually) JOGL can be used instead. Or sound engines, physics engines, [edit]NETWORKING ENGINES such as JGN[/edit], and so on.
darkfrog said:
But like I said, that's the last I'm interested in debating over this topic
lalalala, I can't hear you, lalalalalalalalala... }:-@