Hi Andreas, Thanks for the pointer, however, I'd still like to make one clarification. Do you mean here to internally maintain a DataHandler? or to output a DataHandler from the XMLStreamReader?
If you mean the latter, what would the call to next return from the states in [1]. And, if you mean the former, I'd like to know why is it necessary to maintain a DataHandler when you already got the Map with the byte[]? [1] http://java.sun.com/javase/6/docs/api/javax/xml/stream/XMLStreamConstants.html Regards, Senaka On Mon, Nov 10, 2008 at 10:34 PM, Andreas Veithen <[EMAIL PROTECTED] > wrote: > Senaka, > > I think for efficiency, it should be the other way round: The > XMLStreamReader should produce a DataHandler, which is a thin layer on > top of the byte[]. AXIOM will then convert to Base64 on demand. A look > at OMStAXWrapper#getProperty might help to understand how this can be > achieved. > > Andreas > > On Mon, Nov 10, 2008 at 16:26, Senaka Fernando <[EMAIL PROTECTED]> > wrote: > > Hi Andreas, > > > > I have added code to handle byte[] data as well, at [1]. As far as I > > understood, normally Axiom will store data as text, unless a DataHandler > is > > created and attached to a tree, and the DataHandler can be extracted from > > the text (the DataHandler is created on-demand). For this to happen the > text > > must be Base64 encoded. This is the same procedure that takes place when > the > > Axis2 engine receives a XML payload having binary content embedded as > Base64 > > encoded text. Also, since I'm dealing with an XMLStreamReader, I believe > > that this approach sounds logical. WDYT? > > > > I have also moved the char[] based code to use Strings as suggested. > > > > [1] > > > http://sci-flex.googlecode.com/svn/sci-flex/trunk/java/axiom/src/main/java/org/apache/axiom/om/util/WrappedMapNodeStreamReader.java > > > > Regards, > > Senaka > > > > On Mon, Nov 10, 2008 at 12:22 AM, Senaka Fernando <[EMAIL PROTECTED] > >wrote: > > > >> Hi Andreas, > >> > >> I did some modifications to the source and committed it minutes ago. My > >> previous post to the thread shows a sample output. Seems that your last > post > >> and my last post were sent almost at the same time. :-).. So in addition > to > >> what I've said in the previous post, i have added some comments to this > >> post, inline. > >> > >> On Mon, Nov 10, 2008 at 12:06 AM, Andreas Veithen < > >> [EMAIL PROTECTED]> wrote: > >> > >>> Senaka, > >>> > >>> I didn't execute the code yet, but I did a quick review and it looks > >>> already very good. I would like to make the following comments to > >>> improve this still further: > >>> > >> > >> Thanks, and I will add some tests for this code, shortly. I tweaked the > >> present test source to observe the sample output, which I have not > >> committed. > >> > >>> > >>> * In WrappedTextNodeStreamReader, the character data is returned in > >>> chunks in order to avoid loading the entire data into memory > >>> (typically the data comes from a temporary file). I don't think that > >>> this is necessary for the map values, and could even introduce > >>> unnecessary overhead. They should simply be converted to a String and > >>> returned as a single chunk. Getting rid of the java.io.Reader would > >>> also simplify the code. > >> > >> > >> Sounds logical. But, what made me go for this approach is that I assumed > >> that at times a typical Map MIGHT have data that is too large to fit in > >> memory. WDYT? > >> > >>> > >>> * The right way to represent a byte[] value is to produce a > >>> DataHandler (which is equivalent to having the binary data encoded as > >>> Base64). Note that this is not directly supported by the StAX API, but > >>> rather an extension introduced by AXIOM to handle binary data > >>> efficiently. Please have a look at > >>> StAXBuilder#createOMText(OMContainer, int) to see how this magic > >>> works. > >> > >> > >> Thanks for the pointer, I will try to add this logic as well. > >> > >>> > >>> * For the moment the key of a map entry is represented using a "key" > >>> attribute but also used for the element name. I guess this is a > >>> mistake. Since a map key is not necessarily a valid XML element name, > >>> I think we should prefer the representation using an attribute. > >> > >> > >> I corrected this. Now, element names are "value", and the key is an > >> attribute. The logic limits Map keys to types that can be represented as > >> Strings, and an exception is thrown if it is of any other type. > >> > >> Regards, > >> Senaka > >> > >>> > >>> Regards, > >>> > >>> Andreas > >>> > >>> On Sun, Nov 9, 2008 at 11:40, Senaka Fernando <[EMAIL PROTECTED]> > >>> wrote: > >>> > Andreas, > >>> > > >>> > I did go through your suggested implementation, and [1]'s what I'm > >>> planning > >>> > to do. Please do let me know whether I've made the correct choices. > As > >>> of > >>> > now, the getElementText() method is perhaps not quite correct and I > have > >>> not > >>> > yet added a mechanism to represent a byte[]. > >>> > > >>> > [1] > >>> > > >>> > http://sci-flex.googlecode.com/svn/sci-flex/trunk/java/axiom/src/main/java/org/apache/axiom/om/util/WrappedMapNodeStreamReader.java > >>> > > >>> > Regards, > >>> > Senaka > >>> > > >>> > On Sat, Nov 8, 2008 at 1:36 AM, Sanjiva Weerawarana > >>> > <[EMAIL PROTECTED]>wrote: > >>> > > >>> >> +1 Andreas. This should be written so that the OM is created IFF XML > >>> >> navigation is done. Otherwise the map message should remain in Java > and > >>> then > >>> >> just get piped thru - that's critical for Synapse performance. > >>> >> > >>> >> Sanjiva. > >>> >> > >>> >> > >>> >> Andreas Veithen wrote: > >>> >> > >>> >>> Senaka, > >>> >>> > >>> >>> The AXIOM tree is built twice because of the following piece of > code: > >>> >>> > >>> >>> public XMLStreamReader getReader() throws XMLStreamException { > >>> >>> return getUnderlyingElement().getXMLStreamReader(); > >>> >>> } > >>> >>> > >>> >>> The getUnderlyingElement method will build an AXIOM tree > representing > >>> >>> the Map(Message), but when the OMSourcedElement is expanded, AXIOM > >>> >>> will build another tree based on the events pulled from the > >>> >>> XMLStreamReader. There are two options then: > >>> >>> > >>> >>> 1. One considers that in the vast majority of cases, the content > will > >>> >>> be accessed anyway. Then it would make more sense to construct the > >>> >>> AXIOM tree directly when the message is received (i.e. no need for > an > >>> >>> OMSourcedElement). > >>> >>> 2. Don't build an AXIOM tree inside the OMDataSource but construct > an > >>> >>> XMLStreamReader implementation that returns the sequence of StAX > >>> >>> events corresponding to the desired XML representation. > >>> >>> > >>> >>> I used the technique behind option 2 in the following piece of > code: > >>> >>> > >>> >>> > >>> >>> > >>> > http://svn.apache.org/repos/asf/synapse/trunk/java/modules/core/src/main/java/org/apache/synapse/util/WrappedTextNodeStreamReader.java > >>> >>> > >>> >>> The XMLStreamReader implementation shown in this link is used to > >>> >>> transform character data (provided by a java.io.Reader) into an > >>> >>> OMSourcedElement that wraps this data, i.e. the resulting tree > would > >>> >>> be an element with a text node as child. That doesn't sound very > >>> >>> useful at first glance, but in case of very long character data, it > >>> >>> allows to stream the data almost directly from the source to the > >>> >>> destination without ever building the OMText nodes (which would > >>> >>> consume a large amount of memory). > >>> >>> > >>> >>> Given that reading the data source is non destructive, option 2 has > >>> >>> the advantage that the AXIOM tree > >>> >>> * will be built exactly once if somebody queries the child OMNodes; > >>> >>> * will not be built at all when somebody serializes the content > into a > >>> >>> byte stream. > >>> >>> > >>> >>> While this is the optimal solution, it is also much more difficult > to > >>> >>> implement. It is certainly an interesting challenge to do that. > >>> >>> > >>> >>> Finally, for the type problem, it is indeed sufficient to add a > "type" > >>> >>> attribute to the element that represents the key-value pair: > >>> >>> > >>> >>> <price type="double">12.456</price> > >>> >>> > >>> >>> Andreas > >>> >>> > >>> >>> On Thu, Oct 30, 2008 at 10:34, Senaka Fernando < > [EMAIL PROTECTED]> > >>> >>> wrote: > >>> >>> > >>> >>>> Hi Andreas, > >>> >>>> I agree with your observations here. Also, I would like to > understand > >>> >>>> what > >>> >>>> you mean by "it will build the AXIOM tree twice when the content > >>> >>>> is accessed", can this be corrected? As far as Map Messages found > in > >>> the > >>> >>>> jms > >>> >>>> transport are concerned, the key is of type string, and the value > is > >>> a > >>> >>>> primitive java type, I believe that a slight modification option 2 > >>> >>>> discussed > >>> >>>> here should work. WDYT? > >>> >>>> > >>> >>>> Regards, > >>> >>>> Senaka > >>> >>>> > >>> >>>> On Thu, Oct 30, 2008 at 2:10 AM, Andreas Veithen > >>> >>>> <[EMAIL PROTECTED]>wrote: > >>> >>>> > >>> >>>> 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 > >>> >>>>>>>>>> > >>> >>>>>>>>>> > >>> >> > >>> >> -- > >>> >> Sanjiva Weerawarana, Ph.D. > >>> >> Founder & Director; Lanka Software Foundation; > >>> http://www.opensource.lk/ > >>> >> Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/ > >>> >> Member; Apache Software Foundation; http://www.apache.org/ > >>> >> Visiting Lecturer; University of Moratuwa; > http://www.cse.mrt.ac.lk/ > >>> >> > >>> >> Blog: http://sanjiva.weerawarana.org/ > >>> >> > >>> > > >>> > >> > >> > > >
