[ORM] Reducing startup log verbosity
by Guillaume Smet
Hi,
Got a report from a fellow Red Hatter complaining about our logging
verbosity being so 2004 and, well, I must admit I tend to agree.
This is from a launch on a simple PostgreSQL app. I added some comments
inline.
Note that it might seem like wasting our time but I would like to improve
the user experience in some contexts - happy to discuss the rationale
behing this discussion privately if needed.
[o.h.Version] (build-) HHH000412: Hibernate Core {5.4.0.Final}
-> this one is a product requirement so let's keep it as is for now,
hopefully, we will have a global solution for that at some point
[o.h.c.Environment] (build-) HHH000206: hibernate.properties not found
-> I think we should use DEBUG here, framework nowadays rely on their own
config injection mechanisms
[o.h.b.e.s.Enhancer] (pool-2-thread-6) Enhancing [jpa.SequencedAddress] as
Entity
[o.h.b.e.s.Enhancer] (pool-2-thread-10) Enhancing [jpa.WorkAddress] as
Composite
[o.h.b.e.s.Enhancer] (pool-2-thread-1) Enhancing [jpa.Address] as Composite
[o.h.b.e.s.Enhancer] (pool-2-thread-8) Extended enhancement of [jpa.Animal]
[o.h.b.e.s.Enhancer] (pool-2-thread-13) Enhancing [jpa.Human] as
MappedSuperclass
[o.h.b.e.s.Enhancer] (pool-2-thread-16) Enhancing [jpa.Person] as Entity
[o.h.b.e.s.Enhancer] (pool-2-thread-5) Enhancing [jpa.Customer] as Entity
-> I would vote for using DEBUG. Let's imagine a 250 entities model and I
think we can agree we don't want it to be logged by default.
[o.h.j.i.u.LogHelper] (main) HHH000204: Processing PersistenceUnitInfo [
name: templatePU
...]
-> so, first, I would make this one a one liner as we apparently didn't add
any other properties. I think it was done to mimic the DEBUG output but I
don't see any value to having it on several lines.
And, frankly, I think I would get rid of it altogether and only log
something at debug level.
[o.h.a.c.Version] (main) HCANN000001: Hibernate Commons Annotations
{5.1.0.Final}
-> version, can't touch it for now.
[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.
[o.h.e.j.e.i.LobCreatorBuilderImpl] (main) HHH000422: Disabling contextual
LOB creation as connection was null
-> I would move that to DEBUG.
[o.h.t.BasicTypeRegistry] (main) HHH000270: Type registration
[java.util.UUID] overrides previous :
org.hibernate.type.UUIDBinaryType@7e8dcdaa
-> as I understand it, we will always have this message at startup when
using PostgreSQL. I think we should make it DEBUG too. Or find another
solution for this specific case but having it logged on each PostgreSQL app
is definitely a bad thing.
[o.h.e.t.j.p.i.JtaPlatformInitiator] (main) HHH000490: Using JtaPlatform
implementation:
[org.hibernate.engine.transaction.jta.platform.internal.JBossStandAloneJtaPlatform]
-> This one, I don't know. It's probably important to know that JTA is
properly configured but I'm not terribly excited about keeping it. Thoughts?
Maybe one solution could be to have all these ones tied to a
"org.hibernate.bootstrap" logger and thus have the ability to enable them
in one go.
I heard you made nice things in 6 about logging but I would like to improve
the situation in the stable version.
I would like to move quickly on this and hopefully integrate it in the
upcoming 5.4.1 so feedback very welcome! If some are polemic, I will just
work on the easy ones, that would still improve the situation.
Thanks!
--
Guillaume
7 years, 1 month
Planning an ORM maintenance release: 5.4.1.Final
by Sanne Grinovero
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
7 years, 1 month
Default access type and MappedSuperclass
by Guillaume Smet
Hi,
We recently had this issue opened about us not choosing the right access
type for a mapped super class:
https://hibernate.atlassian.net/browse/HHH-12938 .
Hibernate currently base the access type decision on the sole placement of
the @Id annotation, which, in the case of a @MappedSuperclass might not be
defined (this is the OP's case).
I closed the issue explaining what we do and pointing a workaround but the
OP rightfully replied with the JPA spec saying "The default access type of
an entity hierarchy is determined by the placement of mapping annotations
on the attributes of the entity classes and mapped superclasses of the
entity hierarchy that do not explicitly specify an access type".
I'm wondering if we should also consider the @Column annotations placement
if there is no @Id annotation.
If the answer is that it's already fixed in 6, it's all good for me :).
Thoughts?
--
Guillaume
7 years, 1 month
inSession / inTransaction
by Steve Ebersole
In tests we find our `#inSession` and `#inTransaction` methods very
useful. Which got me thinking that maybe we should support these on
SessionFactory directly:
public interface SessionFactory ... {
...
void inSession(Consumer<Session> action);
void inTransaction(Consumer<Session> action);
void inTransaction(Session session, Consumer<Session> action);
}
and maybe even:
public interface Session ... {
void inTransaction(Consumer<Session> action);
}
Objections?
7 years, 1 month
JDK 12 Early Access build 26 & JDK 13 Early Access builds available
by Rory O'Donnell
Hi Sanne,
Happy New Year!
*OpenJDK builds *- JDK 12 Early Access build 26 is available at
http://jdk.java.net/12/
* These early-access, open-source builds are provided under the GNU
General Public License, version 2, with the Classpath Exception
<http://openjdk.java.net/legal/gplv2+ce.html>.
* Changes since last email
o Distrust TLS server certificates anchored by Symantec Root CAs
(JDK-8207258 <https://bugs.openjdk.java.net/browse/JDK-8207258>)
o Customizing the generation of a PKCS12 keystore (JDK-8076190
<https://bugs.openjdk.java.net/browse/JDK-8076190>)
o Compact Number Formatting Support (JDK-8177552
<https://bugs.openjdk.java.net/browse/JDK-8177552>)
*OpenJDK builds *- JDK 13 - Early Access build 2 is available at
http://jdk.java.net/13/
* These early-access, open-source builds are provided under the GNU
General Public License, version 2, with the Classpath Exception
<http://openjdk.java.net/legal/gplv2+ce.html>.
* Changes in this build
<http://hg.openjdk.java.net/jdk/jdk/log?rev=reverse%28%22jdk-13%2B1%22%3A%...>
*jpackage EA builds*
* This is an early access build of JEP 343: Packaging Tool
<https://openjdk.java.net/jeps/343>, aimed at testing a prototype
implementation of jpackage, which is a new tool for packaging
self-contained Java applications along with a Java Runtime Environment.
* Please send feedback via e-mail to core-libs-dev(a)openjdk.java.net
<mailto:core-libs-dev@openjdk.java.net>
*Quality Outreach report for December 2018*
* The report for December 2018 is available here
<https://wiki.openjdk.java.net/display/quality/Quality+Outreach+report+for...>
Rgds,Rory
--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland
7 years, 1 month
SAP HANA build failing for a while - does it reveal a bug?
by Guillaume Smet
Hi,
Since this build
http://ci.hibernate.org/view/ORM/job/hibernate-orm-master-hana-main/688/ ,
the SAP HANA build is failing consistently.
With a lot of tests failing with:
Caused by: org.hibernate.MappingException: Unable to build insert statement
for table [Employee]: SAP HANA requires at least one value in insert
value-list clause.
at org.hibernate.sql.Insert.toStatementString(Insert.java:104)
at
org.hibernate.persister.entity.AbstractEntityPersister.generateIdentityInsertString(AbstractEntityPersister.java:2826)
at
org.hibernate.persister.entity.AbstractEntityPersister.doLateInit(AbstractEntityPersister.java:4147)
at
org.hibernate.persister.entity.AbstractEntityPersister.postInstantiate(AbstractEntityPersister.java:4220)
at
org.hibernate.metamodel.internal.MetamodelImpl.initialize(MetamodelImpl.java:257)
at
org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:294)
at
org.hibernate.boot.internal.SessionFactoryBuilderImpl.build(SessionFactoryBuilderImpl.java:462)
at
org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:938)
I wonder if we have broken something because I wouldn't expect so many
tests to end with an empty insert?
Could someone more familiar with these tests take a look at it? I don't
think we need SAP HANA to check for the empty INSERT issue.
Thanks.
--
Guillaume
7 years, 1 month
