On Thursday, January 30, 2003, at 03:23  PM, Keith Visco wrote:
True. I've found out the problem, it comes from a hack that allows JDO
to think user specified handlers are actually FieldHandlerImpl.

In MappingLoader you will see the following:

667: //-- Fix for Castor JDO from Steve Vaughan, Castor JDO
668: //-- requires FieldHandlerImpl or a ClassCastException
669: //-- will be thrown...
670: handler = new FieldHandlerImpl(handler, typeInfo);
671: //-- End Castor JDO fix

It's this fix which is causing the converUponGet to be called again each
time because that handler will use the given typeInfo and specify it's
own CollectionHandler.

I'll try to get that cleaned up.
This appears to be a fix for a specific case of the problem I outlined in this message:

http://www.mail-archive.com/[email protected]/msg11575.html

The problem arises because JDO wants to use the three methods in FieldHandlerImpl that access TypeConvertors or related items: getConvertorTo, getConvertorFrom, and getConvertParam. These methods are not exposed in FieldHandler. The solution I propose is:

1) Create a subinterface of FieldHandler that includes these methods. Call it ConvertorFieldHandler.
2) Change FieldHandlerImpl's class declaration to indicate that it implements this new interface. This is a descriptive change only, since it already implements all these methods.
3) Require that any FieldHandlers that will be used with JDO implement this interface. Correct me if I'm wrong, but this should only be a going-forward problem. I don't believe JDO currently uses anything but FieldHandlerImpl.
4) Modify SQLEngine and ClassMolder (the places where this troublesome explicit cast occurs) to cast to ConvertorFieldHandler instead. (They each contain about three such casts.)

This fix does not change any JDO functionality and, as expected, JDO still passes all the CTF tests after it is implemented (at least, it passes them all against PostgreSQL).

I would supply a patch, but my local copy of castor where I made these changes has extensive modifications to ClassMolder that reflect my (thus far incomplete) attempts to integrate FieldMolder and FieldHandler. Hopefully this won't be a problem; as it happens, this description of the solution is about as long as the total code modifications needed to implement it.

Rhett
--
Rhett Sutphin
Research Assistant (Software)
Coordinated Laboratory for Computational Genomics
and the Center for Macular Degeneration
University of Iowa - Iowa City, IA 52242 - USA
4111 MEBRF - email: [EMAIL PROTECTED]

----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev



Reply via email to