I am certain ASM's license is fine since its BSD: http://people.apache.org/~cliffs/3party.html
Second, Geronimo uses CGLib, which in-turn uses ASM, so I am pretty sure there are no issues at all. 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 >>>> >>>> >>>> >>> >>
