no, didn't work. LieGrue, strub
> Am 18.07.2020 um 18:00 schrieb Romain Manni-Bucau <rmannibu...@gmail.com>: > > Not sure I got the question but I suspect the case can be reproduced with a > plain new MyEntity() before your Persistence.createEMF. > > 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 sam. 18 juil. 2020 à 17:57, Mark Struberg <strub...@yahoo.de.invalid> a > écrit : > >> Found it yesterday when reviewing my sample with Romain: >> >> I apparently did copy the following property over from another example: >> <property name="openjpa.InitializeEagerly" value="true"/> >> And this did lead to already trigger the class transformation while >> createEntityManagerFactory. >> >> I did create a few samples, but did not manage to trigger any subsequent >> classloading at all. So no wonder in which case this could hit us yet. >> Before we introduce another expensive mechanism I would love to understand >> when the situation occurs at all. >> >> LieGrue, >> strub >> >> >> >> >> >>> Am 17.07.2020 um 12:03 schrieb Romain Manni-Bucau <rmannibu...@gmail.com >>> : >>> >>> Le ven. 17 juil. 2020 à 11:27, Mark Struberg <strub...@yahoo.de.invalid >> <mailto:strub...@yahoo.de.invalid>> a >>> écrit : >>> >>>> 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. >>>> >>> >>> Did and I can guarantee you it is lazy if your conf does not enforce it >>> somehow. >>> >>> >>>> >>>> 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 >> >>
