[wildfly-dev] Heads up on JBoss Logger 3.2 : more changed than what it looks like

Sanne Grinovero sanne at hibernate.org
Fri Feb 27 15:08:00 EST 2015


Hi all,
today I've upgraded jboss-logging from version 3.1.4.GA to 3.2.1.Final
in an Hibernate project, and got some integration test failures.

The surprising aspect is that everything seemed fine at compile level:
just switch the version in the pom, and without needing any further
changes it compiles fine and runs all unit tests successfully.. but
fails when using the freshly built libraries in WildFly 8.2.

It's not a regression of jboss-logging, but one of its improvements
require a bit of attention.

This is what happened to us:
we have some log statements which look like this in source code (after
simplifying):

    int i = ...
    log.debugf( "Number: %d", i );

This does of course compile fine in both old an new versions of JBoss
Logger. And it all works as expected in unit tests.
But when deploying the modified version of this Hibernate library in
WildFly 8.2, you'd get some of these:
 - java.lang.NoSuchMethodError:
org.hibernate.search.util.logging.impl.Log.debugf(Ljava/lang/String;J)V"}}

When using the older version of JBoss Logger (at compile time), the
above line of code is compiled as an invocation to:

    void debugf(String format, Object param1);

(which is a method present in both versions)

When using the new version of JBoss Logger (at compile time), the same
line of code is interpreted as the (better) invocation to:

    void debugf(String format, int arg);

So that's what the library is going to invoke at runtime - and that
method doesn't exist in WildFly 8.2.

Be aware of this when upgrading as it might look like a trivial
version bump but it makes it quite hard to guarantee backwards
compatibility with older versions of the logger.

Personally since I want to upgrade the logger but don't want to drop
compatibility with existing WildFly releases, I'm trying to figure how
to reliably validate that no logging statement is going to invoke one
of the new ones.. for now.

I guess this also means that users won't actually benefit from the
better performance of the new logging methods until we recompile all
of its client libraries using the new version ;-)
Auto-boxing is evil..

Sanne


More information about the wildfly-dev mailing list