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&lt;david.lloyd(a)redhat.com&gt; 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&lt;emmanuel(a)hibernate.org&gt; 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 >

Also, I'm not sure if this is a blocking problem; it surely isn't great that it won't work on AS <7.1 but we have to move forward. Emmanuel, would this be an acceptable limitation for Search ?

> I don't think the shade approach is the way to go; it wouldn't work in > AS 7.1, which is our final goal. Yeah, it would actually. It would just put a copy of that base class in your JAR somewhere, and then your generated classes would extend that class instead of the one which is missing in 3.0, thus your program would function normally.

if jboss-logging 3.1.0 final would compatible with 3.1.0.Beta3, then i would vote for releasing 4.0 Final today hope AS7 could cut off a CR release with jboss-logging 3.1.0.Beta3 or Final soon |------------------------------------------------------- or we wait for jboss-logging goes final and --` shade plugin is not always a good choice and i don't know if there is an alternative can be used in gradle On Nov 8, 2011, at 6:12 PM, Hardy Ferentschik wrote: > On Tue, 08 Nov 2011 00:33:23 +0100, David M. Lloyd > <david.lloyd(a)redhat.com&gt; wrote: > >>> I don't think the shade approach is the way to go; it wouldn't work in >>> AS 7.1, which is our final goal. >> >> Yeah, it would actually. It would just put a copy of that base class in >> your JAR somewhere, and then your generated classes would extend that >> class instead of the one which is missing in 3.0, thus your program >> would function normally. > > Even though this solution seems of the table, I just thought that the > productization > team cannot use the shade plugin (don't ask me why). For that reasons they > actually > have to remove the shade plugin from the pom and patch the build in other > ways. > > --Hardy > _______________________________________________ > 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

Maybe instead of "shading in" the removed class you could just add it back to the JBoss Logging codebase?

On 11/09/2011 04:48 AM, Emmanuel Bernard wrote: > I see a few outputs > > - JBoss Logging 3.1.0.Final is released in the next 24h and we use it > in Core and Search

On 11/09/2011 08:22 AM, Hardy Ferentschik wrote: > On Wed, 09 Nov 2011 15:00:07 +0100, Steve Ebersole <steve(a)hibernate.org&gt; > wrote: > >> Maybe instead of "shading in" the removed class you could just add it >> back to the JBoss Logging codebase? > > Right, why can we not do that? You have it backwards. We didn't *remove* a class, we *added* one - which makes it not present in 3.0.x. >> On 11/09/2011 04:48 AM, Emmanuel Bernard wrote: >>> I see a few outputs >>> >>> - JBoss Logging 3.1.0.Final is released in the next 24h and we use it >>> in Core and Search > > What's stopping a 3.1.0.Final release? Trying to resolve this issue for you guys.

Yeah, the problem was that to *implement* BasicLogger we had switched to using a base class (bundled in 3.1) to implement the multitude of methods, due to problems associated with generating all the implementations in every class. On 11/09/2011 08:39 AM, Steve Ebersole wrote: > Ok, I am totally confused then. I thought this was a discussion about > BasicLogger. But we have been using that afaik way before our recent > upgrade to 3.1 > > On Wed 09 Nov 2011 08:23:33 AM CST, David M. Lloyd wrote: >> On 11/09/2011 08:22 AM, Hardy Ferentschik wrote: >>> On Wed, 09 Nov 2011 15:00:07 +0100, Steve Ebersole >>> <steve(a)hibernate.org&gt; >>> wrote: >>> >>>> Maybe instead of "shading in" the removed class you could just add it >>>> back to the JBoss Logging codebase? >>> >>> Right, why can we not do that? >> >> You have it backwards. We didn't *remove* a class, we *added* one - >> which makes it not present in 3.0.x. >> >>>> On 11/09/2011 04:48 AM, Emmanuel Bernard wrote: >>>>> I see a few outputs >>>>> >>>>> - JBoss Logging 3.1.0.Final is released in the next 24h and we use it >>>>> in Core and Search >>> >>> What's stopping a 3.1.0.Final release? >> >> Trying to resolve this issue for you guys. >> >> >

Thanks David! Just to make sure I understand. Doing the steps above will allow the built artifact to run in either AS 7.0 or 7.1. Correct? I thought we had said on IRC that Hibernate could really get away with (1) and (2) and that JBoss AS 7.0 could specify to use JBoss Logging 3.0 via dep-mgmt in its pom(s) rather than allowing Hibernate (or others) to pull in Logging 3.1. On Wed 09 Nov 2011 02:32:11 PM CST, David M. Lloyd wrote: > OK folks. I've pushed out jboss-logging 3.1.0.CR1 and > jboss-logging-tools 1.0.0.CR4. > > Here's what you need to do. > > 0. Update your dep versions (obviously) > 1. Add the following switch to your annotation processing step (or to > javac if it's combined): -AloggingVersion=3.0 > 2. Build your artifacts against jboss-logging 3.1.0.CR1. > 3. When you publish the POMs for artifacts built this way, you may > specify jboss-logging 3.0.0.GA as the required version, and it will be > compatible with such. > > Basically what you're doing with the -AloggingVersion=3.0 flag is > generating larger classes in exchange for backwards compatibility. If > you develop other frameworks which are not expected to be supported on > AS 7.0 (for example), you do not need this flag (logging version 3.1 > is required in this case). > > If this doesn't solve your issues please let me know right away. > > On 11/09/2011 08:47 AM, David M. Lloyd wrote: >> Yeah, the problem was that to *implement* BasicLogger we had switched to >> using a base class (bundled in 3.1) to implement the multitude of >> methods, due to problems associated with generating all the >> implementations in every class. >> >> On 11/09/2011 08:39 AM, Steve Ebersole wrote: >>> Ok, I am totally confused then. I thought this was a discussion about >>> BasicLogger. But we have been using that afaik way before our recent >>> upgrade to 3.1 >>> >>> On Wed 09 Nov 2011 08:23:33 AM CST, David M. Lloyd wrote: >>>> On 11/09/2011 08:22 AM, Hardy Ferentschik wrote: >>>>> On Wed, 09 Nov 2011 15:00:07 +0100, Steve Ebersole >>>>> <steve(a)hibernate.org&gt; >>>>> wrote: >>>>> >>>>>> Maybe instead of "shading in" the removed class you could just >>>>>> add it >>>>>> back to the JBoss Logging codebase? >>>>> >>>>> Right, why can we not do that? >>>> >>>> You have it backwards. We didn't *remove* a class, we *added* one - >>>> which makes it not present in 3.0.x. >>>> >>>>>> On 11/09/2011 04:48 AM, Emmanuel Bernard wrote: >>>>>>> I see a few outputs >>>>>>> >>>>>>> - JBoss Logging 3.1.0.Final is released in the next 24h and we >>>>>>> use it >>>>>>> in Core and Search >>>>> >>>>> What's stopping a 3.1.0.Final release? >>>> >>>> Trying to resolve this issue for you guys. >>>> >>>> >>> >> >> > >

Chill out man :) Just making sure everyone know the ramifications and intentions. On Wed 09 Nov 2011 02:43:43 PM CST, David M. Lloyd wrote: > Yup, that's correct. And yeah #3 is optional which is why I said "may". > > On 11/09/2011 02:38 PM, Steve Ebersole wrote: >> Thanks David! >> >> Just to make sure I understand. Doing the steps above will allow the >> built artifact to run in either AS 7.0 or 7.1. Correct? >> >> I thought we had said on IRC that Hibernate could really get away with >> (1) and (2) and that JBoss AS 7.0 could specify to use JBoss Logging 3.0 >> via dep-mgmt in its pom(s) rather than allowing Hibernate (or others) to >> pull in Logging 3.1. >> >> On Wed 09 Nov 2011 02:32:11 PM CST, David M. Lloyd wrote: >>> OK folks. I've pushed out jboss-logging 3.1.0.CR1 and >>> jboss-logging-tools 1.0.0.CR4. >>> >>> Here's what you need to do. >>> >>> 0. Update your dep versions (obviously) >>> 1. Add the following switch to your annotation processing step (or to >>> javac if it's combined): -AloggingVersion=3.0 >>> 2. Build your artifacts against jboss-logging 3.1.0.CR1. >>> 3. When you publish the POMs for artifacts built this way, you may >>> specify jboss-logging 3.0.0.GA as the required version, and it will be >>> compatible with such. >>> >>> Basically what you're doing with the -AloggingVersion=3.0 flag is >>> generating larger classes in exchange for backwards compatibility. If >>> you develop other frameworks which are not expected to be supported on >>> AS 7.0 (for example), you do not need this flag (logging version 3.1 >>> is required in this case). >>> >>> If this doesn't solve your issues please let me know right away. >>> >>> On 11/09/2011 08:47 AM, David M. Lloyd wrote: >>>> Yeah, the problem was that to *implement* BasicLogger we had >>>> switched to >>>> using a base class (bundled in 3.1) to implement the multitude of >>>> methods, due to problems associated with generating all the >>>> implementations in every class. >>>> >>>> On 11/09/2011 08:39 AM, Steve Ebersole wrote: >>>>> Ok, I am totally confused then. I thought this was a discussion about >>>>> BasicLogger. But we have been using that afaik way before our recent >>>>> upgrade to 3.1 >>>>> >>>>> On Wed 09 Nov 2011 08:23:33 AM CST, David M. Lloyd wrote: >>>>>> On 11/09/2011 08:22 AM, Hardy Ferentschik wrote: >>>>>>> On Wed, 09 Nov 2011 15:00:07 +0100, Steve Ebersole >>>>>>> <steve(a)hibernate.org&gt; >>>>>>> wrote: >>>>>>> >>>>>>>> Maybe instead of "shading in" the removed class you could just >>>>>>>> add it >>>>>>>> back to the JBoss Logging codebase? >>>>>>> >>>>>>> Right, why can we not do that? >>>>>> >>>>>> You have it backwards. We didn't *remove* a class, we *added* one - >>>>>> which makes it not present in 3.0.x. >>>>>> >>>>>>>> On 11/09/2011 04:48 AM, Emmanuel Bernard wrote: >>>>>>>>> I see a few outputs >>>>>>>>> >>>>>>>>> - JBoss Logging 3.1.0.Final is released in the next 24h and we >>>>>>>>> use it >>>>>>>>> in Core and Search >>>>>>> >>>>>>> What's stopping a 3.1.0.Final release? >>>>>> >>>>>> Trying to resolve this issue for you guys. >>>>>> >>>>>> >>>>> >>>> >>>> >>> >>> >> > > -- steve(a)hibernate.org http://hibernate.org _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

From: "Strong Liu" <stliu(a)hibernate.org&gt; To: "Sanne Grinovero" <sanne(a)hibernate.org&gt; Cc: "James Perkins" <jperkins(a)redhat.com&gt;, hibernate-dev(a)lists.jboss.org, "David M. Lloyd" <david.lloyd(a)redhat.com&gt; Sent: Monday, November 14, 2011 1:30:40 AM Subject: Re: [hibernate-dev] [jboss-as7-dev] Which JBoss Logging version to use in AS and Hibernate Core after pull all changes, I get a logging issue :( if i run a test in IDE (IntelliJ), the log output are all like this: 17:20:31,767 DEBUG AbstractEntityPersister:576 - org.hibernate.internal.CoreMessageLogger_$logger 17:20:31,768 DEBUG AbstractEntityPersister:576 - org.hibernate.internal.CoreMessageLogger_$logger 17:20:31,768 DEBUG AbstractEntityPersister:576 - org.hibernate.internal.CoreMessageLogger_$logger 17:20:31,768 DEBUG AbstractEntityPersister:581 - org.hibernate.internal.CoreMessageLogger_$logger 17:20:31,768 DEBUG AbstractEntityPersister:581 - org.hibernate.internal.CoreMessageLogger_$logger 17:20:31,769 DEBUG AbstractEntityPersister:581 - org.hibernate.internal.CoreMessageLogger_$logger 17:20:31,769 DEBUG AbstractCollectionPersister:576 - org.hibernate.internal.CoreMessageLogger_$logger 17:20:31,769 DEBUG AbstractCollectionPersister:576 - org.hibernate.internal.CoreMessageLogger_$logger 17:20:31,769 DEBUG AbstractCollectionPersister:576 - org.hibernate.internal.CoreMessageLogger_$logger 17:20:31,770 DEBUG AbstractCollectionPersister:576 - org.hibernate.internal.CoreMessageLogger_$logger 17:20:31,770 DEBUG AbstractCollectionPersister:576 - org.hibernate.internal.CoreMessageLogger_$logger but it is fine if I run it from command line p.s. I have updated to the latest source and 'gradle cleanIdea idea clean test', so the dependencies in IDE are update-to-date and the generated source as well any idea or am i missing some configuration here? ------------------------- Best Regards, Strong Liu <stliu at hibernate.org> http://about.me/stliu/bio On Nov 10, 2011, at 5:35 AM, Sanne Grinovero wrote: > Awesome! > just verified on both Hibernate Search and Infinispan, no issues > spotted ! > > thanks a lot, > Sanne > > > On 9 November 2011 21:29, Steve Ebersole <steve(a)hibernate.org&gt; > wrote: >> Chill out man :) >> >> Just making sure everyone know the ramifications and intentions. >> >> On Wed 09 Nov 2011 02:43:43 PM CST, David M. Lloyd wrote: >>> Yup, that's correct. And yeah #3 is optional which is why I said >>> "may". >>> >>> On 11/09/2011 02:38 PM, Steve Ebersole wrote: >>>> Thanks David! >>>> >>>> Just to make sure I understand. Doing the steps above will allow >>>> the >>>> built artifact to run in either AS 7.0 or 7.1. Correct? >>>> >>>> I thought we had said on IRC that Hibernate could really get >>>> away with >>>> (1) and (2) and that JBoss AS 7.0 could specify to use JBoss >>>> Logging 3.0 >>>> via dep-mgmt in its pom(s) rather than allowing Hibernate (or >>>> others) to >>>> pull in Logging 3.1. >>>> >>>> On Wed 09 Nov 2011 02:32:11 PM CST, David M. Lloyd wrote: >>>>> OK folks. I've pushed out jboss-logging 3.1.0.CR1 and >>>>> jboss-logging-tools 1.0.0.CR4. >>>>> >>>>> Here's what you need to do. >>>>> >>>>> 0. Update your dep versions (obviously) >>>>> 1. Add the following switch to your annotation processing step >>>>> (or to >>>>> javac if it's combined): -AloggingVersion=3.0 >>>>> 2. Build your artifacts against jboss-logging 3.1.0.CR1. >>>>> 3. When you publish the POMs for artifacts built this way, you >>>>> may >>>>> specify jboss-logging 3.0.0.GA as the required version, and it >>>>> will be >>>>> compatible with such. >>>>> >>>>> Basically what you're doing with the -AloggingVersion=3.0 flag >>>>> is >>>>> generating larger classes in exchange for backwards >>>>> compatibility. If >>>>> you develop other frameworks which are not expected to be >>>>> supported on >>>>> AS 7.0 (for example), you do not need this flag (logging >>>>> version 3.1 >>>>> is required in this case). >>>>> >>>>> If this doesn't solve your issues please let me know right >>>>> away. >>>>> >>>>> On 11/09/2011 08:47 AM, David M. Lloyd wrote: >>>>>> Yeah, the problem was that to *implement* BasicLogger we had >>>>>> switched to >>>>>> using a base class (bundled in 3.1) to implement the multitude >>>>>> of >>>>>> methods, due to problems associated with generating all the >>>>>> implementations in every class. >>>>>> >>>>>> On 11/09/2011 08:39 AM, Steve Ebersole wrote: >>>>>>> Ok, I am totally confused then. I thought this was a >>>>>>> discussion about >>>>>>> BasicLogger. But we have been using that afaik way before our >>>>>>> recent >>>>>>> upgrade to 3.1 >>>>>>> >>>>>>> On Wed 09 Nov 2011 08:23:33 AM CST, David M. Lloyd wrote: >>>>>>>> On 11/09/2011 08:22 AM, Hardy Ferentschik wrote: >>>>>>>>> On Wed, 09 Nov 2011 15:00:07 +0100, Steve Ebersole >>>>>>>>> <steve(a)hibernate.org&gt; >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Maybe instead of "shading in" the removed class you could >>>>>>>>>> just >>>>>>>>>> add it >>>>>>>>>> back to the JBoss Logging codebase? >>>>>>>>> >>>>>>>>> Right, why can we not do that? >>>>>>>> >>>>>>>> You have it backwards. We didn't *remove* a class, we >>>>>>>> *added* one - >>>>>>>> which makes it not present in 3.0.x. >>>>>>>> >>>>>>>>>> On 11/09/2011 04:48 AM, Emmanuel Bernard wrote: >>>>>>>>>>> I see a few outputs >>>>>>>>>>> >>>>>>>>>>> - JBoss Logging 3.1.0.Final is released in the next 24h >>>>>>>>>>> and we >>>>>>>>>>> use it >>>>>>>>>>> in Core and Search >>>>>>>>> >>>>>>>>> What's stopping a 3.1.0.Final release? >>>>>>>> >>>>>>>> Trying to resolve this issue for you guys. >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> >> >> -- >> steve(a)hibernate.org >> http://hibernate.org >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

after pull all changes, I get a logging issue :( if i run a test in IDE (IntelliJ), the log output are all like this: 17:20:31,767 DEBUG AbstractEntityPersister:576 - org.hibernate.internal.CoreMessageLogger_$logger 17:20:31,768 DEBUG AbstractEntityPersister:576 - org.hibernate.internal.CoreMessageLogger_$logger 17:20:31,768 DEBUG AbstractEntityPersister:576 - org.hibernate.internal.CoreMessageLogger_$logger 17:20:31,768 DEBUG AbstractEntityPersister:581 - org.hibernate.internal.CoreMessageLogger_$logger 17:20:31,768 DEBUG AbstractEntityPersister:581 - org.hibernate.internal.CoreMessageLogger_$logger 17:20:31,769 DEBUG AbstractEntityPersister:581 - org.hibernate.internal.CoreMessageLogger_$logger 17:20:31,769 DEBUG AbstractCollectionPersister:576 - org.hibernate.internal.CoreMessageLogger_$logger 17:20:31,769 DEBUG AbstractCollectionPersister:576 - org.hibernate.internal.CoreMessageLogger_$logger 17:20:31,769 DEBUG AbstractCollectionPersister:576 - org.hibernate.internal.CoreMessageLogger_$logger 17:20:31,770 DEBUG AbstractCollectionPersister:576 - org.hibernate.internal.CoreMessageLogger_$logger 17:20:31,770 DEBUG AbstractCollectionPersister:576 - org.hibernate.internal.CoreMessageLogger_$logger but it is fine if I run it from command line p.s. I have updated to the latest source and 'gradle cleanIdea idea clean test', so the dependencies in IDE are update-to-date and the generated source as well any idea or am i missing some configuration here? ------------------------- Best Regards, Strong Liu <stliu at hibernate.org <http://hibernate.org>> http://about.me/stliu/bio On Nov 10, 2011, at 5:35 AM, Sanne Grinovero wrote: > Awesome! > just verified on both Hibernate Search and Infinispan, no issues spotted ! > > thanks a lot, > Sanne > > > On 9 November 2011 21:29, Steve Ebersole <steve(a)hibernate.org > <mailto:steve@hibernate.org>> wrote: >> Chill out man :) >> >> Just making sure everyone know the ramifications and intentions. >> >> On Wed 09 Nov 2011 02:43:43 PM CST, David M. Lloyd wrote: >>> Yup, that's correct. And yeah #3 is optional which is why I said "may". >>> >>> On 11/09/2011 02:38 PM, Steve Ebersole wrote: >>>> Thanks David! >>>> >>>> Just to make sure I understand. Doing the steps above will allow the >>>> built artifact to run in either AS 7.0 or 7.1. Correct? >>>> >>>> I thought we had said on IRC that Hibernate could really get away with >>>> (1) and (2) and that JBoss AS 7.0 could specify to use JBoss >>>> Logging 3.0 >>>> via dep-mgmt in its pom(s) rather than allowing Hibernate (or >>>> others) to >>>> pull in Logging 3.1. >>>> >>>> On Wed 09 Nov 2011 02:32:11 PM CST, David M. Lloyd wrote: >>>>> OK folks. I've pushed out jboss-logging 3.1.0.CR1 and >>>>> jboss-logging-tools 1.0.0.CR4. >>>>> >>>>> Here's what you need to do. >>>>> >>>>> 0. Update your dep versions (obviously) >>>>> 1. Add the following switch to your annotation processing step (or to >>>>> javac if it's combined): -AloggingVersion=3.0 >>>>> 2. Build your artifacts against jboss-logging 3.1.0.CR1. >>>>> 3. When you publish the POMs for artifacts built this way, you may >>>>> specify jboss-logging 3.0.0.GA as the required version, and it will be >>>>> compatible with such. >>>>> >>>>> Basically what you're doing with the -AloggingVersion=3.0 flag is >>>>> generating larger classes in exchange for backwards compatibility. If >>>>> you develop other frameworks which are not expected to be supported on >>>>> AS 7.0 (for example), you do not need this flag (logging version 3.1 >>>>> is required in this case). >>>>> >>>>> If this doesn't solve your issues please let me know right away. >>>>> >>>>> On 11/09/2011 08:47 AM, David M. Lloyd wrote: >>>>>> Yeah, the problem was that to *implement* BasicLogger we had >>>>>> switched to >>>>>> using a base class (bundled in 3.1) to implement the multitude of >>>>>> methods, due to problems associated with generating all the >>>>>> implementations in every class. >>>>>> >>>>>> On 11/09/2011 08:39 AM, Steve Ebersole wrote: >>>>>>> Ok, I am totally confused then. I thought this was a discussion >>>>>>> about >>>>>>> BasicLogger. But we have been using that afaik way before our recent >>>>>>> upgrade to 3.1 >>>>>>> >>>>>>> On Wed 09 Nov 2011 08:23:33 AM CST, David M. Lloyd wrote: >>>>>>>> On 11/09/2011 08:22 AM, Hardy Ferentschik wrote: >>>>>>>>> On Wed, 09 Nov 2011 15:00:07 +0100, Steve Ebersole >>>>>>>>> <steve(a)hibernate.org <mailto:steve@hibernate.org>> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Maybe instead of "shading in" the removed class you could just >>>>>>>>>> add it >>>>>>>>>> back to the JBoss Logging codebase? >>>>>>>>> >>>>>>>>> Right, why can we not do that? >>>>>>>> >>>>>>>> You have it backwards. We didn't *remove* a class, we *added* one - >>>>>>>> which makes it not present in 3.0.x. >>>>>>>> >>>>>>>>>> On 11/09/2011 04:48 AM, Emmanuel Bernard wrote: >>>>>>>>>>> I see a few outputs >>>>>>>>>>> >>>>>>>>>>> - JBoss Logging 3.1.0.Final is released in the next 24h and we >>>>>>>>>>> use it >>>>>>>>>>> in Core and Search >>>>>>>>> >>>>>>>>> What's stopping a 3.1.0.Final release? >>>>>>>> >>>>>>>> Trying to resolve this issue for you guys. >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> >> >> -- >> steve(a)hibernate.org <mailto:steve@hibernate.org> >> http://hibernate.org >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev(a)lists.jboss.org <mailto:hibernate-dev@lists.jboss.org> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org <mailto:hibernate-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/hibernate-dev

On Nov 14, 2011, at 11:16 PM, David M. Lloyd wrote: > Can you tell me: > > 1. What logging backend are you using? (log4j?) yes, log4j, see below slf4jVersion = "1.6.1" // logging for testing slf4j_api: 'org.slf4j:slf4j-api:' + slf4jVersion, slf4j_log4j12: 'org.slf4j:slf4j-log4j12:' + slf4jVersion, jcl_slf4j: 'org.slf4j:jcl-over-slf4j:' + slf4jVersion, jcl_api: 'commons-logging:commons-logging-api:99.0-does-not-exist', jcl: 'commons-logging:commons-logging:99.0-does-not-exist', > 2. Are the file/line numbers correct? > file is correct, but line numbers are not > Thanks. My suspicion is that it's a (well, another) problem in the > log4j backend. > > On 11/14/2011 03:30 AM, Strong Liu wrote: >> after pull all changes, I get a logging issue :( >> >> if i run a test in IDE (IntelliJ), the log output are all like this: >> >> 17:20:31,767 DEBUG AbstractEntityPersister:576 - >> org.hibernate.internal.CoreMessageLogger_$logger >> 17:20:31,768 DEBUG AbstractEntityPersister:576 - >> org.hibernate.internal.CoreMessageLogger_$logger >> 17:20:31,768 DEBUG AbstractEntityPersister:576 - >> org.hibernate.internal.CoreMessageLogger_$logger >> 17:20:31,768 DEBUG AbstractEntityPersister:581 - >> org.hibernate.internal.CoreMessageLogger_$logger >> 17:20:31,768 DEBUG AbstractEntityPersister:581 - >> org.hibernate.internal.CoreMessageLogger_$logger >> 17:20:31,769 DEBUG AbstractEntityPersister:581 - >> org.hibernate.internal.CoreMessageLogger_$logger >> 17:20:31,769 DEBUG AbstractCollectionPersister:576 - >> org.hibernate.internal.CoreMessageLogger_$logger >> 17:20:31,769 DEBUG AbstractCollectionPersister:576 - >> org.hibernate.internal.CoreMessageLogger_$logger >> 17:20:31,769 DEBUG AbstractCollectionPersister:576 - >> org.hibernate.internal.CoreMessageLogger_$logger >> 17:20:31,770 DEBUG AbstractCollectionPersister:576 - >> org.hibernate.internal.CoreMessageLogger_$logger >> 17:20:31,770 DEBUG AbstractCollectionPersister:576 - >> org.hibernate.internal.CoreMessageLogger_$logger >> >> >> but it is fine if I run it from command line >> >> p.s. I have updated to the latest source and 'gradle cleanIdea idea >> clean test', so the dependencies in IDE are update-to-date and the >> generated source as well >> >> any idea or am i missing some configuration here? >> >> ------------------------- >> Best Regards, >> >> Strong Liu <stliu at hibernate.org <http://hibernate.org> >> <http://hibernate.org>> >> http://about.me/stliu/bio >> >> On Nov 10, 2011, at 5:35 AM, Sanne Grinovero wrote: >> >>> Awesome! >>> just verified on both Hibernate Search and Infinispan, no issues >>> spotted ! >>> >>> thanks a lot, >>> Sanne >>> >>> >>> On 9 November 2011 21:29, Steve Ebersole <steve(a)hibernate.org >>> <mailto:steve@hibernate.org> >>> <mailto:steve@hibernate.org>> wrote: >>>> Chill out man :) >>>> >>>> Just making sure everyone know the ramifications and intentions. >>>> >>>> On Wed 09 Nov 2011 02:43:43 PM CST, David M. Lloyd wrote: >>>>> Yup, that's correct. And yeah #3 is optional which is why I said >>>>> "may". >>>>> >>>>> On 11/09/2011 02:38 PM, Steve Ebersole wrote: >>>>>> Thanks David! >>>>>> >>>>>> Just to make sure I understand. Doing the steps above will allow the >>>>>> built artifact to run in either AS 7.0 or 7.1. Correct? >>>>>> >>>>>> I thought we had said on IRC that Hibernate could really get away >>>>>> with >>>>>> (1) and (2) and that JBoss AS 7.0 could specify to use JBoss >>>>>> Logging 3.0 >>>>>> via dep-mgmt in its pom(s) rather than allowing Hibernate (or >>>>>> others) to >>>>>> pull in Logging 3.1. >>>>>> >>>>>> On Wed 09 Nov 2011 02:32:11 PM CST, David M. Lloyd wrote: >>>>>>> OK folks. I've pushed out jboss-logging 3.1.0.CR1 and >>>>>>> jboss-logging-tools 1.0.0.CR4. >>>>>>> >>>>>>> Here's what you need to do. >>>>>>> >>>>>>> 0. Update your dep versions (obviously) >>>>>>> 1. Add the following switch to your annotation processing step >>>>>>> (or to >>>>>>> javac if it's combined): -AloggingVersion=3.0 >>>>>>> 2. Build your artifacts against jboss-logging 3.1.0.CR1. >>>>>>> 3. When you publish the POMs for artifacts built this way, you may >>>>>>> specify jboss-logging 3.0.0.GA as the required version, and it >>>>>>> will be >>>>>>> compatible with such. >>>>>>> >>>>>>> Basically what you're doing with the -AloggingVersion=3.0 flag is >>>>>>> generating larger classes in exchange for backwards >>>>>>> compatibility. If >>>>>>> you develop other frameworks which are not expected to be >>>>>>> supported on >>>>>>> AS 7.0 (for example), you do not need this flag (logging version 3.1 >>>>>>> is required in this case). >>>>>>> >>>>>>> If this doesn't solve your issues please let me know right away. >>>>>>> >>>>>>> On 11/09/2011 08:47 AM, David M. Lloyd wrote: >>>>>>>> Yeah, the problem was that to *implement* BasicLogger we had >>>>>>>> switched to >>>>>>>> using a base class (bundled in 3.1) to implement the multitude of >>>>>>>> methods, due to problems associated with generating all the >>>>>>>> implementations in every class. >>>>>>>> >>>>>>>> On 11/09/2011 08:39 AM, Steve Ebersole wrote: >>>>>>>>> Ok, I am totally confused then. I thought this was a discussion >>>>>>>>> about >>>>>>>>> BasicLogger. But we have been using that afaik way before our >>>>>>>>> recent >>>>>>>>> upgrade to 3.1 >>>>>>>>> >>>>>>>>> On Wed 09 Nov 2011 08:23:33 AM CST, David M. Lloyd wrote: >>>>>>>>>> On 11/09/2011 08:22 AM, Hardy Ferentschik wrote: >>>>>>>>>>> On Wed, 09 Nov 2011 15:00:07 +0100, Steve Ebersole >>>>>>>>>>> <steve(a)hibernate.org <mailto:steve@hibernate.org> >>>>>>>>>>> <mailto:steve@hibernate.org>> >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> Maybe instead of "shading in" the removed class you could just >>>>>>>>>>>> add it >>>>>>>>>>>> back to the JBoss Logging codebase? >>>>>>>>>>> >>>>>>>>>>> Right, why can we not do that? >>>>>>>>>> >>>>>>>>>> You have it backwards. We didn't *remove* a class, we *added* >>>>>>>>>> one - >>>>>>>>>> which makes it not present in 3.0.x. >>>>>>>>>> >>>>>>>>>>>> On 11/09/2011 04:48 AM, Emmanuel Bernard wrote: >>>>>>>>>>>>> I see a few outputs >>>>>>>>>>>>> >>>>>>>>>>>>> - JBoss Logging 3.1.0.Final is released in the next 24h and we >>>>>>>>>>>>> use it >>>>>>>>>>>>> in Core and Search >>>>>>>>>>> >>>>>>>>>>> What's stopping a 3.1.0.Final release? >>>>>>>>>> >>>>>>>>>> Trying to resolve this issue for you guys. >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> >>>> -- >>>> steve(a)hibernate.org <mailto:steve@hibernate.org> >>>> <mailto:steve@hibernate.org> >>>> http://hibernate.org >>>> _______________________________________________ >>>> hibernate-dev mailing list >>>> hibernate-dev(a)lists.jboss.org >>>> <mailto:hibernate-dev@lists.jboss.org> >>>> <mailto:hibernate-dev@lists.jboss.org> >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>> >>> _______________________________________________ >>> hibernate-dev mailing list >>> hibernate-dev(a)lists.jboss.org <mailto:hibernate-dev@lists.jboss.org> >>> <mailto:hibernate-dev@lists.jboss.org> >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > > > -- > - DML

David, the fix works :) ------------------------- Best Regards, Strong Liu <stliu at hibernate.org <http://hibernate.org>> http://about.me/stliu/bio On Nov 15, 2011, at 1:53 AM, David M. Lloyd wrote: > I may have a fix. Is there any way you can check out and install the > latest jboss-logging-tools, and try to recompile with that and see if > the issue still exists? > > On 11/14/2011 09:23 AM, Strong Liu wrote: >> >> >> On Nov 14, 2011, at 11:16 PM, David M. Lloyd wrote: >> >>> Can you tell me: >>> >>> 1. What logging backend are you using? (log4j?) >> >> yes, log4j, see below >> slf4jVersion = "1.6.1" >> // logging for testing >> slf4j_api: 'org.slf4j:slf4j-api:' + slf4jVersion, >> slf4j_log4j12: 'org.slf4j:slf4j-log4j12:' + slf4jVersion, >> jcl_slf4j: 'org.slf4j:jcl-over-slf4j:' + slf4jVersion, >> jcl_api: 'commons-logging:commons-logging-api:99.0-does-not-exist', >> jcl: 'commons-logging:commons-logging:99.0-does-not-exist', >> >>> 2. Are the file/line numbers correct? >>> >> >> file is correct, but line numbers are not >> >> >>> Thanks. My suspicion is that it's a (well, another) problem in the >>> log4j backend. >>> >>> On 11/14/2011 03:30 AM, Strong Liu wrote: >>>> after pull all changes, I get a logging issue :( >>>> >>>> if i run a test in IDE (IntelliJ), the log output are all like this: >>>> >>>> 17:20:31,767 DEBUG AbstractEntityPersister:576 - >>>> org.hibernate.internal.CoreMessageLogger_$logger >>>> 17:20:31,768 DEBUG AbstractEntityPersister:576 - >>>> org.hibernate.internal.CoreMessageLogger_$logger >>>> 17:20:31,768 DEBUG AbstractEntityPersister:576 - >>>> org.hibernate.internal.CoreMessageLogger_$logger >>>> 17:20:31,768 DEBUG AbstractEntityPersister:581 - >>>> org.hibernate.internal.CoreMessageLogger_$logger >>>> 17:20:31,768 DEBUG AbstractEntityPersister:581 - >>>> org.hibernate.internal.CoreMessageLogger_$logger >>>> 17:20:31,769 DEBUG AbstractEntityPersister:581 - >>>> org.hibernate.internal.CoreMessageLogger_$logger >>>> 17:20:31,769 DEBUG AbstractCollectionPersister:576 - >>>> org.hibernate.internal.CoreMessageLogger_$logger >>>> 17:20:31,769 DEBUG AbstractCollectionPersister:576 - >>>> org.hibernate.internal.CoreMessageLogger_$logger >>>> 17:20:31,769 DEBUG AbstractCollectionPersister:576 - >>>> org.hibernate.internal.CoreMessageLogger_$logger >>>> 17:20:31,770 DEBUG AbstractCollectionPersister:576 - >>>> org.hibernate.internal.CoreMessageLogger_$logger >>>> 17:20:31,770 DEBUG AbstractCollectionPersister:576 - >>>> org.hibernate.internal.CoreMessageLogger_$logger >>>> >>>> >>>> but it is fine if I run it from command line >>>> >>>> p.s. I have updated to the latest source and 'gradle cleanIdea idea >>>> clean test', so the dependencies in IDE are update-to-date and the >>>> generated source as well >>>> >>>> any idea or am i missing some configuration here? >>>> >>>> ------------------------- >>>> Best Regards, >>>> >>>> Strong Liu <stliu at hibernate.org <http://hibernate.org> >>>> <http://hibernate.org> >>>> <http://hibernate.org>> >>>> http://about.me/stliu/bio >>>> >>>> On Nov 10, 2011, at 5:35 AM, Sanne Grinovero wrote: >>>> >>>>> Awesome! >>>>> just verified on both Hibernate Search and Infinispan, no issues >>>>> spotted ! >>>>> >>>>> thanks a lot, >>>>> Sanne >>>>> >>>>> >>>>> On 9 November 2011 21:29, Steve Ebersole <steve(a)hibernate.org >>>>> <mailto:steve@hibernate.org> >>>>> <mailto:steve@hibernate.org> >>>>> <mailto:steve@hibernate.org>> wrote: >>>>>> Chill out man :) >>>>>> >>>>>> Just making sure everyone know the ramifications and intentions. >>>>>> >>>>>> On Wed 09 Nov 2011 02:43:43 PM CST, David M. Lloyd wrote: >>>>>>> Yup, that's correct. And yeah #3 is optional which is why I said >>>>>>> "may". >>>>>>> >>>>>>> On 11/09/2011 02:38 PM, Steve Ebersole wrote: >>>>>>>> Thanks David! >>>>>>>> >>>>>>>> Just to make sure I understand. Doing the steps above will >>>>>>>> allow the >>>>>>>> built artifact to run in either AS 7.0 or 7.1. Correct? >>>>>>>> >>>>>>>> I thought we had said on IRC that Hibernate could really get away >>>>>>>> with >>>>>>>> (1) and (2) and that JBoss AS 7.0 could specify to use JBoss >>>>>>>> Logging 3.0 >>>>>>>> via dep-mgmt in its pom(s) rather than allowing Hibernate (or >>>>>>>> others) to >>>>>>>> pull in Logging 3.1. >>>>>>>> >>>>>>>> On Wed 09 Nov 2011 02:32:11 PM CST, David M. Lloyd wrote: >>>>>>>>> OK folks. I've pushed out jboss-logging 3.1.0.CR1 and >>>>>>>>> jboss-logging-tools 1.0.0.CR4. >>>>>>>>> >>>>>>>>> Here's what you need to do. >>>>>>>>> >>>>>>>>> 0. Update your dep versions (obviously) >>>>>>>>> 1. Add the following switch to your annotation processing step >>>>>>>>> (or to >>>>>>>>> javac if it's combined): -AloggingVersion=3.0 >>>>>>>>> 2. Build your artifacts against jboss-logging 3.1.0.CR1. >>>>>>>>> 3. When you publish the POMs for artifacts built this way, you may >>>>>>>>> specify jboss-logging 3.0.0.GA as the required version, and it >>>>>>>>> will be >>>>>>>>> compatible with such. >>>>>>>>> >>>>>>>>> Basically what you're doing with the -AloggingVersion=3.0 flag is >>>>>>>>> generating larger classes in exchange for backwards >>>>>>>>> compatibility. If >>>>>>>>> you develop other frameworks which are not expected to be >>>>>>>>> supported on >>>>>>>>> AS 7.0 (for example), you do not need this flag (logging >>>>>>>>> version 3.1 >>>>>>>>> is required in this case). >>>>>>>>> >>>>>>>>> If this doesn't solve your issues please let me know right away. >>>>>>>>> >>>>>>>>> On 11/09/2011 08:47 AM, David M. Lloyd wrote: >>>>>>>>>> Yeah, the problem was that to *implement* BasicLogger we had >>>>>>>>>> switched to >>>>>>>>>> using a base class (bundled in 3.1) to implement the multitude of >>>>>>>>>> methods, due to problems associated with generating all the >>>>>>>>>> implementations in every class. >>>>>>>>>> >>>>>>>>>> On 11/09/2011 08:39 AM, Steve Ebersole wrote: >>>>>>>>>>> Ok, I am totally confused then. I thought this was a discussion >>>>>>>>>>> about >>>>>>>>>>> BasicLogger. But we have been using that afaik way before our >>>>>>>>>>> recent >>>>>>>>>>> upgrade to 3.1 >>>>>>>>>>> >>>>>>>>>>> On Wed 09 Nov 2011 08:23:33 AM CST, David M. Lloyd wrote: >>>>>>>>>>>> On 11/09/2011 08:22 AM, Hardy Ferentschik wrote: >>>>>>>>>>>>> On Wed, 09 Nov 2011 15:00:07 +0100, Steve Ebersole >>>>>>>>>>>>> <steve(a)hibernate.org <mailto:steve@hibernate.org> >>>>>>>>>>>>> <mailto:steve@hibernate.org> >>>>>>>>>>>>> <mailto:steve@hibernate.org>> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Maybe instead of "shading in" the removed class you could >>>>>>>>>>>>>> just >>>>>>>>>>>>>> add it >>>>>>>>>>>>>> back to the JBoss Logging codebase? >>>>>>>>>>>>> >>>>>>>>>>>>> Right, why can we not do that? >>>>>>>>>>>> >>>>>>>>>>>> You have it backwards. We didn't *remove* a class, we *added* >>>>>>>>>>>> one - >>>>>>>>>>>> which makes it not present in 3.0.x. >>>>>>>>>>>> >>>>>>>>>>>>>> On 11/09/2011 04:48 AM, Emmanuel Bernard wrote: >>>>>>>>>>>>>>> I see a few outputs >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> - JBoss Logging 3.1.0.Final is released in the next 24h >>>>>>>>>>>>>>> and we >>>>>>>>>>>>>>> use it >>>>>>>>>>>>>>> in Core and Search >>>>>>>>>>>>> >>>>>>>>>>>>> What's stopping a 3.1.0.Final release? >>>>>>>>>>>> >>>>>>>>>>>> Trying to resolve this issue for you guys. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> -- >>>>>> steve(a)hibernate.org <mailto:steve@hibernate.org> >>>>>> <mailto:steve@hibernate.org> >>>>>> <mailto:steve@hibernate.org> >>>>>> http://hibernate.org >>>>>> _______________________________________________ >>>>>> hibernate-dev mailing list >>>>>> hibernate-dev(a)lists.jboss.org <mailto:hibernate-dev@lists.jboss.org> >>>>>> <mailto:hibernate-dev@lists.jboss.org> >>>>>> <mailto:hibernate-dev@lists.jboss.org> >>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>>> >>>>> _______________________________________________ >>>>> hibernate-dev mailing list >>>>> hibernate-dev(a)lists.jboss.org >>>>> <mailto:hibernate-dev@lists.jboss.org> >>>>> <mailto:hibernate-dev@lists.jboss.org> >>>>> <mailto:hibernate-dev@lists.jboss.org> >>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>> >>> >>> >>> -- >>> - DML >> > > > -- > - DML