java.util.logging usage

[heymjo]

Hi,

Activiti is using jdk logging currently. When an application uses log4j or logback it is harder than necessary to consolidate the debug logs. Has it been considered to use a logging bridge which is a tad bit more flexible towards whatever logging framework the embedding application is using ? slf4j maybe ?

tx
Jorg

[ronald_van_kuij]

Isn't that what slf4j can do for you, bridge whatever logging framework there is to something else with the libs using whatever they want instead of *forcing* then to use slf4j or whatever… Search the net and you'll quickly find how to simple bridge this.

[heymjo]

yes i did my homework before posting this The jul-to-slf4j bridge [1] is doable but not as straightforward as the jcl or log4j bridge where you just copy jars around and be done with it, i'm quite familiar with this. For jul-to-slf4j i need to write init code to make it work [2]. There are some performance impact warnings because of the way it is implemented, and the advice is to only use this bridge in combination with logback's LevelChangePropagator [3], but what if we're already using log4j in our app ? Should we then bridge both j.u.l and log4j over slf4j to logback ? Oh hey i just used 4 logging frameworks in one sentence !

So all this sounded like the too-many-hoops-to-jump-through syndrome and that's why i mentioned it here.

Jorg

[1] http://www.slf4j.org/legacy.html#jul-to-slf4j
[2] http://www.slf4j.org/api/org/slf4j/bridge/SLF4JBridgeHandler.html
[3] http://logback.qos.ch/manual/configuration.html#LevelChangePropagator

[jbarrez]

The reason why we're using jul is exactly what you are describing there: there is just not a standard for doing loggin in java. So we choose JUL primarly for the reason that it doesnt add any extra dependencies, simple as that.

[heymjo]

adding no extra dependencies is simpler for you indeed but makes it more difficult for users to bridge it.

Also j.u.l is configured on a per VM basis, meaning that changing the logging config affects all running apps and make multi-tennancy more annoying than needed. Tomcat example replaces the j.u.l LogManager with a container and webapp friendly implementation for this reason exactly (see http://tomcat.apache.org/tomcat-6.0-doc/logging.html#Using_java.util.logging_%28default%29).

Anyway it's your call, we adapt 🙂

[trevershick]

Instead of just using Juli in Activiti, could you simply use your own small wrapper around a pluggable log mechanism to allow the client to choose?  Something via configuration or an environment property….

You don't have to implement the bridges yourself, but you could end up with something similar to slf4j but without adding a dependency.

If Activiti code uses ActivitiLogger which is an interface that looks up an implementation to use (which by default would be your JUL), you would allow us to add our own implementation to bridge to whatever logging mechanism we would prefer to use.

This would solve your zero dependency requirement yet allow us as clients to bridge to whatever logging mechanism we wish.

[heymjo]

If Activiti code uses ActivitiLogger which is an interface that looks up an implementation to use (which by default would be your JUL), you would allow us to add our own implementation to bridge to whatever logging mechanism we would prefer to use.

uh oh, do i see yet another logging bridge adapter converter manager on the horizon ?

[trevershick]

Perhaps… their stated goal of "(JUL) reason that it doesnt add any extra dependencies" is hard to ignore.
it's a good goal.
Even a 'small' framework like slf4j is still a PITA sometimes depending on where you deploy it. Clashes between slf4j are handled well, but i'd rather avoid the clashes completely.

I actually prefer the JUL implementation they have.  Yes, it's no fun to bridge it, but it's better than having to deal with a transitive dependency.

http://trevershick.tumblr.com/post/18127159072/state-of-java-logging