I don't get your question. Hibernate does not enhance the entities by itself, you have to explicitly use one of the build tool plugins (maven, gradle, ant) to perform that step. Even then, the plugins have all the features disabled by default. The support for enhanced entities in hibernate is not something you can enable or disable. The only thing configurable is the bytecode provider, and that is something that has indeed changed for 5.3. AFAICT the generated bytecode should be identical. Luis Barreiro Middleware Performance Team <https://red.ht/sig> On 05/18/2018 08:38 PM, Gail Badner wrote:

There is a tradeoff in WF deployment, between Hibernate bytecode (runtime) enhancing class transformers, being registered before CDI deployment, reads the entity classes. There is also the tradeoff between Hibernate bytecode (runtime) enhancing class transformers being registered too late because the persistent unit uses a datasourcedefinition. I asked Gail's question for 5.1.x and the answer was no. Now, for 5.3, I don't understand the answers yet. Anyway, wanted to mention the above, to share more info with all, as to why we are asking. Regards, Scott On Sat, May 19, 2018, 6:30 AM Sanne Grinovero <sanne(a)hibernate.org&gt; wrote:

On 05/20/2018 08:48 AM, Sanne Grinovero wrote: Hi Sanne, Sure, see below for more details. To explain what I mean by the "tradeoff", I will first explain some ordering rules based on the current WildFly/Hibernate deployment scheme. 1. The first "must happen before" rule is that the Hibernate ORM bytecode enhancer must register via PersistenceUnitInfo.addTransformer(ClassTransformer) [1], before any application classes are loaded/defined by the application classloader. 2. Another "must happen before" rule is that the DataSource [2] must be available before the first Hibernate ORM (persistence unit) bootstrap phase (in the case of applications using the two-phase bootstrap). For applications using the single phase PU bootstrap, the DataSource must be available before the call to Persistence.createEntityManagerFactory(). 3. Another "must happen before" rule, is that CDI handling (WF) deployer unit processing code must read the application classes and transform application classes as part of CDI deployment, in order to meet the CDI requirements. The first Hibernate ORM pu bootstrap phrase, must currently register its class transformer [1] before CDI reads/transforms application classes, or the Hibernate entity class transformer, will be ignored (note, there is no deployment failure for this, nor can there be currently). 4. Another "must happen before" rule, is that WildFly @DataSourceDefinitions, do not become available until very late deployment phases, when application classes, will already have been read. Hibernate can also start its first Hibernate ORM pu bootstrap phrase, very late as well but again, the Hibernate entity class will be ignored (since application classes are already defined before Hibernate starts deployment). If applications want entity classes to be enhanced, the first Hibernate ORM pu bootstrap phrase, must run early enough but that cannot happen if the pu depends on a @DataSourceDefinition. There are some WildFly pu hints that influence the ordering but currently, apps have to decide what they really want to work: jboss.as.jpa.classtransformer - defaults to true but if false, WildFly does not try to register the entity class transformers early. wildfly.jpa.twophasebootstrap - defaults to true but if false, WildFly does not try to use two phase persistence unit bootstrap (currently only supported for Hibernate). Steve Ebersole and I have talked about adding additional phases to the PU bootstrap, but that was so long ago, I forget if it was about registering the ORM class transformer [1] earlier. If ORM 5.3 or 6.0, is depending on [1] to work correctly in order to implement the ORM features, we need to take some action. In the past, I recall someone mentioning that lazy loading or dirty flag handling, would depend on bytecode enhancing. If that happened or will happen, we should discuss what the fallback solution is for when bytecode enhancing is not working. Another subject, is how should a user find out that bytecode enhancing is actually updating application entity classes. Should that operation have trace logging and should that be at the WF or ORM level? Scott [1] https://docs.oracle.com/javaee/7/api/javax/persistence/spi/PersistenceUni... [2] https://docs.oracle.com/javase/7/docs/api/javax/sql/DataSource.html

On 05/23/2018 09:17 AM, Steve Ebersole wrote: The @DataSourceDefinition DataSource that ORM needs, doesn't start until after application classes are loaded/defined. This is good news, so applications will still work correctly. Should we document that applications with entity classes using bi-dir association, also depend on enhancement working? And also mention why run-time enhancement might not work and perhaps mention build-time enhancement as a workaround to run-time enhancement not working? https://issues.jboss.org/browse/WFLY-10456 is for #1 + #2. +10 for ORM to also log #2 + #3. :) Scott