On Jun 30, 2008, at 1:43 PM, Rick McGuire wrote:
Dain Sundstrom wrote:
On Jun 27, 2008, at 11:57 AM, David Blevins wrote:
[psst, update your openejb-dev mail alias, it's still using [EMAIL PROTECTED]
]
On Jun 27, 2008, at 6:33 AM, Rick McGuire wrote:
I've been trying to understand and document how the CMP-JPA
integration works, and I've found something in the CMP2 code that
has me confused. In the mapClass2X() method in CmpJmpConversion,
the code derives the names of the CMP field mappings by looking
for abstract "get" and "is" methods in the bean class. However,
in the createGetter() method in Cmp2Generator, the getter name is
always generated using a "get" prefix. Shouldn't this be
checking to see if the abstract method is an "is" method and
generate the appropriate one? The current code would appear to
generate a non-instantiable class if the source bean is using
"is" methods.
I added the "is" logic in there and I'm not sure at all if it is
compliant. I guess that'd be the first question. Second one
might be, if we do it anyway, will it mess up JPA? If the answers
are yes and no respectively, we definitely should. If the answers
are no and no, then we still could if we wanted to add it as an
extra feature.
In CMP-JPA, we configure JPA not use the getters or setters, but
instead it accesses the field directly. The main reason for this
is because the CMR getter/setter is defined in terms of the EJB
local interface which JPA doesn't understand.
Ok, that makes sense. So that still leaves me with the question
about the mismatch between CmpJpaConversion and Cmp2Generator. The
first is deciding that a field is a CMP field based on the existence
of an abstract is<Name> method, but the generator is unconditionally
generating get<Name> methods for each of the CmpFields. Shouldn't
this be checking to see what form of get method it needs to emit?
Absolutely. I thought it did emit is<Name> methods, but if it isn't,
it is a major bug.
-dain
