Okay! I got a working test case! http://pendaran.arborius.net/~jphekman/maptestcase.tgz
You will want to edit Mapper.java to point to the correct locations of two files (search for "/home/jphekman" to see where to edit). Then: cd maptestcase ant build export CLASSPATH=build/classes/:lib/castor-xml.jar:lib/commons-logging.jar:lib/xercesImpl.jar:lib/xml-apis.jar java com.ingenta.Mapper It should break. Note: it is NOT breaking on the Map (despite the name of the file). Turned out the Map seemed to be working fine: it broke when it started having to actually unmarshall the Cost class. That was the point at which the NPE was generated. (So when y'all gave good suggestions and unmarshalling got past the Map point and started working, this other problem was uncovered.) Now that I have it simplified I'll see if I can find out what's going on. After lunch :) Thanks for all the help so far! Jessica On Tue, Dec 20, 2005 at 11:13:04AM -0500, Stephen Bash wrote: > Jessica- > > So along the lines Werner is talking about, I've used either auto-naming > or nested class mappings to clean up the xml associated with Map > objects. Basically as Werner points out, auto-naming uses either the > class name or the field name to name the xml element (this provides > enough information on unmarshal to find the class). Unfortunately, in > the past auto-naming has had issues with the location attribute, so I > try to not use location and auto-naming at the same time (might not be a > problem for you). > > The method I've been using more is nested class mappings. Basically you > take your class mapping for org.exolab.castor.mapping.MapItem (from your > first e-mail), and place it inside your bind-xml element like so: > > <field name="myHashMap" collection="map"> > <bind-xml name="hash-item"> > <class name="org.exolab.castor.mapping.MapItem"> > <field name="key" type="string"> > <bind-xml name="key" node="attribute" /> > </field> > <field name="value" type="insert class here"> > <bind-xml name="value" /> > </field> > </class> > </bind-xml> > </field> > > This doesn't produce the xsi:type as long as Castor can look at the > mapping an know exactly what classes it needs. Now if you only have one > Java Map to ...um... map, whether you place the mapping inside the > bind-xml or not shouldn't make a big difference. I have an application > where I have multiple maps, all with different mappings, so by nesting > the mappings all of them can exist at the same time. > > This might still cause an NPE similar to your first e-mail, but it is > the approach I would take to avoid the xsi:type attribute. > > Hopefully that gets you close enough to a solution that something works. > > Stephen > > > Werner Guttmann wrote: > >Jessica, > > > >At the bottom of section 5 > >(http://castor.codehaus.org/xml-mapping.html#5.-xsi:type) you are going > >to find a statement similar to > > > >Suppose we wanted the following XML instead: > > > ><engine> > > <myProcessor/> > ></engine> > > > >Instead of using the xsi:type attribute. If you read on, you are going > >so see that you can instruct Castor XML to use the class name instead, > >as specified in the following field mapping. > > > ><field name="processor" type="IProcessor" required="true"> > > <bind-xml auto-naming="deriveByClass" node="element" /> > ></field> > > > >I hope this answers your question in parts. > > > >Werner > > > > > >wg> -----Original Message----- > >wg> From: Jessica Perry Hekman [mailto:[EMAIL PROTECTED] > >wg> Sent: Tuesday, December 20, 2005 4:02 PM > >wg> To: [email protected] > >wg> Subject: Re: [castor-user] Objects in Maps > >wg> > >wg> ...actually, as I struggle to get my little test case to > >wg> break with that NullPointerException at > >wg> org.exolab.castor.xml.MarshalFramework.searchInheritance > >wg> (or alternately and even better to get the real code to NOT > >wg> break), I realize: this whole project is intended to get > >wg> the system to listen to commands via REST. As one coworker > >wg> said when I asked him why we had setSuppressXSIType to true > >wg> in the first place, "otherwise it puts in all kinds of > >wg> stuff that we didn't think REST wanted to see." > >wg> > >wg> In other words, people are going to want to send XML over > >wg> the wire to create a new one of these objects, and > >wg> apparently we don't want to have to ask them to specify > >wg> XSI:type. I can push back on this if necessary, but: > >wg> > >wg> Is there in fact another way to go about taking the XML for > >wg> a map and turning it into a Map with the correct objects inside it? > >wg> > >wg> I fantasize about something like > >wg> > >wg> <map> > >wg> <key>some string here</key> > >wg> <value> > >wg> <cost>...</cost> > >wg> </value> > >wg> </map> > >wg> > >wg> ...such that it knows to map "cost" into a Cost object. (I > >wg> guess the question of how to map the key into a String remains.) > >wg> > >wg> Am I headed in completely the wrong direction? > >wg> > >wg> Jessica > >wg> > >wg> ------------------------------------------------- > >wg> If you wish to unsubscribe from this list, please send an > >wg> empty message to the following address: > >wg> > >wg> [EMAIL PROTECTED] > >wg> ------------------------------------------------- > >wg> > >wg> > > > >------------------------------------------------- > >If you wish to unsubscribe from this list, please > >send an empty message to the following address: > > > >[EMAIL PROTECTED] > >------------------------------------------------- > > > > > > ------------------------------------------------- > If you wish to unsubscribe from this list, please > send an empty message to the following address: > > [EMAIL PROTECTED] > ------------------------------------------------- > ------------------------------------------------- If you wish to unsubscribe from this list, please send an empty message to the following address: [EMAIL PROTECTED] -------------------------------------------------
