Senaka,
How does your question actually relate to the MapMessage support you
are working on? AFAIK MapMessages can't contain arbitrary Java
objects.
Andreas
On Sun, Oct 26, 2008 at 22:19, Senaka Fernando <[EMAIL PROTECTED]> wrote:
> 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
>> >
>>
>
