Implementation Version: 1.0.1
Feb. 14, 2007
sjsxp.jar is the implementation of JSR 173.
javax.xml.stream.XMLStreamReader
doesn't report CDATA events. If you have an application that needs to receive that event, configure theXMLInputFactory
to set the following implementation-specific "report-cdata-event" property:XMLInputFactory factory = XMLInputFactory.newInstance(); if (factory.isPropertySupported("report-cdata-event")) { factory.setProperty("report-cdata-event", Boolean.TRUE); }
If you would like to have any new feature, please let us know at users@sjsxp.dev.java.net.
Most applications do not need to know about the factory implementation class name. Just adding the
sjsxp.jar
file to the classpath is sufficient for most applications because thesjsxp.jar
file supplies the factory implementation classname of different properties (javax.xml.stream.XMLInputFactory
,javax.xml.stream.XMLOutputFactory<,code>,
javax.xml.stream.XMLEventFactory
) under theMETA-INF/services
directory, which is the third step of a lookup operation when applications ask for the factory instance. See the javadoc of theXMLInputFactory.newInstance()
method for more information about the lookup mechanism.However, there may be scenarios when an application would like to know about the factory implementation class name and set the property explicitly. These scenarios could include cases where there are multiple JSR 173 implementations in the classpath and the application wants to choose one, perhaps one that has superior performance, contains a crucial bug fix, etc.
If an application sets the
SystemProperty
, it is the first step in a lookup operation, obtaining the factory instance would be fast compared to other options.javax.xml.stream.XMLInputFactory --> com.sun.xml.stream.ZephyrParserFactoryjavax.xml.stream.XMLOutputFactory --> com.sun.xml.stream.ZephyrWriterFactorjavax.xml.stream.XMLEventFactory --> com.sun.xml.stream.events.ZephyrEventFactory
Due to the undefined condition in the JSR 173 specification, there are differences in implementing the Filtered StreamReader. In this implementation, it has been implemented so that:
1) On initialization, it moves to an acceptable filtered event. That is, when an application creates a filtered reader object by invoking thecreateFilteredReader
method on theInputFactory
object, the filtered reader will point to the first event that is accepted by theStreamFilter
orEventFilter
implementation provided by the application.
2) The hasNext() method advances the stream in order to test if there is a "next" event.
3) END_DOCUMENT is always accepted as an valid event.
We believe these are necessary in order to pass the TCK. See the sample MyStreamFilter under samples/filter.We are interested in your opinion of what should be the right behavior. We would like to make sure that the correct behavior is specified in the next version of the StAX specification.
The JSR 173 specification is not clear what should the parser behavior should be when
javax.xml.stream.XMLStreamConstants.IS_COALESCE
is set to "true" andjavax.xml.stream.XMLStreamConstants.IS_REPLACE_ENTITY_REFERENCE
is set to "false". The SJSXP implementation's behavior is that'javax.xml.stream.XMLStreamConstants.IS_COALESCE'
takes precedence and the value ofjavax.xml.stream.XMLStreamConstants.IS_REPLACE_ENTITY_REFERENCE
is ignored.We are interested in your opinion of what the right behavior should be. We want to make sure that the correct behavior is specified in next version of the StAX specification.
SJSXP 1.0.1 Changelog contains details of changes and bug fixes since the 1.0 release.
If you find a bug with the SJSXP implementation, please use the java.net Issue Reports to open an issue with a detailed description and standalone test case showing the problem.
Please direct any questions about SJSXP to users@sjsxp.dev.java.net.