Jessica and Stephen, given that the NPE should really be replaced with a more human readable exception, can you please raise a new issue at http://jira.codehaus.org/browse/CASTOR, and attach a working sample (minimal, if possible) that highlights the break.
Thanks in advance Werner Jessica Perry Hekman wrote: > 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] > ------------------------------------------------- > > ------------------------------------------------- If you wish to unsubscribe from this list, please send an empty message to the following address: [EMAIL PROTECTED] -------------------------------------------------
