PS: 6. when you synchronize mapping, classes are loaded earlier than when you don't
Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le ven. 17 juil. 2020 à 10:11, Romain Manni-Bucau <rmannibu...@gmail.com> a écrit : > Hi Mark, > > If it helps: > > 1. org.apache.openjpa.kernel.AbstractBrokerFactory#postCreationCallback > only triggers the prepareUnenhancedClasses if preload=true (never the case > right? ;)) > 2. Normally classes are loaded in > there org.apache.openjpa.kernel.AbstractBrokerFactory#initializeBroker > *when creating an em, not an emf* so better to have loaded ran the > enhancement early (loadAgent) > 3. Not sure it is done but it can happen 2 has a custom MDR not returning > right the classes - seems code is ok with that. I don't know if it is a > case we want to handle, I don't think it is needed. > 4. There is another case you didn't list where the EMF can be there but no > EM and enhancement should happen ASAP: deserialization ;) > 5. Finally there is a subtle difference between SE and EE case where one > will trigger the agent and the other will just add the transformer in the > classloader through PersistenUnitInfo (and container should handle this > additional properly), I don't know if our agent should be compatible with > it for apploader (jvm one). > > Romain Manni-Bucau > @rmannibucau <https://twitter.com/rmannibucau> | Blog > <https://rmannibucau.metawerx.net/> | Old Blog > <http://rmannibucau.wordpress.com> | Github > <https://github.com/rmannibucau> | LinkedIn > <https://www.linkedin.com/in/rmannibucau> | Book > <https://www.packtpub.com/application-development/java-ee-8-high-performance> > > > Le ven. 17 juil. 2020 à 09:35, Mark Struberg <strub...@yahoo.de.invalid> > a écrit : > >> hi folks! >> >> I'm right now cleaning up old code in our enhancer. Like removing java5 >> hacks, etc >> This is also triggered by our recent discussion about _transform and >> other pieces. >> Slowly getting my head into the right space for it. This is way more >> complex than I remembered ;) >> >> So here is my next puzzle: >> >> I've created a new example with 2 classes: Person and Employee extends >> Person >> Plus a persistence.xml with enlisting those 2 classes (makes a >> difference!) and essentially >> <property name="openjpa.DynamicEnhancementAgent" value="true"/> >> <property name="openjpa.RuntimeUnenhancedClasses" value="supported"/> >> The reason I switched on RuntimeUnenhancedClasses is that this check is >> performed when the BrokerFactory gets created. >> And if the classes are not build-time enhanced, then it fails in >> org.apache.openjpa.enhance.ManagedClassSubclasser#prepareUnenhancedClasses >> if (conf.getRuntimeUnenhancedClassesConstant() != >> RuntimeUnenhancedClassesModes.SUPPORTED) { .. >> And if you switch to supported, then it will create a new subclass and >> replaces field access to the getters/setters. Sadly >> java.lang.instrument.Instrumentation#retransform cannot be used to add new >> fields or methods. Otherwise we could do a direct full replacement of this >> class. >> >> Fun thing is that later on in >> org.apache.openjpa.persistence.PersistenceProviderImpl#createEntityManagerFactory(java.lang.String, >> java.lang.String, java.util.Map) >> we call loadAgent(factory); >> But what is it supposed to do? Which cases does it serve? >> If the classes did not have been already enhanced at build time nor via >> javaagent they will now be subclassed by ManagedClassSubclasser. >> And if we do not set RuntimeUnenhancedClasses=supported then we will >> never make it so far but blow up way earlier. >> >> Also: it is nice to have that agent attached. But why? All the entity >> classe already have been loaded already during BrokerFactory startup. There >> is no more entity class left over which needs enhancement, isn't? >> >> This is the log I get which reflects what I mean. Happy to share the code >> in a playground branch. >> >> 1261 test-classtransform INFO [main] openjpa.Enhance - Creating >> subclass and redefining methods for "[class >> org.apache.openjpa.examples.dynenhance.Employee, class >> org.apache.openjpa.examples.dynenhance.Person]". This means that your >> application will be less efficient than it would if you ran the OpenJPA >> enhancer. >> 1412 test-classtransform INFO [main] openjpa.Runtime - OpenJPA >> dynamically loaded the class enhancer. Any classes that were not enhanced >> at build time will be enhanced when they are loaded by the JVM. >> >> >> LieGrue, >> strub >> >>
