On 05/20/2018 08:48 AM, Sanne Grinovero wrote:
could you explain what you mean by "tradeoff" in this context?
Sure, see below for more details.
On 20 May 2018 at 12:06, Scott Marlow <smarlow(a)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) , before any
application classes are loaded/defined by the application classloader.
2. Another "must happen before" rule is that the DataSource  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  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
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
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  earlier. If ORM 5.3 or 6.0,
is depending on  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?
> 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.