Thanks for the feedback! 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".
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 On Fri, Sep 28, 2018 at 10:35 AM Sanne Grinovero <sa...@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 <st...@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.v...@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 <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 > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
