Filtered XMLStreamReader Exceptions (java.xml)
Joe Wang
huizhe.wang at oracle.com
Wed Oct 28 16:52:48 UTC 2020
Hi Mike,
As you said, creating a bug report would be a good start. If it involves
a signature change, it'd need to go through a proper review (CSR) process.
When you are ready to submit a bug report, please make sure to add a
test case to illustrate the use case scenario.
Thanks,
Joe
On 10/28/20 5:14 AM, Michael Edgar wrote:
> Hi everyone,
> I'm working on a project that makes use of the StAX API and an issue I have
> encountered is that when wrapping an `XMLStreamReader` with a
> `StreamFilter`, errors encountered in the setup are not thrown to the
> caller. The source of the error could be any stream error that is triggered
> as the `XMLStreamFilterImpl` advances to the next acceptable event.
> Ultimately, when attempting to utilize the filtered reader, some secondary
> exception will occur, but the original `Exception` is lost.
>
> I have not seen any other issues related specifically to this problem, so I
> would like to propose removal of the try/catch in the constructor of
> `com.sun.org.apache.xerces.internal.impl.XMLStreamFilterImpl` and the
> method signature changed to declare that `XMLStreamException` is thrown.
> The constructor is used by
> `com.sun.xml.internal.stream.XMLInputFactoryImpl.createFilteredReader(XMLStreamReader,
> StreamFilter)` which itself already declares the same exception and is an
> implementation of the public `XMLInputFactory` interface.
>
> Further, the `nextTag` method of the same class has a bug where it checks
> for `START_ELEMENT` events twice.
>
> I have an OCA in place and I am happy to submit a PR, but I believe that a
> bug record needs to be opened in order to proceed.
>
> Thank you,
> Mike
More information about the core-libs-dev
mailing list