Having alternative strategies that map between MapMessages and XML
might be interesting, but to start with we should have at least one
implementation that meets all of the following requirements:
1. Highly optimized and having the least possible overhead (even if
the AXIOM tree is build).
2. The XML representation must be simple so that it can be easily used
with XSLT and XPath.
3. The mapping must be two way and lossless. That is important if you
want to switch from JMS to another protocol and then back again to
JMS.
In my opinion, the XMLEncoder based solution doesn't satisfy the first
two requirements, but will meet the last one.
The other implementation you propose
- partially satisfies requirement 1 (partially because - as far as I
can see - it will build the AXIOM tree twice when the content is
accessed);
- satisfies requirement 2;
- doesn't satisfy requirement 3 because it looses information about
the property types, i.e. you will not be able to recreate an
equivalent MapMessage from the XML representation.
Andreas
On Tue, Oct 28, 2008 at 04:44, Senaka Fernando <[EMAIL PROTECTED]> wrote:
> Hi Andreas,
>
> The scenario here was to have an implementation that will support Map
> Messages "as well as" hierarchical Maps, and any generic use of Maps with
> OM. And as you have mentioned here Map Messages can only have primitive
> types on it. Therefore, in theory MapMessage support would only require a
> subset of provisions made by this implementation.
>
> Also, if you have tried the implementation I have at the moment, it supports
> alternative strategies (so you may use whatever type of serializer you
> want).
>
> Regards,
> Senaka
>
> On Tue, Oct 28, 2008 at 5:34 AM, Andreas Veithen
> <[EMAIL PROTECTED]>wrote:
>
>> 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
>> >> >
>> >>
>> >
>>
>
