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
