I guess we should try to come up with a 'proper' scheme to handle multi-dimensional arrays (irrespective of whether they are mapped or not).
Can you please create a new Jira issue at http://jira.codehaus.org/browse/CASTOR and attach a set of relevant (and minimal) files to this issue that gives us a working sample. Thanks in advance Werner Guttmann Iain Milne wrote: > Hi all, > > This is an update/further query on something that was discussed waaay > back in Feb (original message is appended). > > In brief, I had a problem where classes containing 2D float[][] arrays > were not being handled properly when I tried to define them in a mapping > file. > > I got around the issue by *not* defining the field in the mapping file, > but marking the class with (auto-complete="true") so that Castor would > still serialize/deserialize the data. > > For better or worse, this generates xml in the following form (this is a > example of one element in the array). > > <myArray xsi:type="java:[F"> > <float>0.5</float> > <float>0.5</float> > </myArray> > > Now to the problem. Under Java 1.5 this was all working fine, despite > the suspect looking "F" type. (It worked, I was happy, back to what I > was doing, etc). > > Under recent testing with the 1.6 beta2 version of Java though, I'm > getting errors along the lines of: > > java.lang.ClassNotFoundException: [F > > I can't read the old 1.5-created xml, and I've yet to successfully > generate any new files under 1.6. > > I'm not too worried about it yet seeing as 1.6 is still in beta, and > maybe it's a fault there rather than with Castor, but I thought I'd > mention it none the less. Perhaps someone has more thoughts/opinions on > this, or a better way of handling 2D arrays. > > Thanks > > Iain > >> -----Original Message----- >> From: Stephen Bash [mailto:[EMAIL PROTECTED] >> Sent: 13 February 2006 20:37 >> To: [email protected] >> Subject: Re: [castor-user] Using a mapping file with classes >> containing (eg float[][]) arrays >> >> Iain- >> >> I would guess the problem is that there is no type="float[]" >> or type="array" for the mapping file (since a 2D array is an >> array of arrays). I'm glad to hear Castor handles the field >> fine on introspection though :) >> >> Two things you can try. If you need the mapping file for >> other fields, but not the 2D array, just specify the other >> fields in the mapping, and then place auto-complete="true" in >> the class element of the mapping file. Castor will then >> introspect the class as normal and according to your test >> case, work fine. This does require that any fields you DON'T >> want marshalled must be declared as transient >> (transient="true" in the field element). >> >> The other option is to declare that the field exists, but not >> define type or collection attributes for it. This is kind of >> sketchy, but there are times that Castor's introspection will >> find all the necessary information and do things right. >> >> I think both of these options are short-term solutions (more >> like work-arounds), and it would be beneficial if you could >> post an issue in Jira >> (http://jira.codehaus.org/browse/CASTOR) so that a long term >> solution can be created. It would be great if you have a >> test case you can attach. >> >> Stephen >> >> On 2/13/06, Iain Milne <[EMAIL PROTECTED]> wrote: >>> I have a simple TestClass consisting of a single field that is a 2D >>> array: >>> public float[][] array; >>> >>> (and a constructor to initialize the array). >>> >>> Using Castor's default class inspection stuff, an instance of this >>> class can be converted into xml. >>> >>> If I then attempt to unmarshal the object using the >> following, it works: >>> Unmarshaller u = new Unmarshaller(TestClass.class); >> TestClass test = >>> (TestClass) u.unmarshal(new StringReader(xml)); >>> >>> >>> However, I need to use a mapping file. The entry for this >> class looks >>> as >>> follows: >>> >>> <class name="TestClass"> >>> <field name="array" type="float" collection="array" direct="true"/> >>> </class> >>> >>> Using this mapping file, the same xml is written out by the >> Marshaller. >>> No problems so far. However, when attempting to unmarshal >> the object >>> using the mapping, it fails: >>> >>> Mapping mapping = new Mapping(); >>> mapping.loadMapping( "mapping.xml" ); >>> >>> Unmarshaller u = new Unmarshaller(mapping); TestClass test = >>> (TestClass) u.unmarshal(new StringReader(xml)); >>> >>> throwing a NullPointerException in >>> >> org.exolab.castor.xml.UnmarshalHandler.endElement(UnmarshalHan >> dler.java: >>> 757) >>> >>> >>> This leads me to believe that Castor *can* successfully marshal and >>> unmarshal objects with 2D arrays, but either: >>> a) not when a mapping file is specified >>> b) not when the mapping file is wrong! >>> >>> Hopefully it's b) and fixable? Or maybe even a c) ? >>> >>> I don't have any other problems using mapping files, but for some >>> reason these 2D arrays are just not working. >>> >>> Thanks > _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ > > DISCLAIMER: > > This email is from the Scottish Crop Research Institute, but the views > expressed by the sender are not necessarily the views of SCRI and its > subsidiaries. This email and any files transmitted with it are confidential > to the intended recipient at the e-mail address to which it has been > addressed. It may not be disclosed or used by any other than that addressee. > If you are not the intended recipient you are requested to preserve this > confidentiality and you must not use, disclose, copy, print or rely on this > e-mail in any way. Please notify [EMAIL PROTECTED] quoting the > name of the sender and delete the email from your system. > > Although SCRI has taken reasonable precautions to ensure no viruses are > present in this email, neither the Institute nor the sender accepts any > responsibility for any viruses, and it is your responsibility to scan the > email > and the attachments (if any). > > > --------------------------------------------------------------------- > To unsubscribe from this list please visit: > > http://xircles.codehaus.org/manage_email > > --------------------------------------------------------------------- To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email
