On Thu, 10 Jan 2019 at 01:44, Steve Ebersole <steve(a)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.smet(a)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 <sanne(a)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.smet(a)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 <crancran(a)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(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