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
