Note that with the current implementation, parsing is greedy, so whenever multiple parses would apply, the rule starting the earliest and parsing the most tokens wins. For example if you have these rules:
a -> x a b -> y b c d -> zThen input
a b c d eparses to
y b c d, ie the 2nd rule "wins" because it started earliest and matched the most input tokens of other rules starting at that point.
A future improvement to this filter could allow non-greedy parsing, such that the 3rd rule would win, and also separately allow multiple parses, such that all 3 rules would match, perhaps even on a rule by rule basis.
NOTE: when a match occurs, the output tokens associated with the matching rule are
"stacked" on top of the input stream (if the rule had
keepOrig=true) and also on top
of another matched rule's output tokens. This is not a correct solution, as really the output
should be an arbitrary graph/lattice. For example, with the above match, you would expect an
c" to match the parsed tokens, but it will fail to do so. This limitation is necessary
because Lucene's TokenStream (and index) cannot yet represent an arbitrary graph.
NOTE: If multiple incoming tokens arrive on the same position, only the first token at that position is used for parsing. Subsequent tokens simply pass through and are not parsed. A future improvement would be to allow these tokens to also be matched.
Nested Class Summary
Methods inherited from class org.apache.lucene.util.AttributeSource
addAttribute, addAttributeImpl, captureState, clearAttributes, cloneAttributes, copyTo, endAttributes, equals, getAttribute, getAttributeClassesIterator, getAttributeFactory, getAttributeImplsIterator, hasAttribute, hasAttributes, hashCode, reflectAsString, reflectWith, removeAllAttributes, restoreState, toString