answers inside. LieGrue, strub
> Am 17.07.2020 um 11:14 schrieb Romain Manni-Bucau <rmannibu...@gmail.com>: > > Le ven. 17 juil. 2020 à 10:45, Mark Struberg <strub...@yahoo.de.invalid> a > écrit : > >> Both prepareUnenhancedClasses and loadAgent already run in >> createEntityManagerFactory. >> > > Not in general, depends the conf and by default i run in none of both with > a standard config for ex for EE. Let me rephrase this: both those methods will get called in createEntityManagerFactory already. If they actually perform some bytecode enhancement is up to configuration and whether the classes have been enhanced otherwise before ;) > > >> crateEntityManager does not trigger enhancement afaict. >> > > createEMF does not since the creation of openjpa is lazy so the first > createEM does (in general case one again). Nope, it really gets called already by createEntityManagerFactory. You can debug into this if you want. LieGrue, strub > >> >> LieGrue, >> strub >> >>> Am 17.07.2020 um 10:11 schrieb Romain Manni-Bucau <rmannibu...@gmail.com >>> : >>> >>> 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 >>>> >>>> >> >>
