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@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
