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

[Sanne Grinovero]

Hi Eduardo,
thanks but really it's not an issue at all.

My email was just to warn to not upgrade Logger in a project which
still needs compatibility with WildFly 8 - as even if it looks like as
simple as changing the version in some build script, there is more
going on.

Sanne

On 1 March 2015 at 22:49, Stuart Douglas <stuart.w.douglas at gmail.com> wrote:
>
>
> On Sun, 1 Mar 2015 at 02:32 Eduardo Sant'Ana da Silva
> <eduardo.santanadasilva at gmail.com> wrote:
>>
>> 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);
>
>
> This won't help. The issue is that method signatures are resolved at compile
> time. If you add these new methods the compiler will use them, but they are
> still not present in the older version, and you will have the same problem.
>
> Stuart
>
>>
>>
>> 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
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev