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 <smar...@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. >> _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev