Loggers
by Steve Ebersole
Yes, I know no one likes talking about logging. "Its not important", until
it is ;)
TLDR I am considering moving to using "module names" for logger names
instead of Class names even for DEBUG/TRACE logging and see if anyone had
strong arguments to not do this..
Full version---
For some time I have been moving to an approach of defining message
loggers[1] using a single contract per function or "module" - e.g.:
1. the second level caching module uses the dedicated message logger
`ConnectionPoolingLogger`
2. the ManagedBeanRegistry module uses the dedicated message logger
`BeansMessageLogger`
3. etc
Each of these define a dedicate instance instance they can use. E.g.
ConnectionPoolingLogger is defined as:
````
@MessageLogger( projectCode = "HHH" )
@ValidIdRange( min = 10001001, max = 10001500 )
public interface ConnectionPoolingLogger extends BasicLogger {
ConnectionPoolingLogger CONNECTIONS_LOGGER = Logger.getMessageLogger(
ConnectionPoolingLogger.class,
"org.hibernate.orm.connections.pooling"
);
...
}
````
I won't get into all the whys I do this unless someone cares ;)
But I am contemplating doing the same for basic loggers so I wanted to ask
everyone else's opinion since this means a change in how you'd have to
configure logging for DEBUG/TRACE output. Usually you'd use the Class name
as the logger name and use that to control logging in the back-end (log4j,
etc). If I do this, you'd have to instead use the module name.
There are quite a few reasons I am considering this, including all of the
reasons I did it for message loggers in the first place. If I am
debugging the loading of a collection or an entity, today I'd have to know
all the packages involved (there is no common root name) and list them in
my log4j.properties; that is because the process is ultimately handled by
delegates or helpers in many different packages (`org.hibernate.loader`,
`org.hibernate.persister`, `org.hibernate.type`, ...). It sure would be
nice to just be able to say `org.hibernate.loading` or
`org.hibernate.loading.entity` or `org.hibernate.loading.collection` or ...
for a number of reasons:
1. When we need to see logging from someone it is a lot easier to tell
the module name(s) you need enabled as opposed a list of package and class
names.
2. When running JPA TCK it is essentially impossible to attach debugger
to step through code when debugging a failure - you have to rely on
debugging through output. *Well that used to be the case, but the
latest TCK broke logging to STDOUT somehow so we ended up having to try and
reproduce the failure in our testsuite - so then it does not matter either
way ;)*
3. Easier to document -
http://docs.jboss.org/hibernate/orm/5.3/topical/html_single/logging/Loggi...
Thoughts?
[1] JBoss Logging's `org.jboss.logging.annotations.MessageLogger` - which
we use for user-focused log messages. Should always be logged at >= INFO
[2]
[3] JBoss Logging's `org.jboss.logging.BasicLogger` - which we use for
developer-focused log messages (for debugging). Should always be logged at
DEBUG or TRACE
5 years, 11 months
What should happen to queued operations when a collection is detached?
by Gail Badner
HHH-11209 involves a bug merging a detached entity with an uninitialized
collection that has queued operations.
After looking into this issue I found a bug
where AbstractPersistentCollection#operationQueue was not being cleared
after a commit, if there was no cascade mapped for the collection.
I've fixed that in a PR. [1]
After that fix, the detached entity in the test case attached to HHH-11209
has an uninitialized entity without any queued operations after commit,
which can be merged successfully in a new session/transaction.
There is still a problem when Hibernate tries to merge a detached entity
has an uninitialized collection with queued operations though. My PR throws
UnsupportedOperationException in this case, and there is a test case that
reproduces it.
I've been working on a fix to add support for this, but I have my doubts
that it really should be supported. I see that prior to fixing HHH-5855
(which caused HHH-11209), Hibernate simply ignored the queued operations in
the detached collection. [2].
The fix for HHH-5855 properly dealt with merging a managed collection that
was uninitialized with queued operations. It introduced the bug where a
NullPointerException would get thrown if that collection was detached.
If we want to support merging the queued operations, then I would consider
that an improvement. Would this be a worthwhile improvement? I'm guessing
not, but I wanted to get some opinions.
For now, I see a couple of ways to deal with this so that HHH-11209 can be
wrapped up:
1) ignore queued operations in a detached collection when merging, as was
done before HHH-5855 was fixed.
2) clear the queued operations when the collection is detached.
Comments?
Thanks,
Gail
[1] https://github.com/hibernate/hibernate-orm/pull/2460
[2]
https://github.com/hibernate/hibernate-orm/commit/c1934b72edb4f7815209376...
6 years, 2 months
Release Announcement: General Availability of JDK 11
by Rory O'Donnell
Hi Sanne,
*1) Release Announcement: General Availability of JDK 11 *
* JDK 11, the reference implementation of Java 11 and the first
long-term support release produced under the six-month rapid-cadence
release model [1][2], is now Generally Available.
* GPL-licensed OpenJDK builds from Oracle are available here:
https://jdk.java.net/11
This release includes seventeen features:
* 181: Nest-Based Access Control <http://openjdk.java.net/jeps/181>
* 309: Dynamic Class-File Constants <http://openjdk.java.net/jeps/309>
* 315: Improve Aarch64 Intrinsics <http://openjdk.java.net/jeps/315>
* 318: Epsilon: A No-Op Garbage Collector
<http://openjdk.java.net/jeps/318>
* 320: Remove the Java EE and CORBA Modules
<http://openjdk.java.net/jeps/320>
* 321: HTTP Client (Standard) <http://openjdk.java.net/jeps/321>
* 323: Local-Variable Syntax for Lambda Parameters
<http://openjdk.java.net/jeps/323>
* 324: Key Agreement with Curve25519 and Curve448
<http://openjdk.java.net/jeps/324>
* 327: Unicode 10 <http://openjdk.java.net/jeps/327>
* 328: Flight Recorder <http://openjdk.java.net/jeps/328>
* 329: ChaCha20 and Poly1305 Cryptographic Algorithms
<http://openjdk.java.net/jeps/329>
* 330: Launch Single-File Source-Code Programs
<http://openjdk.java.net/jeps/330>
* 331: Low-Overhead Heap Profiling <http://openjdk.java.net/jeps/331>
* 332: Transport Layer Security (TLS) 1.3
<http://openjdk.java.net/jeps/332>
* 333: ZGC: A Scalable Low-Latency Garbage Collector (Experimental)
<http://openjdk.java.net/jeps/333>
* 335: Deprecate the Nashorn JavaScript Engine
<http://openjdk.java.net/jeps/335>
* 336: Deprecate the Pack200 Tools and API
<http://openjdk.java.net/jeps/336>
2) Quality Outreach Report for September 2018 is available*
*
* Quality Outreach report September 2018
*Thanks to everyone who contributed to JDK 11 by downloading and testing
the early-access builds.
In particular the following developers who logged **18 issues in the JDK
Bug System.*
* Netty
* Eclipse Jetty
* Apache Lucene
* JUnit5
* Apache Tomcat
* Apache Ant
* Apache POI
* AssertJ
* Eclipse Collections
* Byte Buddy
* RxJava
3) JDK 12 EA build 12, under both the GPL and Oracle EA licenses, are
now available at http://jdk.java.net/11 .
* Schedule , Status & Features
o http://openjdk.java.net/projects/jdk/12/
* Release Notes:
o http://jdk.java.net/12/release-notes
**
Rgds,Rory
--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA, Dublin,Ireland
6 years, 2 months
Broken link JIRA tickets
by Yoann Rodiere
Hello,
FYI, I added default content to the JIRA tickets created from the 404 error
page on hibernate.org, so that at the very least we have the exact broken
link, and if available, the referrer. Before that, reporters had to check a
box in order to add the information, and a lot did not...
To see it in action: http://hibernate.org/foobar
Yoann Rodière
Hibernate NoORM Team
yoann(a)hibernate.org
6 years, 3 months
Fwd: Fwd: @OneToOne with @PrimaryKeyJoinColumn(s) vs @MapsId without value element
by Gail Badner
Forwarding Emmanuel's responses, which reduces the scope of what I thought
was buggy behavior.
There are still some weird cases though. I'll hone in on those in a
separate thread.
---------- Forwarded message ----------
From: Emmanuel Bernard <ebernard(a)redhat.com>
Date: Wed, Sep 12, 2018 at 5:54 AM
Subject: Re: Fwd: @OneToOne with @PrimaryKeyJoinColumn(s) vs @MapsId
without value element
To: Gail Badner <gbadner(a)redhat.com>
Cc: Guillaume Smet <gsmet(a)redhat.com>
On Wed 18-09-12 0:29, Gail Badner wrote:
> Hibernate treats @OneToOne @PKJC differently from @OneToOne MapsId (without
> a value element). I believe some of the differences are expected, but I
> suspect some of the differences are bugs. In some cases, I'm not sure which
> is treated correctly.
>
All my comments are caveat by me not having looked at this for years.
Note that these are different features.
@PKJC says that we don't create a new FK column, we reuse the id one.
@MapsId says, copy the value of the id from that property and pretend
it's an id generator.
> I've also found that the following mapping has some problems:
>
> @OneToOne
> @MapsId
> @JoinColumn(name = "FK")
> private Employee employee;
>
> Sometimes Hibernate treats that mapping like @OneToOne @PKJC; other cases
> it treats that mapping like @OneToOne @MapsId.
>
> I'm in the process of documenting the differences in a Google document so
> it can all be sorted out.
>
> As a start, it would help a lot if you could address the questions in this
> email.
>
> I've gotten very familiar with the related code, so once I have the
> answers, I'll know how to fix them.
>
> Thanks,
> Gail
>
> ---------- Forwarded message ----------
> From: Gail Badner <gbadner(a)redhat.com>
> Date: Sat, Sep 1, 2018 at 12:21 AM
> Subject: Re: @OneToOne with @PrimaryKeyJoinColumn(s) vs @MapsId without
> value element
> To: hibernate-dev <hibernate-dev(a)lists.jboss.org>
>
>
> FYI, I am taking PTO Tuesday, 9/4. I hope to be able to move forward on
> this when I return on 9/5.
>
> I see some differences. Some may be expected, but I think there are some
> bugs.
>
> For example, suppose we have the following entities:
>
> @Entity
> public class Parent {
> @Id
> private Long id;
> }
>
> @Entity
> public class ChildPKJC {
> @Id
> private Long id;
>
> @OneToOne // note that cascade-persist is not enabled
> @PrimaryKeyJoinColumn
> private Parent parent;
> }
>
> public class ChildMapsId {
> @Id
> private Long id;
>
> @OneToOne // note that cascade-persist is not enabled
> @MapsId
> private Parent parent;
> }
>
> ------------------------------------------------------------
> ------------------------------------------------------------
> -------------------
>
> When persisting ChildPKJC:
>
> 1) the application must initialize ChildPKJC#id before persisting the
> entity [1]; otherwise, the following exception is thrown:
> javax.persistence.PersistenceException:
> org.hibernate.id.IdentifierGenerationException:
> ids for this class must be manually assigned before calling save():
>
Sounds fine.
> 2) if ChildPKJC#parent is new with an assigned ID, and ChildPKJC#id is
> assigned parent's ID, the ChildPKJC Entity is persisted with the parent's
> ID, but parent is not persisted.
>
Sounds fine.
> When persisting ChildMapsId:
>
> 1) Hibernate automatically initializes ChildMapsId#id to parent.id [2]
>
Yes that's the expected behavior.
> 2) if ChildMapsId#parent is new, parent is automatically cascade-persisted
> (even though CascadeStyle.PERSIST is not mapped), then the ChildMapsId
> entity
> is persisted.
>
So that is not expressed in the spec but it might be that disabling that
is making things too complex for the Hibernate ORM engine. I would not
sweat too much on it.
> Are these expected difference? (My guess is yes)
>
> ------------------------------------------------------------
> ------------------------------------------------------------
> -------------------
>
> Foreign key generation:
>
> If ChildPKJC#parent is optional there is no foreign key generated from
> ChildPKJC
> referencing Parent.
>
Sounds fine.
[3] If ChildPKJC#parent is not optional, a foreign key
> is generated
>
Sounds fine.
> For ChildMapsId, a foreign key is generated from ChildPKJC referencing
> Parent, even if ChildMapsId#parent is optional.
>
ChildMapsId cannot be optional as it is the generator of the id. So we
ignore that the user has marked it optional.
> Is this a bug? My guess is that it is.
>
Not to me, see above.
> Adding the following mapping to ChildMapsId#parent works to disable foreign
> key generation:
> @JoinColumn(foreignKey = @ForeignKey(value = ConstraintMode.NO_CONSTRAINT))
> (can be used as a workaround)
>
> ------------------------------------------------------------
> ------------------------------------------------------------
> -------------------
>
> Loading an existing ChildPKJC/ChildMapsId with an optional Parent
> association by ID, when there is no Parent entity with the same ID (IIUC,
> this is the only way that ChildPKJC#parent or ChildMapsId#parent can be
> optional [3]):
>
> For ChildPKJC, the loaded ChildPKJC entity will have a null parent. There
> is no need to add @NotFound(IGNORE) to ChildPKJC#parent.
>
That's a bit weird but if the parent is not optional, why isn't there a
parent in the database with the proper id. Feels like a data incoherence
problem. If people have that,t hey must make it optional.
> If ChildPKJC#parent is optional, it is always eagerly loaded.
>
> This makes sense, since we cannot create a proxy if there is the
> possibility of a null Parent entity.
>
> For ChildMapsId, the loaded value will be null because
> ObjectNotFoundException
> will be thrown when Hibernate tries to load the Parent entity.
>
Right, this is a data incoherence, the parent must not be null.
Adding @NotFound(IGNORE) to ChildMapsId#parent will result in ChildMapsId
> entity being loaded with a null parent association.
>
> Is this expected? If so, then ChildMapsId#parent cannot be optional by
> default (without @NotFound(IGNORE).
>
Again I don't think parent being null is valid for @MapsId
> I think it would make more sense if the ChildMapsId entity is loaded with a
> null parent association, consistent with what happens for ChildPKJC. If we
> go that route, then ChildMapsId#parent will always have to be loaded
> eagerly.
>
> ------------------------------------------------------------
> ------------------------------------------------------------
> -------------------
>
> Please let me know your thoughts on this.
>
> [1] this requirement is documented in Example 178. Derived identifier
> @PrimaryKeyJoinColumn with a note that says: "Unlike @MapsId, the
> application developer is responsible for ensuring that the identifier and
> the many-to-one (or one-to-one) association are in sync as you can see in
> the PersonDetails#setPerson method."
>
> [2] Section 2.4.1 Primary Keys Corresponding to Derived Identities of the
> spec has this footnote:
> [12] If the application does not set the primary key attribute
> corresponding to the relationship, the value of that attribute may not be
> available until after the entity has been flushed to the database.
>
> [3] Section 11.1.44 PrimaryKeyJoinColumn Annotation has a footnote:
> [121]It is not expected that a database foreign key be defined for the
> OneToOne mapping, as the OneToOne relationship may be defined as
> “optional=true”.
>
>
> On Fri, Aug 31, 2018 at 1:29 PM, Gail Badner <gbadner(a)redhat.com> wrote:
>
> The fix for HHH-12436 involves correcting the foreign key direction for
>> "real" one-to-one associations. I've been looking into the ramifications
>> of
>> this change because I'm concerned that applications can rely on the old
>> (incorrect) foreign key direction.
>>
>> In the process I've found that Hibernate treats:
>>
>> @OneToOne
>> @PrimaryKeyJoinColumn
>> private Employee employee;
>>
>> differently from:
>>
>> @OneToOne
>> @MapsId
>> private Employee employee;
>>
>> I believe they should be treated consistently. You can see my reasoning
>> below. [1]
>>
>> Before going into details about how they are treated differently, I'd like
>> to get confirmation, in case I am missing some subtlety.
>>
>> Could someone please confirm this?
>>
>> Regards,
>> Gail
>>
>> ------------------------------------------------------------
>> ---------------------------------
>> [1]
>>
>> In 2.4.1.3 Examples of Derived Identities, Example 4(b) uses MapsId
>> without the value element as follows:
>>
>> @MapsId
>> @JoinColumn(name="FK")
>> @OneToOne Person patient;
>>
>> This example has the following footnote:
>> "[15] Note that the use of PrimaryKeyJoinColumn instead of MapsId would
>> result in the same mapping in this example. Use of MapsId
>> is preferred for the mapping of derived identities."
>>
>> The description has a footnote that says that using PrimaryKeyJoinColumn
>> instead of MapsId would result in the same mapping.
>>
>> In 11.1.45 PrimaryKeyJoinColumns Annotation, Example 2 uses
>> @PrimaryKeyJoinColumns as follows:
>>
>> @OneToOne
>> @PrimaryKeyJoinColumns({
>> @PrimaryKeyJoinColumn(name="ID",
>> referencedColumnName="EMP_ID"),
>> @PrimaryKeyJoinColumn(name="NAME",
>> referencedColumnName="EMP_NAME")})
>> EmployeeInfo info;
>>
>> This example has the following footnote:
>> "[123]Note that the derived identity mechanisms decribed in section
>> 2.4.1.1 is now preferred to the use of PrimaryKeyJoinColumn for
>> this case."
>>
>>
>>
6 years, 3 months
