struberg commented on pull request #65: URL: https://github.com/apache/openjpa/pull/65#issuecomment-662836767
hi @dazey3 I took about whole evenings for about a week to dig into the code and all it's constellation I could think of. I think we now understand the problem really well. The whole recursive situation usually does _not_ occur if the agent is attached dynamically, it does _not_ occur if the PCClassFileTransformer is used programmatically etc. It will mostly happen if the transformer is used as javaagent and then _only_ for all the classes used in the PCClassFileTransformer code itself. Like `org.apache.openjpa.meta.MetaDataRepository` or `serp.bytecode.lowlevel.ConstantPoolTable`. It will also _not_ happen for any classes referenced inside an entity. When you touch the first entity the `ClassFileTransformer#transform` will return a byte[] which will be analysed by the JVM. And only after that it will load the classes found therein (and invoke the Transformer again subsequently). Now both the boolean and the exclude list from @rmannibucau serve the same needs. Both are an exit criteria in the classloader iteration for *internal* classes. Both have their pros and cons. I personally like the `ThreadLocal<Boolean>` better as it needs less maintenance. But actually there is one more thing we should check (later?): once the `PCClassFileTransformer` did successfully run for the first time and triggered all the classloading, do we need all this guarding at all? Or can we assume that all the necessary class loading did get triggered the first time already? ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
