Looks like CGLib itself depends on ASM (although I may be completely
wrong) -
http://ibiblio.org/maven2/cglib/cglib-asm/
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 lega..pache.org 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
>>>>
>>>>
>>>>
>>>
>>
>
>
This archive was generated by hypermail 2.0.0 : Mon Mar 27 2006 - 13:59:43 EST