[hibernate-dev] Loggers

[Vlad Mihalcea]

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
>