castor

MappingTool generate wrong mapping

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 1.1
  • Fix Version/s: 1.1.1
  • Component/s: XML
  • Labels:
    None
  • Environment:
    Windows XP
  • Number of attachments :
    6

Description

the simpleType base64Binary is mapped by MappingTool as

<field name="fieldname" type="byte">

instead of

<field name="documento" type="byte" collection "array">

The code generator generate the correct java type:

byte[] _fieldname;

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Werner Guttmann added a comment -

Can you please attach a small sample XML schema that demonstrates the issue at hand ?

Show
Werner Guttmann added a comment - Can you please attach a small sample XML schema that demonstrates the issue at hand ?
Hide
Permalink
Michele Lazzeri added a comment -

I attach the:

  • xsd file with "base64Binary" field "documento"
  • the java generated
  • the xml mapping
Show
Michele Lazzeri added a comment - I attach the:
  • xsd file with "base64Binary" field "documento"
  • the java generated
  • the xml mapping
Hide
Permalink
Werner Guttmann added a comment -

How are you actually calling the source generator ? When I try to have the source generator (against SVN trunk) generate a mapping file for the schema you attached, I get

<?xml version="1.0" encoding="UTF-8"?>
<mapping>
<class name="xml.c1886.generated.Allegato" access="shared">
<map-to xml="Allegato"
ns-uri="http://datadictionary.nefin.carige.it"
element-definition="false" />
</class>
</mapping>

Show
Werner Guttmann added a comment - How are you actually calling the source generator ? When I try to have the source generator (against SVN trunk) generate a mapping file for the schema you attached, I get <?xml version="1.0" encoding="UTF-8"?> <mapping> <class name="xml.c1886.generated.Allegato" access="shared"> <map-to xml="Allegato" ns-uri="http://datadictionary.nefin.carige.it" element-definition="false" /> </class> </mapping>
Hide
Permalink
Werner Guttmann added a comment -

Okay, just found a small bug in MappingFileSourcefactory.createFieldMapping() that prevented field mappings to created and added to the classMapping accordingly.

Show
Werner Guttmann added a comment - Okay, just found a small bug in MappingFileSourcefactory.createFieldMapping() that prevented field mappings to created and added to the classMapping accordingly.
Hide
Permalink
Werner Guttmann added a comment -

After fixing this small bug, the field mapping for the element 'documento' looks okay to me,

<field name="documento" type="byte[]">
<bind-xml name="documento" node="element" />
</field>

which matches the Java member created in Allegato.java.

Show
Werner Guttmann added a comment - After fixing this small bug, the field mapping for the element 'documento' looks okay to me, <field name="documento" type="byte[]"> <bind-xml name="documento" node="element" /> </field> which matches the Java member created in Allegato.java.
Hide
Permalink
Werner Guttmann added a comment -

Patch for review.

Show
Werner Guttmann added a comment - Patch for review.
Hide
Permalink
Werner Guttmann added a comment -

Just out of curiosity, what version of Castor have you been using when encountering this problem ?

Show
Werner Guttmann added a comment - Just out of curiosity, what version of Castor have you been using when encountering this problem ?
Hide
Permalink
Michele Lazzeri added a comment -

Initially I encouter the problem in the latest release version 1.1 ( 10 Feb 2007). Yesterday I try the snapshot castor-1.1.1-20070223.

Thank you!!!

Michele

Show
Michele Lazzeri added a comment - Initially I encouter the problem in the latest release version 1.1 ( 10 Feb 2007). Yesterday I try the snapshot castor-1.1.1-20070223. Thank you!!! Michele
Hide
Permalink
Werner Guttmann added a comment -

Thanks. The patch committed to SVN trunk will be made available as part of the next (snapshot) release.

Show
Werner Guttmann added a comment - Thanks. The patch committed to SVN trunk will be made available as part of the next (snapshot) release.
Hide
Permalink
Michele Lazzeri added a comment -

Sorry Werner, but I think that the bug is not fixed.

I doesn't apply the patch but I modify by hand the mapping.xml with the tag

<field name="documento" type="byte[]">

and the "MappingUnmarshaller.getMappingLoader(mapping, BindingType.XML)" fails with exception "org.exolab.castor.mapping.MappingException: Could not find the class byte[]"

Instead, if I use the tag

<field name="documento" type="byte" collection="array">
or
<field name="documento" type="bytes">

It's work.

Show
Michele Lazzeri added a comment - Sorry Werner, but I think that the bug is not fixed. I doesn't apply the patch but I modify by hand the mapping.xml with the tag <field name="documento" type="byte[]"> and the "MappingUnmarshaller.getMappingLoader(mapping, BindingType.XML)" fails with exception "org.exolab.castor.mapping.MappingException: Could not find the class byte[]" Instead, if I use the tag <field name="documento" type="byte" collection="array"> or <field name="documento" type="bytes"> It's work.
Hide
Permalink
Werner Guttmann added a comment -

Will have a look. I towuld be nice if you could attach a JUnit test case that I could use to replay the problem during (un)marshalling.

Show
Werner Guttmann added a comment - Will have a look. I towuld be nice if you could attach a JUnit test case that I could use to replay the problem during (un)marshalling.
Hide
Permalink
Werner Guttmann added a comment -

Committed another small patch, adding special logic for byte[].

Show
Werner Guttmann added a comment - Committed another small patch, adding special logic for byte[].
Hide
Permalink
Michele Lazzeri added a comment -

In attachment you can find a zip with the test case.

Show
Michele Lazzeri added a comment - In attachment you can find a zip with the test case.
Hide
Permalink
Michele Lazzeri added a comment -

I downloaded the latest snapshot (castor-1.1.1-20070305.202754-5.jar) and the MappingTool continue to generate the wrong mapping.xml.
I attach e new JUnit test case which generate the mapping (Castor1886_MappingTool.zip)

Show
Michele Lazzeri added a comment - I downloaded the latest snapshot (castor-1.1.1-20070305.202754-5.jar) and the MappingTool continue to generate the wrong mapping.xml. I attach e new JUnit test case which generate the mapping (Castor1886_MappingTool.zip)
Hide
Permalink
Werner Guttmann added a comment -

Michele, I am a bit confused right now. Looking at the change history, it seems like this is still not working, correct ?

Show
Werner Guttmann added a comment - Michele, I am a bit confused right now. Looking at the change history, it seems like this is still not working, correct ?
Hide
Permalink
Michele Lazzeri added a comment -

yes,

I download the latest snapshot (castor-1.1.1-20070413.115134-10.jar) and it doesn't still work:

the type base64Binary is converted by MappingTool in

<field name="fieldname" type="byte"> instead of <field name="fieldname" type="bytes">

I still use my workaround

Michele

Show
Michele Lazzeri added a comment - yes, I download the latest snapshot (castor-1.1.1-20070413.115134-10.jar) and it doesn't still work: the type base64Binary is converted by MappingTool in <field name="fieldname" type="byte"> instead of <field name="fieldname" type="bytes"> I still use my workaround Michele
Hide
Permalink
Romain PELISSE added a comment -

Hi,

I've reproduced this issue on the following version (since 1.1.1) :

  • 1.1.2
  • 1.2
  • 1.3

I agree with Michelle, this is not fixed. For the moment i did reproduce this issue as a testcase you could integrate in your framework... However, you can download a small project to reproduce it easily here : http://people.portaildulibre.fr/~rpelisse/support/castor/CASTOR-1886.zip

I can't add a patch on this issue, so here is my quick fix for this issue:

Index: MappingTool.java
===================================================================
— MappingTool.java (révision 8178)
+++ MappingTool.java (copie de travail)
@@ -400,7 +400,10 @@
}

// – fieldType

  • fieldMap.setType(fieldType.getName());
    + if ( "byte".equals(fieldType.getName()) && isArray )
    + fieldMap.setType("bytes");
    + else
    + fieldMap.setType(fieldType.getName());

// – handle XML Specific information
fieldMap.setBindXml(new BindXml());

Maybe not the best way to fix this, but i think it is rather simple and costless... Obviously somebody more at ease with Castor may find a better way to fix this. Meanwhile at least this will fix the issue.

Show
Romain PELISSE added a comment - Hi, I've reproduced this issue on the following version (since 1.1.1) :
  • 1.1.2
  • 1.2
  • 1.3
I agree with Michelle, this is not fixed. For the moment i did reproduce this issue as a testcase you could integrate in your framework... However, you can download a small project to reproduce it easily here : http://people.portaildulibre.fr/~rpelisse/support/castor/CASTOR-1886.zip I can't add a patch on this issue, so here is my quick fix for this issue: Index: MappingTool.java =================================================================== — MappingTool.java (révision 8178) +++ MappingTool.java (copie de travail) @@ -400,7 +400,10 @@ } // – fieldType
  • fieldMap.setType(fieldType.getName()); + if ( "byte".equals(fieldType.getName()) && isArray ) + fieldMap.setType("bytes"); + else + fieldMap.setType(fieldType.getName());
// – handle XML Specific information fieldMap.setBindXml(new BindXml()); Maybe not the best way to fix this, but i think it is rather simple and costless... Obviously somebody more at ease with Castor may find a better way to fix this. Meanwhile at least this will fix the issue.
Hide
Permalink
Werner Guttmann added a comment -

Romain, I have just had a look at the ZIP archive you supplied above, and for some reasons I can not reproduce the problem against SVN trunk. Here's what I did:

a) Generate sources and mapping file from the given XML schema (clientData.xsd).
b) Unmarshal from the following XML, using a couple of assert statements to validate the result.

<?xml version="1.0" ?>
<clientData>
	<name>Jean Smith</name>
	<address>2000, Alameda de las Pulgas, San Mateo, CA 94403</address>
    <id>AAE=</id>
</clientData>

It looks like everything works as intended. For what it is worth, here's the mapping file as generated:

<?xml version="1.0" encoding="UTF-8"?>
<mapping>
   <class name="xml.c1886.generated.ClientData" access="shared">
      <map-to xml="clientData" ns-uri="http://demande.ovdiscours.demandes.tiersdemmas"
         element-definition="false" />
      <field name="name" type="java.lang.String">
         <bind-xml name="name" node="element" />
      </field>
      <field name="address" type="java.lang.String">
         <bind-xml name="address" node="element" />
      </field>
      <field name="id" type="bytes">
         <bind-xml name="id" node="element" />
      </field>
   </class>
</mapping>

After unmarshalling, I extract the id(s) from the ClientData instance, and it is not null, has an size of 2 and holds the expected data.

Show
Werner Guttmann added a comment - Romain, I have just had a look at the ZIP archive you supplied above, and for some reasons I can not reproduce the problem against SVN trunk. Here's what I did: a) Generate sources and mapping file from the given XML schema (clientData.xsd). b) Unmarshal from the following XML, using a couple of assert statements to validate the result. 
<?xml version="1.0" ?>
<clientData>
	<name>Jean Smith</name>
	<address>2000, Alameda de las Pulgas, San Mateo, CA 94403</address>
    <id>AAE=</id>
</clientData>
It looks like everything works as intended. For what it is worth, here's the mapping file as generated: 
<?xml version="1.0" encoding="UTF-8"?>
<mapping>
   <class name="xml.c1886.generated.ClientData" access="shared">
      <map-to xml="clientData" ns-uri="http://demande.ovdiscours.demandes.tiersdemmas"
         element-definition="false" />
      <field name="name" type="java.lang.String">
         <bind-xml name="name" node="element" />
      </field>
      <field name="address" type="java.lang.String">
         <bind-xml name="address" node="element" />
      </field>
      <field name="id" type="bytes">
         <bind-xml name="id" node="element" />
      </field>
   </class>
</mapping>
After unmarshalling, I extract the id(s) from the ClientData instance, and it is not null, has an size of 2 and holds the expected data.

People

Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.