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

[Eduardo Sant'Ana da Silva]

I was wondering if just adding a new method to the BasicLogger interface could resolve the problem.
 
void debugf(String format, Integer arg);
void debugf(String format, Long arg);

Correct me if I'm wrong, but the problem reported was a collateral effect of the the addition of  : 

   void debugf(String format, int arg);
   void debugf(String format, long arg);

https://github.com/jboss-logging/jboss-logging/blob/master/src/main/java/org/jboss/logging/BasicLogger.java

This was added last September, and with the additions of the Integer and Long types, the autoboxing will resolve our problems, and not cast will be necessary.


int i = 123;
bl.debugf( "Number: %d", i );
>> void debugf(String format, int arg);

Integer i = 123;
bl.debugf( "Number: %d", i );
>> void debugf(String format, Integer param1);


Object i = new Integer(123);
bl.debugf( "Number: %d", i );
>> void debugf(String format, Object param1);

(same thing to Long type)


Since debugf methods are inherited from BasicLogger.




On Feb 27, 2015, at 8:50 PM, James R. Perkins <jperkins at redhat.com> wrote:

> We faced some odd compile errors with JDK 7 when we switched WildFly 
> Core to 3.2.1.Final. Really the only way to get around it would be to 
> cast int's or long's to their object types. Though that's not really 
> ideal either I realize.
> 
> That said it should be fine in WildFly 9 as we're using 3.2.1.Final now.
> 
> On 02/27/2015 12:08 PM, Sanne Grinovero wrote:
>> 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
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> 
> -- 
> James R. Perkins
> JBoss by Red Hat
> 
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150228/65b43a84/attachment-0001.html