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...
3 weeks, 6 days
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
3 weeks, 6 days
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
3 months, 1 week
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
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, 4 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
7 years, 4 months
