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
