Dariusz on Software

I assume you're a developer and want to control global log level you are getting on your console window in Eclipse. Just log level. You don't want to learn all Log4J machinery to create many log files, customize logging format etc. I'll describe simplest steps to achieve this.

First, create commons-logging.properties file in your src/ directory (or directory on your classpath):

org.apache.commons.logging.Log=org.apache.commons.logging.impl.SimpleLog

Next, create simplelog.properties in the same location:

org.apache.commons.logging.simplelog.defaultlog=warn
org.apache.commons.logging.simplelog.showlogname=false
org.apache.commons.logging.simplelog.showShortLogname=false
org.apache.commons.logging.simplelog.showdatetime=false

That's all! Your app will now log on WARN level and above in short, one-line format. Isn't it simple?

If you want to give different log levels (info for instance) to different packeges:

org.apache.commons.logging.simplelog.log.<package prefix>=info

Recently I was asked to integrate WXS (Websphere Extreme Scale, commercial cache implementation from IBM) into existing WPS (Websphere Process Server)-based project to implement read-only non-distributed cache (one independent cache instance per JVM). The idea is to plug cache implementation using 2nd level cache interfaces defined by Hibernate.

I plugged in the objectgrid.jar into hibernate configuration:

<property name="cache.provider_class">
com.ibm.websphere.objectgrid.hibernate.cache.ObjectGridHibernateCacheProvider
</property>

then saw the following exception during Hibernate initialisation:

[4/29/10 10:08:34:462 CEST] 00000069 RegisteredSyn E WTRN0074E:
Exception caught from after_completion synchronization operation:
java.lang.NoSuchMethodError:
org/hibernate/cache/CacheException.<init>(Ljava/lang/Throwable; )V
at com.ibm.ws.objectgrid.hibernate.cache.ObjectGridHibernateCache.getSession(
ObjectGridHibernateCache.java:149)
at com.ibm.ws.objectgrid.hibernate.cache.ObjectGridHibernateCache.put(
ObjectGridHibernateCache.java:385)
at org.hibernate.cache.UpdateTimestampsCache.invalidate(
UpdateTimestampsCache.java:67)

WXS expects CacheException(java.lang.Throwable) constructor, Hibernate API supports this constructor since version 3.2. Version 3.1 currently used in project doesn't support this constructor (only CacheException(java.lang.Exception) is present). This issue forced Hibernate upgrade in the project. Note that no Hibernate version requirements found on official "requirements" page (huh?).

Conclusions:

• BIG BLUE is not a guarantee for high quality documentation
• Closed source is harder to implement (any problems put you in waiting support queue)
• "Big" != Good (IMHO), would you pay for read-only cache implementation $14,400.00 per PVU and deploy giant objectgrid.jar (15M) for this very purpose? Yikes!

I'm going to talk with project sponsor about better ways to spend money (my salary increase, maybe ;-) ). Seriously: free EHCache / OSCache are more than sufficient for the task. They are small and Open Source.

"Do not hire Godzilla to pull Santa's sleigh, reindeers are better for this purpose" - Bart Simpson.

During recent 2nd level cache implementation research I noticed EHCache has a very funny dependency: slf4j. Hey, WTH, yet another log library implementation? - I asked myself. No commons-logging as everywhere?

I googled around and found "The evils of commons-logging.jar and its ilk" article. It highlight some problems related to commons-logging usage:

1. Different commons-logging versions in one project mirrors DLL-hell problem
2. Collection logs from all sources into one stream has no bigger value for a developer
3. Advanced configuration is logging back-end dependant (appenders for log4j for example), so unified layer is not valuable here
4. Configuration is not intuitive and hard

I agree with 1, 3 and 4. 2 is questionable: sometimes logs sorted in one timeline allows for better error analysis.

slf4j is proposed as an alternative. It's more modular and (probably) simpler that commons-logging. All configuration is a matter of placing selected implementation (slf4j-jdk14-1.5.8.jar for instance) jar on classpath. And voila! - logging is done thru JDK 1.4 logging. Quite simple.

Sometimes you want to customize logging level for given package in your application (to see tracing details for example). If you're using commons-logging library the configuration file is called "commons-logging.properties" and it should be places somewhere on classpath.

org.apache.commons.logging.Log=org.apache.commons.logging.impl.SimpleLog
priority=1

Then we can configure SimpleLog back-end just declared in simplelog.properties:

org.apache.commons.logging.simplelog.defaultlog=warn
org.apache.commons.logging.simplelog.log.com.mycompany.package=debug

You place those two files on classpath, redeploy application and ... NOTHING HAPPENS. Those files aren't visible!

Why is it happening? Here's the explanation:

• Default WebSphere class-loader is defined as PARENT_FIRST, that means WebSphere classpath is being searched in first place
• WebSphere ships with commons-logging.properties that selects JDK 1.4 logging back-end

That's why your commons logging configuration is not visible.

How to fix that: place files inside /opt/IBM/WID61/pf/wps/properties directory (it's the first entry on the classpath). Then those files will become visible and log level customisation is possible then.