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
-> 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:
-> 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
-> 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.
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
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
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`, 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.
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.
hibernate-dev mailing list