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


Reply via email to