I mean output a DataHandler from the XMLStreamReader. In that case next() would still return a CHARACTERS event.
What AXIOM does for CHARACTERS events is to call getProperty (on your XMLStreamReader) with property name OMConstants.IS_BINARY. If the value is false, it simply calls getText(). If it is true, it calls getProperty again with OMConstants.DATA_HANDLER (instead of calling getText), giving you a chance to return a DataHandler object. Note that your XMLStreamReader also needs to recognize the OMConstants.IS_DATA_HANDLERS_AWARE property and return true to enable this mechanism in AXIOM. Andreas On Mon, Nov 10, 2008 at 18:35, Senaka Fernando <[EMAIL PROTECTED]> wrote: > 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/ >> >>> >> >> >>> > >> >>> >> >> >> >> >> > >> >
