[hibernate-dev] Is bytecode enhancement enabled by default in 5.3?

[Scott Marlow]

On 05/20/2018 08:48 AM, Sanne Grinovero wrote:
> Hi Scott,
> 
> could you explain what you mean by "tradeoff" in this context?  

Hi Sanne,

Sure, see below for more details.

> 
> Thanks!
> 
> 
> On 20 May 2018 at 12:06, Scott Marlow <smarlow at redhat.com> wrote:
>> There is a tradeoff in WF deployment, between Hibernate bytecode (runtime)
>> enhancing class transformers, being registered before CDI deployment, reads
>> the entity classes.

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/PersistenceUnitInfo.html#addTransformer-javax.persistence.spi.ClassTransformer-

[2] https://docs.oracle.com/javase/7/docs/api/javax/sql/DataSource.html

>>
>> 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.
>>