Announcement Announcement Module
Collapse
No announcement yet.
XMLEvent Method Is Platform Specific? Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • XMLEvent Method Is Platform Specific?

    Hello,

    I'm working with a javax.xml.stream.events.XMLEvent in batch within a class that implements the ItemWriter interface. The XMLEvent was created and populated via a StAX XMLEventReader which had parsed a UTF-8 XML file. It is a StartElement event type.

    The XMLEvent has a writeAsEncodedUnicode(Writer w) method that will format it's contents as an XML string and write it to your writer. It works great when running on Windows, but on UNIX - the XML string is not written out (the method does not throw an exception either). Anyone have an ideas for how to make it work on UNIX?

    Here's the call:
    Code:
    private static FileWriter reportWriter;
                             :
    currentElement.writeAsEncodedUnicode(reportWriter);
    Here's a javadoc note for the method:
    This method will write the XMLEvent as per the XML 1.0 specification as Unicode characters. No indentation or whitespace should be outputted. Any user defined event type SHALL have this method called when being written to on an output stream. Built in Event types MUST implement this method, but implementations MAY choose not call these methods for optimizations reasons when writing out built in Events to an output stream. The output generated MUST be equivalent in terms of the infoset expressed.
    Based on what I see, I see no reason why it should not work on UNIX. I appreciate any comments.

    Thanks!
    Mike

  • #2
    Is your writer flushed anywhere?

    Comment


    • #3
      Originally posted by Dave Syer View Post
      Is your writer flushed anywhere?
      Yes, immediately after calling the method:

      Code:
      currentElement.writeAsEncodedUnicode(reportWriter);
      reportWriter.flush();

      Comment


      • #4
        Then I don't understand either. Are you using the same Java library, same JRE etc?

        Comment


        • #5
          Yes, we're running JDK 1.6, same Java, looked to make sure we are pulling in the correct jars & in the same order. Hunch is that it's somehow related to encoding conflict - but just grasping at straws.

          Comment

          Working...
          X