Building with debug/trace log level
by Hardy Ferentschik
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
12 years, 5 months
Move team meeting 2 hours earlier?
by Gail Badner
I discussed moving the team meeting two hours earlier on Tuesday with some of you. IIRC, Steve E., Strong, and Hardy are OK with this change.
That would be at 14:00 UTC (6am Seattle; 8 am Austin/St Louis; 9pm Beijing).
Would that work for everyone?
If so, should we start 11/15?
Thanks,
Gail
12 years, 5 months
Re: [hibernate-dev] [jboss-as7-dev] Which JBoss Logging version to use in AS and Hibernate Core
by Sanne Grinovero
I thought this was an expected limitation, since the Logger
implementations generated by the latest tools depend on the new logger
classes.
We're having a Shrinkwrap+Arquillian test in Hibernate Search itself
which creates a test app containing it's own latest build and deploys
it to a test-managed AS7 instance on version 7.0.2.Final.
If I build Hibernate Search using
<jbossLoggingVersion>3.1.0.Beta3</jbossLoggingVersion>
<jbossLoggingProcessorVersion>1.0.0.CR3</jbossLoggingProcessorVersion>
then the generated logger implementation will extend
org.jboss.logging.DelegatingBasicLogger, which is not found as
7.0.2.Final doesn't have such a class.
To reproduce, checkout :
github https://github.com/Sanne/hibernate-search
branch: HSEARCH-965
Maven module : hibernate-search-integrationtest
testname: MemberRegistrationIT
Error:
19:37:07,415 ERROR [org.jboss.msc.service.fail] (MSC service thread
1-2) MSC00001: Failed to start service
jboss.persistenceunit."MemberRegistrationIT.war#primary":
org.jboss.msc.service.StartException in service
jboss.persistenceunit."MemberRegistrationIT.war#primary": Failed to
start service
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1780)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
[:1.6.0_27]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
[:1.6.0_27]
at java.lang.Thread.run(Thread.java:662) [:1.6.0_27]
Caused by: java.util.ServiceConfigurationError:
org.hibernate.integrator.spi.Integrator: Provider
org.hibernate.search.hcore.impl.HibernateSearchIntegrator could not be
instantiated: java.lang.LinkageError: Failed to link
org/hibernate/search/util/logging/impl/Log_$logger (Module
"deployment.MemberRegistrationIT.war:main" from Service Module Loader)
at org.hibernate.integrator.internal.ServiceLoader.fail(ServiceLoader.java:99)
at org.hibernate.integrator.internal.ServiceLoader.<init>(ServiceLoader.java:71)
at org.hibernate.integrator.internal.ServiceLoader.load(ServiceLoader.java:191)
at org.hibernate.integrator.internal.IntegratorServiceImpl.getIntegrators(IntegratorServiceImpl.java:61)
at org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:293)
at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1722)
at org.hibernate.ejb.EntityManagerFactoryImpl.<init>(EntityManagerFactoryImpl.java:76)
at org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:899)
at org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:884)
at org.hibernate.ejb.HibernatePersistence.createContainerEntityManagerFactory(HibernatePersistence.java:73)
at org.jboss.as.jpa.service.PersistenceUnitService.createContainerEntityManagerFactory(PersistenceUnitService.java:143)
at org.jboss.as.jpa.service.PersistenceUnitService.start(PersistenceUnitService.java:77)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1824)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1759)
... 3 more
Caused by: java.lang.LinkageError: Failed to link
org/hibernate/search/util/logging/impl/Log_$logger (Module
"deployment.MemberRegistrationIT.war:main" from Service Module Loader)
at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:401)
at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:261)
at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:76)
at org.jboss.modules.Module.loadModuleClass(Module.java:590)
at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:183)
at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:361)
at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:333)
at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:310)
at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:103)
at java.lang.Class.forName0(Native Method) [:1.6.0_27]
at java.lang.Class.forName(Class.java:247) [:1.6.0_27]
at org.jboss.logging.Logger.getMessageLogger(Logger.java:2249)
at org.jboss.logging.Logger.getMessageLogger(Logger.java:2215)
at org.hibernate.search.util.logging.impl.LoggerFactory.make(LoggerFactory.java:37)
at org.hibernate.search.hcore.impl.HibernateSearchIntegrator.<clinit>(HibernateSearchIntegrator.java:48)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method) [:1.6.0_27]
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
[:1.6.0_27]
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
[:1.6.0_27]
at java.lang.reflect.Constructor.newInstance(Constructor.java:513) [:1.6.0_27]
at java.lang.Class.newInstance0(Class.java:355) [:1.6.0_27]
at java.lang.Class.newInstance(Class.java:308) [:1.6.0_27]
at org.hibernate.integrator.internal.ServiceLoader.<init>(ServiceLoader.java:67)
... 15 more
Caused by: java.lang.NoClassDefFoundError:
org/jboss/logging/DelegatingBasicLogger
at java.lang.ClassLoader.defineClass1(Native Method) [:1.6.0_27]
at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631) [:1.6.0_27]
at java.lang.ClassLoader.defineClass(ClassLoader.java:615) [:1.6.0_27]
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141)
[:1.6.0_27]
at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:397)
... 36 more
Caused by: java.lang.ClassNotFoundException:
org.jboss.logging.DelegatingBasicLogger from [Module
"deployment.MemberRegistrationIT.war:main" from Service Module Loader]
at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:191)
at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:361)
at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:333)
at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:333)
at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:310)
at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:103)
... 41 more
On 7 November 2011 19:27, David M. Lloyd <david.lloyd(a)redhat.com> wrote:
> The first issue I will make sure is resolved before releasing.
>
> The second issue should not be true - the primary differences between 3.0
> and 3.1 are in annotations, which have been changed in 3.1 to have CLASS
> retention - but if you find there is a compatibility problem please let me
> know ASAP.
>
> On 11/07/2011 01:25 PM, Sanne Grinovero wrote:
>>
>> There are two problems:
>> * JBLOGGING-74 - opened last week, is not a blocker but has some
>> consequences on performance
>> * second is that if we go with 3.1 it will not work on all releases
>> of AS7 having 3.0.x.; Which means for all the people waiting for
>> Hibernate 4.0.0.Final won't have a nice AS to play with when it's
>> released.
>>
>> Sanne
>>
>>
>> On 7 November 2011 16:33, Emmanuel Bernard<emmanuel(a)hibernate.org> wrote:
>>>
>>> Yep, we have it running against 3.1.0.Beta3 which is the latest release
>>> published.
>>>
>>> On 7 nov. 2011, at 17:27, David M. Lloyd wrote:
>>>
>>>> I can look into it tonight. Have you tested with the latest 3.1.0
>>>> release to verify there are no problems?
>>>>
>>>> On 11/07/2011 09:51 AM, Steve Ebersole wrote:
>>>>>
>>>>> Specifically, is there anyway to get org.jboss.logging:jboss-logging to
>>>>> Final/GA in the next few days? The generator/processor is irrelevant as
>>>>> far as we are concerned for a Hibernate release.
>>>>>
>>>>> On Mon 07 Nov 2011 09:47:08 AM CST, Steve Ebersole wrote:
>>>>>>
>>>>>> Which really sucks since 4.0 Final is slated for 2 days.
>>>>>>
>>>>>> Ugh.
>>>>>>
>>>>>> On Fri 04 Nov 2011 10:59:24 AM CDT, Emmanuel Bernard wrote:
>>>>>>>
>>>>>>> Do you know when JBoss Logging 3.1.0.GA will hit the road. I can't
>>>>>>> really release Hibernate Commons Annotations nor Core etc until we
>>>>>>> have the final version. I mean we could but we might have to redo it.
>>>>>>>
>>>>>>> Emmanuel
>>>>>>>
>>>>>>> On 4 nov. 2011, at 16:05, David M. Lloyd wrote:
>>>>>>>
>>>>>>>> Yeah let's target 3.1.0.GA for everything. The final 1.0.0.GA
>>>>>>>> release
>>>>>>>> of the i18n logging tool will require 3.1.0.GA.
>>>>>>>>
>>>>>>>> On 11/04/2011 09:42 AM, Scott Marlow wrote:
>>>>>>>>>
>>>>>>>>> Currently, in AS7, the AS7 "org.jboss.logging" module is used by
>>>>>>>>> the
>>>>>>>>> Hibernate (Core) module. The "org.jboss.logging" module happens to
>>>>>>>>> be
>>>>>>>>> "3.1.0.Beta3". I think that Hibernate (4.0.x) Core needs to stay in
>>>>>>>>> sync with the AS7 version of JBoss Logging.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> https://github.com/jbossas/jboss-as/blob/master/build/src/main/resources/...
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I think that AS7 needs to stay in sync with what integrated
>>>>>>>>> projects are
>>>>>>>>> using (using the 3.1.0.* versions of JBoss logging for AS 7.1).
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 11/04/2011 07:30 AM, Emmanuel Bernard wrote:
>>>>>>>>>>
>>>>>>>>>> JBoss AS 7.1 is targeted to use JBoss Logging 3.0.1 AFAIK.
>>>>>>>>>> Hibernate Core 4.0 right now is using JBoss Logging 3.1.0.Beta3
>>>>>>>>>>
>>>>>>>>>> // logging
>>>>>>>>>> logging: 'org.jboss.logging:jboss-logging:3.1.0.Beta3',
>>>>>>>>>> logging_generator:
>>>>>>>>>> 'org.jboss.logging:jboss-logging-generator:1.0.0.CR3',
>>>>>>>>>> logging_processor:
>>>>>>>>>> 'org.jboss.logging:jboss-logging-processor:1.0.0.CR3',
>>>>>>>>>>
>>>>>>>>>> So which one we should go to? Once we have decided, I will align
>>>>>>>>>> Search, OGM and Commons Annotations.
>>>>>>>>>>
>>>>>>>>>> Emmanuel
>>>>>>>>>> _______________________________________________
>>>>>>>>>> hibernate-dev mailing list
>>>>>>>>>> hibernate-dev(a)lists.jboss.org
>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> jboss-as7-dev mailing list
>>>>>>>>> jboss-as7-dev(a)lists.jboss.org
>>>>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> - DML
>>>>>>>> _______________________________________________
>>>>>>>> jboss-as7-dev mailing list
>>>>>>>> jboss-as7-dev(a)lists.jboss.org
>>>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> hibernate-dev mailing list
>>>>>>> hibernate-dev(a)lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> - DML
>>>
>>>
>>> _______________________________________________
>>> jboss-as7-dev mailing list
>>> jboss-as7-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>
>
>
> --
> - DML
>
12 years, 5 months
postponing Hibernate Search 4.0.0.CR2 release?
by Sanne Grinovero
I'm wondering if the Hibernate Search is still going to happen tomorrow, as:
- Hibernate Core 4 wasn't released as final.
- My pull requests are lingering, and I might need to make some
adaptations according to feedback; I don't think I will, but some
patches resulted more complex than expected.
- Emmanuel mentioned he won't be online (?!)
- I have to check in on a ferry boat to Holland at 16h, likely no
connectivity until next morning
- Java 7 issues ?!
Overall state doesn't look bad, but if we had four more days I could
solve the latest minor bugs and would consider including Davide and
Zach's patch.. I've aborted that currently as it feels too rushed if
it's for tomorrow.
Also I wouldn't mind taking some hours to look at why some tests fail on Java 7.
Fixes that I'd want to include if we move the date:
HSEARCH-798 Make use of categories instead of fqcn for logging
HSEARCH-937 Search fails when loading associated entity with different ID type
HSEARCH-703 QueryBuilder should support specialization by superclasses
of indexed entities
All other tasks scheduled for CR2 sound like we can fix them for
tomorrow morning.
Cheers,
Sanne
12 years, 6 months
Negative value returned by BaseRegion.getTimeOut(); Inconsistent UpdateTimestamps cache hit/put counts
by Gail Badner
I'm looking into the CMTTest.testConcurrentCachedDirtyQueries() failure, which involves an unexpected second-level cache hit. This test is skipped when using H2, so this failure was overlooked until recently.
It turns out that org.hibernate.testing.cache.BaseRegion.getTimeout() returns Timestamper.ONE_MS * 600000.
Since Timestamper.ONE_MS is 4095, the product is 2457000000, which overflows the int return value, resulting in a negative timeout being returned. Because of this, the update timestamp ends up being before the cached query result timestamp. Hibernate assumes (erroneously) that the cached query results are up-to-date.
Changing BaseRegion.getTimeout() to return Timestamper.ONE_MS * 60000 gets past that assertion. I should also mention that this change causes org.hibernate.ejb.test.EntityManagerTest and org.hibernate.ejb.test.packaging.PackagedEntityManagerTest to fail on H2 because there are fewer than expected second-level cache hits. My guess is that the lower number is really correct, but I haven't looked into it.
Later assertions in CMTTest.testConcurrentCachedDirtyQueries() involving UpdateTimestamps cache hit/put counts fail. In fact, none of the expected values for the UpdateTimestamps cache hit/put counts in that test match the actual values, and I'm seeing different counts depending on whether the full test suite is run vs the failing test method alone.
As an example, this assertion is on line 307:
assertEquals( sessionFactory().getStatistics().getUpdateTimestampsCacheHitCount(), 4 );
(Yes, I know the expected value is supposed to be first.)
The expected value is 4.
The actual value when running/debugging the full test in Intellij is 2.
The actual value when running/debugginb the CMTTest.testConcurrentCachedDirtyQueries() alone in Intellij is 1.
I see that CMTTest.getCacheConcurrencyStrategy() returns "transactional", which gets mapped to org.hibernate.testing.cache.NonstrictReadWriteEntityRegionAccessStrategy (which is obviously not transactional) by org.hibernate.testing.cache.EntityRegionImpl.
Was a different cache used when this test was written? Could that be a reason why the counts are off?
Does anyone know if this test ever passed on the other dialects?
Does anyone have any insight into what is going on here?
Thanks,
Gail
12 years, 6 months
