Woodstox

A filtered xml event stream can sometimes still return something that should be filtered out

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: None
  • Fix Version/s: None
  • Component/s: None
  • Labels:
    None
  • Environment:
    Current Wstx, Mac, 1.5/1.6
  • Testcase included:
    yes
  • Number of attachments :
    2

Description

// Parse the data, filtering out the start elements
XMLInputFactory xmlif = XMLInputFactory.newInstance();
FileReader fr = new FileReader("src-data/foundbugs.xml");
XMLEventReader xmler = xmlif.createXMLEventReader(fr);
EventFilter filter = new EventFilter() {
public boolean accept(XMLEvent event) { return event.isStartElement(); }
};
XMLEventReader xmlfer = xmlif.createFilteredReader(xmler, filter);
while (xmlfer.peek() != null) {

At this point the event that is peeked() should always be a StartElement or null. I've found this not to be true and have gotten back peeks() that are Characters, etc.

  1. WoodstoxTest.java
    07/May/06 5:02 PM
    1 kB
    Sam Pullara
  2. WoodstoxTest.java
    07/May/06 4:55 PM
    1 kB
    Sam Pullara

Activity

Hide
Sam Pullara added a comment -

Update so that it works with the RI

Show
Sam Pullara added a comment - Update so that it works with the RI
Hide
Tatu Saloranta added a comment -

Thanks! It's known that the filtered event reader has plenty of problems (some of which may be fundamental problems with the concept itself – should START/END_DOCUMENT events ever be suppressed; and if latter is, should 'null' be returned instead of it at the end: also, implementing hasNext() is quite complicated). However, specific problems like this one should definitely be fixed; I can look into both Woodstox and Ref. Impl. to resolve problem in both.

Show
Tatu Saloranta added a comment - Thanks! It's known that the filtered event reader has plenty of problems (some of which may be fundamental problems with the concept itself – should START/END_DOCUMENT events ever be suppressed; and if latter is, should 'null' be returned instead of it at the end: also, implementing hasNext() is quite complicated). However, specific problems like this one should definitely be fixed; I can look into both Woodstox and Ref. Impl. to resolve problem in both.
Hide
Tatu Saloranta added a comment -

Added unit test (within StaxTest, part of stax ref. impl. distribution), and fixed for Woodstox. Ref. impl. does not seem to have the same bug.
Will be included in 2.9.4 release.

Show
Tatu Saloranta added a comment - Added unit test (within StaxTest, part of stax ref. impl. distribution), and fixed for Woodstox. Ref. impl. does not seem to have the same bug. Will be included in 2.9.4 release.
Hide
Tatu Saloranta added a comment -

Included in 3.0rc1 release.

Show
Tatu Saloranta added a comment - Included in 3.0rc1 release.

People

Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: