Log4J Best Practises ?

[hmaass]

Hello

After reading
> showthread.php?t=62180&highlight=log4j and
> showthread.php?t=62077&highlight=log4j

I came to following assumptions:

> Log4J classes can be used in the code for logging.
> But own appenders cannot be properly used / or configured, because only the log4j configuration(log4j.properties / log4j.xml) of the first deployed bundle is parsed.

So what are the best practises for logging in Spring DM Server ? Due to the lack of own appenders, no specific fine-grained logging is possible.

Would an own "logging" bundle be an alternative ?

Thanks & Cheers

Heiko

[Andy Wilkinson]

Hello

After reading
> showthread.php?t=62180&highlight=log4j and
> showthread.php?t=62077&highlight=log4j

I came to following assumptions:

> Log4J classes can be used in the code for logging.
> But own appenders cannot be properly used / or configured, because only the log4j configuration(log4j.properties / log4j.xml) of the first deployed bundle is parsed.

So what are the best practises for logging in Spring DM Server ? Due to the lack of own appenders, no specific fine-grained logging is possible.

Would an own "logging" bundle be an alternative ?

Thanks & Cheers

Heiko

Log4J is somewhat restrictive due to its use of statics to hold its configuration. This means that, if you only have one copy of Log4J, then you can only have one Log4J configuration.

If you'd like to take advantage of Log4J's support for configuring multiple appenders, etc. and would like to have per-application configuration of Log4J available to you, then you may want to consider packaging the Log4J bundle in a PAR file along with the rest of your application.

By packaging Log4J within a PAR file, dm Server will automatically scope the Log4J bundle. This scoping process creates a 'copy' of Log4J, that's specific to your application. This copy exists in its own bundle, and therefore has its own classloader, thereby allowing you to configure Log4J specifically for your application. The slight downside here is that you lose the benefit of being able to re-use a server-wide copy of Log4J. It's a trade-off between reuse of a single copy of Log4J, and have per-application Log4J configuration.

[hmaass]

Hello Andy

Thanks for your help, it works !

Here are the details of my test (for those who are interested):
I've created two PARs (test_par and test2_par) and put "com.springsource.org.apache.log4j-1.2.15.jar" each PAR file.
Each PAR contains three bundles. The test_impl and the test2_impl bundle contain different log4.properties (to test that they will be loaded by a different classloader).

Bundles in test_par

test_api.jar
test_impl.jar
test_web.jar
com.springsource.org.apache.log4j-1.2.15.jar

Bundles test2_par

test2_api.jar
test2_impl.jar
test2_web.jar
com.springsource.org.apache.log4j-1.2.15.jar

In addition I've put two more bundles into test2_par in order to test SLF4J.
Bundles test2_par (with SLF4J)

test2_api.jar
test2_impl.jar
test2_web.jar
com.springsource.org.apache.log4j-1.2.15.jar
com.springsource.slf4j.api-1.5.6.jar
com.springsource.slf4j.log4j-1.5.6.jar

It worked as well.

Cheers and Thanks again

Heiko

[sruch]

If this is the case as heiko discribed above then common bundles (referenced from different application pars) - as they are well known in bigger project - cannot be configured outside dm-server configuration... Is this true?

Cheers,
Sandro

[vishalj]

seperate loggin configuration for dependent bundles is not possible , should i suppose so then

[apostille]

"I recommend skipping the generalization if possible. You will have more
> control over log4j if you use it directly. You cannot execute log4j's
> PropertyConfigurator.configure( "/etc/log4j.properties" ) at your leisure if
> using "commons-logging"."
>
> You can use JCL everywhere except the config part where you use Log4j
> directly. If you're forced to change logging api you only have to change one
> or two files instead of the whole project.
>

Good point. I like your hybrid approach of using Log4J directly, but
only in a few tiny spots, and otherwise using JCL or SLF4J.


apostille

Speaking of best practices - is it really better to use things like
logger.debug("The entry is {}.", entry);

instead of
String.valueOf(entry.
Sure the first one is shorter, but isn't the second one faster?
ssuming an optimal implementation of both in the underlying logging
framework, here's what I suspect (but don't really know.
If DEBUG is disabled they should be the same speed. (As long as Java5
varargs aren't used to implement #1.... those seem to cause a slight
slowdown). The 1st one will not bother replacing {} with "entry" if
debug is not enabled.
If DEBUG is enabled, #1 will probably be faster. I don't remember
exactly, but I think the string concat operator ("+") doesn't prep the
StringBuilder it actually uses with a good initial size, so it may
have to resize itself. However, if you used StringBuilder instead of
the + operator, #2 and #1 would become about the same speed (very very
very slight edge to #2). By now #2 is turning into a 25 line gob of
ugliness, so I still prefer #1


apostille

[AttorneyCompany]

Also, if your application EVER reports a problem, make sure your application logs it. It's not enough to just show a webpage or send an email. You need the log (and hopefully the stacktrace/register-dump/diagnostics).
Attorney Companies