[hibernate-dev] hibernate-tools-maven-plugin 5.4 snapshots are not being uploaded to Nexus
Someone mentioned in a jira that hibernate-tools-maven-plugin is not available for 5.4. snapshots. [1] Should it be? Regards, Gail [1] https://repository.jboss.org/nexus/content/groups/public-jboss/org/hibernate/hibernate-tools-maven-plugin/ ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Loggers
Following the recent post about boot logging and recent work on a new "module" (criteria queries) in 6, I wanted to circle back to this with a few thoughts. Now that this approach has been in place for quite a while and has been getting used we have a better feel for how this works in practice. One thing I realized is that the use of symbolic names for the loggers allows us to extend the idea of a "supported API" to logging as well. What I mean by this is that logging config would work from one release to the next because we are using symbolic names rather than class names. Even if we did extensive refactoring moving classes to different packages, renaming classes, etc... the logger names would stay the same. Which is not a small thing. From a document I am working on: == Logger/category names Symbolic name versus FQN as logger/category name Pros:: * Easier to configure as a hierarchy (imo); * Safe from refactoring - which seems minor, but it makes logging config something we could support, just as if it were an API Cons:: * Easy for classes to use FQN instead of symbolic name I personally really like moving TRACE and DEBUG logging to using this approach as well. It has worked really well in testing. Its is so much nicer to enable logging for query handling using: log4j.logger.org.hibernate.orm.query=debug log4j.logger.org.hibernate.orm.sql=debug compared to: log4j.logger.org.hibernate.hql=debug log4j.logger.org.hibernate.loader=debug log4j.logger.org.hibernate.sql=debug log4j.logger.org.hibernate.type=debug ... To be clear, there are also categories "under" the ones I used in the example. E.g. to see "query logging" just for HQL you'd use the `log4j.logger.org.hibernate.orm.query.hql` (which has additional categories as well (`log4j.logger.org.hibernate.orm.query.sqm.hql.parse.tree`, etc). I wanted to make sure everyone is on board with this before we get too far down this path - using symbolic names for TRACE/DEBUG logging. One last thing I forgot to mention earlier is that this does require changing the message ids. The range for these ids are defined as part of the message logger (the interface) via annotation. As we move messages to a different (modular) logger class the id range has to change. This only affects (is only supposed to affect[1]) message loggers (INFO/WARN/ERROR), not info logging (TRACE/DEBUG). [1] Historically we have only used message loggers (with ids) for INFO/WARN/ERROR. Some of the more recent changes by Guillaume change that a bit and moved a few message logger messages to be DEBUG. I think this is another thing we should nail down moving forward - do we want TRACE/DEBUG logging to potentially be messaged (with id) logs? On Fri, Sep 28, 2018 at 10:46 AM Sanne Grinovero wrote: > On Fri, 28 Sep 2018 at 16:43, Steve Ebersole wrote: > > > > Thanks for the feedback! > > I'm actually sorry for the delay :) Just back from 2 weeks off, catching > up. > > > 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". > > +1 > > > 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 > > Awesome! > > Thanks, > Sanne > > > > > On Fri, Sep 28, 2018 at 10:35 AM Sanne Grinovero > 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 > 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. > >>
Re: [hibernate-dev] [ORM] Reducing startup log verbosity
On Tue, 15 Jan 2019 at 14:24, Guillaume Smet wrote: > > > 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. Nice, thanks for checking. > > -- > Guillaume > > On Fri, Jan 11, 2019 at 12:04 PM Sanne Grinovero wrote: >> >> On Fri, 11 Jan 2019 at 09:53, Guillaume Smet >> 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 >> > 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 >> >> wrote: >> >>> >> >>> >> >>> >> >>> On Thu, Jan 10, 2019 at 10:15 AM Sanne Grinovero >> >>> wrote: >> >> On Thu, 10 Jan 2019 at 01:44, Steve Ebersole >> 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. >> >>> >> >>> ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [ORM] Reducing startup log verbosity
> 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 wrote: > On Fri, 11 Jan 2019 at 09:53, Guillaume Smet > 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.s...@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 > wrote: > >>> > >>> > >>> > >>> On Thu, Jan 10, 2019 at 10:15 AM Sanne Grinovero > wrote: > > On Thu, 10 Jan 2019 at 01:44, Steve Ebersole > 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. > >>> > >>> > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] NoORM IRC meeting minutes
Hi, Here are the minutes of today's meeting: (15:18:41) jbott: Meeting ended Tue Jan 15 14:18:34 2019 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) (15:18:41) jbott: Minutes: http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2019/hibernate-dev.2019-01-15-14.00.html (15:18:41) jbott: Minutes (text): http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2019/hibernate-dev.2019-01-15-14.00.txt (15:18:42) jbott: Log: http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2019/hibernate-dev.2019-01-15-14.00.log.html Have a nice day. Yoann Rodière Hibernate NoORM Team yo...@hibernate.org ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] Planning an ORM maintenance release: 5.4.1.Final
Hi all, I plan to tag a maintenance release of Hibernate ORM 5.4.1.Final on Thursday, to be published and distributed Friday. Please try to polish and merge any work you might want included, or yell at me if you object with the timing? And of course, as usual: don't freak out if your work won't be ready on time; there will be more releases. Thanks, Sanne ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
