CMP2 generator

[Dain Sundstrom <da...@iq80.com>]

I just committed the CMP2 generator.  It uses ASM directly and  
supports cmp fields, single valued cmr fields, and set valued cmrs.   
I still need to add support for ejbSelect methods and we should have  
a collection valued cmr handler (although treating them all as sets  
is legal).

All of the itest are using the cmp2 stuff.

-dain

Re: CMP2 generator

[Dain Sundstrom <da...@iq80.com>]

One more thing... I expect many-to-many relationships to Just Work 
(TM), but I think unidirectional relationships won't.

We have tests for these, but they haven't been updated to OpenEJB 3 yet.

-dain

On Jan 3, 2007, at 9:13 PM, Dain Sundstrom wrote:

> It occurred to me that some details on how it works would be nice :)
>
> In the Assembler.buildContainer system class there is a loop that  
> deploys each ejbJar.  In the top of that loop before the class  
> loader for the ejbJar is created, I generate an additional jar file  
> that contains all of the cmp2 concrete implementation classes.   
> Then when the class loader is constructed for the application all  
> of the cmp2 classes are available.  The is means that we don't need  
> any special hooks to get the JPA implementation to enhance our  
> classes, and gives a good place to put our generated CMP  
> persistence unit when I implement that feature :)
>
> When I originally started coding this, I wanted to generate each  
> cmp class and load it into the class loader directly one at a  
> time.  As it turns out that won't work because cmp classes have  
> bidirectional relationships to each other and there is no way to  
> load multiple classes into a class loader with one method class.   
> Instead, you must generate a resource, something with a URL  
> (normally a jar or directory) and add that to the class loader.  Of  
> course there is no standard method of for that either, so it turns  
> out that generating a new jar before the class is created is the  
> most elegant solution.
>
> In the process of implementing this, I made a few other changes to  
> make the generator simpler:
>
> * Each CMP bean must have a persistence-unti-ref "openejb/cmp"  
> which is persistence unit used by the cmp engine.  In the future we  
> will automatically generate and add the reference, but for now you  
> must add it explicitly.
> * KenGenerator only has one method in the interface now.  The other  
> methods went to castor specific sub class.
> * All of the cmp2 generator stuff was moved to the  
> org.apache.openejb.core.cmp.cmp2 package.
> * I removed the factory for the SingleValuedCmr and SetValuedCmr  
> code.  They were only there so concrete subclasses could be placed  
> in the itests.
> * I as many generics as possible from the cmp2 generated sub class  
> as it can create problems if the super class doesn't use generics  
> also.
> * I left ExampleABean_JPA clases in the core tests directory as  
> they are very useful for testing the generator against a know  
> working example.
> * We now have info objects for relationships
>
> I still need to add a few things like (posting here so I don't forget)
> * It would be nice to configure the name of the cmp2 concrete sub  
> class to make switching to the ExampleABean_JPA.java file easier.
> * We should have a test case that Generates a cmp impl and attempts  
> to load it.  This catches any generation errors.
> * We should have a test that verifies the signatures of methods  
> referenced by generated code hasn't changes.  This will catch over  
> zealous re-factoring.
> * We need a CollectionValuedCmr
>
> That is all I can think of now...
>
> -dain
>
> On Jan 3, 2007, at 8:31 PM, Dain Sundstrom wrote:
>
>> I just committed the CMP2 generator.  It uses ASM directly and  
>> supports cmp fields, single valued cmr fields, and set valued  
>> cmrs.  I still need to add support for ejbSelect methods and we  
>> should have a collection valued cmr handler (although treating  
>> them all as sets is legal).
>>
>> All of the itest are using the cmp2 stuff.
>>
>> -dain

Re: CMP2 generator

[Dain Sundstrom <da...@iq80.com>]

It occurred to me that some details on how it works would be nice :)

In the Assembler.buildContainer system class there is a loop that  
deploys each ejbJar.  In the top of that loop before the class loader  
for the ejbJar is created, I generate an additional jar file that  
contains all of the cmp2 concrete implementation classes.  Then when  
the class loader is constructed for the application all of the cmp2  
classes are available.  The is means that we don't need any special  
hooks to get the JPA implementation to enhance our classes, and gives  
a good place to put our generated CMP persistence unit when I  
implement that feature :)

When I originally started coding this, I wanted to generate each cmp  
class and load it into the class loader directly one at a time.  As  
it turns out that won't work because cmp classes have bidirectional  
relationships to each other and there is no way to load multiple  
classes into a class loader with one method class.  Instead, you must  
generate a resource, something with a URL (normally a jar or  
directory) and add that to the class loader.  Of course there is no  
standard method of for that either, so it turns out that generating a  
new jar before the class is created is the most elegant solution.

In the process of implementing this, I made a few other changes to  
make the generator simpler:

* Each CMP bean must have a persistence-unti-ref "openejb/cmp" which  
is persistence unit used by the cmp engine.  In the future we will  
automatically generate and add the reference, but for now you must  
add it explicitly.
* KenGenerator only has one method in the interface now.  The other  
methods went to castor specific sub class.
* All of the cmp2 generator stuff was moved to the  
org.apache.openejb.core.cmp.cmp2 package.
* I removed the factory for the SingleValuedCmr and SetValuedCmr  
code.  They were only there so concrete subclasses could be placed in  
the itests.
* I as many generics as possible from the cmp2 generated sub class as  
it can create problems if the super class doesn't use generics also.
* I left ExampleABean_JPA clases in the core tests directory as they  
are very useful for testing the generator against a know working  
example.
* We now have info objects for relationships

I still need to add a few things like (posting here so I don't forget)
* It would be nice to configure the name of the cmp2 concrete sub  
class to make switching to the ExampleABean_JPA.java file easier.
* We should have a test case that Generates a cmp impl and attempts  
to load it.  This catches any generation errors.
* We should have a test that verifies the signatures of methods  
referenced by generated code hasn't changes.  This will catch over  
zealous re-factoring.
* We need a CollectionValuedCmr

That is all I can think of now...

-dain

On Jan 3, 2007, at 8:31 PM, Dain Sundstrom wrote:

> I just committed the CMP2 generator.  It uses ASM directly and  
> supports cmp fields, single valued cmr fields, and set valued  
> cmrs.  I still need to add support for ejbSelect methods and we  
> should have a collection valued cmr handler (although treating them  
> all as sets is legal).
>
> All of the itest are using the cmp2 stuff.
>
> -dain