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 >
