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]
-------------------------------------------------
