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
