DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16726>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16726 External FilterReaders don't get chain()ed ------- Additional Comments From [EMAIL PROTECTED] 2003-02-03 18:49 ------- Looking at this again, I don't think the patch would provide a lot of value. Let me try to explain the way things currently work: when using the <filterreader> syntax (as all custom filterreaders would), it gets instantiated as an AntFilterReader. If any nested <param> elements were declared, these parameters would be constructed and set using the setParameters method, assuming the custom filterreader implements Parameterizable. All this is performed by performing an implicit "chain" - when a new AntFilterReader instance is created, it is created using another FilterReader which is present before it in the chain: New AntFilterReader = new instance of AntFilterReader(previous FilterReader in chain). The above ensures an implicit "chaining". So, what is the deal with ChainableReader? Those filterreaders that are provided out-of-the-box have a much more elegant style of defining nextes elements without having to use <param>s. Therefore, for these setters to be called we need a consistent mechanism to invoke the various setters. We also need a mechanism by which the chain can be programatically controlled. Hence, there is the chain(Reader) method. This method is 'intended' to be used to create a new reader instance and invoke the setters as appropriate. So, going back to your original problem, the external filterreaders do get chained, though by not calling the chain() method explicitly. So, what do you do to remedy your situation? Instead of having the chain method in VPPFilter, you may probably investigate moving the logic to the initialize() method, if possible.
