Details
-
Type:
New Feature
-
Status:
Closed
-
Resolution: Fixed
-
Affects Version/s: None
-
Fix Version/s: 1.4
-
Component/s: None
-
Labels:None
Description
The schemas I deal with make heavy use of xsd:key on what are intended as sequences of uniquely identifiable entries; a.k.a, maps. Take for example:
<xsd:key name="ejb-name-key">
<xsd:annotation>
<xsd:documentation>
The ejb-name element contains the name of an enterprise
bean. The name must be unique within the ejb-jar file.
</xsd:documentation>
</xsd:annotation>
<xsd:selector xpath="javaee:enterprise-beans/*"/>
<xsd:field xpath="javaee:ejb-name"/>
</xsd:key>
The attached patch allows someone to flag a field of the java class as being a key and allows that object to be added to a map using that key value. Such as:
xstream.addImplicitKey(EnterpriseBean.class, "ejbName");
I've taken some time and split the patches in two as it may be easier to deal with the addition in logical parts.
Issue Links
- is depended upon by
-
XSTR-408
@XStreamImplicit should support fields of type Map
-
Activity
Removed ImplicitKeySupport.work to avoid confusion.
Mauro Talevi
added a comment - Removed ImplicitKeySupport.work to avoid confusion. I took the liberty now and let me just inspire by the patch and I've added the functionality in a similar fashion as variation of the implicit collection handling. The key is defined with the definition of the implicit map and not with the type itself. Available in HEAD.
Jörg Schaible
added a comment - I took the liberty now and let me just inspire by the patch and I've added the functionality in a similar fashion as variation of the implicit collection handling. The key is defined with the definition of the implicit map and not with the type itself. Available in HEAD. 
Looks like I was too tired when I submitted the patch. ImplicitKeySupport.work was not meant to be the file I intended as it contains some content which needlessly overlaps with a previous patch. Attached now is a clean and double-checked patch.