Re: [hibernate-dev] [jboss-as7-dev] Which JBoss Logging version to use in AS and Hibernate Core
rmLoadClassChecked(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.(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.(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 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 Bernardwrote: >>>> >>>> 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: >>>>>>> >>>>>>
Re: [hibernate-dev] [jboss-as7-dev] Which JBoss Logging version to use in AS and Hibernate Core
On 11/07/2011 02:45 PM, Sanne Grinovero wrote: > Wouldn't it be easier to have us build with Logger 3.0.x ? Yes, however it would also fail because as it turns out, 3.0.x doesn't contain the annotations and classes required by the current CR of the logging processor. The annotations shouldn't be a problem but that missing base class is going to be an issue. Unfortunately I just wasn't thinking about compatibility with 7.0 when I made that call. > 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. However as I said it's a pretty crappy solution because I guarantee at least an hour or two of POM fiddling to get it right anyway. That's per project. > What about including the missing class only as a provided dependency, > to be used with older AS versions? Assuming that would work with the > older Logger implementation; also this might be quite messy for the > users. There might be a split package problem if we did, unless we were to move it to another package (hence the shading idea). And yeah that's pretty ugly for users too. > Regarding the idea of inlining the class.. not sure how that would > look like. Ideally the goal would be to have Hibernate 4 work properly > on both AS 7.0 and 7.1, and possibly on future versions too; if that > solves the issue then why not. It would solve that. It's just a bit of a coding challenge on this end. And I don't like the resultant *large* classes, but I guess at this point that's something we'll just have to live with. I think this is going to be the only viable solution. > Let me know if there is any experimental branch that I could try out. Will do. Hopefully I'll get a bit of quiet after I "passivate" my kids to "stable storage" and I'll have some sort of solution by morning. -- - DML ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [jboss-as7-dev] Which JBoss Logging version to use in AS and Hibernate Core
On 11/09/2011 08:22 AM, Hardy Ferentschik wrote: > On Wed, 09 Nov 2011 15:00:07 +0100, Steve Ebersole > 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. -- - DML ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [jboss-as7-dev] Which JBoss Logging version to use in AS and Hibernate Core
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 >>> 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. >> >> > -- - DML ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [jboss-as7-dev] Which JBoss Logging version to use in AS and Hibernate Core
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 >>>> >>>> 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. >>> >>> >> > > -- - DML ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [jboss-as7-dev] Which JBoss Logging version to use in AS and Hibernate Core
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 >>>>>> >>>>>> 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. >>>>> >>>>> >>>> >>> >>> >> >> > -- - DML ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [jboss-as7-dev] Which JBoss Logging version to use in AS and Hibernate Core
Can you tell me: 1. What logging backend are you using? (log4j?) 2. Are the file/line numbers correct? 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 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 > <mailto:st...@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 t
Re: [hibernate-dev] [jboss-as7-dev] Which JBoss Logging version to use in AS and Hibernate Core
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 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 >>> <mailto:st...@hibernate.org> >>>> <mailto:st...@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. >&g
Re: [hibernate-dev] [jboss-as7-dev] Which JBoss Logging version to use in AS and Hibernate Core
Pushed out 1.0.0.CR5. Thanks for verifying! On 11/14/2011 08:53 PM, Strong Liu wrote: > David, > > the fix works :) > > - > Best Regards, > > Strong Liu 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 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 >>>>> <mailto:st...@hibernate.org> >>>>>> <mailto:st...@hibernate.org> >>>>>> <mailto:st...@hibernate.org>> wrote: >>>>>>> Chill out man :) >>>>&g
Re: [hibernate-dev] Building with debug/trace log level
Can you send us (off-list) a copy of the CoreMessageLogger interface along with the generated CoreMessageLogger_$logger class? Thanks. 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 -- - DML ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Building with debug/trace log level
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 -- - DML ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] on broken usage of logger
The solution is really easy guys:
log.debugf("The thing I want to log is %s", thing);
or
log.debug(thing)
In addition, as you have noticed, it is better to not use the formatting
variants if you aren't actually formatting any strings (it doesn't make
a difference if the message isn't logged, but if it is there is a slight
performance boost).
As for error handling, yes, I think we should be doing somewhat better
at that. Normally this is handled by the internal logging layer but
with the variations on they types of backends and the ways they are
invoked, we should probably put this protection in at the front end as
well. I would accept a JBLOGGING JIRA to this effect.
On 11/23/2011 04:49 AM, Hardy Ferentschik wrote:
> Hi,
>
> this revives my email from Friday
> (http://lists.jboss.org/pipermail/hibernate-dev/2011-November/007307.html)
> where I noticed this problem as well.
>
> Generally speaking Sanne is of course right and the right logging method
> should be used,
> but does the logging framework really have to propagate the exception
> thrown by String.format?
>
> I don't think it has to. I don't think that logging should cause an
> application to die.
> Couldn't the Logger just catch the exception and write out the
> unformatted message optionally
> followed by an additional warning?
>
> --Hardy
>
>
>
> On Wed, 23 Nov 2011 11:34:29 +0100, Sanne Grinovero
> wrote:
>
>> Hi all,
>> I'm having a chat with Hardy about how we used the Logger in some
>> cases, and it turns out there's some confusion about
>>
>> log.debugf vs log.debug
>> log.tracef vs log.trace
>>
>> So the "F" variant is needed when we want to format a message, in this
>> case we should make sure the number of parameters matches exactly.
>>
>> Also when the string is generated, like in the case of:
>>
>> https://github.com/Sanne/hibernate-core/commit/3c5f8a568de99c7a6532647ab7b08c12738762ec#L36L485
>>
>>
>> it's very important that we do NOT use the formatting method, but just
>> a plain "log.debug( string )", otherwise it might happen at runtime
>> that the dynamically generated string contains some characters which
>> the String formatter might want interpret as placeholders, which are
>> missing. (HHH-6817)
>>
>> In practice, it seems like a bad idea to allow a dynamically generated
>> formatting string at all; formatting strings as defined on the Logger
>> interface are safer;
>>
>> In case a dynamically generated message is to be generated, we should
>> all make sure to pick the correct method signature; we're wondering if
>> there could be a reasonable proposal to make the checks of the
>> annotation processor stricter and validate for this, but there are
>> some (rare) valid use cases so just throwing compilation errors would
>> be nasty.
>>
>> Sanne
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
--
- DML
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] AS7-4007 missing Infinispan dependency for clustered JPA second level cache
On 03/06/2012 09:21 AM, Galder Zamarreño wrote: > This reminds me that we had a discussion about this a few months back: > http://goo.gl/DJLhB > > At the time, it wasn't clear whether you can use ModularClassResolver in a > non-module env. Seems like it's not possible. > > So, one option is to have a class resolver lookup class, or similar so that > AS7 can pass us the right ClassResolver. > > There might a quicker option here though: > - Extend VersionAwareMarshaller (http://goo.gl/bu8CF) and provide a variant > of JBossMarshaller (http://goo.gl/o9Ro3) in Infinispan (this requires > JBossMarshaller to be made non-final) > - Override JBossMarshaller.inject(), call super.inject() and then call > baseCfg.setClassResolver(…) > - This would require that the VersionAwareMarshaller extension be passed the > ModuleLoader that ModularClassResolver requires. > - Configure Infinispan with this new marshaller, via > SerializationConfiguration. Thankfully you can now pass an instance of the > marshaller to it, so no need to do any magic ModuleLoader lookup from the > VersionAwareMarshaller extension. > > Scott, other than the change in JBossMarshaller to be made non-final, the > rest can built on AS7. Wanna have a go? Ping me on IRC if you need help. > > Cheers, > > p.s. Silly question, how come this issue is not present in HTTP session > replication use case or EJB3 SFSB? It actually is present anywhere we're using Infinispan (I think). It just hasn't blown up yet anywhere public (in this case it's a 90% effective solution versus a 100% effective solution). > > On Mar 5, 2012, at 11:07 PM, Scott Marlow wrote: > >> Galder, >> >> I'm trying to identify the right fix for addressing AS7-4007. I started a >> clustered second level cache test that currently fails since Infinispan >> isn't on the test application classpath. >> >> The exception call stack that I'm getting is shown here >> http://pastie.org/3503803. >> >> I would like to discuss how we can address AS7-4007 (either on email or IRC). >> >> Initially, I worked around this by ensuring that the infinispan module is >> available in the test application classpath >> (https://github.com/jbossas/jboss-as/commit/31f3547960775dac88275447253fdae942f952b9#L0R40). >> The hack was to export the Infinispan module when the Hibernate module is >> brought into an application. This covered both JPA and Hibernate native >> applications, however it exports into every other module that references the >> Hibernate module (increasing the time that it takes to link the Hibernate >> module into other modules). There are other problems with requiring >> Infinipan to be in the application classpath (see >> https://community.jboss.org/wiki/ModularSerialization). >> >> I would like to better understand the alternatives (both short term and long >> term) to address AS7-4007 and issues like it. Perhaps by using >> MarshallingConfiguration.setClassResolver() to pass a ModuleClassResolver to >> be used with Infinispan marshalling/unmarshalling. Is that currently >> configurable with Infinispan? >> >> Paul Ferraro, David Lloyd and myself chatted on irc briefly about this a few >> days ago (see http://pastie.org/3528553). >> >> https://github.com/dmlloyd/jboss-marshalling/blob/master/api/src/main/java/org/jboss/marshalling/ModularClassResolver.java >> contains the source for the ModularClassResolver class that David referred >> to (as well as the ModularSerialization article linked above). >> >> Scott > > -- > Galder Zamarreño > Sr. Software Engineer > Infinispan, JBoss Cache > -- - DML ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [jboss-as7-dev] AS7-4007 missing Infinispan dependency for clustered JPA second level cache
On 03/06/2012 01:02 PM, Galder Zamarreño wrote: > On Mar 6, 2012, at 6:31 PM, Paul Ferraro wrote: >> - Original Message - >>> From: "Jason T. Greene" >>> To: "David M. Lloyd" >>> Cc: "Galder Zamarreño", "Paul >>> Ferraro", "Bela Ban", >>> "infinispan -Dev List", >>> hibernate-dev@lists.jboss.org, >>> "jboss-as7-...@lists.jboss.org Development" >>> Sent: Tuesday, March 6, 2012 10:30:11 AM >>> Subject: Re: [jboss-as7-dev] AS7-4007 missing Infinispan dependency for >>> clustered JPA second level cache >>> >>> On 3/6/12 9:28 AM, David M. Lloyd wrote: >>>> On 03/06/2012 09:21 AM, Galder Zamarreño wrote: >>>>> This reminds me that we had a discussion about this a few months >>>>> back: http://goo.gl/DJLhB >>>>> >>>>> At the time, it wasn't clear whether you can use >>>>> ModularClassResolver in a non-module env. Seems like it's not >>>>> possible. >>>>> >>>>> So, one option is to have a class resolver lookup class, or >>>>> similar so that AS7 can pass us the right ClassResolver. >>>>> >>>>> There might a quicker option here though: >>>>> - Extend VersionAwareMarshaller (http://goo.gl/bu8CF) and provide >>>>> a variant of JBossMarshaller (http://goo.gl/o9Ro3) in Infinispan >>>>> (this requires JBossMarshaller to be made non-final) >>>>> - Override JBossMarshaller.inject(), call super.inject() and then >>>>> call baseCfg.setClassResolver(…) >>>>> - This would require that the VersionAwareMarshaller extension be >>>>> passed the ModuleLoader that ModularClassResolver requires. >>>>> - Configure Infinispan with this new marshaller, via >>>>> SerializationConfiguration. Thankfully you can now pass an >>>>> instance of the marshaller to it, so no need to do any magic >>>>> ModuleLoader lookup from the VersionAwareMarshaller extension. >>>>> >>>>> Scott, other than the change in JBossMarshaller to be made >>>>> non-final, the rest can built on AS7. Wanna have a go? Ping me on >>>>> IRC if you need help. >>>>> >>>>> Cheers, >>>>> >>>>> p.s. Silly question, how come this issue is not present in HTTP >>>>> session replication use case or EJB3 SFSB? >>>> >>>> It actually is present anywhere we're using Infinispan (I think). >>>> It >>>> just hasn't blown up yet anywhere public (in this case it's a 90% >>>> effective solution versus a 100% effective solution). >>> >>> Session replication does setup a custom marshaller, so it does in >>> fact >>> work. I think the issue is just that the hibernate-infinispan, which >>> is >>> part of the hibernate project set, and not AS code does not do this, >>> and >>> it doesn't expose a way to do it. >> >> Sort of... >> >> To summarize: >> The fundamental issue is that Infinispan uses the same marshaller instance >> for all caches within a cache manager - which doesn't map cleanly to our use >> case, which uses a cache instance per application - thus requires >> cache-grained marshalling configuration. > > Well, this is not exactly correct since 5.0. Internally, we differentiate > between a global marshaller and a per-cache marshaller. What's the > difference? The classloader with which they're configured. > > Since 5.0, you can configure the classloader to use per cache. You can even > configure the classloader per invocation with cache.with(cl)…. > > If that's not helping you, we were wasting our time when we did this... Well :) (see below) > >> To work around this, we typically store MarshalledValues in the cache - >> which are marshalled/unmarshalled using a marshalling configuration specific >> to the application (e.g. via a ModularClassResolver using the ModuleLoader >> of the deployment unit). >> https://github.com/jbossas/jboss-as/blob/master/clustering/api/src/main/java/org/jboss/as/clustering/MarshalledValue.java >> https://github.com/jbossas/jboss-as/blob/master/clustering/api/src/main/java/org/jboss/as/clustering/SimpleMarshalledValue.java >> https://github.com/jbossas/jboss-as/blob/master/clustering/api/src/main/java/org/jboss/as/clustering/HashableMarshalledValue.java > > Isn't a class
Re: [hibernate-dev] [infinispan-dev] [jboss-as7-dev] AS7-4007 missing Infinispan dependency for clustered JPA second level cache
On 03/06/2012 01:27 PM, Galder Zamarreño wrote: > (***) I still don't fully understand how web apps don't have the same issue > as 2LC of not seeing Infinispan classes (Reminder: we're not talking about > the contents of the cache, but about the Infinispan classes themselves). It's possible that someone saw the exception and said to themselves, "oh... well I'll just add Infinispan to all web apps", and then the patch slipped by the code review process. Other problems will continue to lurk beneath the surface though. -- - DML ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
