This is a url comparing the different stax implementations from different company in detail,: http://www.xml.com/pub/a/2007/05/09/xml-parser-benchmarks-part-1.html?page=2 from this article:i think the SUN SJSXP and cohaus Woodstox stax should be our choices. between these two, at to the reference materials amount, maybe the former is better.
2008/4/7, Werner Guttmann <[EMAIL PROTECTED]>: > > Joachim, > > it used to be with older JAXP releases that one could download > separatedly parts of the JAXP implementation classes. Is this not the > case anymore ? > > > Werner > > > Joachim Grüneis wrote: > > JAXP includes StAX starting from JAXP 1.4 (included in JSE 6) on > > JSE 5 (JAXP 1.3) did not include StAX and requires to be included from > > another source, e.g. Codehaus StAX > > JSE 1.4 (and before) also require a StAX implementation besides JAXP > > > > Have fun > > > > Joachim > > > > On Apr 5, 2008, at 11:07 AM, Werner Guttmann wrote: > >> > >> > >> 建坛林 wrote: > >>> another question:There serveral companies that have implements the > stax > >>> APi.For example, the companies listed below. > >>> > >>> * Sun's Implementation - SJSXP <http://sjsxp.dev.java.net/> > >>> * BEA Reference Implementation > >>> <http://dev2dev.bea.com/technologies/stax/index.jsp> > >>> * Oracle StAX Pull Parser Preview > >>> <http://www.oracle.com/technology/tech/xml/xdk/staxpreview.html> > >>> * codehaus StAX > >>> <http://stax.codehaus.org/Download> > >>> > >>> which API package will we adopt? > >> Good question .. ;-). In other words, I don't know yet. I will be part > >> of your task to make this deciskion, or find a Java-based standard that > >> allows us to plug in any STaX parser. > >> > >>> 在08-4-4，*Werner Guttmann* <[EMAIL PROTECTED] > >>> <mailto:[EMAIL PROTECTED]>> 写道： > >>> > >>> > >>> > >>> 建坛林 wrote: > >>>> Hello, Werner.Thanks for your reply and good suggestion. > >>>> > >>>> the problem you refer to does exists. At the begining, i myself > >>> want to > >>>> implements a adapter to bridge the gap between these two Parsers. > >>> So i > >>>> offers a much more obvious one. Obviously, it 's not a good one. > >>> > >>> Well, it's not that it is a bad idea per se. I am just looking at > >>> things > >>> from a different perspective. Well, quite some perspectives .. > ;-). > >>> > >>> a) If we go for an approach where you build the StAX* classes from > >>> scratch (without relying on existing cod base, that is), you'll b > >>> creating lots of code that already exists in the current e.g. > >>> UnmarshalHandler class(es). Now, I don't really like the idea of > >>> code > >>> duplication, but trying to refactor this would clearly make this > >>> work > >>> far bigger in size (and thus not really acceptable for the GSoC > >>> program). > >>> > >>> b) As already mentioned, there's one thing that should not really > >>> change, i.e. the classes the user interacts with. At least not in > an > >>> ideal world. I know that we now and then have to change the public > >>> interfaces, but this should be as limited as possible. > >>> > >>> Having said that, one way to improve things for Castor XML in the > >>> future > >>> is to introduce interfaces, which currently do not exist on the > >>> XML side > >>> of things. > >>> > >>> Looking forward to your follow-up. > >>> > >>> Werner > >>> > >>>> I'll > >>>> try to read more material to verify your suggestion. > >>>> (i will describe it in uml in my next letter) > >>>> > >>>> and there is another idea we can try as the picture in the > >>> accessory show: > >>>> as stax is attractive in filtering our preferable partical(event). we > >>>> can first refine the xml by stax then use the existed SAXhandler to > >>>> finish the rest > >>>> un~/marshalling work. but is it a adapter. it seems a bit not. > >>>> > >>>> 2008/4/3, Werner Guttmann <[EMAIL PROTECTED] > >>> <mailto:[EMAIL PROTECTED]> > >>> > >>>> <mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>>: > >>> > >>>> > >>>> Hi Jiantan, > >>>> > >>>> looking at your ideas, I wonder whether this approach is a > >>> good one > >>>> (though it is a valid one). Let me try to express my thoughts > >>>> (slightly unstructured): > >>>> > >>>> - Is is really a good idea to expose the technologies we are > >>> using > >>>> internally to parse an XML document to the user. In other words, > >>>> should the user know and explicitely have to use classes that > >>> carry > >>>> names that are linked to a technology such as SAX or STaX ? > >>> Is there > >>>> a way to make this more transparent ? > >>>> > >>>> - Would it be possible to layer the approaches ? Personally, > >>> I see > >>>> the main benefits of a STaX parser in the context of XML data > >>>> binding that it would be absolutely easy to restrict the scope of > >>>> processing during e.g. unmarshalling. In other words, within a > >>>> biggish XML document navigate to a (smaller) subset and only use > >>>> this subset as the input for unmarshalling. Such a layering > >>> could be > >>>> achieved by creating an adapter that sits between the StAX parser > >>>> and the UnmarshalHandler (which implements SAX > >>> ContentHandler), and > >>>> translates STaX events into SAX events. This way, we would avoid > >>>> having to completely write a new STaXUnmarshalHandler (and > >>> all the > >>>> logic currently sitting in UnmarshalHandler). > >>>> > >>>> Werner > >>>> > >>>> > >>>> 建坛林 wrote: > >>>> > >>>> 1.introduction marshalling is the processing of convert a > >>>> Object into xml(or other structured) file, while > >>> unmarshalling > >>>> is the reverse processing of marshalling. This techonology is > >>>> very useful in data binding and data transfering. > >>>> Marshaller/Unmarshaller is the very object that > >>> responsible for > >>>> doing these work. For marshaller/unmarshaller to do the > >>>> marshalling work, it need the help of a xml parser. There are > >>>> two kinds of xml parser nowaday:one is based on dom > >>> model, the > >>>> other is based on stream model.As to the latter one, we > >>> got sax > >>>> and stax. sax is a push parser, while stax is a pull > >>> parser. I > >>>> think castor's purpose of switching between the sax and > >>> stax is > >>>> to make castor more adaptive to different situations. > >>>> > >>>> 2.solution > >>>> > >>>> i think the work should be done to the class Marshaller and > >>>> UnMarshaller in Castor source. > >>>> Make Marshaller.java,UnMarshller > >>>> .java upper class instead of final class > >>>> class Marshaller { > >>>> private int parserType; > >>>> Marshaller marshaller = new SAXMarshaller() ; > >>>> ... > >>>> public static void marshal(Object obj,Writer writer); > >>>> public static void marshal(Object obj,int parserType); > >>>> public static void marshal(Object obj,Marshaller > >>> marshaller); > >>>> ... > >>>> public void setMarshaller(Marshaller marshaller); > >>>> public Marshaller getMarshaller(); > >>>> ... > >>>> } > >>>> class UnMarshaller { > >>>> private int parserType; > >>>> UnMarshaller unMarshaller = new SAXUnMarshaller() > >>>> public Object unmarshal(InputSource in){ > >>>> unMarshaller.unmarshal(in); > >>>> } > >>>> public Object unmarshal(InputSource in, int > >>> parserType); > >>>> public Object unmarshal(InputSource in,UnMarshaller > >>>> unmarshaller); > >>>> ... > >>>> public void setUnMarshaller(UnMarshaller unMarshaller); > >>>> public UnMarshaller getUnMarshaller(); > >>>> ... > >>>> } > >>>> this Un~/Marshaller keeps the common methods of SAXMarshaller > >>>> and StaxMarshaller, > >>>> default use a SAXMarshller in order to make the existed code > >>>> unchanged;we change the Marshaller by using the specific > >>>> constructor and setUn~/Marshaller method. In this case, > >>>> it's flexible to switch from sax to stax,vice versa. It seems > >>>> this pattern is much more like > >>>> the strategy pattern. we just abstract the algorithm of > >>>> un~/Marshal. and it's flexible to > >>>> switch between these algorithm. > >>>> > >>>> the former Marshaller.java can be a SAXMarshller.java and > >>>> SAXUnMarshaller.java. > >>>> class SAXMarshaller extends Marshaller { > >>>> ... > >>>> } > >>>> > >>>> class SAXUnMarshaller extends UnMarshaller { > >>>> ... > >>>> } > >>>> > >>>> we can add by the following new Implementation of Marshaller > >>>> class StaxMarshaller implements Marshaller { > >>>> ... > >>>> } > >>>> > >>>> class StaxUnMarshaller implements UnMarshaller { > >>>> ... > >>>> } > >>>> > >>>> > >>>> make MarshallingHandler ,UnMarshallingHandler upper class > >>>> instead of final class just like > >>>> we did to Marshaller,UnMarshller > >>>> > >>>> the specific work we have to do is in implemented a new > >>>> StaxMarshallerHandler and StaxUnMarshallerHandler > >>>> > >>>> to implement the Un~/Marshalling in stax way > >>>> > >>>> class SAXMarshallingHandler extends MarshallingHandler { > >>>> } > >>>> > >>>> class SAXUnMarshallingHandler extends UnMarshallingHandler { > >>>> } > >>>> > >>>> class StaxMarshallingHandler extends MarshallingHandler { > >>>> } > >>>> > >>>> class StaxUnMarshallingHandler extends > >>> UnMarshallingHandler { > >>>> } > >>>> And the specific implementation of StaxMarshallingHandler is > >>>> associated with how to map > >>>> a object to xml(and the reverse process).The detail of > >>> this can > >>>> refer the implementation > >>>> of StaxMarshallingHandler(former MarshallingHandler). > >>>> > >>>> 3.self-introduction > >>>> > >>> http://docs.google.com/Doc?docid=dc42tcq9_88gtxts6fv&hl=en > >>> <http://docs.google.com/Doc?docid=dc42tcq9_88gtxts6fv&hl=en> > >>>> > >>> <http://docs.google.com/Doc?docid=dc42tcq9_88gtxts6fv&hl=en > >>> <http://docs.google.com/Doc?docid=dc42tcq9_88gtxts6fv&hl=en>> > >>>> > >>> <http://docs.google.com/Doc?docid=dc42tcq9_88gtxts6fv&hl=en > >>> <http://docs.google.com/Doc?docid=dc42tcq9_88gtxts6fv&hl=en> > >>>> > >>> <http://docs.google.com/Doc?docid=dc42tcq9_88gtxts6fv&hl=en > >>> <http://docs.google.com/Doc?docid=dc42tcq9_88gtxts6fv&hl=en>>> > >>>> > >>>> > >>>> Jiantan Lin > >>>> > >>>> > >>>> 2008/4/3, Werner Guttmann <[EMAIL PROTECTED] > >>> <mailto:[EMAIL PROTECTED]> > >>> > >>>> <mailto:[EMAIL PROTECTED] > >>> <mailto:[EMAIL PROTECTED]>> <mailto:[EMAIL PROTECTED] > >>> <mailto:[EMAIL PROTECTED]> > >>> > >>>> <mailto:[EMAIL PROTECTED] > >>> <mailto:[EMAIL PROTECTED]>>>>: > >>>> > >>>> HI, > >>>> > >>>> I have recently asked all the students that have > >>> submitted an > >>>> application to be mentored by one of the existing Castor > >>>> committer > >>>> sto subscribe to this mailing list, so that we can ask > >>> questions > >>>> about their proposal and vice versa. > >>>> > >>>> Can I please ask all students to introduce themselves > >>>> briefly, and > >>>> once again describe their proposals. It's especially > >>> the benefits > >>>> for the project that I am personally interested in. > >>>> > >>>> Thanks > >>>> Werner > >>>> > >>>> > >>>> > >>>> --------------------------------------------------------------------- > >>>> To unsubscribe from this list, please visit: > >>>> > >>>> http://xircles.codehaus.org/manage_email > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>> > >>> --------------------------------------------------------------------- > >>>> To unsubscribe from this list, please visit: > >>>> > >>>> http://xircles.codehaus.org/manage_email > >>>> > >>>> > >>>> > >>>> > >>> > >>>> > >>> > >>> > ------------------------------------------------------------------------ > >>>> > >>>> > >>>> > >>> > >>> > ------------------------------------------------------------------------ > >>> > >>>> > >>>> --------------------------------------------------------------------- > >>>> To unsubscribe from this list, please visit: > >>>> > >>>> http://xircles.codehaus.org/manage_email > >>> > >>> > >>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe from this list, please visit: > >>> > >>> http://xircles.codehaus.org/manage_email > >>> > >>> > >>> > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe from this list, please visit: > >> > >> http://xircles.codehaus.org/manage_email > >> > >> > > > > > > --------------------------------------------------------------------- > > To unsubscribe from this list, please visit: > > > > http://xircles.codehaus.org/manage_email > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > >
