Loading ...
Sorry, an error occurred while loading the content.

Evolution Case Study - Solutions

Expand Messages
  • Brendan Macmillan
    Hi Krishna, Thanks for explaining more - it really helps a lot! I m using your example as a case study to show how to handle this kind of evolution in JSX. But
    Message 1 of 7 , Jan 1, 2003
    • 0 Attachment
      Hi Krishna,

      Thanks for explaining more - it really helps a lot!

      I'm using your example as a case study to show how to handle this kind
      of evolution in JSX. But first, I'll recap the specific issues you raised -
      if you like, scroll down to "EVOLUTION CASE STUDY - SOLUTIONS".

      Thinking on your previous email last night, I realized you wanted the XML
      to show the order that the primitives were written, with respect to all
      values written (both primitive and reference); not just with respect to
      other primitive values. But JSX treats the primitives separately from the
      objects, and so (for example) the first primitive might not be the first
      value - there could have been 10 object references before it, for example.

      This causes problems if a field evolves from primitive to reference
      (or vice versa). Your example is great, of an int evolved to an Integer.


      > We are required to upgrade the data
      > in serialized java objects of previous version to the new version.
      > The previous version used both custom serialization and inheritance
      > extensively.

      > We want to take care of data upgrade by exporting the
      > data from the previous version java objects to an XML file and write
      > java code to understand the exported data in the XML and create
      > equivalent java objects of the new version. For transforming the data
      > from XML, we would like make use of java code since we do some
      > computation in the constructor of various new classes and we would
      > like to avoid replicating this code in style sheets.
      A compelling but non-obvious reason to do the transformation in Java
      instead of XSLT - good insight. So, you writing a special-purpose
      transformation in java, in a sense

      Version 1:
      > <SecondLevel_1 alias-ID="0" _.0="1000" ...

      Version 2:
      > <SecondLevel_1 obj-name="secondLevelObj" / >
      > <java.lang.Interger obj-name="FirstLevel.value1" valueOf="1000">

      > I want to write a small java program which
      > parses the first XML file, create new java object and serialize this
      > java object. It would help me a great extent to generic data upgrade
      > framwork if I can know the order in which the data was written to the
      > XML file from the XML file itself without looking at writeObject()
      > method of my classes. For example, _.1 and_.2 might have written
      > after writing the vector and other data. If _.1 and _.2 values were
      > written after writing other 17 values, I would like it to see them in
      > my XML as _.18 and _.19.

      Thinking ahead a bit: Don't you need to look at the writeObject to
      know what those particular value *mean*, so your java program
      knows what to do with them?

      It's easy to change JSX to do this (I can send you a modified version
      to do it) - however, this approach still seems like a lot of work for
      you. I think there are some much easier ways.

      > If you feel I can handle the above data upgrade problem by other
      > ways, i appreciate if you could pass them on to me.

      OK! First, please check out JSX2 - this writes out all values
      as elements (primitives and references together), so everything is
      in the right order. I would guess that this is slightly easier for you
      to work with than the above.


      EVOLUTION CASE STUDY - SOLUTIONS
      Second, in JSX2, you can write a "filter", which will detect what
      class you are in, what fieldname (or index for writeObject data),
      and you can trigger whatever java code you need to convert this
      (eg your constructors). I am happing to assist you in this extensively,
      including giving you access to templates and writing tutorials,
      answering questions, and writing generic helper code (which
      would also go into JSX2 for others to be able to use).

      But the third solution is the best, *assuming* the class structure has
      not changed dramatically - in other words, that the evolution has
      been on the contents of the classes. The idea is to use a "Memento":
      a class that represents another class. I'll illustrate with an example.
      Lets say we have class A and class A' (old and new versions).

      Assuming you have access to the new class versions, you
      write a new inner static class of A', whose serialization format is
      *exactly the same* as the old class A. You call this
      "Memento". The Memento represents the old class. Eg:

      class A { // old class
      int i;
      }

      class A' { // new class version - obviously " A' " is not a valid name ;-)
      Integer i;
      static class Memento {
      int i; // <---- this is the same serialization format as the old
      class
      }
      }


      Now, you write some mapping code, which will transform an instance of Memento
      into an instance of A' - this uses a "readResolve" method, which is
      automatically
      called during deserialization:

      static class Memento {
      int i;
      Object readResolve() throws ObjectStreamException {
      return new A'(i); // assuming you write a constructor that takes
      an int.
      }
      }

      OK! So what happens is that when JSX sees that you have defined an inner
      Memento,
      it automatically reads the old A object into that, instead of into A'. The
      readResolve
      does the mapping that you are talking about.

      Some notes:
      (1). this won't work with regular serialization, because it will try to map the
      old A onto the new A' - which won't work, because of the evolution we spoke
      about.

      (2). There is some trickiness with inheritance (and you mentioned inheritance).
      Please give me some more info about how the inheritance hierarchy has changed,
      and I can show you how to deal with this. The trickiness is that readResolve
      replaces the whole object - so your mapping code needs to handle the object
      and all its superclasses. Maybe this isn't so bad for your example?

      (3). This is a pure java solution, and so much simpler to get correct - you
      get static type checking from the Memento, for example.

      (4). You can still use your XML parsing technique for more dramatic changes
      (eg that cross classes).


      Finally, we have almost finalized a design for the "Memento" that is easier
      to use than this, and that works on a per class basis (this means that if class
      A and class B have the same super class, you only need to write the
      mapping code for the super class once). It will include some
      default mappings automatically, so you only have to explicitly map the
      fields that have actually changed between classes.

      If this sounds interesting to you, I'd be very happy to work closely with
      you to help solve your evolution with it - please let me know. We can
      also do some preliminary work (to ensure it's a good fit for your
      issues), before committing to it.


      Cheers,
      Brendan
    • Preetham Kajekar
      Hi Brendan, I too am working with Krishna to solve the class evolution problem. I am afraid that we cannot use the third solution you had mentioned since the
      Message 2 of 7 , Jan 2, 2003
      • 0 Attachment
        Message
        Hi Brendan,
           I too am working with Krishna to solve the class evolution problem.
         
        I am afraid that we cannot use the third solution you had mentioned since the classes have evolved quite dramatically in some case (eg one class has evolved into hierarchy of about 20 classes to make it more scalable etc).
        I tried JSX2 and think the XML has all the information needed (as mentioned by krishna). I am currently trying to understand the structure of the XML generated by JSX 2, and these are my observations/questions
        - Class names no longer appear as tag names. Instead, I see only the following tag name
            primitive - for primitive types I suppose.
            object - indicating this is a non primitive type
           declaredClass - Is this *only* to store inheritance related information ?
         Are the above correct ?If not, it would be great if you could send me some doc (if u already have one)describing this format.
         
         
        Another thing I noticed is JSX2 does not solve the problem if two object are written in the same file. (I had mentioned this before and the mail is attchd). Perhaps writing two objects into the same file is bad practice like you and others pointed out. However, it would help if JSX can take care of this.
         
        Thanks,
        ~preetham
        -----Original Message-----
        From: Brendan Macmillan [mailto:bren@...]
        Sent: Wednesday, January 01, 2003 2:41 PM
        To: JSX-ideas@yahoogroups.com
        Subject: [JSX] Evolution Case Study - Solutions

        Hi Krishna,

        Thanks for explaining more - it really helps a lot!

        I'm using your example as a case study to show how to handle this kind
        of evolution in JSX. But first, I'll recap the specific issues you raised -
        if you like, scroll down to "EVOLUTION CASE STUDY - SOLUTIONS".

        Thinking on your previous email last night, I realized you wanted the XML
        to show the order that the primitives were written, with respect to all
        values written (both primitive and reference); not just with respect to
        other primitive values. But JSX treats the primitives separately from the
        objects, and so (for example) the first primitive might not be the first
        value - there could have been 10 object references before it, for example.

        This causes problems if a field evolves from primitive to reference
        (or vice versa). Your example is great, of an int evolved to an Integer.


        > We are required to upgrade the data
        > in serialized java objects of previous version to the new version.
        > The previous version used both custom serialization and inheritance
        > extensively.

        > We want to take care of data upgrade by exporting the
        > data from the previous version java objects to an XML file and write
        > java code to understand the exported data in the XML and create
        > equivalent java objects of the new version. For transforming the data
        > from XML, we would like make use of java code since we do some
        > computation in the constructor of various new classes and we would
        > like to avoid replicating this code in style sheets.
        A compelling but non-obvious reason to do the transformation in Java
        instead of XSLT - good insight. So, you writing a special-purpose
        transformation in java, in a sense

        Version 1:
        > <SecondLevel_1 alias-ID="0" _.0="1000" ...

        Version 2:
        > <SecondLevel_1 obj-name="secondLevelObj" / >
        >     <java.lang.Interger obj-name="FirstLevel.value1" valueOf="1000">

        > I want to write a small java program which
        > parses the first XML file, create new java object and serialize this
        > java object. It would help me a great extent to generic data upgrade
        > framwork if I can know the order in which the data was written to the
        > XML file from the XML file itself without looking at writeObject()
        > method of my classes. For example, _.1 and_.2 might have written
        > after writing the vector and other data. If _.1 and _.2 values were
        > written after writing other 17 values, I would like it to see them in
        > my XML as _.18 and _.19.

        Thinking ahead a bit: Don't you need to look at the writeObject to
        know what those particular value *mean*, so your java program
        knows what to do with them?

        It's easy to change JSX to do this (I can send you a modified version
        to do it) - however, this approach still seems like a lot of work for
        you. I think there are some much easier ways.

        > If you feel I can handle the above data upgrade problem by other
        > ways, i appreciate if you could pass them on to me.

        OK! First, please check out JSX2 - this writes out all values
        as elements (primitives and references together), so everything is
        in the right order. I would guess that this is slightly easier for you
        to work with than the above.


        EVOLUTION CASE STUDY - SOLUTIONS
        Second, in JSX2, you can write a "filter", which will detect what
        class you are in, what fieldname (or index for writeObject data),
        and you can trigger whatever java code you need to convert this
        (eg your constructors).  I am happing to assist you in this extensively,
        including giving you access to templates and writing tutorials,
        answering questions, and writing generic helper code (which
        would also go into JSX2 for others to be able to use).

        But the third solution is the best, *assuming* the class structure has
        not changed dramatically - in other words, that the evolution has
        been on the contents of the classes. The idea is to use a "Memento":
        a class that represents another class. I'll illustrate with an example.
        Lets say we have class A and class A' (old and new versions).

        Assuming you have access to the new class versions, you
        write a new inner static class of A', whose serialization format is
        *exactly the same* as the old class A. You call this
        "Memento". The Memento represents the old class. Eg:

        class A {        // old class
            int i;
        }

        class A' {       // new class version - obviously " A' " is not a valid name ;-)
            Integer i;
            static class Memento {
                int i;    // <---- this is the same serialization format as the old
        class
            }
        }


        Now, you write some mapping code, which will transform an instance of Memento
        into an instance of A' - this uses a "readResolve" method, which is
        automatically
        called during deserialization:

            static class Memento {
                int i;
                Object readResolve() throws ObjectStreamException {
                    return new A'(i);    // assuming you write a constructor that takes
        an int.
                }
            }

        OK! So what happens is that when JSX sees that you have defined an inner
        Memento,
        it automatically reads the old A object into that, instead of into A'. The
        readResolve
        does the mapping that you are talking about.

        Some notes:
        (1). this won't work with regular serialization, because it will try to map the
        old A onto the new A' - which won't work, because of the evolution we spoke
        about.

        (2). There is some trickiness with inheritance (and you mentioned inheritance).
        Please give me some more info about how the inheritance hierarchy has changed,
        and I can show you how to deal with this. The trickiness is that readResolve
        replaces the whole object - so your mapping code needs to handle the object
        and all its superclasses. Maybe this isn't so bad for your example?

        (3). This is a pure java solution, and so much simpler to get correct - you
        get static type checking from the Memento, for example.

        (4). You can still use your XML parsing technique for more dramatic changes
        (eg that cross classes).


        Finally, we have almost finalized a design for the "Memento" that is easier
        to use than this, and that works on a per class basis (this means that if class
        A and class B have the same super class, you only need to write the
        mapping code for the super class once). It will include some
        default mappings automatically, so you only have to explicitly map the
        fields that have actually changed between classes.

        If this sounds interesting to you, I'd be very happy to work closely with
        you to help solve your evolution with it - please let me know. We can
        also do some preliminary work (to ensure it's a good fit for your
        issues), before committing to it.


        Cheers,
        Brendan



        To unsubscribe from this group, send an email to:
        JSX-ideas-unsubscribe@egroups.com



        Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
      • Brendan Macmillan
        Hi Preetham, ... When you say evolved into a hierarchy , is there a root object, that refers to this new graph of objects? If there is, then the third
        Message 3 of 7 , Jan 2, 2003
        • 0 Attachment
          Hi Preetham,

          > I am afraid that we cannot use the third solution you had mentioned
          > since the classes have evolved quite dramatically in some case (eg one
          > class has evolved into hierarchy of about 20 classes to make it more
          > scalable etc).

          When you say "evolved into a hierarchy", is there a root object, that
          refers to this new graph of objects? If there is, then the third solution
          can be used: in readResolve(), you create the entire hierarchy
          (including any registrations etc that are needed, invoking any
          factory methods etc), and then return the root object (which contains
          references to all the other objects).

          I don't mean to harp on this; but if the third solution *can* work for
          you, it will be a lot simpler.

          > I tried JSX2 and think the XML has all the information needed (as
          > mentioned by krishna). I am currently trying to understand the structure
          > of the XML generated by JSX 2, and these are my observations/questions
          > - Class names no longer appear as tag names. Instead, I see only the
          > following tag name
          > primitive - for primitive types I suppose.
          > object - indicating this is a non primitive type
          > declaredClass - Is this *only* to store inheritance related
          > information ?
          >
          > Are the above correct ?If not, it would be great if you could send me
          > some doc (if u already have one)describing this format.

          Yes, you are correct on all three counts.

          However, note that the "inheritance related" role of declaredClass is
          to distinguish between fields inherited from different superclasses
          with same fieldname. (the old JSX detects shadowed fields in the
          old classes and distinguishes them by prepending the class name -
          but this fails if the evolved version adds shadowed fields, as they
          can't be detected at write-time).

          We are in the process of assembling some specs. I can send you
          some preliminary specs - however, note that the final form of
          the XML is not yet finalized. This should be a problem for you,
          if you are doing a one-off evolution.

          > Another thing I noticed is JSX2 does not solve the problem if two object
          > are written in the same file. (I had mentioned this before and the mail
          > is attchd). Perhaps writing two objects into the same file is bad
          > practice like you and others pointed out. However, it would help if JSX
          > can take care of this.

          Unlike JSX, JSX2 doesn't write out any <?jsx ... ?> Processing Instructions
          at the moment - so your parser shouldn't have this problem (the attached
          email is for JSX, not JSX2).

          I am assuming that the issue is still whether your *parser* can read two
          objects in the same stream. Do you need *JSX2* to be able to read two
          objects from the same stream?

          BTW: it's not "bad practice" to put two objects in the same stream. My
          main point was that the XML that the parsing tool has difficulties with is
          in fact valid XML. The parser is at fault, not JSX. It's important to be
          clear on technology - but I'm much more concerned with getting a
          working solution than pointing the finger. As I said in my reply to the
          attached email when it was initially sent - if you need this, I can fix it up
          for you. I didn't get a reply to that offer. I now get the impression that
          this reply wasn't read. I don't know what happened there, but experience
          shows that miscommunication can cause a *lot* of unncessary
          problems, waste and frustration - so I flag it now for you, very very
          strongly.

          (1). Can you use solution three, as suggested above?
          (2). I will get some specs on the XML format to you shortly,
          but they will change over time - is that a problem for your
          current use?
          (3). I believe JSX2 won't have the two object problem for
          your parsing tool - please confirm
          (4). Will you need JSX2 to be able to read in two objects
          in this way?


          Cheers,
          Brendan

          >
          > Thanks,
          > ~preetham
          >
          > -----Original Message-----
          > From: Brendan Macmillan [mailto:bren@...]
          > Sent: Wednesday, January 01, 2003 2:41 PM
          > To: JSX-ideas@yahoogroups.com
          > Subject: [JSX] Evolution Case Study - Solutions
          >
          >
          > Hi Krishna,
          >
          > Thanks for explaining more - it really helps a lot!
          >
          > I'm using your example as a case study to show how to handle this kind
          > of evolution in JSX. But first, I'll recap the specific issues you
          > raised -
          > if you like, scroll down to "EVOLUTION CASE STUDY - SOLUTIONS".
          >
          > Thinking on your previous email last night, I realized you wanted the
          > XML
          > to show the order that the primitives were written, with respect to all
          > values written (both primitive and reference); not just with respect to
          > other primitive values. But JSX treats the primitives separately from
          > the
          > objects, and so (for example) the first primitive might not be the first
          > value - there could have been 10 object references before it, for
          > example.
          >
          > This causes problems if a field evolves from primitive to reference
          > (or vice versa). Your example is great, of an int evolved to an Integer.
          >
          >
          > > We are required to upgrade the data
          > > in serialized java objects of previous version to the new version.
          > > The previous version used both custom serialization and inheritance
          > > extensively.
          >
          > > We want to take care of data upgrade by exporting the
          > > data from the previous version java objects to an XML file and write
          > > java code to understand the exported data in the XML and create
          > > equivalent java objects of the new version. For transforming the data
          > > from XML, we would like make use of java code since we do some
          > > computation in the constructor of various new classes and we would
          > > like to avoid replicating this code in style sheets.
          > A compelling but non-obvious reason to do the transformation in Java
          > instead of XSLT - good insight. So, you writing a special-purpose
          > transformation in java, in a sense
          >
          > Version 1:
          > > <SecondLevel_1 alias-ID="0" _.0="1000" ...
          >
          > Version 2:
          > > <SecondLevel_1 obj-name="secondLevelObj" / >
          > > <java.lang.Interger obj-name="FirstLevel.value1" valueOf="1000">
          >
          > > I want to write a small java program which
          > > parses the first XML file, create new java object and serialize this
          > > java object. It would help me a great extent to generic data upgrade
          > > framwork if I can know the order in which the data was written to the
          > > XML file from the XML file itself without looking at writeObject()
          > > method of my classes. For example, _.1 and_.2 might have written
          > > after writing the vector and other data. If _.1 and _.2 values were
          > > written after writing other 17 values, I would like it to see them in
          > > my XML as _.18 and _.19.
          >
          > Thinking ahead a bit: Don't you need to look at the writeObject to
          > know what those particular value *mean*, so your java program
          > knows what to do with them?
          >
          > It's easy to change JSX to do this (I can send you a modified version
          > to do it) - however, this approach still seems like a lot of work for
          > you. I think there are some much easier ways.
          >
          > > If you feel I can handle the above data upgrade problem by other
          > > ways, i appreciate if you could pass them on to me.
          >
          > OK! First, please check out JSX2 - this writes out all values
          > as elements (primitives and references together), so everything is
          > in the right order. I would guess that this is slightly easier for you
          > to work with than the above.
          >
          >
          > EVOLUTION CASE STUDY - SOLUTIONS
          > Second, in JSX2, you can write a "filter", which will detect what
          > class you are in, what fieldname (or index for writeObject data),
          > and you can trigger whatever java code you need to convert this
          > (eg your constructors). I am happing to assist you in this extensively,
          > including giving you access to templates and writing tutorials,
          > answering questions, and writing generic helper code (which
          > would also go into JSX2 for others to be able to use).
          >
          > But the third solution is the best, *assuming* the class structure has
          > not changed dramatically - in other words, that the evolution has
          > been on the contents of the classes. The idea is to use a "Memento":
          > a class that represents another class. I'll illustrate with an example.
          > Lets say we have class A and class A' (old and new versions).
          >
          > Assuming you have access to the new class versions, you
          > write a new inner static class of A', whose serialization format is
          > *exactly the same* as the old class A. You call this
          > "Memento". The Memento represents the old class. Eg:
          >
          > class A { // old class
          > int i;
          > }
          >
          > class A' { // new class version - obviously " A' " is not a valid
          > name ;-)
          > Integer i;
          > static class Memento {
          > int i; // <---- this is the same serialization format as the
          > old
          > class
          > }
          > }
          >
          >
          > Now, you write some mapping code, which will transform an instance of
          > Memento
          > into an instance of A' - this uses a "readResolve" method, which is
          > automatically
          > called during deserialization:
          >
          > static class Memento {
          > int i;
          > Object readResolve() throws ObjectStreamException {
          > return new A'(i); // assuming you write a constructor
          > that takes
          > an int.
          > }
          > }
          >
          > OK! So what happens is that when JSX sees that you have defined an inner
          > Memento,
          > it automatically reads the old A object into that, instead of into A'.
          > The
          > readResolve
          > does the mapping that you are talking about.
          >
          > Some notes:
          > (1). this won't work with regular serialization, because it will try to
          > map the
          > old A onto the new A' - which won't work, because of the evolution we
          > spoke
          > about.
          >
          > (2). There is some trickiness with inheritance (and you mentioned
          > inheritance).
          > Please give me some more info about how the inheritance hierarchy has
          > changed,
          > and I can show you how to deal with this. The trickiness is that
          > readResolve
          > replaces the whole object - so your mapping code needs to handle the
          > object
          > and all its superclasses. Maybe this isn't so bad for your example?
          >
          > (3). This is a pure java solution, and so much simpler to get correct -
          > you
          > get static type checking from the Memento, for example.
          >
          > (4). You can still use your XML parsing technique for more dramatic
          > changes
          > (eg that cross classes).
          >
          >
          > Finally, we have almost finalized a design for the "Memento" that is
          > easier
          > to use than this, and that works on a per class basis (this means that
          > if class
          > A and class B have the same super class, you only need to write the
          > mapping code for the super class once). It will include some
          > default mappings automatically, so you only have to explicitly map the
          > fields that have actually changed between classes.
          >
          > If this sounds interesting to you, I'd be very happy to work closely
          > with
          > you to help solve your evolution with it - please let me know. We can
          > also do some preliminary work (to ensure it's a good fit for your
          > issues), before committing to it.
          >
          >
          > Cheers,
          > Brendan
          >
          >
          >
          > Yahoo! Groups Sponsor
          >
          > ADVERTISEMENT
          >
          > <http://rd.yahoo.com/M=241773.2725424.4169802.1925585/D=egroupweb/S=1706
          > 030390:HM/A=1389615/R=0/*http://www.hgtv.com/hgtv/pac_ctnt/text/0,,HGTV_
          > 3936_5799,FF.html> HGTV Dream Home Giveaway
          >
          > <http://us.adserver.yahoo.com/l?M=241773.2725424.4169802.1925585/D=egrou
          > pmail/S=:HM/A=1389615/rand=291782507>
          >
          > To unsubscribe from this group, send an email to:
          > JSX-ideas-unsubscribe@egroups.com
          >
          >
          >
          > Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service
          > <http://docs.yahoo.com/info/terms/> .
          >
          >
          >
        • Mark van der Kraan <m.van.der.kraan@effe
          ... object ... the mail ... if JSX ... Instructions ... attached ... Perhaps the problem is still that the resulting document has more then one root (so really
          Message 4 of 7 , Jan 2, 2003
          • 0 Attachment
            > > Another thing I noticed is JSX2 does not solve the problem if two
            object
            > > are written in the same file. (I had mentioned this before and
            the mail
            > > is attchd). Perhaps writing two objects into the same file is bad
            > > practice like you and others pointed out. However, it would help
            if JSX
            > > can take care of this.
            >
            > Unlike JSX, JSX2 doesn't write out any <?jsx ... ?> Processing
            Instructions
            > at the moment - so your parser shouldn't have this problem (the
            attached
            > email is for JSX, not JSX2).

            Perhaps the problem is still that the resulting document
            has more then one root (so really there are multiple
            documents). This is not bad practice, but you would
            need to be aware of it. Preetham, would the Object[] array
            solution that Brendan suggested work for you? In that
            case, you would first put all your objects in the array
            and then serialize that array *only once*. That would
            make the Object[] the root, with all your objects
            under it. Otherwise, would you need JSX2 to write something
            like <jsx2> ..(your objects).. </jsx2>?

            Cheers,
            Mark
          • Preetham Kajekar
            ... Yep. This is the problem. I use DOM to parse the XML which I will then manipulate. So basically DOM parsing fails with org.xml.sax.SAXParseException: The
            Message 5 of 7 , Jan 2, 2003
            • 0 Attachment
              >Perhaps the problem is still that the resulting document
              >has more then one root (so really there are multiple
              >documents).
              Yep. This is the problem. I use DOM to parse the XML which I will then
              manipulate. So basically DOM parsing fails with
              "org.xml.sax.SAXParseException: The markup in the document following the
              root element must be well-formed."

              >That would
              >make the Object[] the root, with all your objects
              under it. Otherwise, would you need JSX2 to write something
              >like <jsx2> ..(your objects).. </jsx2>?
              I guess the latter would be better, but the former is a very easy
              alternative. I'll eval these ang get back.

              Thanks,
              ~preetham
            • Brendan Macmillan
              Preetham, Thanks Mark and Preetham!! I understand now. DOM needs just one root object - the problem is not the PI at all! I wasn t looking for that when I
              Message 6 of 7 , Jan 2, 2003
              • 0 Attachment
                Preetham,

                Thanks Mark and Preetham!! I understand now. DOM needs just one root
                object - the problem is not the PI at all! I wasn't looking for that when I
                checked the spec, but you are right; a valid XML document has just the
                one element:
                [1] document ::= prolog element Misc*

                http://www.w3.org/TR/REC-xml#sec-well-formed

                Maybe JSX *should* include a root tag, that covers all the objects
                written, as Mark suggested: a <jsx2>...</jsx2>. For XML
                correctness the XML, the PI <?jsx...?> should also be omitted,
                except for once, at the very start.

                As a change to JSX, there are some issues to consider:

                In terms of the Serialization API, this means that the complete XML
                could not be written until the stream was explicitly closed (so JSX2
                knows to write the </jsx2> tag). At the moment, the user doesn't
                need to explicitly close the stream. Although closing it is "correct",
                it adds another obstacle to the first-time user, and steepens the
                learning curve (slightly).

                Of course, there could be a explicit switch in Config, which would
                enable this behaviour: eg:
                Config c = new Config().setEnclosingRoot(true);
                ObjOut2 out = new ObjOut2(myStream, c); // <jsx2> is written
                out.writeObject(obj1);
                out.writeObject(obj2);
                out.close(); // </jsx2> is written

                Can anyone suggest a better name for this switch than "enclosingRoot"?

                How does that sound, Preetham?

                I'd like to do this; but my plate is ridiculously full at the momentand maybe
                it is fairly easy for you to wrap all the objects in an array?

                Which license would you be purchasing, if we can get all this
                working for you?


                I think Mark's solutions are the way to go.



                > >Perhaps the problem is still that the resulting document
                > >has more then one root (so really there are multiple
                > >documents).
                > Yep. This is the problem. I use DOM to parse the XML which I will then
                > manipulate. So basically DOM parsing fails with
                > "org.xml.sax.SAXParseException: The markup in the document following the
                > root element must be well-formed."
                >
                > >That would
                > >make the Object[] the root, with all your objects
                > under it. Otherwise, would you need JSX2 to write something
                > >like <jsx2> ..(your objects).. </jsx2>?
                > I guess the latter would be better, but the former is a very easy
                > alternative. I'll eval these ang get back.
                >
                > Thanks,
                > ~preetham
                >
                >
                >
                >
                > To unsubscribe from this group, send an email to:
                > JSX-ideas-unsubscribe@egroups.com
                >
                >
                >
                > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
                >
                >
                >
              • Preetham Kajekar
                Of course, there could be a explicit switch in Config, which would enable this behaviour: eg: Config c = new Config().setEnclosingRoot(true); ObjOut2 out = new
                Message 7 of 7 , Jan 3, 2003
                • 0 Attachment
                  Message

                   
                  Of course, there could be a explicit switch in Config, which would
                  enable this behaviour: eg:
                      Config c = new Config().setEnclosingRoot(true);
                      ObjOut2 out = new ObjOut2(myStream, c);     // <jsx2> is written
                      out.writeObject(obj1);
                      out.writeObject(obj2);
                      out.close();      // </jsx2> is written

                  Can anyone suggest a better name for this switch than "enclosingRoot"?

                  How does that sound, Preetham?
                  [Preetham] 
                     This sounds ok to me. I think getting a programmer to explicitly close the stream to get a well formed XML is not too much to ask.


                  I'd like to do this; but my plate is ridiculously full at the momentand maybe
                  it is fairly easy for you to wrap all the objects in an array?
                  [Preetham]  Yes, I'll be looking at alternatives mentioned by Mark and guess these would suffice 

                  Which license would you be purchasing, if we can get all this
                  working for you?
                  [Preetham]  We are not yet sure. Still evaluating and we are trying to zero in on the tool.  
                Your message has been successfully submitted and would be delivered to recipients shortly.