castor
  1. castor
  2. CASTOR-1586

Error loading mapping whem migrating from 1.0.1 to 1.0.3

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Blocker Blocker
    • Resolution: Fixed
    • Affects Version/s: 1.0.3
    • Fix Version/s: 1.0.4
    • Component/s: XML
    • Labels:
      None
    • Environment:
      Windows XP SP2, JDK 1.5.0_07, Eclipse 3.2
    • Testcase included:
      yes
    • Number of attachments :
      5

      Description

      the following code worked under Castor 1.0.1 but doesn't under 1.0.3 A java.io.IOException: Stream closed is thrown when setting the mapping in the unmarshaller instance:

      mapping = new Mapping(getClass().getClassLoader());
      mapping.loadMapping(new InputSource(getClass().getResourceAsStream("mapping.xml")));

      // create Marshaller
      writer = new StringWriter();
      marshaller = new Marshaller(writer);
      marshaller.setMapping(mapping);
      marshaller.setEncoding("UTF-8");
      marshaller.setValidation(true);

      // create Unmarshaller
      unmarshaller = new Unmarshaller();
      unmarshaller.setClassLoader(getClass().getClassLoader());
      unmarshaller.setValidation(false);
      unmarshaller.setMapping(mapping); // --> Exception thrown here
      unmarshaller.setWhitespacePreserve(true);

      If the mapping is not loaded as input stream using

      mapping.loadMapping(new InputSource(getClass().getResource("mapping.xml")));

      everything works fine.

      1. c1586-patch.diff
        2 kB
        Edward Kuns
      2. castor-1586-test.patch
        7 kB
        Edward Kuns
      3. patch-C1586-20061016.txt
        10 kB
        Ralf Joachim
      4. patch-C1586-20061016-02.txt
        14 kB
        Ralf Joachim

        Activity

        Hide
        Werner Guttmann added a comment -

        +1.

        Show
        Werner Guttmann added a comment - +1.
        Hide
        Ralf Joachim added a comment -

        Just before committing I recognized that this patch breaks quite some tests of our XML test suite so we have to search for another solution. Will come back here when i found something.

        Show
        Ralf Joachim added a comment - Just before committing I recognized that this patch breaks quite some tests of our XML test suite so we have to search for another solution. Will come back here when i found something.
        Hide
        Edward Kuns added a comment -

        Attaching a newer version of attachment "bug1586-with-correct-package.zip" that includes a change to the Eclipse path so you can right-click on TestContentTest.java and run-as-junit test.

        Show
        Edward Kuns added a comment - Attaching a newer version of attachment "bug1586-with-correct-package.zip" that includes a change to the Eclipse path so you can right-click on TestContentTest.java and run-as-junit test.
        Hide
        Edward Kuns added a comment -

        Summarizing my understanding of this issue:

        Previously, loadMapping on the mapping itself caused the mapping to be loaded. This was not desirable as it isn't known at the time of loadMapping() whether the mapping will be used for XML or for JDO, and the full configuration of XML or JDO (which the mapping needs) isn't necessarily known at the time of loadMapping.

        Thus, loadMapping was changed to hold a reference to the schema that will be loaded, and setMapping() on the marshaler or unmarshaler loads the file. This works fine when the mapping is created with a URI, but when the mapping is created using a Stream, this causes problems.

        Regardless of anything else ... what are the odds that someone would create a Mapping destined for use both by XML and JDO? Or what are the odds that someone would create a Mapping destined for use by XML but with two different XML configurations? Either of these, if the mapping is loaded via Stream, would cause this to break, yes?

        Is there a way to load the mapping in a way that doesn't depend on JDO or XML configuration, and that wouldn't require the mapping to be reloaded if the JDO or XML configuration is changed?

        Show
        Edward Kuns added a comment - Summarizing my understanding of this issue: Previously, loadMapping on the mapping itself caused the mapping to be loaded. This was not desirable as it isn't known at the time of loadMapping() whether the mapping will be used for XML or for JDO, and the full configuration of XML or JDO (which the mapping needs) isn't necessarily known at the time of loadMapping. Thus, loadMapping was changed to hold a reference to the schema that will be loaded, and setMapping() on the marshaler or unmarshaler loads the file. This works fine when the mapping is created with a URI, but when the mapping is created using a Stream, this causes problems. Regardless of anything else ... what are the odds that someone would create a Mapping destined for use both by XML and JDO? Or what are the odds that someone would create a Mapping destined for use by XML but with two different XML configurations? Either of these, if the mapping is loaded via Stream, would cause this to break, yes? Is there a way to load the mapping in a way that doesn't depend on JDO or XML configuration, and that wouldn't require the mapping to be reloaded if the JDO or XML configuration is changed?
        Hide
        Ralf Joachim added a comment -

        I finally got it. The new patch fixes the problem reported with this issue whitout any drawbacks. At least as far as I know yet. I guess if there is one I get blamed about that very soon again

        Show
        Ralf Joachim added a comment - I finally got it. The new patch fixes the problem reported with this issue whitout any drawbacks. At least as far as I know yet. I guess if there is one I get blamed about that very soon again

          People

          • Assignee:
            Ralf Joachim
            Reporter:
            M.-Leander Reimer
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: