The Jacson configuration is is a XML with a root
<application>
. This XML is parsed with a
SAX1 parser, i.e. no namespaces are used and is stored
as a tree with name-value pairs.
Storage is disregarding the difference between attributes
and elements. That is
<jacson label="otto"> ... </jacson>and
<jacson> <label>otto</label> ... </jacson>make no difference to what Jacson sees. There is als an abbreviation for element text by a reserved attribute:
<label se:this="otto"/>and
<label>otto</label>are equivalent for Jacson. While the "se:" looks like a namespace prefix it is currently only a naming rule for internal elements, but might be lifted to a namespace somewhat in the future.
To generate flexible configuration, Jacson knows parameters. An element
<se:param se:name="otto" se:value="waalkes"/>declares a piece of string named
otto
with a default value waalkes
,
that can be used for substitution whereever constant text
is. For example like:
<jacson label="This is otto ${otto}">The default value of these params can be modified
Within the <application>
there has to be
a <jacson>
element. Although named differently
this element is an classless
Evaluator.
Within this block, you can have
<source>
elements (since 0.89),<filter>
elements,<evaluation>
elements and <report>
elements.A block containing not at least one filter or evaluation must be considered a no operation and is an error.
Filter's, Eval's and Report's take a class name as text. Note when you use the internal Jacson classes, you can leave away the default package, that is.
<jacson se:this="de.spieleck.app.jacson.eval.CountEvaluator">and
<jacson label="CountEvaluator">load the same plugin class. If you write your own plugins in your own package, you need to use the full qualified class name.
Different <filter>
's
<eval>
's and <report>
's accept
different subelements or attributes. And this needs
to be documented elsewhere.
Unlike <filter>
's and <report>
's
<eval>
need not to have a class. If they
do not have the JacsonBlock
is used. This evaluation can carry it's own
<filter>
, <eval>
and <report>
subelements, as described above. This recursive definition is
the most powerful part of the Jacson configuration syntax,
enabling you to configure new evaluations by combining filters
and other evaluations.
Reports attached to non top evaluations only capture output generated below them, but this output is still promoted to all Reports on higher levels.
To avoid some work when designing complex filters, Jacson has a primitive id/idref mechanic. The usage is plugin specific, that is the programmer of the plugin decides to use that mechanic. The builtin plugins implement the following multilevel logic:
The described functionality is implemented by the interaction of
de.spieleck.config
package,
JacsonRegistry
and
ConfigUtil
.
Although JacsonChunkSource
is considered a plugin class for Jacson. There is no
configuration for them. Sources are currently defined
implicitely by the usage of Jacson:
LineChunkSource
is used.
TailSource
.
LineChunkSource
.
With Jacson 0.89 a new concept of configurable sources is
introduced. These so called GenericSources can be configured like
Reports or Filters. For examples have a look at
SQLSource
.