Basically Jacson works on a pipeline of chunks. A chunk (after some consideration about making it an object, but this would loose the power of regular expressions which is helpful in this context) is a String. A chunk could be a line in a logfile or a sequence of fields in a database or words in a natural text. During scanning of input chunks are ...
To make a picture of it.
The main point is that that process is structured recursivly: One can define new evaluators by composing existing filters and evaluators. This requires no programming only configuration via XML.
We can make a somewhat more detailed picture of it, where one eval is itself constructed from filters and other evals. To make it not that complicated, filters have been condensed.
A different perspective to look at Jacson is the temporal one:
Chronologically the process is structured in two phases:
Essential is, that the mentioned devices Sources, Filters, Evaluators and Reports are plugable Java Classes and their use and interaction can be configured by an configuration file which is a piece of XML.
From the flexibility Jacson is (like Ant) somewhat between a programming language and a configurable program. It is rather like a collection of building bricks which are limited but can be arranged to do something different from time to time. And in case you really need Jacson to something not yet implemented, all forementioned entities implement easy interfaces and you can program an extension of your own. Like with Ant. So I'd be happy if Jacson can grow from "useful for me" to "useful for somebody else".