Thanks Steven, slowly I am getting the grip of pipelines... Looking at the code
(using beta1-snapshots) I saw that only two lines of code are causing the
commons-io dependency on 'stax' would it be possible to factor-out this out ?
Code which uses it is there to buffer the InputStream. I think that it's not
task of XMLGenerator to buffer the input, that would be the task of application
code. Also using the default XMLEventReader it precludes the use of custom
XMLEvents. Maybe something along these lines would be simpler ? So we have
externally configured eventReader injected to XMLEventGenerator ?
public class XMLEventGenerator extends AbstractStAXProducer implements Starter {
private final XMLEventReader eventReader;
@Inject
public XMLEventGenerator (final XMLEventReader eventReader) {
// FIXME add null check
this.eventReader = eventReader;
}
/**
* {@inheritDoc}
*
* @see org.apache.cocoon.stax.StAXProducer#peek()
*/
@Override
public XMLEvent peek () throws XMLStreamException {
return eventReader.peek();
}
/**
* {@inheritDoc}
*
* @see org.apache.cocoon.stax.StAXProducer#hasNext()
*/
@Override
public boolean hasNext () throws XMLStreamException {
return eventReader.hasNext();
}
/**
* {@inheritDoc}
*
* @see org.apache.cocoon.stax.StAXProducer#nextEvent()
*/
@Override
public XMLEvent nextEvent () throws XMLStreamException {
return eventReader.nextEvent();
}
@Override
public void execute () {
final StAXConsumer consumer = getConsumer();
consumer.initiatePullProcessing();
}
}
WDYT,
Mazria
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
