API differences in Hibernate ORM 5.1 vs 5.3
by Gail Badner
Hi,
There were lots of differences in the compatibility report, so as a first
step, I've excluded packages/classes that I considered SPI, internal, or
"grey area". This reduced the the differences to a more manageable amount.
You can see a summary of the incompatibilities along with suggested
mitigation at [1].
The report is attached to [1], along with a zip with instructions for
running the report.
I believe there are some "false positives" in the report, and I have
documented them in the section, "False Positives?".
Feel free to comment on the article.
Thanks,
Gail
[1]
https://developer.jboss.org/wiki/HibernateORMBinaryCompatibilityBetween51...
8 months, 3 weeks
IP banned from forum
by Gunnar Morling
Hi,
Is anyone banning users from the forum? I am getting "A ban has been
issued on your IP address."
I don't think banning by IP is a good strategy as many users will have
dynamic IPs from their hoster's shared pool, so it's a random game to
hit an IP previously banned due to some other user's spam.
Thanks,
--Gunnar
8 months, 3 weeks
New CI machine preview
by Sanne Grinovero
You're all welcome to play with http://54.225.162.168/
however please keep these in mind:
- it's not the final machine: don't put too much effort in creating
nice build scripts as we'll reset it to clean state soon. We *might*
be able to store jobs defined so far, but we might choose not to.
- domain name should be coming: ci.hibernate.org ..not sure when, got
no replies so far from.
- authentication: just click on login, it will use OAuth2 to request
your identity via your GitHub account. Permissions to create new jobs,
edit existing jobs, run a build manually depend on your github account
be part of the Hibernate organization (or not, in which case you have
read only status)
At this stage I'd like to get a feeling if the hardware is powerful
enough, and also we need to select which other plugins we want to use,
I'm looking especially to:
- static analysis reports
- pull requests integration
both are relatively undefined, we can of course start simple and
improve later.. just checking this fits basic needs now.
Sanne
11 months
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
7 years, 8 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...
7 years, 11 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
8 years
