[hibernate-dev] Loggers

Fri Sep 28 11:29:08 EDT 2018

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