10:46 a.m.
On Fri, 28 Sep 2018 at 16:43, Steve Ebersole <steve(a)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...
Awesome!
Thanks,
Sanne
On Fri, Sep 28, 2018 at 10:35 AM Sanne Grinovero <sanne(a)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(a)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(a)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(a)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/Loggi...
> > >>
> > >> 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(a)lists.jboss.org
> > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > >>
> > >
> > >
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev