Hi Andreas, I have added DataHandler related logic to [1] , please do let me know whether I've taken the correct approach. There seems to be several ways in which I can create a DataHandler, and to be on the safe side, I chose, the [2] based implementation.
[1] http://sci-flex.googlecode.com/svn/sci-flex/trunk/java/axiom/src/main/java/org/apache/axiom/om/util/WrappedMapNodeStreamReader.java<http://sci-flex.googlecode.com/svn/sci-flex/trunk/java/axiom/src/main/java/org/apache/axiom/om/util/WrappedMapNodeStreamReader.java> [2] http://svn.apache.org/repos/asf/webservices/commons/trunk/modules/axiom/modules/axiom-api/src/main/java/org/apache/axiom/attachments/utils/DataHandlerUtils.java Thanks, Senaka On Tue, Nov 11, 2008 at 10:31 PM, Senaka Fernando <[EMAIL PROTECTED]>wrote: > Thanks for the clarification. Yes, this sounds a perfect scheme. I will > have this implementation added shortly. > > Regards, > Senaka > > > On Tue, Nov 11, 2008 at 10:23 PM, Andreas Veithen < > [EMAIL PROTECTED]> wrote: > >> 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/ >> >> >>> >> >> >> >>> > >> >> >>> >> >> >> >> >> >> >> >> > >> >> >> > >> > >
