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