From guillaume.smet at gmail.com Wed Jan 2 10:34:21 2019 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Wed, 2 Jan 2019 16:34:21 +0100 Subject: [hibernate-dev] [ORM] Reducing startup log verbosity Message-ID: Hi, Got a report from a fellow Red Hatter complaining about our logging verbosity being so 2004 and, well, I must admit I tend to agree. This is from a launch on a simple PostgreSQL app. I added some comments inline. Note that it might seem like wasting our time but I would like to improve the user experience in some contexts - happy to discuss the rationale behing this discussion privately if needed. [o.h.Version] (build-) HHH000412: Hibernate Core {5.4.0.Final} -> this one is a product requirement so let's keep it as is for now, hopefully, we will have a global solution for that at some point [o.h.c.Environment] (build-) HHH000206: hibernate.properties not found -> I think we should use DEBUG here, framework nowadays rely on their own config injection mechanisms [o.h.b.e.s.Enhancer] (pool-2-thread-6) Enhancing [jpa.SequencedAddress] as Entity [o.h.b.e.s.Enhancer] (pool-2-thread-10) Enhancing [jpa.WorkAddress] as Composite [o.h.b.e.s.Enhancer] (pool-2-thread-1) Enhancing [jpa.Address] as Composite [o.h.b.e.s.Enhancer] (pool-2-thread-8) Extended enhancement of [jpa.Animal] [o.h.b.e.s.Enhancer] (pool-2-thread-13) Enhancing [jpa.Human] as MappedSuperclass [o.h.b.e.s.Enhancer] (pool-2-thread-16) Enhancing [jpa.Person] as Entity [o.h.b.e.s.Enhancer] (pool-2-thread-5) Enhancing [jpa.Customer] as Entity -> I would vote for using DEBUG. Let's imagine a 250 entities model and I think we can agree we don't want it to be logged by default. [o.h.j.i.u.LogHelper] (main) HHH000204: Processing PersistenceUnitInfo [ name: templatePU ...] -> so, first, I would make this one a one liner as we apparently didn't add any other properties. I think it was done to mimic the DEBUG output but I don't see any value to having it on several lines. And, frankly, I think I would get rid of it altogether and only log something at debug level. [o.h.a.c.Version] (main) HCANN000001: Hibernate Commons Annotations {5.1.0.Final} -> version, can't touch it for now. [o.h.d.Dialect] (main) HHH000400: Using dialect: org.hibernate.dialect.PostgreSQL95Dialect -> wondering if it has any value to log the dialect? I mean if you don't use the right one, you will definitely have some issues. [o.h.e.j.e.i.LobCreatorBuilderImpl] (main) HHH000422: Disabling contextual LOB creation as connection was null -> I would move that to DEBUG. [o.h.t.BasicTypeRegistry] (main) HHH000270: Type registration [java.util.UUID] overrides previous : org.hibernate.type.UUIDBinaryType at 7e8dcdaa -> as I understand it, we will always have this message at startup when using PostgreSQL. I think we should make it DEBUG too. Or find another solution for this specific case but having it logged on each PostgreSQL app is definitely a bad thing. [o.h.e.t.j.p.i.JtaPlatformInitiator] (main) HHH000490: Using JtaPlatform implementation: [org.hibernate.engine.transaction.jta.platform.internal.JBossStandAloneJtaPlatform] -> This one, I don't know. It's probably important to know that JTA is properly configured but I'm not terribly excited about keeping it. Thoughts? Maybe one solution could be to have all these ones tied to a "org.hibernate.bootstrap" logger and thus have the ability to enable them in one go. I heard you made nice things in 6 about logging but I would like to improve the situation in the stable version. I would like to move quickly on this and hopefully integrate it in the upcoming 5.4.1 so feedback very welcome! If some are polemic, I will just work on the easy ones, that would still improve the situation. Thanks! -- Guillaume From steve at hibernate.org Thu Jan 3 10:29:00 2019 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 3 Jan 2019 09:29:00 -0600 Subject: [hibernate-dev] [ORM] Reducing startup log verbosity In-Reply-To: References: Message-ID: In general I agree with everything you said, but had a few specific comments in line... > [o.h.j.i.u.LogHelper] (main) HHH000204: Processing PersistenceUnitInfo [ > name: templatePU > ...] > > -> so, first, I would make this one a one liner as we apparently didn't add > any other properties. I think it was done to mimic the DEBUG output but I > don't see any value to having it on several lines. > > And, frankly, I think I would get rid of it altogether and only log > something at debug level. > +1 to dropping the INFO one altogether. However, I think we should keep the DEBUG one and it should remain multi-line. I could not tell if you were saying the same wrt DEBUG. [o.h.d.Dialect] (main) HHH000400: Using dialect: > org.hibernate.dialect.PostgreSQL95Dialect > > -> wondering if it has any value to log the dialect? I mean if you don't > use the right one, you will definitely have some issues. > True, but it is probably hard(er) to interpret the true source of the issues later on. However, I think it is reasonable to make this DEBUG. If you have problems the first reasonable thing to do is to crank logging to DEBUG if not TRACE. [o.h.e.t.j.p.i.JtaPlatformInitiator] (main) HHH000490: Using JtaPlatform > implementation: > > [org.hibernate.engine.transaction.jta.platform.internal.JBossStandAloneJtaPlatform] > > -> This one, I don't know. It's probably important to know that JTA is > properly configured but I'm not terribly excited about keeping it. > Thoughts? > I think we agree here if I understand you correctly - a simple "JTA integration enabled" message is fine for the bootstrap INFO logging. But then it is kind of awkward to have 2 messages next to each other - the INFO saying JTA integration was enabled and then a DEBUG message saying which > > Maybe one solution could be to have all these ones tied to a > "org.hibernate.bootstrap" logger and thus have the ability to enable them > in one go. > I heard you made nice things in 6 about logging but I would like to improve > the situation in the stable version. > The specific changes on 6 are more what you mention. I break down each "subsystem" into a dedicated message-logger. The overall idea is to split the intended audience targeted by the messages into 2 groups. "Message logs" are more intended for users and DEBUG/TRACE logs are intended for developers (or "power users"). Message loggers use a different "logger name" scheme not based on class/package names but more of a symbolic subsystem name. E.g., from `org.hibernate.cache.spi.SecondLevelCacheLogger`[1], I grouped all caching related messages using the logger name `org.hibernate.orm.cache`. The reason is two-fold... First it is refactor-safe which is great given the intended audience. Secondly it allows for a more logical hierarchy of logger names. Also it groups all ORM-related logging under a single name, as opposed to having to use `org.hibernate` which affects logging for all Hibernate projects being used. `BootstrapLogger` was one I intended on doing as well already. This is all an on-going process as a task of opportunity, meaning I am doing that conversion as I work in the subsystem. Personally I think it does not make sense to make such changes in 5.4 though. Cleaning up the INFO->DEBUG stuff discussed above makes sense, I just mean re-organizing the loggers/names. [1] https://github.com/hibernate/hibernate-orm/blob/wip/6.0/hibernate-core/src/main/java/org/hibernate/cache/spi/SecondLevelCacheLogger.java > > I would like to move quickly on this and hopefully integrate it in the > upcoming 5.4.1 so feedback very welcome! If some are polemic, I will just > work on the easy ones, that would still improve the situation. > > Thanks! > > -- > Guillaume > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From guillaume.smet at gmail.com Thu Jan 3 16:36:52 2019 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Thu, 3 Jan 2019 22:36:52 +0100 Subject: [hibernate-dev] SAP HANA build failing for a while - does it reveal a bug? Message-ID: Hi, Since this build http://ci.hibernate.org/view/ORM/job/hibernate-orm-master-hana-main/688/ , the SAP HANA build is failing consistently. With a lot of tests failing with: Caused by: org.hibernate.MappingException: Unable to build insert statement for table [Employee]: SAP HANA requires at least one value in insert value-list clause. at org.hibernate.sql.Insert.toStatementString(Insert.java:104) at org.hibernate.persister.entity.AbstractEntityPersister.generateIdentityInsertString(AbstractEntityPersister.java:2826) at org.hibernate.persister.entity.AbstractEntityPersister.doLateInit(AbstractEntityPersister.java:4147) at org.hibernate.persister.entity.AbstractEntityPersister.postInstantiate(AbstractEntityPersister.java:4220) at org.hibernate.metamodel.internal.MetamodelImpl.initialize(MetamodelImpl.java:257) at org.hibernate.internal.SessionFactoryImpl.(SessionFactoryImpl.java:294) at org.hibernate.boot.internal.SessionFactoryBuilderImpl.build(SessionFactoryBuilderImpl.java:462) at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:938) I wonder if we have broken something because I wouldn't expect so many tests to end with an empty insert? Could someone more familiar with these tests take a look at it? I don't think we need SAP HANA to check for the empty INSERT issue. Thanks. -- Guillaume From jonathan.bregler at sap.com Thu Jan 3 17:25:01 2019 From: jonathan.bregler at sap.com (Bregler, Jonathan) Date: Thu, 3 Jan 2019 22:25:01 +0000 Subject: [hibernate-dev] SAP HANA build failing for a while - does it reveal a bug? In-Reply-To: References: Message-ID: Hi, These test failures are caused by the fix for https://hibernate.atlassian.net/browse/HHH-13104. There is some discussion in the ticket around how to best fix the test failures. Vlad has already opened a PR: https://github.com/hibernate/hibernate-orm/pull/2705 Best, Jonathan -----Original Message----- From: hibernate-dev-bounces at lists.jboss.org On Behalf Of Guillaume Smet Sent: Thursday, January 3, 2019 10:37 PM To: Hibernate Subject: [hibernate-dev] SAP HANA build failing for a while - does it reveal a bug? Hi, Since this build http://ci.hibernate.org/view/ORM/job/hibernate-orm-master-hana-main/688/ , the SAP HANA build is failing consistently. With a lot of tests failing with: Caused by: org.hibernate.MappingException: Unable to build insert statement for table [Employee]: SAP HANA requires at least one value in insert value-list clause. at org.hibernate.sql.Insert.toStatementString(Insert.java:104) at org.hibernate.persister.entity.AbstractEntityPersister.generateIdentityInsertString(AbstractEntityPersister.java:2826) at org.hibernate.persister.entity.AbstractEntityPersister.doLateInit(AbstractEntityPersister.java:4147) at org.hibernate.persister.entity.AbstractEntityPersister.postInstantiate(AbstractEntityPersister.java:4220) at org.hibernate.metamodel.internal.MetamodelImpl.initialize(MetamodelImpl.java:257) at org.hibernate.internal.SessionFactoryImpl.(SessionFactoryImpl.java:294) at org.hibernate.boot.internal.SessionFactoryBuilderImpl.build(SessionFactoryBuilderImpl.java:462) at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:938) I wonder if we have broken something because I wouldn't expect so many tests to end with an empty insert? Could someone more familiar with these tests take a look at it? I don't think we need SAP HANA to check for the empty INSERT issue. Thanks. -- Guillaume _______________________________________________ hibernate-dev mailing list hibernate-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev From guillaume.smet at gmail.com Thu Jan 3 17:43:15 2019 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Thu, 3 Jan 2019 23:43:15 +0100 Subject: [hibernate-dev] SAP HANA build failing for a while - does it reveal a bug? In-Reply-To: References: Message-ID: Ah OK, thanks, totally missed that this PR was there to fix these test failures. Let's wait for Chris to be back then. On Thu, Jan 3, 2019 at 11:25 PM Bregler, Jonathan wrote: > Hi, > > These test failures are caused by the fix for > https://hibernate.atlassian.net/browse/HHH-13104. There is some > discussion in the ticket around how to best fix the test failures. > > Vlad has already opened a PR: > https://github.com/hibernate/hibernate-orm/pull/2705 > > Best, > Jonathan > > -----Original Message----- > From: hibernate-dev-bounces at lists.jboss.org < > hibernate-dev-bounces at lists.jboss.org> On Behalf Of Guillaume Smet > Sent: Thursday, January 3, 2019 10:37 PM > To: Hibernate > Subject: [hibernate-dev] SAP HANA build failing for a while - does it > reveal a bug? > > Hi, > > Since this build > http://ci.hibernate.org/view/ORM/job/hibernate-orm-master-hana-main/688/ , > the SAP HANA build is failing consistently. > > With a lot of tests failing with: > Caused by: org.hibernate.MappingException: Unable to build insert statement > for table [Employee]: SAP HANA requires at least one value in insert > value-list clause. > at org.hibernate.sql.Insert.toStatementString(Insert.java:104) > at > > org.hibernate.persister.entity.AbstractEntityPersister.generateIdentityInsertString(AbstractEntityPersister.java:2826) > at > > org.hibernate.persister.entity.AbstractEntityPersister.doLateInit(AbstractEntityPersister.java:4147) > at > > org.hibernate.persister.entity.AbstractEntityPersister.postInstantiate(AbstractEntityPersister.java:4220) > at > > org.hibernate.metamodel.internal.MetamodelImpl.initialize(MetamodelImpl.java:257) > at > > org.hibernate.internal.SessionFactoryImpl.(SessionFactoryImpl.java:294) > at > > org.hibernate.boot.internal.SessionFactoryBuilderImpl.build(SessionFactoryBuilderImpl.java:462) > at > > org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:938) > > I wonder if we have broken something because I wouldn't expect so many > tests to end with an empty insert? > > Could someone more familiar with these tests take a look at it? I don't > think we need SAP HANA to check for the empty INSERT issue. > > Thanks. > > -- > Guillaume > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From rory.odonnell at oracle.com Fri Jan 4 05:15:25 2019 From: rory.odonnell at oracle.com (Rory O'Donnell) Date: Fri, 4 Jan 2019 10:15:25 +0000 Subject: [hibernate-dev] JDK 12 Early Access build 26 & JDK 13 Early Access builds available Message-ID: <39de2b8b-a360-7295-ee73-ae2cb1df3eab@oracle.com> Hi Sanne, Happy New Year! *OpenJDK builds *- JDK 12 Early Access build 26 is available at http://jdk.java.net/12/ * These early-access, open-source builds are provided under the GNU General Public License, version?2, with the Classpath Exception . * Changes since last email o Distrust TLS server certificates anchored by Symantec Root CAs (JDK-8207258 ) o Customizing the generation of a PKCS12 keystore (JDK-8076190 ) o Compact Number Formatting Support (JDK-8177552 ) *OpenJDK builds *- JDK 13 - Early Access build 2 is available at http://jdk.java.net/13/ * These early-access, open-source builds are provided under the GNU General Public License, version?2, with the Classpath Exception . * Changes in this build *jpackage EA builds* * This is an early access build of JEP 343: Packaging Tool , aimed at testing a prototype implementation of jpackage, which is a new tool for packaging self-contained Java applications along with a Java Runtime Environment. * Please send feedback via e-mail to core-libs-dev at openjdk.java.net *Quality Outreach report for December 2018* * The report for December 2018 is available here Rgds,Rory -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland From guillaume.smet at gmail.com Sat Jan 5 16:40:37 2019 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Sat, 5 Jan 2019 22:40:37 +0100 Subject: [hibernate-dev] Still an issue with Agroal when closing the pool Message-ID: Hi Luis, We talked at some point about a potential issue in Agroal, you said 1.3 should have all the known issues solved but apparently, there is still one as we have transient test failures on ORM from time to time. A good example is the following one: http://ci.hibernate.org/view/ORM/job/hibernate-orm-master-h2-javassist/lastCompletedBuild/testReport/org.hibernate.test.agroal/AgroalTransactionIsolationConfigTest/testSettingIsolationAsName/ (it's build #265, haven't found a way to get a stable URL from Jenkins) The issue is in this test: org.hibernate.test.agroal.AgroalTransactionIsolationConfigTest.testSettingIsolationAsName . And we have the following stacktrace when closing the pool: java.util.concurrent.RejectedExecutionException: Task java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask at 189a0b8e rejected from io.agroal.pool.util.PriorityScheduledExecutor at 2ded5d2e[Shutting down, pool size = 1, active threads = 0, queued tasks = 1, completed tasks = 2] at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2063) at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:830) at java.util.concurrent.ScheduledThreadPoolExecutor.delayedExecute(ScheduledThreadPoolExecutor.java:326) at java.util.concurrent.ScheduledThreadPoolExecutor.schedule(ScheduledThreadPoolExecutor.java:533) at java.util.concurrent.ScheduledThreadPoolExecutor.execute(ScheduledThreadPoolExecutor.java:622) at io.agroal.pool.util.PriorityScheduledExecutor.executeNow(PriorityScheduledExecutor.java:46) at io.agroal.pool.util.PriorityScheduledExecutor.executeNow(PriorityScheduledExecutor.java:35) at io.agroal.pool.util.PriorityScheduledExecutor.shutdown(PriorityScheduledExecutor.java:67) at io.agroal.pool.ConnectionPool.close(ConnectionPool.java:126) at io.agroal.pool.DataSource.close(DataSource.java:54) at org.hibernate.agroal.internal.AgroalConnectionProvider.stop(AgroalConnectionProvider.java:142) at org.hibernate.testing.common.connections.BaseTransactionIsolationConfigTest.testSettingIsolationAsName(BaseTransactionIsolationConfigTest.java:101) It happens once in a while. I already had the issue locally but lately I only observed it on CI. I suppose it won't be easy to get to the bottom of it but it would be nice if we could get this fixed. Thanks. -- Guillaume From guillaume.smet at hibernate.org Mon Jan 7 10:36:19 2019 From: guillaume.smet at hibernate.org (Guillaume Smet) Date: Mon, 7 Jan 2019 16:36:19 +0100 Subject: [hibernate-dev] Hibernate Validator 6.0.14.Final Message-ID: Hi, We just released Hibernate Validator 6.0.14.Final to fix an important issue reported by one of our users. This update is highly recommended and contains just a fix for this issue (+ a fix for the Dutch translation and an upgrade to WildFly 15 and 14.0.1 for the WildFly patches we generate). More information in the announcement: http://in.relation.to/2019/01/07/hibernate-validator-6014-final-out/ . Have a nice day. -- Guillaume From crancran at gmail.com Mon Jan 7 10:37:22 2019 From: crancran at gmail.com (Chris Cranford) Date: Mon, 7 Jan 2019 10:37:22 -0500 Subject: [hibernate-dev] inSession / inTransaction In-Reply-To: References: Message-ID: <730804b8-d881-01a9-ebbd-49349001d900@gmail.com> I have no objections to exposing them directly rather than being part of the test infrastructure. On 12/20/18 5:16 PM, Steve Ebersole wrote: > On Thu, Dec 20, 2018 at 1:33 PM Gunnar Morling wrote: > >> Hey, >> >> When discussing this before, there were some doubts about its actual >> usefulness in non-testing, real-world code. E.g. you'd typically >> interact with multiple DAOs/repositories etc. and would have to >> somehow pass the session to each of them. >> > I've written many non-trivial apps in my past that did not use > "DAO/repositories" etc. Not sure why we'd choose to not implement > something that is useful just because not everyone would use it. To me, if > something is repeatedly useful in writing tests... it tends to be > more-or-less generally useful. > > > One other thought is that inTransaction() should allow to return a result >> value. >> > An over-loaded form perhaps, yes I can see that - but non-returning is > valid as well. So maybe: > > public interface SessionFactory ... { > ... > void inSession(Consumer action); > void inTransaction(Consumer action); > void inTransaction(Session session, Consumer action); > > T inSession(Function action); > T inTransaction(Function action); > T inTransaction(Session session, Function action); > } > > and > > public interface Session ... { > void inTransaction(Consumer action); > > T inTransaction(Function action); > } > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From crancran at gmail.com Mon Jan 7 10:46:57 2019 From: crancran at gmail.com (Chris Cranford) Date: Mon, 7 Jan 2019 10:46:57 -0500 Subject: [hibernate-dev] [ORM] Reducing startup log verbosity In-Reply-To: References: Message-ID: <61e1e258-9f0e-90d8-1ab1-9f381f76c448@gmail.com> See below. On 1/3/19 10:29 AM, Steve Ebersole wrote: > [o.h.d.Dialect] (main) HHH000400: Using dialect: >> org.hibernate.dialect.PostgreSQL95Dialect >> >> -> wondering if it has any value to log the dialect? I mean if you don't >> use the right one, you will definitely have some issues. >> > True, but it is probably hard(er) to interpret the true source of the > issues later on. > > However, I think it is reasonable to make this DEBUG. If you have problems > the first reasonable thing to do is to crank logging to DEBUG if not TRACE. I completely agree. I think its reasonable to make it DEBUG/TRACE but I don't think I want to necessarily change it such that it is no longer included in log output at all.? Having it be included is a good first-line of defense on trying to resolve potential problems not only for us, but even for users who are doing their own debugging before reporting an issue; particularly if the error in question implies some Dialect configuration problem. From guillaume.smet at gmail.com Mon Jan 7 10:51:25 2019 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Mon, 7 Jan 2019 16:51:25 +0100 Subject: [hibernate-dev] [ORM] Reducing startup log verbosity In-Reply-To: <61e1e258-9f0e-90d8-1ab1-9f381f76c448@gmail.com> References: <61e1e258-9f0e-90d8-1ab1-9f381f76c448@gmail.com> Message-ID: Yeah sure, they will be kept as is just moved to DEBUG. The only one that would change is the "Processing PersistenceUnitInfo" thing: we will remove the INFO one and keep the more detailed DEBUG one. BTW, I agree with everything Steve said, sorry for not replying earlier. On Mon, Jan 7, 2019 at 4:46 PM Chris Cranford wrote: > See below. > > On 1/3/19 10:29 AM, Steve Ebersole wrote: > > [o.h.d.Dialect] (main) HHH000400: Using dialect: > >> org.hibernate.dialect.PostgreSQL95Dialect > >> > >> -> wondering if it has any value to log the dialect? I mean if you don't > >> use the right one, you will definitely have some issues. > >> > > True, but it is probably hard(er) to interpret the true source of the > > issues later on. > > > > However, I think it is reasonable to make this DEBUG. If you have > problems > > the first reasonable thing to do is to crank logging to DEBUG if not > TRACE. > > I completely agree. > > I think its reasonable to make it DEBUG/TRACE but I don't think I want > to necessarily change it such that it is no longer included in log > output at all. Having it be included is a good first-line of defense on > trying to resolve potential problems not only for us, but even for users > who are doing their own debugging before reporting an issue; > particularly if the error in question implies some Dialect configuration > problem. > From sanne at hibernate.org Wed Jan 9 08:23:33 2019 From: sanne at hibernate.org (Sanne Grinovero) Date: Wed, 9 Jan 2019 13:23:33 +0000 Subject: [hibernate-dev] [ORM] Reducing startup log verbosity In-Reply-To: References: <61e1e258-9f0e-90d8-1ab1-9f381f76c448@gmail.com> Message-ID: +1 to polish output, but: I don't want to need to figure out how to reconfigure whatever Logger of the day one happens to hit, to finally notice that essential configuration details are wrong. Mostly because it requires to get the idea to actually check this, which is not a straightforward thought when all you observe is some odd behaviour. Not least, big we don't want to have to go back to supported customers and community members who have a problem with a "can you change the log levels as I'm missing essential information": that's a huge waste of time especially if we're having an exchange across timezones. Could we rather collect essential info and then print it all out as a single message? "Hibernate ORM ready and operational! [version: 7.0.1.Final, Transaction mode: JTA, Dialect: PostgreSQL2020, Caching: enabled]" Also I'd question that "verbosity" isn't the same as brevity; the focus should be on hiding unnecessary technicalities but showing nicer / better information, so I'd not be shy to use some multi-line information box if that looks better. Thanks, Sanne On Mon, 7 Jan 2019 at 16:14, Guillaume Smet wrote: > > Yeah sure, they will be kept as is just moved to DEBUG. > > The only one that would change is the "Processing PersistenceUnitInfo" > thing: we will remove the INFO one and keep the more detailed DEBUG one. > > BTW, I agree with everything Steve said, sorry for not replying earlier. > > On Mon, Jan 7, 2019 at 4:46 PM Chris Cranford wrote: > > > See below. > > > > On 1/3/19 10:29 AM, Steve Ebersole wrote: > > > [o.h.d.Dialect] (main) HHH000400: Using dialect: > > >> org.hibernate.dialect.PostgreSQL95Dialect > > >> > > >> -> wondering if it has any value to log the dialect? I mean if you don't > > >> use the right one, you will definitely have some issues. > > >> > > > True, but it is probably hard(er) to interpret the true source of the > > > issues later on. > > > > > > However, I think it is reasonable to make this DEBUG. If you have > > problems > > > the first reasonable thing to do is to crank logging to DEBUG if not > > TRACE. > > > > I completely agree. > > > > I think its reasonable to make it DEBUG/TRACE but I don't think I want > > to necessarily change it such that it is no longer included in log > > output at all. Having it be included is a good first-line of defense on > > trying to resolve potential problems not only for us, but even for users > > who are doing their own debugging before reporting an issue; > > particularly if the error in question implies some Dialect configuration > > problem. > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From guillaume.smet at gmail.com Wed Jan 9 13:37:02 2019 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Wed, 9 Jan 2019 19:37:02 +0100 Subject: [hibernate-dev] [ORM] Reducing startup log verbosity In-Reply-To: References: <61e1e258-9f0e-90d8-1ab1-9f381f76c448@gmail.com> Message-ID: Pretty good idea but definitely too much work for the effort I want to put in it right now. But, yes, we can do that for version 7.0.1.Final, I like your example :). I will make a proposal to reduce the log verbosity (enhanced classes, hibernate.properties missing and a few others) but keep the important diagnostic information as is. On Wed, Jan 9, 2019 at 2:23 PM Sanne Grinovero wrote: > +1 to polish output, but: > > I don't want to need to figure out how to reconfigure whatever Logger > of the day one happens to hit, to finally notice that essential > configuration details are wrong. Mostly because it requires to get the > idea to actually check this, which is not a straightforward thought > when all you observe is some odd behaviour. > > Not least, big we don't want to have to go back to supported customers > and community members who have a problem with a "can you change the > log levels as I'm missing essential information": that's a huge waste > of time especially if we're having an exchange across timezones. > > Could we rather collect essential info and then print it all out as a > single message? > > "Hibernate ORM ready and operational! [version: 7.0.1.Final, > Transaction mode: JTA, Dialect: PostgreSQL2020, Caching: enabled]" > > Also I'd question that "verbosity" isn't the same as brevity; the > focus should be on hiding unnecessary technicalities but showing nicer > / better information, so I'd not be shy to use some multi-line > information box if that looks better. > > Thanks, > Sanne > > On Mon, 7 Jan 2019 at 16:14, Guillaume Smet > wrote: > > > > Yeah sure, they will be kept as is just moved to DEBUG. > > > > The only one that would change is the "Processing PersistenceUnitInfo" > > thing: we will remove the INFO one and keep the more detailed DEBUG one. > > > > BTW, I agree with everything Steve said, sorry for not replying earlier. > > > > On Mon, Jan 7, 2019 at 4:46 PM Chris Cranford > wrote: > > > > > See below. > > > > > > On 1/3/19 10:29 AM, Steve Ebersole wrote: > > > > [o.h.d.Dialect] (main) HHH000400: Using dialect: > > > >> org.hibernate.dialect.PostgreSQL95Dialect > > > >> > > > >> -> wondering if it has any value to log the dialect? I mean if you > don't > > > >> use the right one, you will definitely have some issues. > > > >> > > > > True, but it is probably hard(er) to interpret the true source of the > > > > issues later on. > > > > > > > > However, I think it is reasonable to make this DEBUG. If you have > > > problems > > > > the first reasonable thing to do is to crank logging to DEBUG if not > > > TRACE. > > > > > > I completely agree. > > > > > > I think its reasonable to make it DEBUG/TRACE but I don't think I want > > > to necessarily change it such that it is no longer included in log > > > output at all. Having it be included is a good first-line of defense > on > > > trying to resolve potential problems not only for us, but even for > users > > > who are doing their own debugging before reporting an issue; > > > particularly if the error in question implies some Dialect > configuration > > > problem. > > > > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From steve at hibernate.org Wed Jan 9 14:44:33 2019 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 9 Jan 2019 13:44:33 -0600 Subject: [hibernate-dev] [ORM] Reducing startup log verbosity In-Reply-To: References: <61e1e258-9f0e-90d8-1ab1-9f381f76c448@gmail.com> Message-ID: I disagree that logging a single message is a better solution because that probably ends up wrapping multiple lines, just as your sample happened to do in the email. IMO that is actually more difficult to read. And I just do not understand this idea that we have to direct people to enable logging to track down problems. This is a non-argument to me. As for what logger to use... that is definitely a concern, though its not really any different than we have today. If I refactor an internal class (because, well, its internal) - that almost always will affect logging on the user's end. It's one of the reasons I started looking at using "symbolic" logger names. Which of course is its own concern. On Wed, Jan 9, 2019 at 12:54 PM Guillaume Smet wrote: > Pretty good idea but definitely too much work for the effort I want to put > in it right now. > > But, yes, we can do that for version 7.0.1.Final, I like your example :). > > I will make a proposal to reduce the log verbosity (enhanced classes, > hibernate.properties missing and a few others) but keep the important > diagnostic information as is. > > On Wed, Jan 9, 2019 at 2:23 PM Sanne Grinovero > wrote: > > > +1 to polish output, but: > > > > I don't want to need to figure out how to reconfigure whatever Logger > > of the day one happens to hit, to finally notice that essential > > configuration details are wrong. Mostly because it requires to get the > > idea to actually check this, which is not a straightforward thought > > when all you observe is some odd behaviour. > > > > Not least, big we don't want to have to go back to supported customers > > and community members who have a problem with a "can you change the > > log levels as I'm missing essential information": that's a huge waste > > of time especially if we're having an exchange across timezones. > > > > Could we rather collect essential info and then print it all out as a > > single message? > > > > "Hibernate ORM ready and operational! [version: 7.0.1.Final, > > Transaction mode: JTA, Dialect: PostgreSQL2020, Caching: enabled]" > > > > Also I'd question that "verbosity" isn't the same as brevity; the > > focus should be on hiding unnecessary technicalities but showing nicer > > / better information, so I'd not be shy to use some multi-line > > information box if that looks better. > > > > Thanks, > > Sanne > > > > On Mon, 7 Jan 2019 at 16:14, Guillaume Smet > > wrote: > > > > > > Yeah sure, they will be kept as is just moved to DEBUG. > > > > > > The only one that would change is the "Processing PersistenceUnitInfo" > > > thing: we will remove the INFO one and keep the more detailed DEBUG > one. > > > > > > BTW, I agree with everything Steve said, sorry for not replying > earlier. > > > > > > On Mon, Jan 7, 2019 at 4:46 PM Chris Cranford > > wrote: > > > > > > > See below. > > > > > > > > On 1/3/19 10:29 AM, Steve Ebersole wrote: > > > > > [o.h.d.Dialect] (main) HHH000400: Using dialect: > > > > >> org.hibernate.dialect.PostgreSQL95Dialect > > > > >> > > > > >> -> wondering if it has any value to log the dialect? I mean if you > > don't > > > > >> use the right one, you will definitely have some issues. > > > > >> > > > > > True, but it is probably hard(er) to interpret the true source of > the > > > > > issues later on. > > > > > > > > > > However, I think it is reasonable to make this DEBUG. If you have > > > > problems > > > > > the first reasonable thing to do is to crank logging to DEBUG if > not > > > > TRACE. > > > > > > > > I completely agree. > > > > > > > > I think its reasonable to make it DEBUG/TRACE but I don't think I > want > > > > to necessarily change it such that it is no longer included in log > > > > output at all. Having it be included is a good first-line of defense > > on > > > > trying to resolve potential problems not only for us, but even for > > users > > > > who are doing their own debugging before reporting an issue; > > > > particularly if the error in question implies some Dialect > > configuration > > > > problem. > > > > > > > _______________________________________________ > > > hibernate-dev mailing list > > > hibernate-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From guillaume.smet at gmail.com Thu Jan 10 01:14:08 2019 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Thu, 10 Jan 2019 07:14:08 +0100 Subject: [hibernate-dev] Default access type and MappedSuperclass Message-ID: Hi, We recently had this issue opened about us not choosing the right access type for a mapped super class: https://hibernate.atlassian.net/browse/HHH-12938 . Hibernate currently base the access type decision on the sole placement of the @Id annotation, which, in the case of a @MappedSuperclass might not be defined (this is the OP's case). I closed the issue explaining what we do and pointing a workaround but the OP rightfully replied with the JPA spec saying "The default access type of an entity hierarchy is determined by the placement of mapping annotations on the attributes of the entity classes and mapped superclasses of the entity hierarchy that do not explicitly specify an access type". I'm wondering if we should also consider the @Column annotations placement if there is no @Id annotation. If the answer is that it's already fixed in 6, it's all good for me :). Thoughts? -- Guillaume From sanne at hibernate.org Thu Jan 10 05:19:43 2019 From: sanne at hibernate.org (Sanne Grinovero) Date: Thu, 10 Jan 2019 10:19:43 +0000 Subject: [hibernate-dev] [ORM] Reducing startup log verbosity In-Reply-To: References: <61e1e258-9f0e-90d8-1ab1-9f381f76c448@gmail.com> Message-ID: On Thu, 10 Jan 2019 at 01:44, Steve Ebersole wrote: > > I disagree that logging a single message is a better solution because that probably ends up wrapping multiple lines, just as your sample happened to do in the email. IMO that is actually more difficult to read. Ok keep it in one line if you prefer. No strong preference on how it's presented, but I think it's a big mistake to hide essential diagnostics: "paste the logs" is often useful when helping someone; it gets much harder if you first have to change categories. > And I just do not understand this idea that we have to direct people to enable logging to track down problems. This is a non-argument to me. I can understand were you're coming from, but that's how most support people work. Let's try to be nice to them :) > As for what logger to use... that is definitely a concern, though its not really any different than we have today. If I refactor an internal class (because, well, its internal) - that almost always will affect logging on the user's end. It's one of the reasons I started looking at using "symbolic" logger names. Which of course is its own concern. +1 those symbolic loggers are a great idea. But then please don't hide this information at least until we have those easier logger categories: Guillaume is set to patch 5.4x - which doesn't have them yet. Thanks, Sanne > > On Wed, Jan 9, 2019 at 12:54 PM Guillaume Smet wrote: >> >> Pretty good idea but definitely too much work for the effort I want to put >> in it right now. >> >> But, yes, we can do that for version 7.0.1.Final, I like your example :). >> >> I will make a proposal to reduce the log verbosity (enhanced classes, >> hibernate.properties missing and a few others) but keep the important >> diagnostic information as is. >> >> On Wed, Jan 9, 2019 at 2:23 PM Sanne Grinovero wrote: >> >> > +1 to polish output, but: >> > >> > I don't want to need to figure out how to reconfigure whatever Logger >> > of the day one happens to hit, to finally notice that essential >> > configuration details are wrong. Mostly because it requires to get the >> > idea to actually check this, which is not a straightforward thought >> > when all you observe is some odd behaviour. >> > >> > Not least, big we don't want to have to go back to supported customers >> > and community members who have a problem with a "can you change the >> > log levels as I'm missing essential information": that's a huge waste >> > of time especially if we're having an exchange across timezones. >> > >> > Could we rather collect essential info and then print it all out as a >> > single message? >> > >> > "Hibernate ORM ready and operational! [version: 7.0.1.Final, >> > Transaction mode: JTA, Dialect: PostgreSQL2020, Caching: enabled]" >> > >> > Also I'd question that "verbosity" isn't the same as brevity; the >> > focus should be on hiding unnecessary technicalities but showing nicer >> > / better information, so I'd not be shy to use some multi-line >> > information box if that looks better. >> > >> > Thanks, >> > Sanne >> > >> > On Mon, 7 Jan 2019 at 16:14, Guillaume Smet >> > wrote: >> > > >> > > Yeah sure, they will be kept as is just moved to DEBUG. >> > > >> > > The only one that would change is the "Processing PersistenceUnitInfo" >> > > thing: we will remove the INFO one and keep the more detailed DEBUG one. >> > > >> > > BTW, I agree with everything Steve said, sorry for not replying earlier. >> > > >> > > On Mon, Jan 7, 2019 at 4:46 PM Chris Cranford >> > wrote: >> > > >> > > > See below. >> > > > >> > > > On 1/3/19 10:29 AM, Steve Ebersole wrote: >> > > > > [o.h.d.Dialect] (main) HHH000400: Using dialect: >> > > > >> org.hibernate.dialect.PostgreSQL95Dialect >> > > > >> >> > > > >> -> wondering if it has any value to log the dialect? I mean if you >> > don't >> > > > >> use the right one, you will definitely have some issues. >> > > > >> >> > > > > True, but it is probably hard(er) to interpret the true source of the >> > > > > issues later on. >> > > > > >> > > > > However, I think it is reasonable to make this DEBUG. If you have >> > > > problems >> > > > > the first reasonable thing to do is to crank logging to DEBUG if not >> > > > TRACE. >> > > > >> > > > I completely agree. >> > > > >> > > > I think its reasonable to make it DEBUG/TRACE but I don't think I want >> > > > to necessarily change it such that it is no longer included in log >> > > > output at all. Having it be included is a good first-line of defense >> > on >> > > > trying to resolve potential problems not only for us, but even for >> > users >> > > > who are doing their own debugging before reporting an issue; >> > > > particularly if the error in question implies some Dialect >> > configuration >> > > > problem. >> > > > >> > > _______________________________________________ >> > > hibernate-dev mailing list >> > > hibernate-dev at lists.jboss.org >> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev From andrea at hibernate.org Thu Jan 10 06:44:37 2019 From: andrea at hibernate.org (andrea boriero) Date: Thu, 10 Jan 2019 11:44:37 +0000 Subject: [hibernate-dev] Default access type and MappedSuperclass In-Reply-To: References: Message-ID: I'm not sure I have fully understood the issue, the @Id may be not defined in the MappedSuperclass but for sure it must be in the subclasses extending it. I have tried and I can reproduce the issue only if I do not specify any @Id annotation in the subclass, but as soon as I add the @Id to a subclass of the MappedSuperclass the generated static metamodel is correct. On Thu, 10 Jan 2019 at 11:04, Guillaume Smet wrote: > Hi, > > We recently had this issue opened about us not choosing the right access > type for a mapped super class: > https://hibernate.atlassian.net/browse/HHH-12938 . > > Hibernate currently base the access type decision on the sole placement of > the @Id annotation, which, in the case of a @MappedSuperclass might not be > defined (this is the OP's case). > > I closed the issue explaining what we do and pointing a workaround but the > OP rightfully replied with the JPA spec saying "The default access type of > an entity hierarchy is determined by the placement of mapping annotations > on the attributes of the entity classes and mapped superclasses of the > entity hierarchy that do not explicitly specify an access type". > > I'm wondering if we should also consider the @Column annotations placement > if there is no @Id annotation. > > If the answer is that it's already fixed in 6, it's all good for me :). > > Thoughts? > > -- > Guillaume > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From guillaume.smet at gmail.com Thu Jan 10 06:51:40 2019 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Thu, 10 Jan 2019 12:51:40 +0100 Subject: [hibernate-dev] Default access type and MappedSuperclass In-Reply-To: References: Message-ID: The generated model of the MappedSuperclass? Because the one of the subclass is correct for sure. On Thu, Jan 10, 2019 at 12:44 PM andrea boriero wrote: > I'm not sure I have fully understood the issue, the @Id may be not defined > in the MappedSuperclass but for sure it must be in the subclasses extending > it. > > I have tried and I can reproduce the issue only if I do not specify > any @Id annotation in the subclass, but as soon as I add the @Id to a > subclass of the MappedSuperclass the generated static metamodel is correct. > > > On Thu, 10 Jan 2019 at 11:04, Guillaume Smet > wrote: > >> Hi, >> >> We recently had this issue opened about us not choosing the right access >> type for a mapped super class: >> https://hibernate.atlassian.net/browse/HHH-12938 . >> >> Hibernate currently base the access type decision on the sole placement of >> the @Id annotation, which, in the case of a @MappedSuperclass might not be >> defined (this is the OP's case). >> >> I closed the issue explaining what we do and pointing a workaround but the >> OP rightfully replied with the JPA spec saying "The default access type of >> an entity hierarchy is determined by the placement of mapping annotations >> on the attributes of the entity classes and mapped superclasses of the >> entity hierarchy that do not explicitly specify an access type". >> >> I'm wondering if we should also consider the @Column annotations placement >> if there is no @Id annotation. >> >> If the answer is that it's already fixed in 6, it's all good for me :). >> >> Thoughts? >> >> -- >> Guillaume >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > From andrea at hibernate.org Thu Jan 10 06:59:37 2019 From: andrea at hibernate.org (andrea boriero) Date: Thu, 10 Jan 2019 11:59:37 +0000 Subject: [hibernate-dev] Default access type and MappedSuperclass In-Reply-To: References: Message-ID: yes also for the MappedSuperclass from: @MappedSuperclass public abstract class AbstractCatalogEntity { @Column( name = "CODE") private String code; @Column( name = "NAME") private String name; } @Entity public class CatalogEntity extends AbstractCatalogEntity { @Id private Long id; } I obtained : @Generated(value = "org.hibernate.jpamodelgen.JPAMetaModelEntityProcessor") @StaticMetamodel(AbstractCatalogEntity.class) public abstract class AbstractCatalogEntity_ { public static volatile SingularAttribute code; public static volatile SingularAttribute name; public static final String CODE = "code"; public static final String NAME = "name"; } @Generated(value = "org.hibernate.jpamodelgen.JPAMetaModelEntityProcessor") @StaticMetamodel(CatalogEntity.class) public abstract class CatalogEntity_ extends org.hibernate.userguide.model.AbstractCatalogEntity_ { public static volatile SingularAttribute id; public static final String ID = "id"; } On Thu, 10 Jan 2019 at 11:52, Guillaume Smet wrote: > The generated model of the MappedSuperclass? > > Because the one of the subclass is correct for sure. > > On Thu, Jan 10, 2019 at 12:44 PM andrea boriero > wrote: > >> I'm not sure I have fully understood the issue, the @Id may be not >> defined in the MappedSuperclass but for sure it must be in the subclasses >> extending it. >> >> I have tried and I can reproduce the issue only if I do not specify >> any @Id annotation in the subclass, but as soon as I add the @Id to a >> subclass of the MappedSuperclass the generated static metamodel is correct. >> >> >> On Thu, 10 Jan 2019 at 11:04, Guillaume Smet >> wrote: >> >>> Hi, >>> >>> We recently had this issue opened about us not choosing the right access >>> type for a mapped super class: >>> https://hibernate.atlassian.net/browse/HHH-12938 . >>> >>> Hibernate currently base the access type decision on the sole placement >>> of >>> the @Id annotation, which, in the case of a @MappedSuperclass might not >>> be >>> defined (this is the OP's case). >>> >>> I closed the issue explaining what we do and pointing a workaround but >>> the >>> OP rightfully replied with the JPA spec saying "The default access type >>> of >>> an entity hierarchy is determined by the placement of mapping annotations >>> on the attributes of the entity classes and mapped superclasses of the >>> entity hierarchy that do not explicitly specify an access type". >>> >>> I'm wondering if we should also consider the @Column annotations >>> placement >>> if there is no @Id annotation. >>> >>> If the answer is that it's already fixed in 6, it's all good for me :). >>> >>> Thoughts? >>> >>> -- >>> Guillaume >>> _______________________________________________ >>> hibernate-dev mailing list >>> hibernate-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> >> From steve at hibernate.org Thu Jan 10 08:18:05 2019 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 10 Jan 2019 07:18:05 -0600 Subject: [hibernate-dev] Default access type and MappedSuperclass In-Reply-To: References: Message-ID: This is one of the cases (there are others) where we do not completely follow the JPA spec. TBH I'm not really sure how we would address this in an annotation processor, though granted my knowledge of those APIs is limited. But as I understand it we have to generate the metamodel class as we process the model class without knowledge of or access to other classes. Specifically here, we see the MappedSuperclasss first as it is a superclass and the compiler needs to process it first. I had planned on re-looking at this in 7 to offer a non-AP solution to metamodel generation. I don't think anything requires that we support this through an AP. There are other problems using an AP for this, namely it is extremely difficult to incorporate orm.xml info whether partial or complete. I guess a solution for now would involve somehow delaying the generation of the metamodel classes until the end of the AP cycle which (IIUC) would only really work with `proc:only` On Thu, Jan 10, 2019 at 6:29 AM Guillaume Smet wrote: > The generated model of the MappedSuperclass? > > Because the one of the subclass is correct for sure. > > On Thu, Jan 10, 2019 at 12:44 PM andrea boriero > wrote: > > > I'm not sure I have fully understood the issue, the @Id may be not > defined > > in the MappedSuperclass but for sure it must be in the subclasses > extending > > it. > > > > I have tried and I can reproduce the issue only if I do not specify > > any @Id annotation in the subclass, but as soon as I add the @Id to a > > subclass of the MappedSuperclass the generated static metamodel is > correct. > > > > > > On Thu, 10 Jan 2019 at 11:04, Guillaume Smet > > wrote: > > > >> Hi, > >> > >> We recently had this issue opened about us not choosing the right access > >> type for a mapped super class: > >> https://hibernate.atlassian.net/browse/HHH-12938 . > >> > >> Hibernate currently base the access type decision on the sole placement > of > >> the @Id annotation, which, in the case of a @MappedSuperclass might not > be > >> defined (this is the OP's case). > >> > >> I closed the issue explaining what we do and pointing a workaround but > the > >> OP rightfully replied with the JPA spec saying "The default access type > of > >> an entity hierarchy is determined by the placement of mapping > annotations > >> on the attributes of the entity classes and mapped superclasses of the > >> entity hierarchy that do not explicitly specify an access type". > >> > >> I'm wondering if we should also consider the @Column annotations > placement > >> if there is no @Id annotation. > >> > >> If the answer is that it's already fixed in 6, it's all good for me :). > >> > >> Thoughts? > >> > >> -- > >> Guillaume > >> _______________________________________________ > >> hibernate-dev mailing list > >> hibernate-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > >> > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From steve at hibernate.org Thu Jan 10 08:22:26 2019 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 10 Jan 2019 07:22:26 -0600 Subject: [hibernate-dev] Default access type and MappedSuperclass In-Reply-To: References: Message-ID: Hm, seems like the "AP delayed generation" approach is a possibility. From a quick search: https://stackoverflow.com/questions/41874462/java-annotation-process-not-yet-generated-elements https://docs.oracle.com/javase/6/docs/api/javax/annotation/processing/RoundEnvironment.html#processingOver%28%29 Disclaimer - I have not tried this, just read about it... On Thu, Jan 10, 2019 at 7:18 AM Steve Ebersole wrote: > This is one of the cases (there are others) where we do not completely > follow the JPA spec. > > TBH I'm not really sure how we would address this in an annotation > processor, though granted my knowledge of those APIs is limited. But as I > understand it we have to generate the metamodel class as we process the > model class without knowledge of or access to other classes. Specifically > here, we see the MappedSuperclasss first as it is a superclass and the > compiler needs to process it first. > > I had planned on re-looking at this in 7 to offer a non-AP solution to > metamodel generation. I don't think anything requires that we support this > through an AP. > > There are other problems using an AP for this, namely it is extremely > difficult to incorporate orm.xml info whether partial or complete. > > I guess a solution for now would involve somehow delaying the generation > of the metamodel classes until the end of the AP cycle which (IIUC) would > only really work with `proc:only` > > On Thu, Jan 10, 2019 at 6:29 AM Guillaume Smet > wrote: > >> The generated model of the MappedSuperclass? >> >> Because the one of the subclass is correct for sure. >> >> On Thu, Jan 10, 2019 at 12:44 PM andrea boriero >> wrote: >> >> > I'm not sure I have fully understood the issue, the @Id may be not >> defined >> > in the MappedSuperclass but for sure it must be in the subclasses >> extending >> > it. >> > >> > I have tried and I can reproduce the issue only if I do not specify >> > any @Id annotation in the subclass, but as soon as I add the @Id to a >> > subclass of the MappedSuperclass the generated static metamodel is >> correct. >> > >> > >> > On Thu, 10 Jan 2019 at 11:04, Guillaume Smet >> > wrote: >> > >> >> Hi, >> >> >> >> We recently had this issue opened about us not choosing the right >> access >> >> type for a mapped super class: >> >> https://hibernate.atlassian.net/browse/HHH-12938 . >> >> >> >> Hibernate currently base the access type decision on the sole >> placement of >> >> the @Id annotation, which, in the case of a @MappedSuperclass might >> not be >> >> defined (this is the OP's case). >> >> >> >> I closed the issue explaining what we do and pointing a workaround but >> the >> >> OP rightfully replied with the JPA spec saying "The default access >> type of >> >> an entity hierarchy is determined by the placement of mapping >> annotations >> >> on the attributes of the entity classes and mapped superclasses of the >> >> entity hierarchy that do not explicitly specify an access type". >> >> >> >> I'm wondering if we should also consider the @Column annotations >> placement >> >> if there is no @Id annotation. >> >> >> >> If the answer is that it's already fixed in 6, it's all good for me :). >> >> >> >> Thoughts? >> >> >> >> -- >> >> Guillaume >> >> _______________________________________________ >> >> hibernate-dev mailing list >> >> hibernate-dev at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >> >> > >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > From gunnar.morling at googlemail.com Thu Jan 10 09:09:55 2019 From: gunnar.morling at googlemail.com (Gunnar Morling) Date: Thu, 10 Jan 2019 15:09:55 +0100 Subject: [hibernate-dev] Default access type and MappedSuperclass In-Reply-To: References: Message-ID: Yes, we're doing something like that in MapStruct, too: https://github.com/mapstruct/mapstruct/blob/master/processor/src/main/java/org/mapstruct/ap/MappingProcessor.java#L114 There we need to wait with code generation for processed classes until their hierarchy has stabilized (other APs may generate superclasses that we must consider). Perhaps the Code ist helpful to you. --Gunnar Am 10.01.2019 15:01 schrieb "Steve Ebersole" : Hm, seems like the "AP delayed generation" approach is a possibility. From a quick search: https://stackoverflow.com/questions/41874462/java-annotation-process-not-yet-generated-elements https://docs.oracle.com/javase/6/docs/api/javax/annotation/processing/RoundEnvironment.html#processingOver%28%29 Disclaimer - I have not tried this, just read about it... On Thu, Jan 10, 2019 at 7:18 AM Steve Ebersole wrote: > This is one of the cases (there are others) where we do not completely > follow the JPA spec. > > TBH I'm not really sure how we would address this in an annotation > processor, though granted my knowledge of those APIs is limited. But as I > understand it we have to generate the metamodel class as we process the > model class without knowledge of or access to other classes. Specifically > here, we see the MappedSuperclasss first as it is a superclass and the > compiler needs to process it first. > > I had planned on re-looking at this in 7 to offer a non-AP solution to > metamodel generation. I don't think anything requires that we support this > through an AP. > > There are other problems using an AP for this, namely it is extremely > difficult to incorporate orm.xml info whether partial or complete. > > I guess a solution for now would involve somehow delaying the generation > of the metamodel classes until the end of the AP cycle which (IIUC) would > only really work with `proc:only` > > On Thu, Jan 10, 2019 at 6:29 AM Guillaume Smet > wrote: > >> The generated model of the MappedSuperclass? >> >> Because the one of the subclass is correct for sure. >> >> On Thu, Jan 10, 2019 at 12:44 PM andrea boriero >> wrote: >> >> > I'm not sure I have fully understood the issue, the @Id may be not >> defined >> > in the MappedSuperclass but for sure it must be in the subclasses >> extending >> > it. >> > >> > I have tried and I can reproduce the issue only if I do not specify >> > any @Id annotation in the subclass, but as soon as I add the @Id to a >> > subclass of the MappedSuperclass the generated static metamodel is >> correct. >> > >> > >> > On Thu, 10 Jan 2019 at 11:04, Guillaume Smet >> > wrote: >> > >> >> Hi, >> >> >> >> We recently had this issue opened about us not choosing the right >> access >> >> type for a mapped super class: >> >> https://hibernate.atlassian.net/browse/HHH-12938 . >> >> >> >> Hibernate currently base the access type decision on the sole >> placement of >> >> the @Id annotation, which, in the case of a @MappedSuperclass might >> not be >> >> defined (this is the OP's case). >> >> >> >> I closed the issue explaining what we do and pointing a workaround but >> the >> >> OP rightfully replied with the JPA spec saying "The default access >> type of >> >> an entity hierarchy is determined by the placement of mapping >> annotations >> >> on the attributes of the entity classes and mapped superclasses of the >> >> entity hierarchy that do not explicitly specify an access type". >> >> >> >> I'm wondering if we should also consider the @Column annotations >> placement >> >> if there is no @Id annotation. >> >> >> >> If the answer is that it's already fixed in 6, it's all good for me :). >> >> >> >> Thoughts? >> >> >> >> -- >> >> Guillaume >> >> _______________________________________________ >> >> hibernate-dev mailing list >> >> hibernate-dev at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >> >> > >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > _______________________________________________ hibernate-dev mailing list hibernate-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev From steve at hibernate.org Thu Jan 10 11:38:45 2019 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 10 Jan 2019 10:38:45 -0600 Subject: [hibernate-dev] [ORM] Reducing startup log verbosity In-Reply-To: References: <61e1e258-9f0e-90d8-1ab1-9f381f76c448@gmail.com> Message-ID: On Thu, Jan 10, 2019 at 10:15 AM Sanne Grinovero wrote: > On Thu, 10 Jan 2019 at 01:44, Steve Ebersole wrote: > > > > I disagree that logging a single message is a better solution because > that probably ends up wrapping multiple lines, just as your sample happened > to do in the email. IMO that is actually more difficult to read. > > Ok keep it in one line if you prefer. No strong preference on how it's > presented, but I think it's a big mistake to hide essential > diagnostics: "paste the logs" is often useful when helping someone; it > gets much harder if you first have to change categories. > You are combining separate things here.... First, *you* are the one that suggested doing it on one line unless I have misunderstood. My point is simply that practically speaking that will either mean having to read wrapped lines (eww) or scroll horizontally (double eww) to read this info. If your desire is to continue present this information anyway, then, well, what exactly are we changing? Just making it harder to read? "Diagnostics".. interesting choice of word... if you are diagnosing something that implies that there is a problem you are debugging... but here we are talking about boot-time informational logging. Different beasts. If the distinction you are trying to make is that we want to see at a glance what config Hibernate thinks it just processed versus what you think it should be (was caching enabled, etc) - well, where do you draw the line? Because this gets back to my first point; if you log everything that is "useful" in this single boot-time log message it is going to be completely unreadable. +1 those symbolic loggers are a great idea. But then please don't hide > this information at least until we have those easier logger > categories: Guillaume is set to patch 5.4x - which doesn't have them > yet. > What I am doing in 6 has no bearing on this discussion. Either we display information or we don't - that is the crux of this discussion, not which logger/category name we use. From steve at hibernate.org Thu Jan 10 21:04:04 2019 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 10 Jan 2019 20:04:04 -0600 Subject: [hibernate-dev] Default access type and MappedSuperclass In-Reply-To: References: Message-ID: Trying to make sure I understand.. so the report is just wrong? Or is there some difference in your model versus theirs? On Thu, Jan 10, 2019 at 2:22 PM andrea boriero wrote: > yes also for the MappedSuperclass > > from: > > @MappedSuperclass > public abstract class AbstractCatalogEntity { > @Column( name = "CODE") > private String code; > > @Column( name = "NAME") > private String name; > } > > @Entity > public class CatalogEntity extends AbstractCatalogEntity { > @Id > private Long id; > } > > I obtained : > > @Generated(value = "org.hibernate.jpamodelgen.JPAMetaModelEntityProcessor") > @StaticMetamodel(AbstractCatalogEntity.class) > public abstract class AbstractCatalogEntity_ { > > public static volatile SingularAttribute > code; > public static volatile SingularAttribute > name; > > public static final String CODE = "code"; > public static final String NAME = "name"; > > } > > @Generated(value = "org.hibernate.jpamodelgen.JPAMetaModelEntityProcessor") > @StaticMetamodel(CatalogEntity.class) > public abstract class CatalogEntity_ extends > org.hibernate.userguide.model.AbstractCatalogEntity_ { > > public static volatile SingularAttribute id; > > public static final String ID = "id"; > > } > > > > > On Thu, 10 Jan 2019 at 11:52, Guillaume Smet > wrote: > > > The generated model of the MappedSuperclass? > > > > Because the one of the subclass is correct for sure. > > > > On Thu, Jan 10, 2019 at 12:44 PM andrea boriero > > wrote: > > > >> I'm not sure I have fully understood the issue, the @Id may be not > >> defined in the MappedSuperclass but for sure it must be in the > subclasses > >> extending it. > >> > >> I have tried and I can reproduce the issue only if I do not specify > >> any @Id annotation in the subclass, but as soon as I add the @Id to a > >> subclass of the MappedSuperclass the generated static metamodel is > correct. > >> > >> > >> On Thu, 10 Jan 2019 at 11:04, Guillaume Smet > >> wrote: > >> > >>> Hi, > >>> > >>> We recently had this issue opened about us not choosing the right > access > >>> type for a mapped super class: > >>> https://hibernate.atlassian.net/browse/HHH-12938 . > >>> > >>> Hibernate currently base the access type decision on the sole placement > >>> of > >>> the @Id annotation, which, in the case of a @MappedSuperclass might not > >>> be > >>> defined (this is the OP's case). > >>> > >>> I closed the issue explaining what we do and pointing a workaround but > >>> the > >>> OP rightfully replied with the JPA spec saying "The default access type > >>> of > >>> an entity hierarchy is determined by the placement of mapping > annotations > >>> on the attributes of the entity classes and mapped superclasses of the > >>> entity hierarchy that do not explicitly specify an access type". > >>> > >>> I'm wondering if we should also consider the @Column annotations > >>> placement > >>> if there is no @Id annotation. > >>> > >>> If the answer is that it's already fixed in 6, it's all good for me :). > >>> > >>> Thoughts? > >>> > >>> -- > >>> Guillaume > >>> _______________________________________________ > >>> hibernate-dev mailing list > >>> hibernate-dev at lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev > >>> > >> > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From guillaume.smet at gmail.com Fri Jan 11 03:36:17 2019 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Fri, 11 Jan 2019 09:36:17 +0100 Subject: [hibernate-dev] Default access type and MappedSuperclass In-Reply-To: References: Message-ID: I know I reproduced it locally earlier this week. Can't get back to it today but I can push a test case next week. IMHO, it's very low priority. On Fri, Jan 11, 2019 at 3:04 AM Steve Ebersole wrote: > Trying to make sure I understand.. so the report is just wrong? Or is > there some difference in your model versus theirs? > > > On Thu, Jan 10, 2019 at 2:22 PM andrea boriero > wrote: > >> yes also for the MappedSuperclass >> >> from: >> >> @MappedSuperclass >> public abstract class AbstractCatalogEntity { >> @Column( name = "CODE") >> private String code; >> >> @Column( name = "NAME") >> private String name; >> } >> >> @Entity >> public class CatalogEntity extends AbstractCatalogEntity { >> @Id >> private Long id; >> } >> >> I obtained : >> >> @Generated(value = >> "org.hibernate.jpamodelgen.JPAMetaModelEntityProcessor") >> @StaticMetamodel(AbstractCatalogEntity.class) >> public abstract class AbstractCatalogEntity_ { >> >> public static volatile SingularAttribute >> code; >> public static volatile SingularAttribute >> name; >> >> public static final String CODE = "code"; >> public static final String NAME = "name"; >> >> } >> >> @Generated(value = >> "org.hibernate.jpamodelgen.JPAMetaModelEntityProcessor") >> @StaticMetamodel(CatalogEntity.class) >> public abstract class CatalogEntity_ extends >> org.hibernate.userguide.model.AbstractCatalogEntity_ { >> >> public static volatile SingularAttribute id; >> >> public static final String ID = "id"; >> >> } >> >> >> >> >> On Thu, 10 Jan 2019 at 11:52, Guillaume Smet >> wrote: >> >> > The generated model of the MappedSuperclass? >> > >> > Because the one of the subclass is correct for sure. >> > >> > On Thu, Jan 10, 2019 at 12:44 PM andrea boriero >> > wrote: >> > >> >> I'm not sure I have fully understood the issue, the @Id may be not >> >> defined in the MappedSuperclass but for sure it must be in the >> subclasses >> >> extending it. >> >> >> >> I have tried and I can reproduce the issue only if I do not specify >> >> any @Id annotation in the subclass, but as soon as I add the @Id to a >> >> subclass of the MappedSuperclass the generated static metamodel is >> correct. >> >> >> >> >> >> On Thu, 10 Jan 2019 at 11:04, Guillaume Smet > > >> >> wrote: >> >> >> >>> Hi, >> >>> >> >>> We recently had this issue opened about us not choosing the right >> access >> >>> type for a mapped super class: >> >>> https://hibernate.atlassian.net/browse/HHH-12938 . >> >>> >> >>> Hibernate currently base the access type decision on the sole >> placement >> >>> of >> >>> the @Id annotation, which, in the case of a @MappedSuperclass might >> not >> >>> be >> >>> defined (this is the OP's case). >> >>> >> >>> I closed the issue explaining what we do and pointing a workaround but >> >>> the >> >>> OP rightfully replied with the JPA spec saying "The default access >> type >> >>> of >> >>> an entity hierarchy is determined by the placement of mapping >> annotations >> >>> on the attributes of the entity classes and mapped superclasses of the >> >>> entity hierarchy that do not explicitly specify an access type". >> >>> >> >>> I'm wondering if we should also consider the @Column annotations >> >>> placement >> >>> if there is no @Id annotation. >> >>> >> >>> If the answer is that it's already fixed in 6, it's all good for me >> :). >> >>> >> >>> Thoughts? >> >>> >> >>> -- >> >>> Guillaume >> >>> _______________________________________________ >> >>> hibernate-dev mailing list >> >>> hibernate-dev at lists.jboss.org >> >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >>> >> >> >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > From guillaume.smet at gmail.com Fri Jan 11 04:24:37 2019 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Fri, 11 Jan 2019 10:24:37 +0100 Subject: [hibernate-dev] [ORM] Reducing startup log verbosity In-Reply-To: References: <61e1e258-9f0e-90d8-1ab1-9f381f76c448@gmail.com> Message-ID: In meeting all day so making progress on dumb stuff. Here is a very conservative PR on which I hope we could agree on quickly: https://github.com/hibernate/hibernate-orm/pull/2728 -- Guillaume On Thu, Jan 10, 2019 at 5:38 PM Steve Ebersole wrote: > > > On Thu, Jan 10, 2019 at 10:15 AM Sanne Grinovero > wrote: > >> On Thu, 10 Jan 2019 at 01:44, Steve Ebersole wrote: >> > >> > I disagree that logging a single message is a better solution because >> that probably ends up wrapping multiple lines, just as your sample happened >> to do in the email. IMO that is actually more difficult to read. >> >> Ok keep it in one line if you prefer. No strong preference on how it's >> presented, but I think it's a big mistake to hide essential >> diagnostics: "paste the logs" is often useful when helping someone; it >> gets much harder if you first have to change categories. >> > > You are combining separate things here.... > > First, *you* are the one that suggested doing it on one line unless I have > misunderstood. My point is simply that practically speaking that will > either mean having to read wrapped lines (eww) or scroll horizontally > (double eww) to read this info. If your desire is to continue present this > information anyway, then, well, what exactly are we changing? Just making > it harder to read? > > "Diagnostics".. interesting choice of word... if you are diagnosing > something that implies that there is a problem you are debugging... but > here we are talking about boot-time informational logging. Different > beasts. > > If the distinction you are trying to make is that we want to see at a > glance what config Hibernate thinks it just processed versus what you think > it should be (was caching enabled, etc) - well, where do you draw the > line? Because this gets back to my first point; if you log everything that > is "useful" in this single boot-time log message it is going to be > completely unreadable. > > > +1 those symbolic loggers are a great idea. But then please don't hide >> this information at least until we have those easier logger >> categories: Guillaume is set to patch 5.4x - which doesn't have them >> yet. >> > > What I am doing in 6 has no bearing on this discussion. Either we display > information or we don't - that is the crux of this discussion, not which > logger/category name we use. > > > From guillaume.smet at gmail.com Fri Jan 11 04:53:02 2019 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Fri, 11 Jan 2019 10:53:02 +0100 Subject: [hibernate-dev] [ORM] Reducing startup log verbosity In-Reply-To: References: <61e1e258-9f0e-90d8-1ab1-9f381f76c448@gmail.com> Message-ID: So what I suggest: if you disagree on a change, just comment on the specific line of the PR and I'll revert. I plan to merge that on Tuesday. On Fri, Jan 11, 2019 at 10:24 AM Guillaume Smet wrote: > In meeting all day so making progress on dumb stuff. > > Here is a very conservative PR on which I hope we could agree on quickly: > https://github.com/hibernate/hibernate-orm/pull/2728 > > -- > Guillaume > > On Thu, Jan 10, 2019 at 5:38 PM Steve Ebersole > wrote: > >> >> >> On Thu, Jan 10, 2019 at 10:15 AM Sanne Grinovero >> wrote: >> >>> On Thu, 10 Jan 2019 at 01:44, Steve Ebersole >>> wrote: >>> > >>> > I disagree that logging a single message is a better solution because >>> that probably ends up wrapping multiple lines, just as your sample happened >>> to do in the email. IMO that is actually more difficult to read. >>> >>> Ok keep it in one line if you prefer. No strong preference on how it's >>> presented, but I think it's a big mistake to hide essential >>> diagnostics: "paste the logs" is often useful when helping someone; it >>> gets much harder if you first have to change categories. >>> >> >> You are combining separate things here.... >> >> First, *you* are the one that suggested doing it on one line unless I >> have misunderstood. My point is simply that practically speaking that will >> either mean having to read wrapped lines (eww) or scroll horizontally >> (double eww) to read this info. If your desire is to continue present this >> information anyway, then, well, what exactly are we changing? Just making >> it harder to read? >> >> "Diagnostics".. interesting choice of word... if you are diagnosing >> something that implies that there is a problem you are debugging... but >> here we are talking about boot-time informational logging. Different >> beasts. >> >> If the distinction you are trying to make is that we want to see at a >> glance what config Hibernate thinks it just processed versus what you think >> it should be (was caching enabled, etc) - well, where do you draw the >> line? Because this gets back to my first point; if you log everything that >> is "useful" in this single boot-time log message it is going to be >> completely unreadable. >> >> >> +1 those symbolic loggers are a great idea. But then please don't hide >>> this information at least until we have those easier logger >>> categories: Guillaume is set to patch 5.4x - which doesn't have them >>> yet. >>> >> >> What I am doing in 6 has no bearing on this discussion. Either we >> display information or we don't - that is the crux of this discussion, not >> which logger/category name we use. >> >> >> From sanne at hibernate.org Fri Jan 11 06:00:06 2019 From: sanne at hibernate.org (Sanne Grinovero) Date: Fri, 11 Jan 2019 11:00:06 +0000 Subject: [hibernate-dev] [ORM] Reducing startup log verbosity In-Reply-To: References: <61e1e258-9f0e-90d8-1ab1-9f381f76c448@gmail.com> Message-ID: On Thu, 10 Jan 2019 at 16:39, Steve Ebersole wrote: > > > > On Thu, Jan 10, 2019 at 10:15 AM Sanne Grinovero wrote: >> >> On Thu, 10 Jan 2019 at 01:44, Steve Ebersole wrote: >> > >> > I disagree that logging a single message is a better solution because that probably ends up wrapping multiple lines, just as your sample happened to do in the email. IMO that is actually more difficult to read. >> >> Ok keep it in one line if you prefer. No strong preference on how it's >> presented, but I think it's a big mistake to hide essential >> diagnostics: "paste the logs" is often useful when helping someone; it >> gets much harder if you first have to change categories. > > > You are combining separate things here.... > > First, *you* are the one that suggested doing it on one line unless I have misunderstood. My point is simply that practically speaking that will either mean having to read wrapped lines (eww) or scroll horizontally (double eww) to read this info. If your desire is to continue present this information anyway, then, well, what exactly are we changing? Just making it harder to read? I wasn't implying it would necessarily wrap on multiple lines. Not suggesting to add a ton of information, but a careful selection - if we take my example literally that should fit in "most" defintions of lines, especially as it's shorter than many other messages we produce. > "Diagnostics".. interesting choice of word... if you are diagnosing something that implies that there is a problem you are debugging... but here we are talking about boot-time informational logging. Different beasts. Fair enough; I don't agree but happy to follow your guidance. > > If the distinction you are trying to make is that we want to see at a glance what config Hibernate thinks it just processed versus what you think it should be (was caching enabled, etc) - well, where do you draw the line? Because this gets back to my first point; if you log everything that is "useful" in this single boot-time log message it is going to be completely unreadable. Sure; I just meant we should always log: - Hibernate's version - Dialect choice And possibly also: - Transaction mode - If caching is enabled (especially as I have in mind a proposal to have 2LC and query caching enabled by default: not to sidetrack this conversation now but that's where I was coming from) That's just four pieces of information which we could try to show by default; I understand it's not much and not enough to diagnose many problems, but it felt like a good balance to me as it's useful to have some basics logged by default as a starting point. No strong feeling though, so if you disagree.. you're the lead and that's it. Thanks, Sanne > > >> +1 those symbolic loggers are a great idea. But then please don't hide >> this information at least until we have those easier logger >> categories: Guillaume is set to patch 5.4x - which doesn't have them >> yet. > > > What I am doing in 6 has no bearing on this discussion. Either we display information or we don't - that is the crux of this discussion, not which logger/category name we use. > > From sanne at hibernate.org Fri Jan 11 06:04:10 2019 From: sanne at hibernate.org (Sanne Grinovero) Date: Fri, 11 Jan 2019 11:04:10 +0000 Subject: [hibernate-dev] [ORM] Reducing startup log verbosity In-Reply-To: References: <61e1e258-9f0e-90d8-1ab1-9f381f76c448@gmail.com> Message-ID: On Fri, 11 Jan 2019 at 09:53, Guillaume Smet wrote: > > So what I suggest: if you disagree on a change, just comment on the specific line of the PR and I'll revert. > > I plan to merge that on Tuesday. I like it. Not merging it yet to get Steve a chance to comment too. A minor nitpick: not logging which entities are being enhanced seems reasonable when ORM is being booted, but as a user I'd probably expect to see such output if I'm running an explicit enhancement task via some of the tooling. Perhaps you should allow the enhancer tasks to raise these back up to INFO; maybe the enhancer task should pass in its own enhancement observer? Thanks Guillaume! > > On Fri, Jan 11, 2019 at 10:24 AM Guillaume Smet wrote: >> >> In meeting all day so making progress on dumb stuff. >> >> Here is a very conservative PR on which I hope we could agree on quickly: >> https://github.com/hibernate/hibernate-orm/pull/2728 >> >> -- >> Guillaume >> >> On Thu, Jan 10, 2019 at 5:38 PM Steve Ebersole wrote: >>> >>> >>> >>> On Thu, Jan 10, 2019 at 10:15 AM Sanne Grinovero wrote: >>>> >>>> On Thu, 10 Jan 2019 at 01:44, Steve Ebersole wrote: >>>> > >>>> > I disagree that logging a single message is a better solution because that probably ends up wrapping multiple lines, just as your sample happened to do in the email. IMO that is actually more difficult to read. >>>> >>>> Ok keep it in one line if you prefer. No strong preference on how it's >>>> presented, but I think it's a big mistake to hide essential >>>> diagnostics: "paste the logs" is often useful when helping someone; it >>>> gets much harder if you first have to change categories. >>> >>> >>> You are combining separate things here.... >>> >>> First, *you* are the one that suggested doing it on one line unless I have misunderstood. My point is simply that practically speaking that will either mean having to read wrapped lines (eww) or scroll horizontally (double eww) to read this info. If your desire is to continue present this information anyway, then, well, what exactly are we changing? Just making it harder to read? >>> >>> "Diagnostics".. interesting choice of word... if you are diagnosing something that implies that there is a problem you are debugging... but here we are talking about boot-time informational logging. Different beasts. >>> >>> If the distinction you are trying to make is that we want to see at a glance what config Hibernate thinks it just processed versus what you think it should be (was caching enabled, etc) - well, where do you draw the line? Because this gets back to my first point; if you log everything that is "useful" in this single boot-time log message it is going to be completely unreadable. >>> >>> >>>> +1 those symbolic loggers are a great idea. But then please don't hide >>>> this information at least until we have those easier logger >>>> categories: Guillaume is set to patch 5.4x - which doesn't have them >>>> yet. >>> >>> >>> What I am doing in 6 has no bearing on this discussion. Either we display information or we don't - that is the crux of this discussion, not which logger/category name we use. >>> >>> From steve at hibernate.org Fri Jan 11 08:20:26 2019 From: steve at hibernate.org (Steve Ebersole) Date: Fri, 11 Jan 2019 07:20:26 -0600 Subject: [hibernate-dev] [ORM] Reducing startup log verbosity In-Reply-To: References: <61e1e258-9f0e-90d8-1ab1-9f381f76c448@gmail.com> Message-ID: Guillaume - I added a general start-a-discussion comment to the PR. Hopefully anyone with an opinion on that can chime in there. Beyond that, +1 Sanne - ok, I see. You are not expecting users to have to deal with wrapping/scrolling because you limit the presented information to an arbitrary set of values. That's certainly an option. My only caution there is that this is an arbitrary list of values-of-interest. We all agree version is important. It is beyond that that we start to have different preferences. I think everything beyond that is DEBUG-level info. For any additional values, I worry about the arbitrary nature of what we present and don't in this message. I mean to me, the same argument that leads to "caching enabled/disabled" being important enough to list also dictates that CDI integration is important enough too. Same for BytecodeProvider, ConnectionProvider, ... Its this question of where we draw the line that concerns me. And if we are drawing an arbitrary line, why are we drawing that line at all? I'll eagerly await your discussion about enabling caching by default ;) From sanne at hibernate.org Fri Jan 11 09:03:06 2019 From: sanne at hibernate.org (Sanne Grinovero) Date: Fri, 11 Jan 2019 14:03:06 +0000 Subject: [hibernate-dev] [ORM] Reducing startup log verbosity In-Reply-To: References: <61e1e258-9f0e-90d8-1ab1-9f381f76c448@gmail.com> Message-ID: On Fri, 11 Jan 2019 at 14:00, Steve Ebersole wrote: > > Guillaume - I added a general start-a-discussion comment to the PR. Hopefully anyone with an opinion on that can chime in there. Beyond that, +1 > > > Sanne - ok, I see. You are not expecting users to have to deal with wrapping/scrolling because you limit the presented information to an arbitrary set of values. That's certainly an option. My only caution there is that this is an arbitrary list of values-of-interest. > > We all agree version is important. It is beyond that that we start to have different preferences. I think everything beyond that is DEBUG-level info. For any additional values, I worry about the arbitrary nature of what we present and don't in this message. I mean to me, the same argument that leads to "caching enabled/disabled" being important enough to list also dictates that CDI integration is important enough too. Same for BytecodeProvider, ConnectionProvider, ... Its this question of where we draw the line that concerns me. And if we are drawing an arbitrary line, why are we drawing that line at all? Yeah it's arbitrary. When I proposed it I thought with some luck we might have a quick consensus; if not let's just stick to the version. > I'll eagerly await your discussion about enabling caching by default ;) Let's face that in front of some great food in Rome :) From steve at hibernate.org Fri Jan 11 09:52:09 2019 From: steve at hibernate.org (Steve Ebersole) Date: Fri, 11 Jan 2019 08:52:09 -0600 Subject: [hibernate-dev] [ORM] Reducing startup log verbosity In-Reply-To: References: <61e1e258-9f0e-90d8-1ab1-9f381f76c448@gmail.com> Message-ID: Sounds good to me! :) On Fri, Jan 11, 2019 at 8:19 AM Sanne Grinovero wrote: > On Fri, 11 Jan 2019 at 14:00, Steve Ebersole wrote: > > > > Guillaume - I added a general start-a-discussion comment to the PR. > Hopefully anyone with an opinion on that can chime in there. Beyond that, > +1 > > > > > > Sanne - ok, I see. You are not expecting users to have to deal with > wrapping/scrolling because you limit the presented information to an > arbitrary set of values. That's certainly an option. My only caution > there is that this is an arbitrary list of values-of-interest. > > > > We all agree version is important. It is beyond that that we start to > have different preferences. I think everything beyond that is DEBUG-level > info. For any additional values, I worry about the arbitrary nature of > what we present and don't in this message. I mean to me, the same argument > that leads to "caching enabled/disabled" being important enough to list > also dictates that CDI integration is important enough too. Same for > BytecodeProvider, ConnectionProvider, ... Its this question of where we > draw the line that concerns me. And if we are drawing an arbitrary line, > why are we drawing that line at all? > > Yeah it's arbitrary. When I proposed it I thought with some luck we > might have a quick consensus; if not let's just stick to the version. > > > I'll eagerly await your discussion about enabling caching by default ;) > > Let's face that in front of some great food in Rome :) > From sanne at hibernate.org Tue Jan 15 05:34:44 2019 From: sanne at hibernate.org (Sanne Grinovero) Date: Tue, 15 Jan 2019 10:34:44 +0000 Subject: [hibernate-dev] Planning an ORM maintenance release: 5.4.1.Final Message-ID: Hi all, I plan to tag a maintenance release of Hibernate ORM 5.4.1.Final on Thursday, to be published and distributed Friday. Please try to polish and merge any work you might want included, or yell at me if you object with the timing? And of course, as usual: don't freak out if your work won't be ready on time; there will be more releases. Thanks, Sanne From yoann at hibernate.org Tue Jan 15 09:21:15 2019 From: yoann at hibernate.org (Yoann Rodiere) Date: Tue, 15 Jan 2019 15:21:15 +0100 Subject: [hibernate-dev] NoORM IRC meeting minutes Message-ID: Hi, Here are the minutes of today's meeting: (15:18:41) jbott: Meeting ended Tue Jan 15 14:18:34 2019 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) (15:18:41) jbott: Minutes: http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2019/hibernate-dev.2019-01-15-14.00.html (15:18:41) jbott: Minutes (text): http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2019/hibernate-dev.2019-01-15-14.00.txt (15:18:42) jbott: Log: http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2019/hibernate-dev.2019-01-15-14.00.log.html Have a nice day. Yoann Rodi?re Hibernate NoORM Team yoann at hibernate.org From guillaume.smet at gmail.com Tue Jan 15 09:24:14 2019 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Tue, 15 Jan 2019 15:24:14 +0100 Subject: [hibernate-dev] [ORM] Reducing startup log verbosity In-Reply-To: References: <61e1e258-9f0e-90d8-1ab1-9f381f76c448@gmail.com> Message-ID: > A minor nitpick: not logging which entities are being enhanced seems reasonable when ORM is being booted, but as a user I'd probably expect to see such output if I'm running an explicit enhancement task via some of the tooling. > Perhaps you should allow the enhancer tasks to raise these back up to INFO; maybe the enhancer task should pass in its own enhancement observer? They already do log something if a class has been enhanced. Look for "Successfully enhanced class" in the code. So I think we are covered here. -- Guillaume On Fri, Jan 11, 2019 at 12:04 PM Sanne Grinovero wrote: > On Fri, 11 Jan 2019 at 09:53, Guillaume Smet > wrote: > > > > So what I suggest: if you disagree on a change, just comment on the > specific line of the PR and I'll revert. > > > > I plan to merge that on Tuesday. > > I like it. Not merging it yet to get Steve a chance to comment too. > > A minor nitpick: not logging which entities are being enhanced seems > reasonable when ORM is being booted, but as a user I'd probably expect > to see such output if I'm running an explicit enhancement task via > some of the tooling. > Perhaps you should allow the enhancer tasks to raise these back up to > INFO; maybe the enhancer task should pass in its own enhancement > observer? > > Thanks Guillaume! > > > > > On Fri, Jan 11, 2019 at 10:24 AM Guillaume Smet < > guillaume.smet at gmail.com> wrote: > >> > >> In meeting all day so making progress on dumb stuff. > >> > >> Here is a very conservative PR on which I hope we could agree on > quickly: > >> https://github.com/hibernate/hibernate-orm/pull/2728 > >> > >> -- > >> Guillaume > >> > >> On Thu, Jan 10, 2019 at 5:38 PM Steve Ebersole > wrote: > >>> > >>> > >>> > >>> On Thu, Jan 10, 2019 at 10:15 AM Sanne Grinovero > wrote: > >>>> > >>>> On Thu, 10 Jan 2019 at 01:44, Steve Ebersole > wrote: > >>>> > > >>>> > I disagree that logging a single message is a better solution > because that probably ends up wrapping multiple lines, just as your sample > happened to do in the email. IMO that is actually more difficult to read. > >>>> > >>>> Ok keep it in one line if you prefer. No strong preference on how it's > >>>> presented, but I think it's a big mistake to hide essential > >>>> diagnostics: "paste the logs" is often useful when helping someone; it > >>>> gets much harder if you first have to change categories. > >>> > >>> > >>> You are combining separate things here.... > >>> > >>> First, *you* are the one that suggested doing it on one line unless I > have misunderstood. My point is simply that practically speaking that will > either mean having to read wrapped lines (eww) or scroll horizontally > (double eww) to read this info. If your desire is to continue present this > information anyway, then, well, what exactly are we changing? Just making > it harder to read? > >>> > >>> "Diagnostics".. interesting choice of word... if you are diagnosing > something that implies that there is a problem you are debugging... but > here we are talking about boot-time informational logging. Different > beasts. > >>> > >>> If the distinction you are trying to make is that we want to see at a > glance what config Hibernate thinks it just processed versus what you think > it should be (was caching enabled, etc) - well, where do you draw the > line? Because this gets back to my first point; if you log everything that > is "useful" in this single boot-time log message it is going to be > completely unreadable. > >>> > >>> > >>>> +1 those symbolic loggers are a great idea. But then please don't hide > >>>> this information at least until we have those easier logger > >>>> categories: Guillaume is set to patch 5.4x - which doesn't have them > >>>> yet. > >>> > >>> > >>> What I am doing in 6 has no bearing on this discussion. Either we > display information or we don't - that is the crux of this discussion, not > which logger/category name we use. > >>> > >>> > From sanne at hibernate.org Tue Jan 15 09:29:55 2019 From: sanne at hibernate.org (Sanne Grinovero) Date: Tue, 15 Jan 2019 14:29:55 +0000 Subject: [hibernate-dev] [ORM] Reducing startup log verbosity In-Reply-To: References: <61e1e258-9f0e-90d8-1ab1-9f381f76c448@gmail.com> Message-ID: On Tue, 15 Jan 2019 at 14:24, Guillaume Smet wrote: > > > A minor nitpick: not logging which entities are being enhanced seems > reasonable when ORM is being booted, but as a user I'd probably expect > to see such output if I'm running an explicit enhancement task via > some of the tooling. > > Perhaps you should allow the enhancer tasks to raise these back up to > INFO; maybe the enhancer task should pass in its own enhancement > observer? > > They already do log something if a class has been enhanced. Look for "Successfully enhanced class" in the code. > > So I think we are covered here. Nice, thanks for checking. > > -- > Guillaume > > On Fri, Jan 11, 2019 at 12:04 PM Sanne Grinovero wrote: >> >> On Fri, 11 Jan 2019 at 09:53, Guillaume Smet wrote: >> > >> > So what I suggest: if you disagree on a change, just comment on the specific line of the PR and I'll revert. >> > >> > I plan to merge that on Tuesday. >> >> I like it. Not merging it yet to get Steve a chance to comment too. >> >> A minor nitpick: not logging which entities are being enhanced seems >> reasonable when ORM is being booted, but as a user I'd probably expect >> to see such output if I'm running an explicit enhancement task via >> some of the tooling. >> Perhaps you should allow the enhancer tasks to raise these back up to >> INFO; maybe the enhancer task should pass in its own enhancement >> observer? >> >> Thanks Guillaume! >> >> > >> > On Fri, Jan 11, 2019 at 10:24 AM Guillaume Smet wrote: >> >> >> >> In meeting all day so making progress on dumb stuff. >> >> >> >> Here is a very conservative PR on which I hope we could agree on quickly: >> >> https://github.com/hibernate/hibernate-orm/pull/2728 >> >> >> >> -- >> >> Guillaume >> >> >> >> On Thu, Jan 10, 2019 at 5:38 PM Steve Ebersole wrote: >> >>> >> >>> >> >>> >> >>> On Thu, Jan 10, 2019 at 10:15 AM Sanne Grinovero wrote: >> >>>> >> >>>> On Thu, 10 Jan 2019 at 01:44, Steve Ebersole wrote: >> >>>> > >> >>>> > I disagree that logging a single message is a better solution because that probably ends up wrapping multiple lines, just as your sample happened to do in the email. IMO that is actually more difficult to read. >> >>>> >> >>>> Ok keep it in one line if you prefer. No strong preference on how it's >> >>>> presented, but I think it's a big mistake to hide essential >> >>>> diagnostics: "paste the logs" is often useful when helping someone; it >> >>>> gets much harder if you first have to change categories. >> >>> >> >>> >> >>> You are combining separate things here.... >> >>> >> >>> First, *you* are the one that suggested doing it on one line unless I have misunderstood. My point is simply that practically speaking that will either mean having to read wrapped lines (eww) or scroll horizontally (double eww) to read this info. If your desire is to continue present this information anyway, then, well, what exactly are we changing? Just making it harder to read? >> >>> >> >>> "Diagnostics".. interesting choice of word... if you are diagnosing something that implies that there is a problem you are debugging... but here we are talking about boot-time informational logging. Different beasts. >> >>> >> >>> If the distinction you are trying to make is that we want to see at a glance what config Hibernate thinks it just processed versus what you think it should be (was caching enabled, etc) - well, where do you draw the line? Because this gets back to my first point; if you log everything that is "useful" in this single boot-time log message it is going to be completely unreadable. >> >>> >> >>> >> >>>> +1 those symbolic loggers are a great idea. But then please don't hide >> >>>> this information at least until we have those easier logger >> >>>> categories: Guillaume is set to patch 5.4x - which doesn't have them >> >>>> yet. >> >>> >> >>> >> >>> What I am doing in 6 has no bearing on this discussion. Either we display information or we don't - that is the crux of this discussion, not which logger/category name we use. >> >>> >> >>> From steve at hibernate.org Tue Jan 15 10:14:26 2019 From: steve at hibernate.org (Steve Ebersole) Date: Tue, 15 Jan 2019 09:14:26 -0600 Subject: [hibernate-dev] Loggers In-Reply-To: References: Message-ID: Following the recent post about boot logging and recent work on a new "module" (criteria queries) in 6, I wanted to circle back to this with a few thoughts. Now that this approach has been in place for quite a while and has been getting used we have a better feel for how this works in practice. One thing I realized is that the use of symbolic names for the loggers allows us to extend the idea of a "supported API" to logging as well. What I mean by this is that logging config would work from one release to the next because we are using symbolic names rather than class names. Even if we did extensive refactoring moving classes to different packages, renaming classes, etc... the logger names would stay the same. Which is not a small thing. From a document I am working on: == Logger/category names Symbolic name versus FQN as logger/category name Pros:: * Easier to configure as a hierarchy (imo); * Safe from refactoring - which seems minor, but it makes logging config something we could support, just as if it were an API Cons:: * Easy for classes to use FQN instead of symbolic name I personally really like moving TRACE and DEBUG logging to using this approach as well. It has worked really well in testing. Its is so much nicer to enable logging for query handling using: log4j.logger.org.hibernate.orm.query=debug log4j.logger.org.hibernate.orm.sql=debug compared to: log4j.logger.org.hibernate.hql=debug log4j.logger.org.hibernate.loader=debug log4j.logger.org.hibernate.sql=debug log4j.logger.org.hibernate.type=debug ... To be clear, there are also categories "under" the ones I used in the example. E.g. to see "query logging" just for HQL you'd use the `log4j.logger.org.hibernate.orm.query.hql` (which has additional categories as well (`log4j.logger.org.hibernate.orm.query.sqm.hql.parse.tree`, etc). I wanted to make sure everyone is on board with this before we get too far down this path - using symbolic names for TRACE/DEBUG logging. One last thing I forgot to mention earlier is that this does require changing the message ids. The range for these ids are defined as part of the message logger (the interface) via annotation. As we move messages to a different (modular) logger class the id range has to change. This only affects (is only supposed to affect[1]) message loggers (INFO/WARN/ERROR), not info logging (TRACE/DEBUG). [1] Historically we have only used message loggers (with ids) for INFO/WARN/ERROR. Some of the more recent changes by Guillaume change that a bit and moved a few message logger messages to be DEBUG. I think this is another thing we should nail down moving forward - do we want TRACE/DEBUG logging to potentially be messaged (with id) logs? On Fri, Sep 28, 2018 at 10:46 AM Sanne Grinovero wrote: > On Fri, 28 Sep 2018 at 16:43, Steve Ebersole wrote: > > > > Thanks for the feedback! > > I'm actually sorry for the delay :) Just back from 2 weeks off, catching > up. > > > WRT effort, the plan is to make these changes as I do work in a > particular area which is what I have been doing - not a "one shot, go back > and change all logging". > > +1 > > > WRT granularity, sure that would be a concern. It really comes back to > having a good "logical" design of the logger name hierarchy. > > > > WRT coordination, yep - > https://github.com/sebersole/hibernate-core/blob/wip/6.0/logger_id_ranges.adoc > > Awesome! > > Thanks, > Sanne > > > > > On Fri, Sep 28, 2018 at 10:35 AM Sanne Grinovero > wrote: > >> > >> Hi Steve, > >> > >> I love the cathegories idea; I think we discussed it before. My only > >> concern is that it's a lot of work to implement, but if you feel it's > >> doable that's great. > >> > >> In terms of "changes needed" I'm not worried either. Like you said, 6 > >> would have had different names for most cases; at least moving forward > >> such names would be more stable even if we decide to move some code in > >> the future. > >> > >> One doubt is the granularity. I guess the risk is that maintainers > >> will tend to reuse the same limited set of cathegories; we will need > >> to make sure there are enough cathegories so that people can still > >> enable the single aspect they might be interested in debugging, but > >> maybe that's not important as people can always post-filter things > >> when the output gets too verbose. > >> > >> We will need a way to coordinate on valid ranges for the various > >> @ValidIdRange. Infinispan used a wiki for this; the upside is that > >> it's out of the repository: a good thing to avoid reuse across repo > >> branches - e.g. it's not ideal to have to change ids when backporting > >> - , but downside of requiring human care. > >> > >> Thanks, > >> Sanne > >> > >> > >> On Wed, 19 Sep 2018 at 14:31, Steve Ebersole > wrote: > >> > > >> > Yes. As I mentioned in my original, this would mean potential > changes for > >> > people configuring logging. I've started doing this for new logging > in 6 > >> > and it works great. > >> > > >> > Mainly asking opinions about changing existing logging and whether the > >> > benefits are worth the effort. > >> > > >> > And keep in mind that the many many changes in 6 already would > require such > >> > logging config changes anyway for those configuring logging > >> > > >> > > >> > On Wed, Sep 19, 2018, 12:50 AM Vlad Mihalcea > > >> > wrote: > >> > > >> > > I think it's a good idea. > >> > > > >> > > However, will this break all current applications that use the > package > >> > > name log appenders? > >> > > > >> > > Vlad > >> > > > >> > > On Fri, Sep 14, 2018 at 7:20 PM, Steve Ebersole < > steve at hibernate.org> > >> > > wrote: > >> > > > >> > >> Yes, I know no one likes talking about logging. "Its not > important", > >> > >> until > >> > >> it is ;) > >> > >> > >> > >> TLDR I am considering moving to using "module names" for logger > names > >> > >> instead of Class names even for DEBUG/TRACE logging and see if > anyone had > >> > >> strong arguments to not do this.. > >> > >> > >> > >> Full version--- > >> > >> > >> > >> For some time I have been moving to an approach of defining message > >> > >> loggers[1] using a single contract per function or "module" - e.g.: > >> > >> > >> > >> 1. the second level caching module uses the dedicated message > logger > >> > >> `ConnectionPoolingLogger` > >> > >> 2. the ManagedBeanRegistry module uses the dedicated message > logger > >> > >> `BeansMessageLogger` > >> > >> 3. etc > >> > > > >> > > > >> > >> > >> > >> Each of these define a dedicate instance instance they can use. > E.g. > >> > >> ConnectionPoolingLogger is defined as: > >> > >> > >> > >> ```` > >> > >> @MessageLogger( projectCode = "HHH" ) > >> > >> @ValidIdRange( min = 10001001, max = 10001500 ) > >> > >> public interface ConnectionPoolingLogger extends BasicLogger { > >> > >> > >> > >> ConnectionPoolingLogger CONNECTIONS_LOGGER = > Logger.getMessageLogger( > >> > >> ConnectionPoolingLogger.class, > >> > >> "org.hibernate.orm.connections.pooling" > >> > >> ); > >> > >> > >> > >> ... > >> > >> } > >> > >> ```` > >> > >> > >> > >> I won't get into all the whys I do this unless someone cares ;) > >> > >> > >> > >> But I am contemplating doing the same for basic loggers so I > wanted to ask > >> > >> everyone else's opinion since this means a change in how you'd > have to > >> > >> configure logging for DEBUG/TRACE output. Usually you'd use the > Class > >> > >> name > >> > >> as the logger name and use that to control logging in the back-end > (log4j, > >> > >> etc). If I do this, you'd have to instead use the module name. > >> > >> > >> > >> There are quite a few reasons I am considering this, including > all of the > >> > >> reasons I did it for message loggers in the first place. If I am > >> > >> debugging the loading of a collection or an entity, today I'd have > to know > >> > >> all the packages involved (there is no common root name) and list > them in > >> > >> my log4j.properties; that is because the process is ultimately > handled by > >> > >> delegates or helpers in many different packages > (`org.hibernate.loader`, > >> > >> `org.hibernate.persister`, `org.hibernate.type`, ...). It sure > would be > >> > >> nice to just be able to say `org.hibernate.loading` or > >> > >> `org.hibernate.loading.entity` or > `org.hibernate.loading.collection` or > >> > >> ... > >> > >> for a number of reasons: > >> > >> > >> > >> 1. When we need to see logging from someone it is a lot easier > to tell > >> > >> the module name(s) you need enabled as opposed a list of > package and > >> > >> class > >> > >> names. > >> > >> 2. When running JPA TCK it is essentially impossible to attach > debugger > >> > >> to step through code when debugging a failure - you have to > rely on > >> > >> debugging through output. *Well that used to be the case, but > the > >> > >> latest TCK broke logging to STDOUT somehow so we ended up > having to > >> > >> try and > >> > >> reproduce the failure in our testsuite - so then it does not > matter > >> > >> either > >> > >> way ;)* > >> > >> 3. Easier to document - > >> > >> > >> > >> > http://docs.jboss.org/hibernate/orm/5.3/topical/html_single/logging/Logging.html > >> > >> > >> > >> Thoughts? > >> > >> > >> > >> > >> > >> [1] JBoss Logging's `org.jboss.logging.annotations.MessageLogger` > - which > >> > >> we use for user-focused log messages. Should always be logged at > >= INFO > >> > >> [2] > >> > >> [3] JBoss Logging's `org.jboss.logging.BasicLogger` - which we use > for > >> > >> developer-focused log messages (for debugging). Should always be > logged > >> > >> at > >> > >> DEBUG or TRACE > >> > >> _______________________________________________ > >> > >> hibernate-dev mailing list > >> > >> hibernate-dev at lists.jboss.org > >> > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > >> > >> > >> > > > >> > > > >> > _______________________________________________ > >> > hibernate-dev mailing list > >> > hibernate-dev at lists.jboss.org > >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From gbadner at redhat.com Tue Jan 15 17:25:25 2019 From: gbadner at redhat.com (Gail Badner) Date: Tue, 15 Jan 2019 14:25:25 -0800 Subject: [hibernate-dev] hibernate-tools-maven-plugin 5.4 snapshots are not being uploaded to Nexus Message-ID: Someone mentioned in a jira that hibernate-tools-maven-plugin is not available for 5.4. snapshots. [1] Should it be? Regards, Gail [1] https://repository.jboss.org/nexus/content/groups/public-jboss/org/hibernate/hibernate-tools-maven-plugin/ From guillaume.smet at gmail.com Wed Jan 16 05:59:34 2019 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Wed, 16 Jan 2019 11:59:34 +0100 Subject: [hibernate-dev] hibernate-tools-maven-plugin 5.4 snapshots are not being uploaded to Nexus In-Reply-To: References: Message-ID: Hi Gail, If it's the same issue I'm thinking about (namely https://hibernate.atlassian.net/browse/HHH-11807), it's this artifact that you're looking for: https://repository.jboss.org/nexus/content/groups/public-jboss/org/hibernate/orm/tooling/hibernate-enhance-maven-plugin/ . And the snapshots are there. The test case was all broken, I uploaded an updated one. On Wed, Jan 16, 2019 at 7:58 AM Gail Badner wrote: > Someone mentioned in a jira that hibernate-tools-maven-plugin is not > available for 5.4. snapshots. [1] > > Should it be? > > Regards, > Gail > > [1] > > https://repository.jboss.org/nexus/content/groups/public-jboss/org/hibernate/hibernate-tools-maven-plugin/ > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From sanne at hibernate.org Wed Jan 16 07:19:43 2019 From: sanne at hibernate.org (Sanne Grinovero) Date: Wed, 16 Jan 2019 12:19:43 +0000 Subject: [hibernate-dev] Loggers In-Reply-To: References: Message-ID: Hi Steve, thanks that looks very nice; sub- hierarchies also look great. My only oncern is with the mentioned need to change Logger range IDs; can we handle this in such a way to avoid recycling of previous IDs? Maybe the simplest solution is to use the ORM6 release as an opportunity to change the logger prefix? (No longer HHH ?) Alternatively we could pick new ranges; hopefully numbers don't get too silly :) Thanks, Sanne On Tue, 15 Jan 2019 at 15:14, Steve Ebersole wrote: > > Following the recent post about boot logging and recent work on a new "module" (criteria queries) in 6, I wanted to circle back to this with a few thoughts. Now that this approach has been in place for quite a while and has been getting used we have a better feel for how this works in practice. > > One thing I realized is that the use of symbolic names for the loggers allows us to extend the idea of a "supported API" to logging as well. What I mean by this is that logging config would work from one release to the next because we are using symbolic names rather than class names. Even if we did extensive refactoring moving classes to different packages, renaming classes, etc... the logger names would stay the same. Which is not a small thing. From a document I am working on: > > == Logger/category names > > Symbolic name versus FQN as logger/category name > > Pros:: > > * Easier to configure as a hierarchy (imo); > * Safe from refactoring - which seems minor, but it makes logging config something we could support, just as if it were an API > > Cons:: > > * Easy for classes to use FQN instead of symbolic name > > I personally really like moving TRACE and DEBUG logging to using this approach as well. It has worked really well in testing. Its is so much nicer to enable logging for query handling using: > > log4j.logger.org.hibernate.orm.query=debug > log4j.logger.org.hibernate.orm.sql=debug > > compared to: > > log4j.logger.org.hibernate.hql=debug > log4j.logger.org.hibernate.loader=debug > log4j.logger.org.hibernate.sql=debug > log4j.logger.org.hibernate.type=debug > ... > > To be clear, there are also categories "under" the ones I used in the example. E.g. to see "query logging" just for HQL you'd use the `log4j.logger.org.hibernate.orm.query.hql` (which has additional categories as well (`log4j.logger.org.hibernate.orm.query.sqm.hql.parse.tree`, etc). I wanted to make sure everyone is on board with this before we get too far down this path - using symbolic names for TRACE/DEBUG logging. > > One last thing I forgot to mention earlier is that this does require changing the message ids. The range for these ids are defined as part of the message logger (the interface) via annotation. As we move messages to a different (modular) logger class the id range has to change. This only affects (is only supposed to affect[1]) message loggers (INFO/WARN/ERROR), not info logging (TRACE/DEBUG). > > > [1] Historically we have only used message loggers (with ids) for INFO/WARN/ERROR. Some of the more recent changes by Guillaume change that a bit and moved a few message logger messages to be DEBUG. I think this is another thing we should nail down moving forward - do we want TRACE/DEBUG logging to potentially be messaged (with id) logs? > > > > > On Fri, Sep 28, 2018 at 10:46 AM Sanne Grinovero wrote: >> >> On Fri, 28 Sep 2018 at 16:43, Steve Ebersole wrote: >> > >> > Thanks for the feedback! >> >> I'm actually sorry for the delay :) Just back from 2 weeks off, catching up. >> >> > WRT effort, the plan is to make these changes as I do work in a particular area which is what I have been doing - not a "one shot, go back and change all logging". >> >> +1 >> >> > WRT granularity, sure that would be a concern. It really comes back to having a good "logical" design of the logger name hierarchy. >> > >> > WRT coordination, yep - https://github.com/sebersole/hibernate-core/blob/wip/6.0/logger_id_ranges.adoc >> >> Awesome! >> >> Thanks, >> Sanne >> >> > >> > On Fri, Sep 28, 2018 at 10:35 AM Sanne Grinovero wrote: >> >> >> >> Hi Steve, >> >> >> >> I love the cathegories idea; I think we discussed it before. My only >> >> concern is that it's a lot of work to implement, but if you feel it's >> >> doable that's great. >> >> >> >> In terms of "changes needed" I'm not worried either. Like you said, 6 >> >> would have had different names for most cases; at least moving forward >> >> such names would be more stable even if we decide to move some code in >> >> the future. >> >> >> >> One doubt is the granularity. I guess the risk is that maintainers >> >> will tend to reuse the same limited set of cathegories; we will need >> >> to make sure there are enough cathegories so that people can still >> >> enable the single aspect they might be interested in debugging, but >> >> maybe that's not important as people can always post-filter things >> >> when the output gets too verbose. >> >> >> >> We will need a way to coordinate on valid ranges for the various >> >> @ValidIdRange. Infinispan used a wiki for this; the upside is that >> >> it's out of the repository: a good thing to avoid reuse across repo >> >> branches - e.g. it's not ideal to have to change ids when backporting >> >> - , but downside of requiring human care. >> >> >> >> Thanks, >> >> Sanne >> >> >> >> >> >> On Wed, 19 Sep 2018 at 14:31, Steve Ebersole wrote: >> >> > >> >> > Yes. As I mentioned in my original, this would mean potential changes for >> >> > people configuring logging. I've started doing this for new logging in 6 >> >> > and it works great. >> >> > >> >> > Mainly asking opinions about changing existing logging and whether the >> >> > benefits are worth the effort. >> >> > >> >> > And keep in mind that the many many changes in 6 already would require such >> >> > logging config changes anyway for those configuring logging >> >> > >> >> > >> >> > On Wed, Sep 19, 2018, 12:50 AM Vlad Mihalcea >> >> > wrote: >> >> > >> >> > > I think it's a good idea. >> >> > > >> >> > > However, will this break all current applications that use the package >> >> > > name log appenders? >> >> > > >> >> > > Vlad >> >> > > >> >> > > On Fri, Sep 14, 2018 at 7:20 PM, Steve Ebersole >> >> > > wrote: >> >> > > >> >> > >> Yes, I know no one likes talking about logging. "Its not important", >> >> > >> until >> >> > >> it is ;) >> >> > >> >> >> > >> TLDR I am considering moving to using "module names" for logger names >> >> > >> instead of Class names even for DEBUG/TRACE logging and see if anyone had >> >> > >> strong arguments to not do this.. >> >> > >> >> >> > >> Full version--- >> >> > >> >> >> > >> For some time I have been moving to an approach of defining message >> >> > >> loggers[1] using a single contract per function or "module" - e.g.: >> >> > >> >> >> > >> 1. the second level caching module uses the dedicated message logger >> >> > >> `ConnectionPoolingLogger` >> >> > >> 2. the ManagedBeanRegistry module uses the dedicated message logger >> >> > >> `BeansMessageLogger` >> >> > >> 3. etc >> >> > > >> >> > > >> >> > >> >> >> > >> Each of these define a dedicate instance instance they can use. E.g. >> >> > >> ConnectionPoolingLogger is defined as: >> >> > >> >> >> > >> ```` >> >> > >> @MessageLogger( projectCode = "HHH" ) >> >> > >> @ValidIdRange( min = 10001001, max = 10001500 ) >> >> > >> public interface ConnectionPoolingLogger extends BasicLogger { >> >> > >> >> >> > >> ConnectionPoolingLogger CONNECTIONS_LOGGER = Logger.getMessageLogger( >> >> > >> ConnectionPoolingLogger.class, >> >> > >> "org.hibernate.orm.connections.pooling" >> >> > >> ); >> >> > >> >> >> > >> ... >> >> > >> } >> >> > >> ```` >> >> > >> >> >> > >> I won't get into all the whys I do this unless someone cares ;) >> >> > >> >> >> > >> But I am contemplating doing the same for basic loggers so I wanted to ask >> >> > >> everyone else's opinion since this means a change in how you'd have to >> >> > >> configure logging for DEBUG/TRACE output. Usually you'd use the Class >> >> > >> name >> >> > >> as the logger name and use that to control logging in the back-end (log4j, >> >> > >> etc). If I do this, you'd have to instead use the module name. >> >> > >> >> >> > >> There are quite a few reasons I am considering this, including all of the >> >> > >> reasons I did it for message loggers in the first place. If I am >> >> > >> debugging the loading of a collection or an entity, today I'd have to know >> >> > >> all the packages involved (there is no common root name) and list them in >> >> > >> my log4j.properties; that is because the process is ultimately handled by >> >> > >> delegates or helpers in many different packages (`org.hibernate.loader`, >> >> > >> `org.hibernate.persister`, `org.hibernate.type`, ...). It sure would be >> >> > >> nice to just be able to say `org.hibernate.loading` or >> >> > >> `org.hibernate.loading.entity` or `org.hibernate.loading.collection` or >> >> > >> ... >> >> > >> for a number of reasons: >> >> > >> >> >> > >> 1. When we need to see logging from someone it is a lot easier to tell >> >> > >> the module name(s) you need enabled as opposed a list of package and >> >> > >> class >> >> > >> names. >> >> > >> 2. When running JPA TCK it is essentially impossible to attach debugger >> >> > >> to step through code when debugging a failure - you have to rely on >> >> > >> debugging through output. *Well that used to be the case, but the >> >> > >> latest TCK broke logging to STDOUT somehow so we ended up having to >> >> > >> try and >> >> > >> reproduce the failure in our testsuite - so then it does not matter >> >> > >> either >> >> > >> way ;)* >> >> > >> 3. Easier to document - >> >> > >> >> >> > >> http://docs.jboss.org/hibernate/orm/5.3/topical/html_single/logging/Logging.html >> >> > >> >> >> > >> Thoughts? >> >> > >> >> >> > >> >> >> > >> [1] JBoss Logging's `org.jboss.logging.annotations.MessageLogger` - which >> >> > >> we use for user-focused log messages. Should always be logged at >= INFO >> >> > >> [2] >> >> > >> [3] JBoss Logging's `org.jboss.logging.BasicLogger` - which we use for >> >> > >> developer-focused log messages (for debugging). Should always be logged >> >> > >> at >> >> > >> DEBUG or TRACE >> >> > >> _______________________________________________ >> >> > >> hibernate-dev mailing list >> >> > >> hibernate-dev at lists.jboss.org >> >> > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >> > >> >> >> > > >> >> > > >> >> > _______________________________________________ >> >> > hibernate-dev mailing list >> >> > hibernate-dev at lists.jboss.org >> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev From gunnar at hibernate.org Wed Jan 16 07:40:18 2019 From: gunnar at hibernate.org (Gunnar Morling) Date: Wed, 16 Jan 2019 13:40:18 +0100 Subject: [hibernate-dev] Chat migration - D minus 115 until the death of HipChat In-Reply-To: References: Message-ID: Does anyone know whether/how I could export all my existing chat logs from HipChat? I'd like to keep a copy esp. of all 1:1 chats I had, if that's possible. Thanks for any hints, --Gunnar Am Do., 6. Dez. 2018 um 17:03 Uhr schrieb Yoann Rodiere : > > > Hey wait a second :) You invited us to try Gitter. That's fine but we > > never decided we're migrating to Gitter. > > Sure. What I meant was that we are *de facto* done migrating to gitter. Not > that we meant it, but almost everyone is there already and almost no one is > on HipChat. > > I wouldn't expect important matters to be discussed on Gitter, but then > again I seem to remember someone (who was that? ;) ) telling me to use the > mailing list, and not HipChat, for important matters. So, you should be > fine. > > That being said, even if the decision to migrate was not made, we will have > to make it at some point. So if you want something else, I'd be happy to > hear about that :) > > Yoann Rodi?re > Hibernate NoORM Team > yoann at hibernate.org > > > On Thu, 6 Dec 2018 at 16:16, Steve Ebersole wrote: > > > I am never on HipChat at this point. So don't expect any important > > matters to be discussed there ;) > > > > > > On Thu, Dec 6, 2018 at 9:08 AM Sanne Grinovero > > wrote: > > > >> On Thu, 6 Dec 2018 at 10:25, Yoann Rodiere wrote: > >> > > >> > > You also need to use ctrl+enter to send a message, the default enter > >> is a > >> > new line in your message > >> > > >> > There's a checkbox to change that, and its value is persisted, so you > >> only > >> > have to tick it once. It's located just beside the "Send" button, I'm > >> sure > >> > you saw it :) > >> > But apart from that, yes, I agree it's not very user-friendly. It's more > >> > about the user getting used to the tool than the tool being made obvious > >> > from the start. > >> > > >> > I'm also unsure how long Gitter will continue to be maintained, and how > >> > well it will be. But we're mostly done migrating to Gitter; I don't see > >> > much activity on HipChat anymore. > >> > >> Hey wait a second :) You invited us to try Gitter. That's fine but we > >> never decided we're migrating to Gitter. > >> > >> I'm certainly not on Gitter regularly nor right now, so I'm expecting > >> any important matter to be discussed on mailing lists or HipChat. > >> > >> > > >> > Objectively, and regardless of my preferred tool, the main drawback I > >> can > >> > see about not moving to Zulip (or another tool) now, but only later, is > >> the > >> > confusion it will potentially create for users: we were on HipChat, > >> > announced we were moving to Gitter and changed the links on our website, > >> > and a few months later we move again. That is, I think, something we > >> want > >> > to avoid. > >> > > >> > So the question really is: is Gitter the right tool for us, and do we > >> trust > >> > it to stay the right tool for us long enough (say, at least a couple of > >> > years)? > >> > > >> > Yoann Rodi?re > >> > Hibernate NoORM Team > >> > yoann at hibernate.org > >> > > >> > > >> > On Thu, 6 Dec 2018 at 10:41, Guillaume Smet > >> > wrote: > >> > > >> > > So, I'm using Zulip right now on a daily basis. > >> > > > >> > > I maintain my first impression that it's really not user friendly. > >> > > > >> > > The fact that you are required to create topics for discussions (or > >> find a > >> > > suitable topic in a list of a gazillion topics previously created, > >> > > obviously without a search engine where you need it - you have a > >> global one > >> > > at the top where you can find topics) is a pain. You also need to use > >> > > ctrl+enter to send a message, the default enter is a new line in your > >> > > message. The UI is not very good and I don't see any improvement > >> since the > >> > > last time I tested it so I'm wondering if they are investing in it. > >> > > > >> > > We could decide to use it as a dev team as I suppose we would get > >> used to > >> > > it, but I seriously don't think it's a good alternative for our users > >> to > >> > > occasionally come chat with us. > >> > > > >> > > As for Gitter, I agree with the notification issue, the web client is > >> all > >> > > buggy. Haven't tested the desktop client yet. > >> > > > >> > > I must admit that I prefer using Gitter. Probably until I get bitten > >> by > >> > > the 1-1 history issue :). > >> > > > >> > > From what I can see, GitLab doesn't invest much in Gitter either so I > >> > > wonder if it's gonna be viable in the long term. > >> > > > >> > > I suppose we'll see. > >> > > > >> > > -- > >> > > Guillaume > >> > > > >> > > On Thu, Dec 6, 2018 at 8:58 AM Yoann Rodiere > >> wrote: > >> > > > >> > >> The WildFly team is moving from Slack to Zulip, because Zulip seems > >> to be > >> > >> the only solution that is free, provides unlimited history, and > >> allows > >> > >> unlimited users even in private rooms (for OSS projects, at least). > >> Gitter > >> > >> has all that, except unlimited users, as we are limited to 25 people > >> per > >> > >> private room. > >> > >> > >> > >> You can join them here: https://wildfly.zulipchat.com/ > >> > >> > >> > >> Back to our solution... We are now 71 days away from the > >> decommissioning > >> > >> of > >> > >> HipChat. *Is everyone happy with Gitter?* Do you see a strong reason > >> to > >> > >> keep looking for another solution? > >> > >> > >> > >> For my part, I noticed problems with the web client, in particular > >> with > >> > >> notifications, which are sub-standard, but with the desktop client > >> > >> everything seems to work fine. It's simple, but it does the job. > >> > >> > >> > >> Yoann Rodi?re > >> > >> Hibernate NoORM Team > >> > >> yoann at hibernate.org > >> > >> > >> > >> > >> > >> On Wed, 21 Nov 2018 at 14:40, Yoann Rodiere > >> wrote: > >> > >> > >> > >> > On top of not being able to add more than 25 people to a private > >> room, > >> > >> > there's another limitation of Gitter that Fabio just noticed: the > >> chat > >> > >> > history for 1-to-1 conversations is very limited. In our case, we > >> can > >> > >> only > >> > >> > see 2 days back, and there's no concept of archives like there is > >> in > >> > >> rooms. > >> > >> > > >> > >> > Meanwhile, the WildFly team is giving up on Slack because of the > >> very > >> > >> > limited size of history in free plans. They are investigating > >> Zulip, > >> > >> > RocketChat and MatterMost in particular. Maybe let's see what they > >> end > >> > >> up > >> > >> > choosing and why? > >> > >> > > >> > >> > Yoann Rodi?re > >> > >> > Hibernate NoORM Team > >> > >> > yoann at hibernate.org > >> > >> > > >> > >> > > >> > >> > On Tue, 13 Nov 2018 at 11:33, Yoann Rodiere > >> > >> wrote: > >> > >> > > >> > >> >> On Tue, 13 Nov 2018 at 08:49, Yoann Rodiere > >> > >> wrote: > >> > >> >> > >> > >> >>> > Assuming the new chat platform takes off, there's a risk it > >> might be > >> > >> >>> too successful as well > >> > >> >>> > >> > >> >>> Ok. Well, I guess we'll see. As I mentioned above, I don't think > >> > >> forcing > >> > >> >>> people to have a GitHub account will be very effective, but I > >> can't > >> > >> suggest > >> > >> >>> a perfect solution either. Bots answering with a few links > >> > >> (documentation, > >> > >> >>> etc.) to the first message of each user come to mind, but that > >> could > >> > >> be > >> > >> >>> considered rude, so I wouldn't do that unless the traffic becomes > >> > >> >>> unmanageable. Other solutions include kicking out "spammers" > >> (but that > >> > >> >>> doesn't work if it's many users asking a single question), or > >> making > >> > >> the > >> > >> >>> -dev rooms invite-only and only checking the user rooms once in a > >> > >> while > >> > >> >>> (might work if Gitter sends emails when your are mentioned while > >> > >> offline). > >> > >> >>> So, yeah, in short: I don't really know. > >> > >> >>> > >> > >> >>> > More just accountability. But if some form of login in needed > >> to > >> > >> use > >> > >> >>> Gitter, that's enough for me. Sounded like the other option was > >> > >> "allow > >> > >> >>> anonymous", which I wanted to avoid. > >> > >> >>> > >> > >> >>> Then it should be fine: anonymous access apparently only allows > >> to > >> > >> read > >> > >> >>> messages. Login through GitLab, GitHub or Twitter is necessary in > >> > >> order to > >> > >> >>> start posting new messages. > >> > >> >>> > >> > >> >>> Yoann Rodi?re > >> > >> >>> Hibernate NoORM Team > >> > >> >>> yoann at hibernate.org > >> > >> >>> > >> > >> >>> > >> > >> >>> On Mon, 12 Nov 2018 at 19:34, Steve Ebersole < > >> steve at hibernate.org> > >> > >> >>> wrote: > >> > >> >>> > >> > >> >>>> For me its not so much about "the right kind of people". More > >> just > >> > >> >>>> accountability. But if some form of login in needed to use > >> Gitter, > >> > >> that's > >> > >> >>>> enough for me. Sounded like the other option was "allow > >> anonymous", > >> > >> which > >> > >> >>>> I wanted to avoid. > >> > >> >>>> > >> > >> >>>> On Mon, Nov 12, 2018 at 11:41 AM Sanne Grinovero < > >> > >> sanne at hibernate.org> > >> > >> >>>> wrote: > >> > >> >>>> > >> > >> >>>>> On Mon, 12 Nov 2018 at 17:27, Yoann Rodiere < > >> yoann at hibernate.org> > >> > >> >>>>> wrote: > >> > >> >>>>> > > >> > >> >>>>> > I don't see why we should force people to have a GitHub > >> account, > >> > >> >>>>> considering there are other means of logging into Gitter. > >> > >> >>>>> > >> > >> >>>>> Ok. > >> > >> >>>>> > >> > >> >>>>> > > >> > >> >>>>> > As to getting the right type of people, I'm not sure it's > >> > >> relevant. > >> > >> >>>>> Most people are likely to have one, and those who don't are > >> likely > >> > >> to not > >> > >> >>>>> have one for political reasons (think free software extremists) > >> > >> rather than > >> > >> >>>>> because they aren't tech savvy enough: while the "hibernate" > >> naming > >> > >> might > >> > >> >>>>> confuse users looking for information about grizzly bears, I > >> doubt > >> > >> my > >> > >> >>>>> grandmother, my 7-year-old nephew or even my > >> non-software-engineer > >> > >> of a > >> > >> >>>>> wife would end up on Gitter by mistake. > >> > >> >>>>> > >> > >> >>>>> Well since that's obvious, clearly I was referring to a > >> different > >> > >> way > >> > >> >>>>> of cathegorizing people joining@ not by age or expertise in > >> > >> technology > >> > >> >>>>> but in having reasonable expectations and willing to do some > >> > >> research > >> > >> >>>>> before bothering us all. > >> > >> >>>>> > >> > >> >>>>> You probably weren't around yet, but Hibernate has had hard > >> times in > >> > >> >>>>> which it was "victim of its own success": just too many > >> > >> >>>>> kinda-interested people making a ton of basic questions that > >> could > >> > >> be > >> > >> >>>>> easily solved otherwise. > >> > >> >>>>> > >> > >> >>>>> Some "barriers" we have in place have made it manageable; of > >> course > >> > >> I > >> > >> >>>>> can't tell if it's all merit of the barriers of entry or just > >> people > >> > >> >>>>> coming in lower volumes with better intentions, but I'm > >> confident > >> > >> that > >> > >> >>>>> some of the barriers we have have helped to keep some sanity > >> (e.g. > >> > >> >>>>> login on #hibernate-dev on IRC requiring an account). > >> > >> >>>>> > >> > >> >>>>> Assuming the new chat platform takes off, there's a risk it > >> might be > >> > >> >>>>> too successful as well. But I guess we'll see, or let's use a > >> very > >> > >> >>>>> bad chat platform so to keep people from coming :P > >> > >> >>>>> > >> > >> >>>>> > > >> > >> >>>>> > > >> > >> >>>>> > Yoann Rodi?re > >> > >> >>>>> > Hibernate NoORM Team > >> > >> >>>>> > yoann at hibernate.org > >> > >> >>>>> > > >> > >> >>>>> > > >> > >> >>>>> > On Mon, 12 Nov 2018 at 18:02, Sanne Grinovero < > >> > >> sanne at hibernate.org> > >> > >> >>>>> wrote: > >> > >> >>>>> >> > >> > >> >>>>> >> On Mon, 12 Nov 2018 at 16:02, Steve Ebersole < > >> > >> steve at hibernate.org> > >> > >> >>>>> wrote: > >> > >> >>>>> >> > > >> > >> >>>>> >> > What is it a conscious decision to not require a GitHub > >> account > >> > >> >>>>> to join these rooms? I just noticed that is a toggle-option > >> in the > >> > >> room's > >> > >> >>>>> settings also. > >> > >> >>>>> >> > >> > >> >>>>> >> I don't remember. We created these rooms as an experiment in > >> > >> 2014.. > >> > >> >>>>> >> Yoann created some more rooms recently. > >> > >> >>>>> >> > >> > >> >>>>> >> Should we enforce people to have a Github account? I'd like > >> > >> that, I > >> > >> >>>>> >> think it would better nudge towards getting the right type > >> of > >> > >> people > >> > >> >>>>> >> to join. > >> > >> >>>>> >> > >> > >> >>>>> >> Thanks, > >> > >> >>>>> >> Sanne > >> > >> >>>>> >> > >> > >> >>>>> >> > >> > >> >>>>> >> > > >> > >> >>>>> >> > On Mon, Nov 12, 2018 at 6:17 AM Guillaume Smet < > >> > >> >>>>> guillaume.smet at gmail.com> wrote: > >> > >> >>>>> >> >> > >> > >> >>>>> >> >> On Mon, Nov 12, 2018 at 11:35 AM Sanne Grinovero < > >> > >> >>>>> sanne at hibernate.org> > >> > >> >>>>> >> >> wrote: > >> > >> >>>>> >> >> > >> > >> >>>>> >> >> > If one wants a lot of features then clearly only Slack > >> is > >> > >> the > >> > >> >>>>> way to > >> > >> >>>>> >> >> > go. Not saying we should go with Slack, just that > >> we'll need > >> > >> >>>>> to be > >> > >> >>>>> >> >> > patient and we'll always be short of some features - if > >> > >> that's > >> > >> >>>>> not > >> > >> >>>>> >> >> > acceptable then only Slack will make you happy. > >> > >> >>>>> >> >> > > >> > >> >>>>> >> >> > >> > >> >>>>> >> >> TBH, I don't care about fancy features. Gitter is OK for > >> me > >> > >> but > >> > >> >>>>> yeah not > >> > >> >>>>> >> >> having sound is really annoying. > >> > >> >>>>> >> >> > >> > >> >>>>> >> >> I might miss notifications from time to time. > >> > >> >>>>> >> >> > >> > >> >>>>> >> >> In any case, it will mostly be a problem for you all if > >> you > >> > >> ping > >> > >> >>>>> me :). > >> > >> >>>>> >> >> > >> > >> >>>>> >> >> > >> > >> >>>>> >> >> > BTW the issue you linked to suggests the native clients > >> > >> don't > >> > >> >>>>> have > >> > >> >>>>> >> >> > this specific problem.. might want to try that? > >> > >> >>>>> >> >> > > >> > >> >>>>> >> >> > >> > >> >>>>> >> >> I prefer to have it in the browser where I do most of my > >> > >> >>>>> interactions with > >> > >> >>>>> >> >> people. > >> > >> >>>>> >> >> > >> > >> >>>>> >> >> And AFAIK, Yoann wrote they were only packaged as deb > >> (and not > >> > >> >>>>> very excited > >> > >> >>>>> >> >> about compiling it). > >> > >> >>>>> >> >> > >> > >> >>>>> >> >> BTW, tbh, I'm a bit worried GitLab has only one dev on > >> it if > >> > >> >>>>> they want to > >> > >> >>>>> >> >> become a player in this area. They certainly have some > >> work to > >> > >> >>>>> do to catch > >> > >> >>>>> >> >> up with others. > >> > >> >>>>> >> >> > >> > >> >>>>> >> >> -- > >> > >> >>>>> >> >> Guillaume > >> > >> >>>>> >> >> _______________________________________________ > >> > >> >>>>> >> >> hibernate-dev mailing list > >> > >> >>>>> >> >> hibernate-dev at lists.jboss.org > >> > >> >>>>> >> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > >> > >> >>>>> >> _______________________________________________ > >> > >> >>>>> >> hibernate-dev mailing list > >> > >> >>>>> >> hibernate-dev at lists.jboss.org > >> > >> >>>>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > >> > >> >>>>> > >> > >> >>>> > >> > >> _______________________________________________ > >> > >> hibernate-dev mailing list > >> > >> hibernate-dev at lists.jboss.org > >> > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > >> > > > >> > > > >> > _______________________________________________ > >> > hibernate-dev mailing list > >> > hibernate-dev at lists.jboss.org > >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev > >> > >> _______________________________________________ > >> hibernate-dev mailing list > >> hibernate-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From sanne at hibernate.org Wed Jan 16 08:56:29 2019 From: sanne at hibernate.org (Sanne Grinovero) Date: Wed, 16 Jan 2019 13:56:29 +0000 Subject: [hibernate-dev] Chat migration - D minus 115 until the death of HipChat In-Reply-To: References: Message-ID: On Wed, 16 Jan 2019 at 12:55, Gunnar Morling wrote: > > Does anyone know whether/how I could export all my existing chat logs > from HipChat? I'd like to keep a copy esp. of all 1:1 chats I had, if > that's possible. Copy & Paste ? Such a powerful tool :) If you're really lazy you could file a GDPR demand for your data.. > > Thanks for any hints, > > --Gunnar > > Am Do., 6. Dez. 2018 um 17:03 Uhr schrieb Yoann Rodiere : > > > > > Hey wait a second :) You invited us to try Gitter. That's fine but we > > > never decided we're migrating to Gitter. > > > > Sure. What I meant was that we are *de facto* done migrating to gitter. Not > > that we meant it, but almost everyone is there already and almost no one is > > on HipChat. > > > > I wouldn't expect important matters to be discussed on Gitter, but then > > again I seem to remember someone (who was that? ;) ) telling me to use the > > mailing list, and not HipChat, for important matters. So, you should be > > fine. > > > > That being said, even if the decision to migrate was not made, we will have > > to make it at some point. So if you want something else, I'd be happy to > > hear about that :) > > > > Yoann Rodi?re > > Hibernate NoORM Team > > yoann at hibernate.org > > > > > > On Thu, 6 Dec 2018 at 16:16, Steve Ebersole wrote: > > > > > I am never on HipChat at this point. So don't expect any important > > > matters to be discussed there ;) > > > > > > > > > On Thu, Dec 6, 2018 at 9:08 AM Sanne Grinovero > > > wrote: > > > > > >> On Thu, 6 Dec 2018 at 10:25, Yoann Rodiere wrote: > > >> > > > >> > > You also need to use ctrl+enter to send a message, the default enter > > >> is a > > >> > new line in your message > > >> > > > >> > There's a checkbox to change that, and its value is persisted, so you > > >> only > > >> > have to tick it once. It's located just beside the "Send" button, I'm > > >> sure > > >> > you saw it :) > > >> > But apart from that, yes, I agree it's not very user-friendly. It's more > > >> > about the user getting used to the tool than the tool being made obvious > > >> > from the start. > > >> > > > >> > I'm also unsure how long Gitter will continue to be maintained, and how > > >> > well it will be. But we're mostly done migrating to Gitter; I don't see > > >> > much activity on HipChat anymore. > > >> > > >> Hey wait a second :) You invited us to try Gitter. That's fine but we > > >> never decided we're migrating to Gitter. > > >> > > >> I'm certainly not on Gitter regularly nor right now, so I'm expecting > > >> any important matter to be discussed on mailing lists or HipChat. > > >> > > >> > > > >> > Objectively, and regardless of my preferred tool, the main drawback I > > >> can > > >> > see about not moving to Zulip (or another tool) now, but only later, is > > >> the > > >> > confusion it will potentially create for users: we were on HipChat, > > >> > announced we were moving to Gitter and changed the links on our website, > > >> > and a few months later we move again. That is, I think, something we > > >> want > > >> > to avoid. > > >> > > > >> > So the question really is: is Gitter the right tool for us, and do we > > >> trust > > >> > it to stay the right tool for us long enough (say, at least a couple of > > >> > years)? > > >> > > > >> > Yoann Rodi?re > > >> > Hibernate NoORM Team > > >> > yoann at hibernate.org > > >> > > > >> > > > >> > On Thu, 6 Dec 2018 at 10:41, Guillaume Smet > > >> > wrote: > > >> > > > >> > > So, I'm using Zulip right now on a daily basis. > > >> > > > > >> > > I maintain my first impression that it's really not user friendly. > > >> > > > > >> > > The fact that you are required to create topics for discussions (or > > >> find a > > >> > > suitable topic in a list of a gazillion topics previously created, > > >> > > obviously without a search engine where you need it - you have a > > >> global one > > >> > > at the top where you can find topics) is a pain. You also need to use > > >> > > ctrl+enter to send a message, the default enter is a new line in your > > >> > > message. The UI is not very good and I don't see any improvement > > >> since the > > >> > > last time I tested it so I'm wondering if they are investing in it. > > >> > > > > >> > > We could decide to use it as a dev team as I suppose we would get > > >> used to > > >> > > it, but I seriously don't think it's a good alternative for our users > > >> to > > >> > > occasionally come chat with us. > > >> > > > > >> > > As for Gitter, I agree with the notification issue, the web client is > > >> all > > >> > > buggy. Haven't tested the desktop client yet. > > >> > > > > >> > > I must admit that I prefer using Gitter. Probably until I get bitten > > >> by > > >> > > the 1-1 history issue :). > > >> > > > > >> > > From what I can see, GitLab doesn't invest much in Gitter either so I > > >> > > wonder if it's gonna be viable in the long term. > > >> > > > > >> > > I suppose we'll see. > > >> > > > > >> > > -- > > >> > > Guillaume > > >> > > > > >> > > On Thu, Dec 6, 2018 at 8:58 AM Yoann Rodiere > > >> wrote: > > >> > > > > >> > >> The WildFly team is moving from Slack to Zulip, because Zulip seems > > >> to be > > >> > >> the only solution that is free, provides unlimited history, and > > >> allows > > >> > >> unlimited users even in private rooms (for OSS projects, at least). > > >> Gitter > > >> > >> has all that, except unlimited users, as we are limited to 25 people > > >> per > > >> > >> private room. > > >> > >> > > >> > >> You can join them here: https://wildfly.zulipchat.com/ > > >> > >> > > >> > >> Back to our solution... We are now 71 days away from the > > >> decommissioning > > >> > >> of > > >> > >> HipChat. *Is everyone happy with Gitter?* Do you see a strong reason > > >> to > > >> > >> keep looking for another solution? > > >> > >> > > >> > >> For my part, I noticed problems with the web client, in particular > > >> with > > >> > >> notifications, which are sub-standard, but with the desktop client > > >> > >> everything seems to work fine. It's simple, but it does the job. > > >> > >> > > >> > >> Yoann Rodi?re > > >> > >> Hibernate NoORM Team > > >> > >> yoann at hibernate.org > > >> > >> > > >> > >> > > >> > >> On Wed, 21 Nov 2018 at 14:40, Yoann Rodiere > > >> wrote: > > >> > >> > > >> > >> > On top of not being able to add more than 25 people to a private > > >> room, > > >> > >> > there's another limitation of Gitter that Fabio just noticed: the > > >> chat > > >> > >> > history for 1-to-1 conversations is very limited. In our case, we > > >> can > > >> > >> only > > >> > >> > see 2 days back, and there's no concept of archives like there is > > >> in > > >> > >> rooms. > > >> > >> > > > >> > >> > Meanwhile, the WildFly team is giving up on Slack because of the > > >> very > > >> > >> > limited size of history in free plans. They are investigating > > >> Zulip, > > >> > >> > RocketChat and MatterMost in particular. Maybe let's see what they > > >> end > > >> > >> up > > >> > >> > choosing and why? > > >> > >> > > > >> > >> > Yoann Rodi?re > > >> > >> > Hibernate NoORM Team > > >> > >> > yoann at hibernate.org > > >> > >> > > > >> > >> > > > >> > >> > On Tue, 13 Nov 2018 at 11:33, Yoann Rodiere > > >> > >> wrote: > > >> > >> > > > >> > >> >> On Tue, 13 Nov 2018 at 08:49, Yoann Rodiere > > >> > >> wrote: > > >> > >> >> > > >> > >> >>> > Assuming the new chat platform takes off, there's a risk it > > >> might be > > >> > >> >>> too successful as well > > >> > >> >>> > > >> > >> >>> Ok. Well, I guess we'll see. As I mentioned above, I don't think > > >> > >> forcing > > >> > >> >>> people to have a GitHub account will be very effective, but I > > >> can't > > >> > >> suggest > > >> > >> >>> a perfect solution either. Bots answering with a few links > > >> > >> (documentation, > > >> > >> >>> etc.) to the first message of each user come to mind, but that > > >> could > > >> > >> be > > >> > >> >>> considered rude, so I wouldn't do that unless the traffic becomes > > >> > >> >>> unmanageable. Other solutions include kicking out "spammers" > > >> (but that > > >> > >> >>> doesn't work if it's many users asking a single question), or > > >> making > > >> > >> the > > >> > >> >>> -dev rooms invite-only and only checking the user rooms once in a > > >> > >> while > > >> > >> >>> (might work if Gitter sends emails when your are mentioned while > > >> > >> offline). > > >> > >> >>> So, yeah, in short: I don't really know. > > >> > >> >>> > > >> > >> >>> > More just accountability. But if some form of login in needed > > >> to > > >> > >> use > > >> > >> >>> Gitter, that's enough for me. Sounded like the other option was > > >> > >> "allow > > >> > >> >>> anonymous", which I wanted to avoid. > > >> > >> >>> > > >> > >> >>> Then it should be fine: anonymous access apparently only allows > > >> to > > >> > >> read > > >> > >> >>> messages. Login through GitLab, GitHub or Twitter is necessary in > > >> > >> order to > > >> > >> >>> start posting new messages. > > >> > >> >>> > > >> > >> >>> Yoann Rodi?re > > >> > >> >>> Hibernate NoORM Team > > >> > >> >>> yoann at hibernate.org > > >> > >> >>> > > >> > >> >>> > > >> > >> >>> On Mon, 12 Nov 2018 at 19:34, Steve Ebersole < > > >> steve at hibernate.org> > > >> > >> >>> wrote: > > >> > >> >>> > > >> > >> >>>> For me its not so much about "the right kind of people". More > > >> just > > >> > >> >>>> accountability. But if some form of login in needed to use > > >> Gitter, > > >> > >> that's > > >> > >> >>>> enough for me. Sounded like the other option was "allow > > >> anonymous", > > >> > >> which > > >> > >> >>>> I wanted to avoid. > > >> > >> >>>> > > >> > >> >>>> On Mon, Nov 12, 2018 at 11:41 AM Sanne Grinovero < > > >> > >> sanne at hibernate.org> > > >> > >> >>>> wrote: > > >> > >> >>>> > > >> > >> >>>>> On Mon, 12 Nov 2018 at 17:27, Yoann Rodiere < > > >> yoann at hibernate.org> > > >> > >> >>>>> wrote: > > >> > >> >>>>> > > > >> > >> >>>>> > I don't see why we should force people to have a GitHub > > >> account, > > >> > >> >>>>> considering there are other means of logging into Gitter. > > >> > >> >>>>> > > >> > >> >>>>> Ok. > > >> > >> >>>>> > > >> > >> >>>>> > > > >> > >> >>>>> > As to getting the right type of people, I'm not sure it's > > >> > >> relevant. > > >> > >> >>>>> Most people are likely to have one, and those who don't are > > >> likely > > >> > >> to not > > >> > >> >>>>> have one for political reasons (think free software extremists) > > >> > >> rather than > > >> > >> >>>>> because they aren't tech savvy enough: while the "hibernate" > > >> naming > > >> > >> might > > >> > >> >>>>> confuse users looking for information about grizzly bears, I > > >> doubt > > >> > >> my > > >> > >> >>>>> grandmother, my 7-year-old nephew or even my > > >> non-software-engineer > > >> > >> of a > > >> > >> >>>>> wife would end up on Gitter by mistake. > > >> > >> >>>>> > > >> > >> >>>>> Well since that's obvious, clearly I was referring to a > > >> different > > >> > >> way > > >> > >> >>>>> of cathegorizing people joining@ not by age or expertise in > > >> > >> technology > > >> > >> >>>>> but in having reasonable expectations and willing to do some > > >> > >> research > > >> > >> >>>>> before bothering us all. > > >> > >> >>>>> > > >> > >> >>>>> You probably weren't around yet, but Hibernate has had hard > > >> times in > > >> > >> >>>>> which it was "victim of its own success": just too many > > >> > >> >>>>> kinda-interested people making a ton of basic questions that > > >> could > > >> > >> be > > >> > >> >>>>> easily solved otherwise. > > >> > >> >>>>> > > >> > >> >>>>> Some "barriers" we have in place have made it manageable; of > > >> course > > >> > >> I > > >> > >> >>>>> can't tell if it's all merit of the barriers of entry or just > > >> people > > >> > >> >>>>> coming in lower volumes with better intentions, but I'm > > >> confident > > >> > >> that > > >> > >> >>>>> some of the barriers we have have helped to keep some sanity > > >> (e.g. > > >> > >> >>>>> login on #hibernate-dev on IRC requiring an account). > > >> > >> >>>>> > > >> > >> >>>>> Assuming the new chat platform takes off, there's a risk it > > >> might be > > >> > >> >>>>> too successful as well. But I guess we'll see, or let's use a > > >> very > > >> > >> >>>>> bad chat platform so to keep people from coming :P > > >> > >> >>>>> > > >> > >> >>>>> > > > >> > >> >>>>> > > > >> > >> >>>>> > Yoann Rodi?re > > >> > >> >>>>> > Hibernate NoORM Team > > >> > >> >>>>> > yoann at hibernate.org > > >> > >> >>>>> > > > >> > >> >>>>> > > > >> > >> >>>>> > On Mon, 12 Nov 2018 at 18:02, Sanne Grinovero < > > >> > >> sanne at hibernate.org> > > >> > >> >>>>> wrote: > > >> > >> >>>>> >> > > >> > >> >>>>> >> On Mon, 12 Nov 2018 at 16:02, Steve Ebersole < > > >> > >> steve at hibernate.org> > > >> > >> >>>>> wrote: > > >> > >> >>>>> >> > > > >> > >> >>>>> >> > What is it a conscious decision to not require a GitHub > > >> account > > >> > >> >>>>> to join these rooms? I just noticed that is a toggle-option > > >> in the > > >> > >> room's > > >> > >> >>>>> settings also. > > >> > >> >>>>> >> > > >> > >> >>>>> >> I don't remember. We created these rooms as an experiment in > > >> > >> 2014.. > > >> > >> >>>>> >> Yoann created some more rooms recently. > > >> > >> >>>>> >> > > >> > >> >>>>> >> Should we enforce people to have a Github account? I'd like > > >> > >> that, I > > >> > >> >>>>> >> think it would better nudge towards getting the right type > > >> of > > >> > >> people > > >> > >> >>>>> >> to join. > > >> > >> >>>>> >> > > >> > >> >>>>> >> Thanks, > > >> > >> >>>>> >> Sanne > > >> > >> >>>>> >> > > >> > >> >>>>> >> > > >> > >> >>>>> >> > > > >> > >> >>>>> >> > On Mon, Nov 12, 2018 at 6:17 AM Guillaume Smet < > > >> > >> >>>>> guillaume.smet at gmail.com> wrote: > > >> > >> >>>>> >> >> > > >> > >> >>>>> >> >> On Mon, Nov 12, 2018 at 11:35 AM Sanne Grinovero < > > >> > >> >>>>> sanne at hibernate.org> > > >> > >> >>>>> >> >> wrote: > > >> > >> >>>>> >> >> > > >> > >> >>>>> >> >> > If one wants a lot of features then clearly only Slack > > >> is > > >> > >> the > > >> > >> >>>>> way to > > >> > >> >>>>> >> >> > go. Not saying we should go with Slack, just that > > >> we'll need > > >> > >> >>>>> to be > > >> > >> >>>>> >> >> > patient and we'll always be short of some features - if > > >> > >> that's > > >> > >> >>>>> not > > >> > >> >>>>> >> >> > acceptable then only Slack will make you happy. > > >> > >> >>>>> >> >> > > > >> > >> >>>>> >> >> > > >> > >> >>>>> >> >> TBH, I don't care about fancy features. Gitter is OK for > > >> me > > >> > >> but > > >> > >> >>>>> yeah not > > >> > >> >>>>> >> >> having sound is really annoying. > > >> > >> >>>>> >> >> > > >> > >> >>>>> >> >> I might miss notifications from time to time. > > >> > >> >>>>> >> >> > > >> > >> >>>>> >> >> In any case, it will mostly be a problem for you all if > > >> you > > >> > >> ping > > >> > >> >>>>> me :). > > >> > >> >>>>> >> >> > > >> > >> >>>>> >> >> > > >> > >> >>>>> >> >> > BTW the issue you linked to suggests the native clients > > >> > >> don't > > >> > >> >>>>> have > > >> > >> >>>>> >> >> > this specific problem.. might want to try that? > > >> > >> >>>>> >> >> > > > >> > >> >>>>> >> >> > > >> > >> >>>>> >> >> I prefer to have it in the browser where I do most of my > > >> > >> >>>>> interactions with > > >> > >> >>>>> >> >> people. > > >> > >> >>>>> >> >> > > >> > >> >>>>> >> >> And AFAIK, Yoann wrote they were only packaged as deb > > >> (and not > > >> > >> >>>>> very excited > > >> > >> >>>>> >> >> about compiling it). > > >> > >> >>>>> >> >> > > >> > >> >>>>> >> >> BTW, tbh, I'm a bit worried GitLab has only one dev on > > >> it if > > >> > >> >>>>> they want to > > >> > >> >>>>> >> >> become a player in this area. They certainly have some > > >> work to > > >> > >> >>>>> do to catch > > >> > >> >>>>> >> >> up with others. > > >> > >> >>>>> >> >> > > >> > >> >>>>> >> >> -- > > >> > >> >>>>> >> >> Guillaume > > >> > >> >>>>> >> >> _______________________________________________ > > >> > >> >>>>> >> >> hibernate-dev mailing list > > >> > >> >>>>> >> >> hibernate-dev at lists.jboss.org > > >> > >> >>>>> >> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > >> > >> >>>>> >> _______________________________________________ > > >> > >> >>>>> >> hibernate-dev mailing list > > >> > >> >>>>> >> hibernate-dev at lists.jboss.org > > >> > >> >>>>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > >> > >> >>>>> > > >> > >> >>>> > > >> > >> _______________________________________________ > > >> > >> hibernate-dev mailing list > > >> > >> hibernate-dev at lists.jboss.org > > >> > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > >> > > > > >> > > > > >> > _______________________________________________ > > >> > hibernate-dev mailing list > > >> > hibernate-dev at lists.jboss.org > > >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > >> > > >> _______________________________________________ > > >> hibernate-dev mailing list > > >> hibernate-dev at lists.jboss.org > > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > > > > > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From guillaume.smet at gmail.com Sat Jan 19 12:47:54 2019 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Sat, 19 Jan 2019 18:47:54 +0100 Subject: [hibernate-dev] Releasing 5.4.1.Final Message-ID: Hi, I'm in the process of releasing 5.4.1.Final, please don't push anything to master. Thanks. From guillaume.smet at gmail.com Sat Jan 19 14:26:48 2019 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Sat, 19 Jan 2019 20:26:48 +0100 Subject: [hibernate-dev] Releasing 5.4.1.Final In-Reply-To: References: Message-ID: The release is done. I'll announce it on Monday. On Sat, Jan 19, 2019 at 6:47 PM Guillaume Smet wrote: > Hi, > > I'm in the process of releasing 5.4.1.Final, please don't push anything to > master. > > Thanks. > From sanne at hibernate.org Sat Jan 19 15:41:53 2019 From: sanne at hibernate.org (Sanne Grinovero) Date: Sat, 19 Jan 2019 20:41:53 +0000 Subject: [hibernate-dev] Releasing 5.4.1.Final In-Reply-To: References: Message-ID: great! Thanks Guillaume On Sat, 19 Jan 2019 at 19:27, Guillaume Smet wrote: > > The release is done. > > I'll announce it on Monday. > > On Sat, Jan 19, 2019 at 6:47 PM Guillaume Smet > wrote: > > > Hi, > > > > I'm in the process of releasing 5.4.1.Final, please don't push anything to > > master. > > > > Thanks. > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From rory.odonnell at oracle.com Mon Jan 21 06:24:46 2019 From: rory.odonnell at oracle.com (Rory O'Donnell) Date: Mon, 21 Jan 2019 11:24:46 +0000 Subject: [hibernate-dev] JDK 12 enters Rampdown Phase Two Message-ID: <5fca6d9e-1724-59b8-ae26-83968036e541@oracle.com> Hi Sanne, **OpenJDK builds *- JDK 12 Early Access build 28 **is now available **at : - jdk.java.net/12/* * Per the JDK 12 schedule [1], we are now in Rampdown Phase Two. o For more details , see Mark Reinhold's email to jdk-dev mailing list [2] o The overall feature set is frozen, no further JEPs will be targeted to this release. o Per the JDK Release Process [3] we now turn our focusto P1 and P2 bugs. **OpenJDK builds *- JDK 13 Early Access build 4 is **now available **at : - jdk.java.net/13/* * These early-access, open-source builds are provided under the o GNU General Public License, version?2, with the Classpath Exception . * Release Notes: o http://jdk.java.net/13/release-notes * Changes in this build Blog Updates from Java SE Product Management since last email. * Oracle Java SE Releases FAQ [3] * Oracle Java SE Support Roadmap [4] Rgds,Rory [1] http://openjdk.java.net/projects/jdk/12/#Schedule [2] http://mail.openjdk.java.net/pipermail/jdk-dev/2019-January/002537.html [3] https://blogs.oracle.com/java-platform-group/oracle-java-se-releases-faq [4] https://www.oracle.com/technetwork/java/java-se-support-roadmap.html -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland From guillaume.smet at hibernate.org Tue Jan 22 03:53:14 2019 From: guillaume.smet at hibernate.org (Guillaume Smet) Date: Tue, 22 Jan 2019 09:53:14 +0100 Subject: [hibernate-dev] Hibernate ORM 5.4.1.Final released Message-ID: Hi, We released Hibernate ORM 5.4.1.Final which fixes several bugs and regressions. If you are already using ORM 5.4, it's a very recommended upgrade. All the relevant information is in the announcement: http://in.relation.to/2019/01/22/hibernate-orm-541-final-out/ . Have a nice day. -- Guillaume From guillaume.smet at gmail.com Wed Jan 23 08:39:33 2019 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Wed, 23 Jan 2019 14:39:33 +0100 Subject: [hibernate-dev] Still an issue with Agroal when closing the pool In-Reply-To: References: Message-ID: Hello Luis, Any chance you could take a look at this one? I just got it again on my laptop and it happened quite frequently on our CI lately. AFAICS, it's always failing in the setting isolation test but it can be different test methods. Just had it for AgroalTransactionIsolationConfigTest > testSettingIsolationAsNumericString this time. -- Guillaume On Sat, Jan 5, 2019 at 10:40 PM Guillaume Smet wrote: > Hi Luis, > > We talked at some point about a potential issue in Agroal, you said 1.3 > should have all the known issues solved but apparently, there is still one > as we have transient test failures on ORM from time to time. > > A good example is the following one: > > http://ci.hibernate.org/view/ORM/job/hibernate-orm-master-h2-javassist/lastCompletedBuild/testReport/org.hibernate.test.agroal/AgroalTransactionIsolationConfigTest/testSettingIsolationAsName/ > (it's build #265, haven't found a way to get a stable URL from Jenkins) > > The issue is in this test: > org.hibernate.test.agroal.AgroalTransactionIsolationConfigTest.testSettingIsolationAsName > . > > And we have the following stacktrace when closing the pool: > > java.util.concurrent.RejectedExecutionException: Task java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask at 189a0b8e rejected from io.agroal.pool.util.PriorityScheduledExecutor at 2ded5d2e[Shutting down, pool size = 1, active threads = 0, queued tasks = 1, completed tasks = 2] > at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2063) > at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:830) > at java.util.concurrent.ScheduledThreadPoolExecutor.delayedExecute(ScheduledThreadPoolExecutor.java:326) > at java.util.concurrent.ScheduledThreadPoolExecutor.schedule(ScheduledThreadPoolExecutor.java:533) > at java.util.concurrent.ScheduledThreadPoolExecutor.execute(ScheduledThreadPoolExecutor.java:622) > at io.agroal.pool.util.PriorityScheduledExecutor.executeNow(PriorityScheduledExecutor.java:46) > at io.agroal.pool.util.PriorityScheduledExecutor.executeNow(PriorityScheduledExecutor.java:35) > at io.agroal.pool.util.PriorityScheduledExecutor.shutdown(PriorityScheduledExecutor.java:67) > at io.agroal.pool.ConnectionPool.close(ConnectionPool.java:126) > at io.agroal.pool.DataSource.close(DataSource.java:54) > at org.hibernate.agroal.internal.AgroalConnectionProvider.stop(AgroalConnectionProvider.java:142) > at org.hibernate.testing.common.connections.BaseTransactionIsolationConfigTest.testSettingIsolationAsName(BaseTransactionIsolationConfigTest.java:101) > > > It happens once in a while. I already had the issue locally but lately I > only observed it on CI. > > I suppose it won't be easy to get to the bottom of it but it would be nice > if we could get this fixed. > > Thanks. > > -- > Guillaume > From steve at hibernate.org Tue Jan 29 15:48:22 2019 From: steve at hibernate.org (Steve Ebersole) Date: Tue, 29 Jan 2019 14:48:22 -0600 Subject: [hibernate-dev] Still an issue with Agroal when closing the pool In-Reply-To: References: Message-ID: Have we gotten any reply about this? On Wed, Jan 23, 2019 at 8:58 AM Guillaume Smet wrote: > Hello Luis, > > Any chance you could take a look at this one? > > I just got it again on my laptop and it happened quite frequently on our CI > lately. > > AFAICS, it's always failing in the setting isolation test but it can be > different test methods. Just had it for > AgroalTransactionIsolationConfigTest > testSettingIsolationAsNumericString > this time. > > -- > Guillaume > > On Sat, Jan 5, 2019 at 10:40 PM Guillaume Smet > wrote: > > > Hi Luis, > > > > We talked at some point about a potential issue in Agroal, you said 1.3 > > should have all the known issues solved but apparently, there is still > one > > as we have transient test failures on ORM from time to time. > > > > A good example is the following one: > > > > > http://ci.hibernate.org/view/ORM/job/hibernate-orm-master-h2-javassist/lastCompletedBuild/testReport/org.hibernate.test.agroal/AgroalTransactionIsolationConfigTest/testSettingIsolationAsName/ > > (it's build #265, haven't found a way to get a stable URL from Jenkins) > > > > The issue is in this test: > > > org.hibernate.test.agroal.AgroalTransactionIsolationConfigTest.testSettingIsolationAsName > > . > > > > And we have the following stacktrace when closing the pool: > > > > java.util.concurrent.RejectedExecutionException: Task > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask at 189a0b8e > rejected from io.agroal.pool.util.PriorityScheduledExecutor at 2ded5d2e[Shutting > down, pool size = 1, active threads = 0, queued tasks = 1, completed tasks > = 2] > > at > java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2063) > > at > java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:830) > > at > java.util.concurrent.ScheduledThreadPoolExecutor.delayedExecute(ScheduledThreadPoolExecutor.java:326) > > at > java.util.concurrent.ScheduledThreadPoolExecutor.schedule(ScheduledThreadPoolExecutor.java:533) > > at > java.util.concurrent.ScheduledThreadPoolExecutor.execute(ScheduledThreadPoolExecutor.java:622) > > at > io.agroal.pool.util.PriorityScheduledExecutor.executeNow(PriorityScheduledExecutor.java:46) > > at > io.agroal.pool.util.PriorityScheduledExecutor.executeNow(PriorityScheduledExecutor.java:35) > > at > io.agroal.pool.util.PriorityScheduledExecutor.shutdown(PriorityScheduledExecutor.java:67) > > at io.agroal.pool.ConnectionPool.close(ConnectionPool.java:126) > > at io.agroal.pool.DataSource.close(DataSource.java:54) > > at > org.hibernate.agroal.internal.AgroalConnectionProvider.stop(AgroalConnectionProvider.java:142) > > at > org.hibernate.testing.common.connections.BaseTransactionIsolationConfigTest.testSettingIsolationAsName(BaseTransactionIsolationConfigTest.java:101) > > > > > > It happens once in a while. I already had the issue locally but lately I > > only observed it on CI. > > > > I suppose it won't be easy to get to the bottom of it but it would be > nice > > if we could get this fixed. > > > > Thanks. > > > > -- > > Guillaume > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From guillaume.smet at gmail.com Tue Jan 29 16:30:20 2019 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Tue, 29 Jan 2019 22:30:20 +0100 Subject: [hibernate-dev] Still an issue with Agroal when closing the pool In-Reply-To: References: Message-ID: On Tue, Jan 29, 2019 at 9:48 PM Steve Ebersole wrote: > Have we gotten any reply about this? > No. From steve at hibernate.org Wed Jan 30 09:43:54 2019 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 30 Jan 2019 08:43:54 -0600 Subject: [hibernate-dev] Still an issue with Agroal when closing the pool In-Reply-To: References: Message-ID: I hate to be overly reactionary, but we we may want to consider dropping that module then. If there is a bug and we cannot get in touch with him to figure it out then we cannot really suppport it On Tue, Jan 29, 2019 at 3:31 PM Guillaume Smet wrote: > On Tue, Jan 29, 2019 at 9:48 PM Steve Ebersole > wrote: > >> Have we gotten any reply about this? >> > > No. > From lbarreiro at redhat.com Wed Jan 30 11:43:43 2019 From: lbarreiro at redhat.com (Luis Barreiro) Date: Wed, 30 Jan 2019 16:43:43 +0000 Subject: [hibernate-dev] Still an issue with Agroal when closing the pool In-Reply-To: References: Message-ID: Hi, Although I have not experienced that particular issue in Agroal (either locally or in the CI), I was aware that the race condition that was mitigated in 1.3 could still happen. I've long reworked the shutdown code so the issue is completely gone. It just happens that I'm about to release Agroal 1.4 that will include this fix. Regards, Luis Barreiro Middleware Performance Team On 1/30/19 2:43 PM, Steve Ebersole wrote: > I hate to be overly reactionary, but we we may want to consider > dropping that module then.? If there is a bug and we cannot get in > touch with him to figure it out then we cannot really suppport it > > On Tue, Jan 29, 2019 at 3:31 PM Guillaume Smet > > wrote: > > On Tue, Jan 29, 2019 at 9:48 PM Steve Ebersole > > wrote: > > Have we gotten any reply about this? > > > No. >