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/ > >> >>> >> > >> >>> > > >> >>> > >> >> > >> >> > >> > > >> > > >
