You've stumbled upon one of the ugly issues with the MappingLoader +
shared JDO + XML mapping code...
The bug is that ClassDescriptorImpl does not return identity fields when
the getFields method is called, and it should. Instead it only returns
them when the getIdentities field is called. All fields should be
returned when the getFields method is called, but for some reason
ClassDescriptorImpl does not do this. I already added a fix on the XML
side once for this before multiple identites were added to
ClassDescriptorImpl...
The reason that the identity is dropped on the XML side is that the
interface ClassDescriptor has a method called getIdentity which returns
a single identity field. This interface is shared by both Castor JDO and
Castor XML. When the JDO folks decided they needed more than one
identity field, they changed the default implementation of
ClassDescriptor (ClassDescriptorImpl) to have an extra method called
getIdentities which returns the multiple identities. The interface
ClassDescriptor is not aware of this extra method and the XML side
doesn't use ClassDescriptorImpl directly. Instead the XML side uses
XMLClassDescriptor which is an implementation of ClassDescriptor (only
the single getIdentity method). The MappingLoader does use
ClassDescriptotImpl when it loads a mapping, but it's getIdentity method
simply returns the first identity.
The real bug however is that ClassDescriptorImpl does not return the
identity fields when the getFields method is called. It has this
behavior most likely because MappingLoader separates the two types of
fields and that's how it constructs ClassDescriptorImpl. So either
MappingLoader needs to group all fields together or ClassDescriptorImpl
needs to. If it did, we wouldn't have the problem of multiple or single
identities.
I don't want to change the implementation of ClassDescriptorImpl or
MappingLoader right now however since it would probably break the code
of the JDO folks (Thomas and friends)...but ultimately that's were the
fix needs to go.
I've just added a quick fix on the XML side which checks to see if the
ClassDescriptor returned by the MappingLoader is ClassDescriptorImpl and
makes sure it handles the getIdentities method. It is not a clean
approach, but it should fix the problem until we have a chance to do
some major cleanup to the aging MappingLoader + related classes.
Can you test the latest CVS version to see if it's working for you.
Thanks,
--Keith
Hong Rae Cho wrote:
>
> Dear castor-dev.
>
> I have a big problem about XML marshalling bug.
> Our project is near the end, I found a problem about multi-column identities.
>
> In my XML schema, I assigned multi-column identities.
> After marshalling, I got a XML Data without fields assigned identities except for
>first identity field.
>
> Here is related my problem below.
>
> http://castor.exolab.org/list-archive/msg10932.html
> http://castor.exolab.org/list-archive/msg10950.html
> http://castor.exolab.org/list-archive/msg11058.html
>
> In the last article, Mr. Ned Wolpert recommended the way to use a schema(XSD).
>
> My problem is that I have to use the way to use a mapping.xml for using Java
>Object(Class).
> Moreover, I' like to deal as Java Object with data from database, data from raw
>file, data from Legacy system, and etc.
>
> How can I fix this bug?
> Is anyone solve this problem?
>
> Thank you very much for any asistance.
>
> -----------------------------------------------------------
> If you wish to unsubscribe from this mailing, send mail to
> [EMAIL PROTECTED] with a subject of:
> unsubscribe castor-dev
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
