Suggestions for alternative due to deprecation of Configuration access in ServiceContributor...
by Scott Marlow
For the WildFly use of ServiceContributor [1], which registers for each
SF/EMF, the 2lc RegionFactoryInitiator + JtaPlatform, I am worried that
we don't yet have a "per app deployment" way to disable the WF
ServiceContributorImpl.
I'm thinking that some applications (e.g. Spring) may not want to use
the WF 2lc RegionFactoryInitiator + JtaPlatform classes. To accomadate
that need, I'm thinking of introducing WF configuration properties for
controlling this:
* wildfly.jpa.jtaplatform will default to true but if set to false, [1]
will not call serviceRegistryBuilder.addInitiator(new
WildFlyCustomJtaPlatformInitiator()).
* wildfly.jpa.regionfactory will default to true but if set to false,
[1] will not call serviceRegistryBuilder.addInitiator(new
WildFlyCustomRegionFactoryInitiator()).
My request is that we keep the
StandardServiceRegistryBuilder.getSettings() call and document that in
the future, instead of removing it, we will change it to return a read
only copy of the configuration settings. Then, I can update [1] to
check for these new properties and know that I can depend on using
StandardServiceRegistryBuilder.getSettings().
An alternative could be to add a new method
StandardServiceRegistryBuilder.getReadOnlySettings().
I'd like to make the WF code change now for WF13, so a quick response is
appreciated! :)
Scott
[1]
https://github.com/scottmarlow/wildfly/blob/WFLY-10427/jpa/hibernate5_3/s...
7 years, 10 months
WildFly 14 requirements for Hibernate libraries
by Sanne Grinovero
Hi all,
good news first: WildFly 13 will include our latest Hibernate
libraries, in addition to the existing ones.
When booting WildFly 13 with the "-Dee8.preview.mode=true" property
set, it will use:
- Hibernate ORM 5.3
- Hibernate Search 5.10
- Hibernate Validator 6.0
(Validator 6 was available also in WildFly 12)
By default, for users not setting this preview mode, it will use the
older versions which were included in previous WildFly releases -
providing JPA 2.1 and EE7 compatibility only.
We're getting some requirements for WildFly 14 though, which needs to
be ready within 3 months.
In particular:
A] EE8 will be the only mode
So while today users have the ability to opt-in or ORM 5.3 and
companions, this will be enforced as the older libraries are removed.
Not much we need to do, other than further ensuring that people will
not have trouble. It's also an opportunity to get rid of unnecessary
dependencies.
B] we need to finish some backward compatibility work.
We did quite some work to ensure ORM 5.3 would be great at backward
compatibility but we left some pending work, e.g. the Compatibility
Transformer that David proposed is not available yet and it needs some
more details from us, such as a definitive list of the transformations
it will need to perform.
Also, the QE team didn't have a chance to review the work in detail
yet; I'm confident we did most of the work already but they might
raise the bar further or just have some questions, we will need to
work with them. I also hope we'll get more familiar with them and
their processes as clearly this isn't a one-off, we can all benefit
from working more closely with them for all future releases.
C] WildFly 14 is expected to work on both JDK8 and JDK11
Most work to support new JDKs has been done but we need to finish the
last details.
- CI jobs still not entirely working on JDK11
- Javassist might stay as an option but we need to make sure no
feature relies on it, as I don't think Javassist will be supportable
on JDK11
- consequentially, the Byte Buddy based alternative needs to be great
(some issues have been raised)
- some code to work on JDK11 will need to invoke APIs which were not
available in JDK8: are we going to release "multi-release jars"?
- resume the work on modernizing the XML parsers?
In particular, Byte Buddy on JDK11 will need access to the classloader
via VarHandles to enhance entities; I didn't investigate this
thoroughly yet but I believe I won't be able to give these references
to BB while relying exclusively on JDK8 APIs.
If we manage to improve anything by the 28th we can still include
micro-fixes in WildFly 13; in particular, if you are aware of any
blocker let's fix them now so that people can give us more detailed
feedback by actually using the EE8 preview mode.
(This includes possibly planning for some micro releases within a week)
Thanks,
Sanne
7 years, 10 months
Disallow uncategorized topics
by Yoann Rodiere
Hi,
We've seen a few posts on discourse lately without any category. More often
than not, these are about ORM (which makes sense since most posts are about
ORM).
This is a bit annoying since it makes it hard to configure Discourse to
only receive notifications about topics we want to actively monitor.
Would anyone object to disallowing uncategorized topics? I can create a
"Miscellaneous" category if you want, but I'd really like people to pick a
category when they create a topic.
--
Yoann Rodiere
yoann(a)hibernate.org / yrodiere(a)redhat.com
Software Engineer
Hibernate NoORM team
7 years, 10 months
Cache region names are not prefixed in 5.3
by Gail Badner
I see that cache region names are not being prefixed in 5.3.
EnabledCaching sets the TimestampsRegion region name
to TimestampsRegion.class.getName(), and sets the QueryResultsRegion region
name to QueryResultsRegion.class.getName(). [1]
Without a prefix, WildFly is failing intermittently when there are 2
persistence units with the query cache enabled due to:
org.infinispan.commons.CacheConfigurationException: ISPN000453: Attempt to
define configuration for cache org.hibernate.cache.spi.TimestampsRegion
which already exists
Entity region names are not being prefixed either.
Should they be prefixed by Hibernate or by the RegionFactory?
Regards,
Gail
[1]
https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src...
7 years, 10 months
Hibernate Search 5.10.0.Final released
by Yoann Rodiere
Hello,
We just published Hibernate Search 5.10.0.Final, the first stable release
in the 5.10 branch. This release mainly brings an upgrade to Hibernate ORM
5.3 and JPA 2.2, but also an integration to dependency injection frameworks
through Hibernate ORM 5.3, an upgrade to WildFly 12 and JGroups 4, and Java
9 automatic module names.
Check out our blog for more information about this release:
http://in.relation.to/2018/05/17/hibernate-search-5-10-0-Final/
--
Yoann Rodiere
yoann(a)hibernate.org / yrodiere(a)redhat.com
Software Engineer
Hibernate NoORM team
7 years, 10 months
Mail System Error - Returned Mail
by MAILER-DAEMON
<�>�y����W����<jr�R��e��8n��rn�I�����S����)"pt�����yT
���qxk��y�Zx]t����b�^��r?��b��U���0l{��4��
��M��XE�A#���XO%�~�����\�|-U���5o:�.~K��&���T�����Z�]F�q�����%��y�iV�����b�������md�n���:�}���m"L��h
rI�����Qp:��K��\$�H�,��)��V0���t�3Mn ��_0��b���{��<~��zNpB�&Y
B�v>!#A;�Q�rZ6����c����� �\�-������\
�u&&��sV���\��z�}���`����bX���pTAk�J��:,y����qq){���3X�%;]:d��!t��l��v��C-p���J��!&X�;m;u�-_*>��
���iOr1�0���h6��U��TJ�w)���_1�[C2b
�����g�5s,��Wy�SR��{�r�l6���K�'C9A������r�jP�Q��^Z;�������M�������H���5�M���������
%, G�i���Q
���)H��3zl1���-��q�3v��-�-��9��f�v3�aP����
7 years, 10 months
Differences in ORM exception handling in 5.1 vs 5.3
by Gail Badner
I've been looking at differences in Hibernate exception handling for
applications that uses "native" (non-JPA) Hibernate when moving from 5.1 to
5.3.
As you know, exception handling changed in 5.2 when hibernate-entitymanager
was merged into hibernate-core. This change is documented in the 5.2
migration guide. [1]
Here is the relevant text:
"org.hibernate.HibernateException now extends
javax.persistence.PersistenceExceptions.
Hibernate methods that "override" methods from their JPA counterparts now
will also throw various JDK defined RuntimeExceptions (such as
IllegalArgumentException, IllegalStateException, etc) as required by the
JPA contract."
While digging into this, I see that a HibernateException thrown when using
5.1 may, in 5.3, be unwrapped, or may be wrapped by a PersistenceException
(or a subclass), IllegalArgumentException, or IllegalStateException,
depending on the particular operation being performed when the
HibernateException is thrown.
The reason why the exceptions may be wrapped or unwrapped is because
Hibernate converts exceptions (via
AbstractSharedSessionContract#exceptionConverter)
for JPA operations which may wrap the HibernateException or throw a
different exception. Hibernate does not convert exceptions from strictly
"native" operations, so those exceptions remain unwrapped.
Here are a couple of examples to illustrate:
1) A HibernateException (org.hibernate.TransientObjectException) was thrown
in 5.1. In 5.3, the same condition can result in
org.hibernate.TransientObjectException
that is either unwrapped, or wrapped by IllegalStateException. I've pushed
a test to my fork to illustrate. [2]
Thrown during Session#save, #saveOrUpdate
In 5.1: org.hibernate.TransientObjectException (unwrapped)
In 5.3: org.hibernate.TransientObjectException (unwrapped)
Thrown during Session#persist, #merge, #flush
In 5.1, org.hibernate.TransientObjectException (unwrapped)
In 5.3, org.hibernate.TransientObjectException wrapped by
IllegalStateException
2) A HibernateException thrown when using 5.1 may be wrapped by a
PersistenceException, even though HibernateException already extends
PersistenceException.
For example, see TransactionTimeoutTest#testTransactionTimeoutFailure:
https://github.com/hibernate/hibernate-orm/blob/master/
hibernate-core/src/test/java/org/hibernate/test/tm/
TransactionTimeoutTest.java#L60-L82
The exception thrown by the test indicates that the transaction timed out.
This exception is important enough that an application might retry the
operation, or at least log for future investigation.
Thrown during Session#persist (or when changed to use Session#merge or
Session#flush):
In 5.1: org.hibernate.TransactionException (unwrapped)
In 5.3: org.hibernate.TransactionException wrapped by javax.persistence.
PersistenceException
Thrown if the test is changed to use Session#save or #saveOrUpdate instead:
In 5.1: org.hibernate.TransactionException (unwrapped)
In 5.3: org.hibernate.TransactionException (unwrapped)
Similarly, by adding some logging, I see that HibernateException objects
can be wrapped by PersistenceException when running the 5.3 hibernate-core
unit tests. Depending on the context, I see that some of the following
exceptions can be wrapped or unwrapped.
org.hibernate.exception.ConstraintViolationException
org.hibernate.exception.DataException
org.hibernate.exception.GenericJDBCException
org.hibernate.exception.SQLGrammarException
org.hibernate.id.IdentifierGenerationException
org.hibernate.loader.custom.NonUniqueDiscoveredSqlAliasException
org.hibernate.PersistentObjectException
org.hibernate.PropertyAccessException
org.hibernate.PropertyValueException
org.hibernate.TransactionException
You can see an example using
org.hibernate.exception.ConstraintViolationException
at [3].
In order to deal with these differences, an application could change the
following (which was appropriate for 5.1):
try {
...
}
catch (HibernateException ex) {
procressHibernateException( ex );
}
to the following for 5.3:
try {
...
}
catch (PersistenceException | IllegalStateException |
IllegalArgumentException ex) {
if ( HibernateException.class.isInstance( ex ) ) {
handleHibernateException( (HibernateException) ex );
}
else if ( HibernateException.class.isInstance( ex.getCause() ) ) {
handleHibernateException( (HibernateException) ex.getCause() );
}
}
IMO, it's a little clumsy having to deal with both wrapped and unwrapped
exceptions. It would be better if exceptions were consistently wrapped, or
consistently unwrapped.
I haven't had much of a chance to think about how we can deal with this,
but one thing that comes to mind is to allow an application to choose a
particular ExceptionConverter implementation. Hibernate would need to be
changed to always convert exceptions (including for strictly native
operations) before returning to the application.
For example, a property, hibernate.exception_converter could be added with
the following values:
jpa - default for JPA applications (org.hibernate.internal.
ExceptionConverterImpl)
native (or legacy?) - default for native applications that does not wrap
HibernateException
fully-qualified class name that implements ExceptionConverter
If users have to make changes to exception handling for 5.3, do you think
they would be willing to change their application to use JPA exceptions
(i.e., hibernate.exception_converter=jpa)?
Comments?
Regards,
Gail
[1] https://github.com/hibernate/hibernate-orm/blob/5.2/migration-guide.adoc
[2] https://github.com/gbadner/hibernate-core/blob/exception-
compatibility/orm/hibernate-orm-5/src/test/java/org/hibernate/bugs/
ORMTransientObjectExceptionUnitTestCase.java
[3] https://github.com/gbadner/hibernate-core/blob/exception-
compatibility/orm/hibernate-orm-5/src/test/java/org/hibernate/bugs/
ORMConstraintViolationExceptionUnitTestCase.java
7 years, 10 months
