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.
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. 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. 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
