A minor nitpick: not logging which entities are being enhanced seems
reasonable when ORM is being booted, but as a user I'd probably expect
to see such output if I'm running an explicit enhancement task via
some of the tooling.
Perhaps you should allow the enhancer tasks to raise these back up to
INFO; maybe the enhancer task should pass in its own enhancement
observer?
They already do log something if a class has been enhanced. Look for
"Successfully enhanced class" in the code.
So I think we are covered here.
--
Guillaume
On Fri, Jan 11, 2019 at 12:04 PM Sanne Grinovero <sanne(a)hibernate.org>
wrote:
> On Fri, 11 Jan 2019 at 09:53, Guillaume Smet <guillaume.smet(a)gmail.com>
> wrote:
> >
> > So what I suggest: if you disagree on a change, just comment on the
> specific line of the PR and I'll revert.
> >
> > I plan to merge that on Tuesday.
>
> I like it. Not merging it yet to get Steve a chance to comment too.
>
A minor nitpick: not logging which entities are being enhanced seems
> reasonable when ORM is being booted, but as a user I'd probably expect
> to see such output if I'm running an explicit enhancement task via
> some of the tooling.
Perhaps you should allow the enhancer tasks to raise these back up to
> INFO; maybe the enhancer task should pass in its own enhancement
> observer?
>
> Thanks Guillaume!
>
> >
> > On Fri, Jan 11, 2019 at 10:24 AM Guillaume Smet <
> guillaume.smet(a)gmail.com> wrote:
> >>
> >> In meeting all day so making progress on dumb stuff.
> >>
> >> Here is a very conservative PR on which I hope we could agree on
> quickly:
> >>
https://github.com/hibernate/hibernate-orm/pull/2728
> >>
> >> --
> >> Guillaume
> >>
> >> On Thu, Jan 10, 2019 at 5:38 PM Steve Ebersole <steve(a)hibernate.org>
> wrote:
> >>>
> >>>
> >>>
> >>> On Thu, Jan 10, 2019 at 10:15 AM Sanne Grinovero
<sanne(a)hibernate.org>
> wrote:
> >>>>
> >>>> 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.
> >>>
> >>>
> >>> You are combining separate things here....
> >>>
> >>> First, *you* are the one that suggested doing it on one line unless I
> have misunderstood. My point is simply that practically speaking that will
> either mean having to read wrapped lines (eww) or scroll horizontally
> (double eww) to read this info. If your desire is to continue present this
> information anyway, then, well, what exactly are we changing? Just making
> it harder to read?
> >>>
> >>> "Diagnostics".. interesting choice of word... if you are
diagnosing
> something that implies that there is a problem you are debugging... but
> here we are talking about boot-time informational logging. Different
> beasts.
> >>>
> >>> If the distinction you are trying to make is that we want to see at a
> glance what config Hibernate thinks it just processed versus what you think
> it should be (was caching enabled, etc) - well, where do you draw the
> line? Because this gets back to my first point; if you log everything that
> is "useful" in this single boot-time log message it is going to be
> completely unreadable.
> >>>
> >>>
> >>>> +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.
> >>>
> >>>
> >>> What I am doing in 6 has no bearing on this discussion. Either we
> display information or we don't - that is the crux of this discussion, not
> which logger/category name we use.
> >>>
> >>>
>