Andrus Adamchik wrote: > Looks like CGLib itself depends on ASM (although I may be completely > wrong) - > > http://ibiblio.org/maven2/cglib/cglib-asm/ >
Yes...CGLib is a higher level front end to ASM. I guess a good analogy for CGLib/ASM is C and assembler. With assembler, you need to have a good understanding of the processor and opcodes. C is a much higher level abstraction and relieves the need to know op codes. CGLib is essentially the same concept. Its a higher level abstraction for ASM, relieving the need to know byte code and JVM inner workings. Jeff > Andrus > > > On Mar 27, 2006, at 10:45 PM, Bill Dudney wrote: > >> Hi All, >> >> The other advantage of CGLib is its licensed with the ASL 1.1. While >> ASM's license is very liberal its not a 'typical' license and we would >> have to go through some review with [EMAIL PROTECTED] to get the >> license OK'd. >> >> TTFN, >> >> Bill Dudney >> MyFaces - http://myfaces.apache.org >> Cayenne - http://incubator.apache.org/projects/cayenne.html >> >> >> >> On Mar 27, 2006, at 10:29 AM, Andrus Adamchik wrote: >> >>> I have almost no experience with bytecode enhancement frameworks. The >>> only reason ASM seemed attractive is because of its small footprint >>> (generally we are trying to keep the dependency list as small as >>> reasonably possible). >>> >>> I agree - ASM is too low level, and I am not against CGLib if it >>> saves us time. But can anyone show a simple example of the >>> differences between the two? >>> >>> Also with CGLib how would we solve the problem of changing >>> CayenneDataObject code? Is there a good way to grab stuff from the >>> existing compiled class? >>> >>> Andrus >>> >>> >>> On Mar 27, 2006, at 6:58 PM, Jeff Genender wrote: >>> >>>> How about CGLib instead of ASM directly? ASM is a bit complex and >>>> necessitates a certain knowledge of the JVM op codes. IMHO, CGLib >>>> seems >>>> high level enough to make this work. Thoughts? >>>> >>>> Jeff >>>> >>>> Bill Dudney wrote: >>>>> Hi Andrus, >>>>> >>>>> Sorry for such a tardy reply but I'm just getting going on the JPA >>>>> stuff... >>>>> >>>>> Jeff and I were at TSS Symposium last week and we had a chance to talk >>>>> through the work for JPA. I wanted to get our thoughts into an >>>>> email and >>>>> off to the list so we are not duplicating work. We are planning on >>>>> doing >>>>> the mapping work. Jeff is going to tackle handling the annotations >>>>> and I >>>>> am going to handle parsing the orm.xml files and augmenting the >>>>> mapping >>>>> info. >>>>> >>>>> Other thoughts etc are inline. >>>>> >>>>> On Mar 7, 2006, at 2:45 AM, Andrus Adamchik wrote: >>>>> >>>>>> I did a little research on bytecode enhancement (CAY-460) and wanted >>>>>> to share some thoughts. >>>>>> >>>>>> It turned out that it is fairly simple to modify bytecode with the >>>>>> ASM >>>>>> framework: >>>>>> >>>>>> http://asm.objectweb.org/ >>>>>> >>>>>> I checked in a basic enhancer that adds objectId and persistenceState >>>>>> properties to POJOs already. Coding the rest of the DataObject >>>>>> enhancements shouldn't be a problem, however ASM code is not >>>>>> something >>>>>> that is easy to maintain by hand (so if say CayenneDataObject changes >>>>>> internally, I'd like the enhancer to pick up such changes >>>>>> automatically). I guess we may implement some sort of template based >>>>>> approach. ASM allows to take an existing class X and generate regular >>>>>> Java code that can act as a script for creating class X bytcode from >>>>>> scratch. So theoretically an enhancer itself can be generated. >>>>>> >>>>> >>>>> This looks interesting. I like the idea of using ASM to weave in the >>>>> required enhancements. I looked at the code you checked in and I'm >>>>> happy >>>>> to start down the path of getting the rest of the required code woven >>>>> in. I will also start looking at the template based approach. I will >>>>> probably do this before I get to the XML work so we can start >>>>> testing ASAP. >>>>> >>>>>> BTW, ASM visitor API can be used for another purpose - processing >>>>>> annotations (CAY-456), thus solving two problems at once. >>>>>> >>>>> >>>>> This looks cool (the ASM is really cool for doing this kind of work >>>>> AFAICT). Jeff is going to head down this path. >>>>> >>>>>> >>>>>> Another issue is integrating the enhancer in the provider. The >>>>>> requirement is that enhanced classes must be accessible to the >>>>>> application ClassLoader, so my original solution with a specialized >>>>>> child ClassLoader won't work. I see three ways to do the integration >>>>>> (we may implement all three of them). >>>>>> >>>>>> 1. "cgen" - by merging all CayenneDataObject code in the class >>>>>> generator template. This will work for people who use Cayenne to >>>>>> model >>>>>> their ORM classes, but want a superclass that is not a DataObject. >>>>>> This is not suitable for persistent classes created outside Cayenne >>>>>> and deployed with Cayenne provider. >>>>>> >>>>>> 2. "cdeploy" - enhancing compiler Ant task ala JDO. >>>>>> >>>>>> 3. Runtime - this would use JDK 1.5 java.lang.instrument API. On the >>>>>> one hand it is the least intrusive option, but on the other it >>>>>> requires a special runtime parameter (-javaagent:cayenne.jar). >>>>>> >>>>>> Ideas, comments? >>>>>> >>>>> >>>>> From my reading of the spec it looks like the ClassTransformer is >>>>> there >>>>> so that 3 does not require the special runtime parameter. Is there >>>>> something that I'm missing? I am basing my assumptions on the comment >>>>> (starting on page 148) on the addTransformer(ClassTransformer) >>>>> method on >>>>> the PersistenceUnitInfo class. >>>>> >>>>> Thoughts welcome. Also if you are doing any of this work please >>>>> speak up >>>>> so we don't duplicate. >>>>> >>>>> TTFN, >>>>> >>>>> Bill Dudney >>>>> MyFaces - http://myfaces.apache.org >>>>> Cayenne - http://incubator.apache.org/projects/cayenne.html >>>>> >>>>> >>>>> >>>> >>> >> >>
