Hi Andreas,
Here you go:
<map>
<java version="1.6.0_06" class="java.beans.XMLDecoder">
<object class="java.util.TreeMap">
<void method="put">
<string>KeyStr</string>
<string>five</string>
</void>
<void method="put">
<string>Test</string>
<float>5.5</float>
</void>
<void method="put">
<string>SomeKey</string>
<int>5</int>
</void>
<void method="put">
<string>nested</string>
<object class="java.util.TreeMap">
<void method="put">
<string>me</string>
<float>2.0</float>
</void>
<void method="put">
<string>more</string>
<int>100</int>
</void>
<void method="put">
<string>moreNested</string>
<object class="java.util.TreeMap">
<void method="put">
<string>String</string>
<string>ten</string>
</void>
</object>
</void>
</object>
</void>
</object>
</java>
</map>
This is the serialization for a TreeMap having {<KeyStr, five>, <Test, 5.5>,
<someKey, 5>, <nested, {<me, 2.0>, <more, 100>, <moreNested, {<String,
ten>}>}>}
Regards,
Senaka
On Mon, Oct 27, 2008 at 1:52 AM, Andreas Veithen
<[EMAIL PROTECTED]>wrote:
> Senaka,
>
> Just a quick question: what does the serialization of a Map looks like
> with XMLEncoder?
>
> Andreas
>
> On Sat, Oct 25, 2008 at 20:01, Senaka Fernando <[EMAIL PROTECTED]>
> wrote:
> > Hi all,
> >
> > I'm working on a mechanism to attach a java.util.Map onto an Axiom Tree.
> So
> > far, I have been able to attach the java.util.Map onto the OM Tree with
> the
> > help of a specialized data source I have created. This implementation
> > features on-demand building of the XML payload and I believe the broader
> > usefulness of this would be to serve as a mechanism to store a
> java.util.Map
> > as a part of the OM Tree and perform XML operations (ex:- XPath) to
> extract
> > data if needed. However, there can be situations where one would require
> to
> > serialize the internal Map payload and obtain an XML representation. This
> > can be achieved either through a custom serializer or through a built-in
> > serializer that will convert the Map into an XML representation. I have
> as
> > of present added two serializers to the implementation.
> >
> > 1. A simple serializer i I wrote that can handle primitive types, and
> Maps
> > (supports hierarchical maps)
> > 2. The Java XML encoder/decoder for beans java.beans.XMLEncoder /
> > java.beans.XMLDecoder (Apache Harmony has an implementation of this if
> you
> > are interested in digging deeper into what happens, [1], [2])
> >
> > Now, after having a word with Paul on this setup I decided to make this
> > implementation more generic, and capable of supporting any type of object
> > attached to the Map, which eventually drops the 1st implementation above.
> > The second works fine, but, is a highly Java specific way of doing things
> > (but there is another point here, java.util.Map is Java anyway so this
> might
> > not be an issue) and make no sense in a non-Java context, and can also be
> > memory consuming and inefficient.
> >
> > I have investigated the possibility to make use of,
> >
> > 3. org.apache.axis2.databinding.utils.BeanUtil
> > - This is a sample source code portion that i used,
> >
> > XMLStreamReader xtr = BeanUtil.getPullParser(map);
> > StAXOMBuilder builder = new StAXOMBuilder(xtr);
> > OMElement ele = builder.getDocumentElement();
> >
> > However, for some reason this doesn't work and I run into an NPE.
> >
> > org.apache.axiom.om.OMException: java.lang.NullPointerException
> > at
> >
> org.apache.axiom.om.impl.builder.StAXOMBuilder.next(StAXOMBuilder.java:251)
> > at
> >
> org.apache.axiom.om.impl.llom.OMDocumentImpl.getOMDocumentElement(OMDocumentImpl.java:132)
> > at
> >
> org.apache.axiom.om.impl.builder.StAXOMBuilder.getDocumentElement(StAXOMBuilder.java:526)
> > at my.package.MyClass.myMethod(MyClass.java:127)
> > Caused by: java.lang.NullPointerException
> > at
> >
> org.apache.axiom.om.impl.builder.StAXOMBuilder.endElement(StAXOMBuilder.java:508)
> > at
> >
> org.apache.axiom.om.impl.builder.StAXOMBuilder.next(StAXOMBuilder.java:222)
> > ... 35 more
> >
> > I spoke to Chinthaka on this matter, and was told that there might be
> an
> > assumption that the BeanUtil can only handle Bean Classes, or Classes
> that
> > are not Maps, which might have lead to this situation. I believe it wont
> be
> > easy to fix these issues. This is the rationale: I might be able to get
> this
> > to work for java.util.Map, but the whole idea is to make use of it to
> > serialize any type of object, where I can't anticipate the stability.
> >
> > 4. PayloadHelper in Apache Synapse
> > This is a robust implementation that will work for primitive Maps (based
> > on org.apache.synapse.util.SimpleMap) like option 1. above. However, it
> > lacks some aspects.
> > a. It is still a part of Synapse and needs to be ported to Axiom (this
> > is do-able as the system has clear and loosely coupled interfaces).
> > b. It is an extension of HashMap and thus will not work with other Map
> > types, such as TreeMap which can be an issue when element ordering comes
> > into play.
> > c. It wont support Hierarchical Maps (please correct me if I made a
> > mistake here).
> > d. It still doesn't serve the purpose of supporting more generic Maps
> > with any types of objects in it.
> >
> > 5. A serialization/de-serialization mechanism found in Axis1 seems
> > interesting as well.
> > - test/soap12/TestDeser.java, test/soap12/TestSer.java explains this
> > fact.
> >
> > In here, we have several advantages
> > a. Uniform representation of any primitive type as well as complex
> types
> > as composites of primitive types
> > b. Good performance
> > c. Ability to nest
> > d. Highly customizable
> >
> > But, there are disadvantages
> > a. This scheme is not capable of storing information about the
> > underlying object unless it being explicitly told. Thus, unless we know
> what
> > is going on, the Vector class or an extension of a Vector class is
> > represented in the very same way. This is not the case in the java
> > serializer mechanism as object type information is automatically encoded.
> > b. Assume that we came up with a modification to this scheme that
> makes
> > it possible to encode object types, still the implementor will have to
> > perhaps write his own Type Table for a type that we did not anticipate.
> > c. Implementation can be complicated as the complexity of the types of
> > objects representable increases
> > d. Additional maintenance overhead
> >
> > Therefore, each scheme seem to have pros and cons, and are not perfectly
> > fitting in. IMHO, the Java serializer might be the best scheme if we are
> to
> > consider a single scheme. However, modifications to a certain scheme to
> have
> > a combination of schemes to yield a useful result can prove to be
> > advantages. Also, I might have missed some other possibilities. Your
> input
> > is highly appreciated, and will serve as means for the approach I should
> be
> > taking.
> >
> > The current implementation is not as yet a part of Axiom and is available
> > at, [3]. The source includes a maven build system, and please note that
> if
> > you may run into some test failures due to an issue in the Axiom
> forceExpand
> > logic. I'm looking forward to have this fixed on the Axiom trunk.
> >
> > [1]
> >
> http://svn.apache.org/repos/asf/harmony/enhanced/classlib/trunk/modules/beans/src/main/java/java/beans/XMLEncoder.java
> > [2]
> >
> http://svn.apache.org/repos/asf/harmony/enhanced/classlib/trunk/modules/beans/src/main/java/java/beans/XMLDeccoder.java
> > [3] http://sci-flex.googlecode.com/svn/sci-flex/trunk/java/axiom
> >
> > Thanks,
> > Senaka
> >
>
