[hibernate-dev] Loggers

Fri Sep 28 11:46:02 EDT 2018

On Fri, 28 Sep 2018 at 16:43, Steve Ebersole <steve at hibernate.org> 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 <sanne at hibernate.org> 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 <steve at hibernate.org> 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 <mihalcea.vlad at gmail.com>
>> > 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