[hibernate-dev] Building with debug/trace log level

Steve Ebersole steve at hibernate.org
Mon Nov 21 11:39:17 EST 2011


Why don't we just manually run the tests once against all the QA 
databases with logging cranked up to ferret out any of these string 
format issues.  I just still do not see why we need to make this a 
routine part of the CI runs and slow them down even more.


On Fri 18 Nov 2011 05:01:36 PM CST, David M. Lloyd wrote:
> Reviewing your stack trace, I can see that you're using debugf, which
> passes through to the logger.  If you have an error in your format then
> there is nothing which can be done about that by the logging framework.
>    You would get a similar error if you were using String.format()
> directly with an invalid format string, and with the same level of
> validation (which is to say, none at compile time).
>
> On 11/18/2011 09:06 AM, Hardy Ferentschik wrote:
>> Hi,
>>
>> we recently discussed on IRC the need to run the builds with debug/trace
>> level.
>> I totally agree that at some stage we should be able rely on upstream
>> testing, speak testing
>> within JBoss Logging. Unfortunately, that does not seem to be good enough.
>>
>> I just switched from default 'info' logging to 'debug' and got errors in:
>>
>> Test org.hibernate.test.criteria.CriteriaQueryTest FAILED
>> Test org.hibernate.test.legacy.FooBarTest FAILED
>> Test org.hibernate.test.legacy.FumTest FAILED
>> Test org.hibernate.test.legacy.ParentChildTest FAILED
>> Test org.hibernate.test.subselect.SubselectTest FAILED
>> Test org.hibernate.test.unionsubclass.UnionSubclassTest FAILED
>>
>> Looking at one of the test errors I think the problem is related to passing
>> wrong parameters to formatted messages:
>>
>> java.util.UnknownFormatConversionException: Conversion = '1'
>> at java.util.Formatter.checkText(Formatter.java:2503)
>> at java.util.Formatter.parse(Formatter.java:2485)
>> at java.util.Formatter.format(Formatter.java:2414)
>> at java.util.Formatter.format(Formatter.java:2367)
>> at java.lang.String.format(String.java:2769)
>> at org.jboss.logging.Log4jLogger.doLogf(Log4jLogger.java:55)
>> at org.jboss.logging.Logger.logf(Logger.java:2143)
>> at
>> org.hibernate.internal.CoreMessageLogger_$logger.debugf(CoreMessageLogger_$logger.java:571)
>>
>> at
>> org.hibernate.internal.util.EntityPrinter.toString(EntityPrinter.java:121)
>> at
>> org.hibernate.event.internal.AbstractFlushingEventListener.logFlushResults(AbstractFlushingEventListener.java:134)
>>
>> at
>> org.hibernate.event.internal.AbstractFlushingEventListener.flushEverythingToExecutions(AbstractFlushingEventListener.java:110)
>>
>> at
>> org.hibernate.event.internal.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:49)
>>
>> at org.hibernate.internal.SessionImpl.flush(SessionImpl.java:1082)
>> at
>> org.hibernate.test.criteria.CriteriaQueryTest.testEscapeCharacter(CriteriaQueryTest.java:114)
>>
>>
>> I think before the final release we will need to build with debug/trace
>> level to fix these issues.
>> I am also wondering whether the logger should not behave a little more
>> graceful.
>>
>> --Hardy
>
>

-- 
steve at hibernate.org
http://hibernate.org



More information about the hibernate-dev mailing list