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 <st...@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@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
