Well because [logging] was longly broken in a not flat classloading
environment (didnt check last release but almost all logging facade got
this issue at a point) and because almost nothing in TomEE stacks uses it,
it is not as integrated as log4j, slf4j or JUL (which is the default). Main
issue I saw was leaks (due to classloaders management) and potentially
wrong config detection (same reason). I hacked in TomEE slf4j to force it
to be smart cause users often rely on it but not [logging yet]. Until here
you can say that's a TomEE issue (as fair as saying that's a JCS one).
Then you can't seriously use JUL with [logging] cause of this method (from
Jdk14Logger):
protected void log( Level level, String msg, Throwable ex ) {
Logger logger = getLogger();
if (logger.isLoggable(level)) {
// Hack (?) to get the stack trace.
Throwable dummyException = new Throwable();
StackTraceElement locations[] = dummyException.getStackTrace();
// LOGGING-132: use the provided logger name instead of
the class name
String cname = name;
String method = "unknown";
// Caller will be the third element
if( locations != null && locations.length > 2 ) {
StackTraceElement caller = locations[2];
method = caller.getMethodName();
}
if( ex == null ) {
logger.logp( level, cname, method, msg );
} else {
logger.logp( level, cname, method, msg, ex );
}
}
}
getStackTrace will be too expensive that you will just want
logger.isLoggable(level) to be false. There is no magic to make it
consistent and fast. Half of impl doesn't respect method to avoid it.
But then the question is regarding JCache. All apache spec impl uses JUL as
primary logger (allowing then to override it) to avoid to force the
container/environment and let the user deciding what to use. Here the issue
is JCache is built on top of JCS. So either both use JUL or if JCS uses
[logging] by default then JCache will bring [logging] and force its usage.
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2014-06-02 8:17 GMT+02:00 Jörg Schaible <joerg.schai...@swisspost.com>:
> Romain Manni-Bucau wrote:
>
> > Hi
> >
> > I have two main point to discuss regarding the logging:
> > 1) LogHelper stuffI committed. Idea was to cache isDebugEnabled to get a
> > if (boolean) complexity and not go through the logging framework which
> can
> > imply several layers (filter, appender, handler, logger...) for nothing
> > and slow down caching (which has more perf constraints than other
> > backends. This really depends on the logger you use but we can't suppose
> > it is the one we benched against. Solutions I see: a) keep LogHelper, b)
> > remove logs (some are useless I think), 3) other?
> >
> > 2) logger api used. ATM we use [logging] but it will surely be an issue
> > for TomEE when integrated ([logging] is the less integrated framework -
> > compared to JUL or SLF4J where we don't have the choice at all)
>
> ?? Can you explain a bit more? You can logging redirect to use JUL, so what
> kind of issues are you thinking about?
>
> > and I
> > think we'd be happy to remove it from the container to let it be
> > application oriented if we can. Any idea to make it hurtless? This
> doesn't
> > urge and doesn't block anything but if someone has an awesome idea it
> > would be welcomed ;)
> >
> >
> > Romain Manni-Bucau
> > Twitter: @rmannibucau
> > Blog: http://rmannibucau.wordpress.com/
> > LinkedIn: http://fr.linkedin.com/in/rmannibucau
> > Github: https://github.com/rmannibucau
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
