On Thu, 10 Jan 2019 at 01:44, Steve Ebersole <st...@hibernate.org> wrote: > > I disagree that logging a single message is a better solution because that > probably ends up wrapping multiple lines, just as your sample happened to do > in the email. IMO that is actually more difficult to read.
Ok keep it in one line if you prefer. No strong preference on how it's presented, but I think it's a big mistake to hide essential diagnostics: "paste the logs" is often useful when helping someone; it gets much harder if you first have to change categories. > And I just do not understand this idea that we have to direct people to > enable logging to track down problems. This is a non-argument to me. I can understand were you're coming from, but that's how most support people work. Let's try to be nice to them :) > As for what logger to use... that is definitely a concern, though its not > really any different than we have today. If I refactor an internal class > (because, well, its internal) - that almost always will affect logging on the > user's end. It's one of the reasons I started looking at using "symbolic" > logger names. Which of course is its own concern. +1 those symbolic loggers are a great idea. But then please don't hide this information at least until we have those easier logger categories: Guillaume is set to patch 5.4x - which doesn't have them yet. Thanks, Sanne > > On Wed, Jan 9, 2019 at 12:54 PM Guillaume Smet <guillaume.s...@gmail.com> > wrote: >> >> Pretty good idea but definitely too much work for the effort I want to put >> in it right now. >> >> But, yes, we can do that for version 7.0.1.Final, I like your example :). >> >> I will make a proposal to reduce the log verbosity (enhanced classes, >> hibernate.properties missing and a few others) but keep the important >> diagnostic information as is. >> >> On Wed, Jan 9, 2019 at 2:23 PM Sanne Grinovero <sa...@hibernate.org> wrote: >> >> > +1 to polish output, but: >> > >> > I don't want to need to figure out how to reconfigure whatever Logger >> > of the day one happens to hit, to finally notice that essential >> > configuration details are wrong. Mostly because it requires to get the >> > idea to actually check this, which is not a straightforward thought >> > when all you observe is some odd behaviour. >> > >> > Not least, big we don't want to have to go back to supported customers >> > and community members who have a problem with a "can you change the >> > log levels as I'm missing essential information": that's a huge waste >> > of time especially if we're having an exchange across timezones. >> > >> > Could we rather collect essential info and then print it all out as a >> > single message? >> > >> > "Hibernate ORM ready and operational! [version: 7.0.1.Final, >> > Transaction mode: JTA, Dialect: PostgreSQL2020, Caching: enabled]" >> > >> > Also I'd question that "verbosity" isn't the same as brevity; the >> > focus should be on hiding unnecessary technicalities but showing nicer >> > / better information, so I'd not be shy to use some multi-line >> > information box if that looks better. >> > >> > Thanks, >> > Sanne >> > >> > On Mon, 7 Jan 2019 at 16:14, Guillaume Smet <guillaume.s...@gmail.com> >> > wrote: >> > > >> > > Yeah sure, they will be kept as is just moved to DEBUG. >> > > >> > > The only one that would change is the "Processing PersistenceUnitInfo" >> > > thing: we will remove the INFO one and keep the more detailed DEBUG one. >> > > >> > > BTW, I agree with everything Steve said, sorry for not replying earlier. >> > > >> > > On Mon, Jan 7, 2019 at 4:46 PM Chris Cranford <cranc...@gmail.com> >> > wrote: >> > > >> > > > See below. >> > > > >> > > > On 1/3/19 10:29 AM, Steve Ebersole wrote: >> > > > > [o.h.d.Dialect] (main) HHH000400: Using dialect: >> > > > >> org.hibernate.dialect.PostgreSQL95Dialect >> > > > >> >> > > > >> -> wondering if it has any value to log the dialect? I mean if you >> > don't >> > > > >> use the right one, you will definitely have some issues. >> > > > >> >> > > > > True, but it is probably hard(er) to interpret the true source of the >> > > > > issues later on. >> > > > > >> > > > > However, I think it is reasonable to make this DEBUG. If you have >> > > > problems >> > > > > the first reasonable thing to do is to crank logging to DEBUG if not >> > > > TRACE. >> > > > >> > > > I completely agree. >> > > > >> > > > I think its reasonable to make it DEBUG/TRACE but I don't think I want >> > > > to necessarily change it such that it is no longer included in log >> > > > output at all. Having it be included is a good first-line of defense >> > on >> > > > trying to resolve potential problems not only for us, but even for >> > users >> > > > who are doing their own debugging before reporting an issue; >> > > > particularly if the error in question implies some Dialect >> > configuration >> > > > problem. >> > > > >> > > _______________________________________________ >> > > 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
