The engine can process java.util.Map events via the sendEvent(Map map, String eventTypeName) method on the EPRuntime interface. Entries in the Map represent event properties. Keys must be of type java.util.String for the engine to be able to look up event property names in pattern or EPL statements. Values can be of any type. JavaBean-style objects as values in a Map can be processed by the engine, and strongly-typed nested maps are also supported. Please see the Chapter 2, Event Representations section for details on how to use Map events with the engine.

Via configuration you can provide an event type name for Map events for use in statements, and the event property names and types enabling the engine to validate properties in statements.

The below snippet of XML configuration configures an event named MyMapEvent.

<event-type name="MyMapEvent">
  <java-util-map>
    <map-property name="carId" class="int"/>
    <map-property name="carType" class="string"/>
    <map-property name="assembly" class="com.mycompany.Assembly"/>    
  </java-util-map>
</event-type>

This configuration defines the carId property of MyMapEvent events to be of type int, and the carType property to be of type java.util.String. The assembly property of the Map event will contain instances of com.mycompany.Assembly for the engine to query.

The valid types for the class attribute are listed in Section 15.5, “Type Names”. In addition, any fully-qualified Java class name that can be resolved via Class.forName is allowed.

You can also use the configuration API to configure Map event types, as the short code snippet below demonstrates:

Map<String, Object> properties = new Map<String, Object>();
properties.put("carId", "int");
properties.put("carType", "string");
properties.put("assembly", Assembly.class.getName());

Configuration configuration = new Configuration();
configuration.addEventType("MyMapEvent", properties);

For strongly-typed nested maps (maps-within-maps), the configuration API method addEventType can also used to define the nested types. The XML configuration does not provide the capability to configure nested maps.

Finally, here is a sample EPL statement that uses the configured MyMapEvent map event. This statement uses the chassisTag and numParts properties of Assembly objects in each map.

select carType, assembly.chassisTag, count(assembly.numParts) from MyMapEvent.win:time(60 sec)

A Map event type may also become a subtype of one or more supertypes that must also be Map event types. The java-util-map element provides the optional attribute supertype-names that accepts a comma-separated list of names of Map event types that are supertypes to the type:

<event-type name="AccountUpdate">
<java-util-map supertype-names="BaseUpdate, AccountEvent">
...

For initialization time configuration, the addMapSuperType method can be used to add Map hierarchy information. For runtime configuration, pass the supertype names to the addEventType method in ConfigurationOperations.

A Map event type may declare a start and end timestamp property name. The XML shown next instructs the engine that the startts property carries the event start timestamp and the endts property carries the event end timestamp:

<event-type name="AccountUpdate">
<java-util-map start-timestamp-property-name="startts" end-timestamp-property-name="endts">
...

The engine can process Object-array (Object[]) events via the sendEvent(Object[] array, String eventTypeName) method on the EPRuntime interface. Elements in the Object array represent event properties. Values can be of any type. JavaBean-style objects as values in an Object[] can be processed by the engine, and strongly-typed nested map or object-array event types are also supported. Please see the Chapter 2, Event Representations section for details on how to use Object[] events with the engine.

Via configuration you can provide an event type name for Object[] events for use in statements, and the event property names and types enabling the engine to validate properties in statements.

The below snippet of XML configuration configures an event named MyObjectArrayEvent.

<event-type name="MyObjectArrayEvent">
  <objectarray>
    <objectarray-property name="carId" class="int"/>
    <objectarray-property name="carType" class="string"/>
    <objectarray-property name="assembly" class="com.mycompany.Assembly"/>    
  </objectarray>
</event-type>

This configuration defines the carId property of MyObjectArrayEvent events to be of type int and in the object array first element ([0]). The carType property to be of type java.util.String is expected in the second array element ([1]) . The assembly property of the object array event will contain instances of com.mycompany.Assembly for the engine to query in element two ([2]).

Note that the engine does not verify the length and property values of object array events when your application sends object-array events into the engine. For the example above, the proper object array would look as follows: new Object[] {carId, carType, assembly}.

The valid types for the class attribute are listed in Section 15.5, “Type Names”. In addition, any fully-qualified Java class name that can be resolved via Class.forName is allowed.

You can also use the configuration API to configure Object[] event types, as the short code snippet below demonstrates:

String[] propertyNames = {"carId", "carType", "assembly"};
Object[] propertyTypes = {int.class, String.class, Assembly.class};

Configuration configuration = new Configuration();
configuration.addEventType("MyObjectArrayEvent", propertyNames, propertyTypes);

Finally, here is a sample EPL statement that uses the configured MyObjectArrayEvent object-array event. This statement uses the chassisTag and numParts properties of Assembly objects.

select carType, assembly.chassisTag, count(assembly.numParts) from MyObjectArrayEvent.win:time(60 sec)

An Object-array event type may also become a subtype of one supertype that must also be an Object-array event type. The objectarray element provides the optional attribute supertype-names that accepts a single name of an Object-array event type that is the supertype to the type:

<event-type name="AccountUpdate">
<objectarray supertype-names="BaseUpdate">
...

An Object-array event type may declare a start and end timestamp property name. The XML shown next instructs the engine that the startts property carries the event start timestamp and the endts property carries the event end timestamp:

<event-type name="AccountUpdate">
<objectarray start-timestamp-property-name="startts" end-timestamp-property-name="endts">
...

Via this configuration item the Esper engine can natively process org.w3c.dom.Node instances, i.e. XML document object model (DOM) nodes. Please see the Chapter 2, Event Representations section for details on how to use Node events with the engine.

Esper allows configuring XPath expressions as event properties. You can specify arbitrary XPath functions or expressions and provide a property name by which their result values will be available for use in expressions.

For XML documents that follow a XML schema, Esper can load and interrogate your schema and validate event property names and types against the schema information.

Nested, mapped and indexed event properties are also supported in expressions against org.w3c.dom.Node events. Thus XML trees can conveniently be interrogated using the existing event property syntax for querying JavaBean objects, JavaBean object graphs or java.util.Map events.

In the simplest form, the Esper engine only requires a configuration entry containing the root element name and the event type name in order to process org.w3c.dom.Node events:

<event-type name="MyXMLNodeEvent">
  <xml-dom root-element-name="myevent" />
</event-type>

You can also use the configuration API to configure XML event types, as the short example below demonstrates. In fact, all configuration options available through XML configuration can also be provided via setter methods on the ConfigurationEventTypeXMLDOM class.

Configuration configuration = new Configuration();
ConfigurationEventTypeXMLDOM desc = new ConfigurationEventTypeXMLDOM();
desc.setRootElementName("myevent");
desc.addXPathProperty("name1", "/element/@attribute", XPathConstants.STRING);
desc.addXPathProperty("name2", "/element/subelement", XPathConstants.NUMBER);
configuration.addEventType("MyXMLNodeEvent", desc);

The next example presents configuration options in a sample configuration entry.

<event-type name="AutoIdRFIDEvent">
  <xml-dom root-element-name="Sensor" schema-resource="data/AutoIdPmlCore.xsd" 
       default-namespace="urn:autoid:specification:interchange:PMLCore:xml:schema:1">
    <namespace-prefix prefix="pmlcore" 
       namespace="urn:autoid:specification:interchange:PMLCore:xml:schema:1"/>
    <xpath-property property-name="countTags" 
       xpath="count(/pmlcore:Sensor/pmlcore:Observation/pmlcore:Tag)" type="number"/>
  </xml-dom>
</event-type>

This example configures an event property named countTags whose value is computed by an XPath expression. The namespace prefixes and default namespace are for use with XPath expressions and must also be made known to the engine in order for the engine to compile XPath expressions. Via the schema-resource attribute we instruct the engine to load a schema file. You may also use schema-text instead to provide the actual text of the schema.

Here is an example EPL statement using the configured event type named AutoIdRFIDEvent.

select ID, countTags from AutoIdRFIDEvent.win:time(30 sec)

desc.addXPathProperty("name", "/element/sub", XPathConstants.STRING, "long");

<xpath-property property-name="name"  xpath="/element/sub" type="string" cast="long"/>

select request, request.symbol from GetQuote

ConfigurationEventTypeXMLDOM desc = new ConfigurationEventTypeXMLDOM();
desc.setRootElementName("GetQuote");
desc.setDefaultNamespace("http://services.samples/xsd");
desc.setRootElementNamespace("http://services.samples/xsd");
desc.addNamespacePrefix("m0", "http://services.samples/xsd");
desc.setResolvePropertiesAbsolute(false);
configuration.addEventType("GetQuote", desc);

ConfigurationEventTypeXMLDOM desc = new ConfigurationEventTypeXMLDOM();
desc.setXPathFunctionResolver(MyXPathFunctionResolver.class.getName());
desc.setXPathVariableResolver(MyXPathVariableResolver.class.getName());

ConfigurationEventTypeXMLDOM desc = new ConfigurationEventTypeXMLDOM();
desc.setAutoFragment(false);

ConfigurationEventTypeXMLDOM desc = new ConfigurationEventTypeXMLDOM();
desc.setXPathPropertyExpr(true);

ConfigurationEventTypeXMLDOM desc = new ConfigurationEventTypeXMLDOM();
desc.setEventSenderValidatesRoot(false);

ConfigurationEventTypeXMLDOM desc = new ConfigurationEventTypeXMLDOM();
desc.setStartTimestampPropertyName("startts");
desc.setEndTimestampPropertyName("endts");

As part of the extension API plug-in event representations allows an application to create new event types and event instances based on information available elsewhere. Please see Section 17.8, “Event Type And Event Object” for details.

The configuration examples shown next use the configuration API to select settings. All options are also configurable via XML, please refer to the sample configuration XML in file esper.sample.cfg.xml.

URI rootURI = new URI("type://mycompany/myproject/myname");
config.addPlugInEventRepresentation(rootURI, 
    MyEventRepresentation.class.getName(), null);

URI childURI = new URI("type://mycompany/myproject/myname/MyEvent");
configuration.addPlugInEventType("MyEvent", new URI[] {childURI}, null);

URI childURI = new URI("type://mycompany/myproject/myname");
configuration.setPlugInEventTypeNameResolutionURIs(new URI[] {childURI});

Esper allows invocations of static Java library functions in expressions, as outlined in Section 9.1, “Single-row Function Reference”. This configuration item can be set to allow a partial rather than a fully qualified class name in such invocations. The imports work in the same way as in Java files, so both packages and classes can be imported.

select Math.max(priceOne, PriceTwo)
// via configuration equivalent to
select java.lang.Math.max(priceOne, priceTwo)

Esper auto-imports the following Java library packages. Any additional imports that are specified in configuration files or through the API are added to the configuration in addition to the imports below.

In a XML configuration file the auto-import configuration may look as below:

<auto-import import-name="com.mycompany.mypackage.*"/>
<auto-import import-name="com.mycompany.myapp.MyUtilityClass"/>

Here is an example of providing imports via the API:

Configuration config = new Configuration();
config.addImport("com.mycompany.mypackage.*");	// package import
config.addImport("com.mycompany.mypackage.MyLib");   // class import

Method invocations are allowed in the from clause in EPL, such that your application may join event streams to the data returned by a web service, or to data read from a distributed cache or object-oriented database, or obtain data by other means. A local cache may be placed in front of such method invocations through the configuration settings described herein.

The LRU cache is described in detail in Section 15.4.9.6.1, “LRU Cache”. The expiry-time cache documentation can be found in Section 15.4.9.6.2, “Expiry-time Cache”

The next XML snippet is a sample cache configuration that applies to methods provided by the classes 'MyFromClauseLookupLib' and 'MyFromClauseWebServiceLib'. The XML and API configuration understand both the fully-qualified Java class name, as well as the simple class name:

<method-reference class-name="com.mycompany.MyFromClauseLookupLib">
  <expiry-time-cache max-age-seconds="10" purge-interval-seconds="10" ref-type="weak"/>
</method-reference> 	
<method-reference class-name="MyFromClauseWebServiceLib">
  <lru-cache size="1000"/>
</method-reference> 

Variables can be created dynamically in EPL via the create variable syntax but can also be configured at runtime and at configuration time.

A variable is declared by specifying a variable name, the variable type, an optional initialization value and an optional boolean-type flag indicating whether the variable is a constant (false by default). The initialization value can be of the same or compatible type as the variable type, or can also be a String value that, when parsed, is compatible to the type declared for the variable. Declare each variable a constant to achieve the best performance.

In a XML configuration file the variable configuration may look as below. The Configuration API can also be used to configure variables.

<variable name="var_threshold" type="long" initialization-value="100"/>
<variable name="var_key" type="string"/>
<variable name="test" type="int" constant="true"/>

Please find the list of valid values for the type attribute in Section 15.5, “Type Names”.

Esper has the capability to join event streams against historical data sources, such as a relational database. This section describes the configuration entries that the engine requires to access data stored in your database. Please see Section 5.13, “Accessing Relational Data via SQL” for information on the use of EPL queries that include historical data sources.

EPL queries that poll data from a relational database specify the name of the database as part of the EPL statement. The engine uses the configuration information described here to resolve the database name in the statement to database settings. The required and optional database settings are summarized below.

Some of the settings can have important performance implications that need to be carefully considered in relationship to your database software, JDBC driver and runtime environment. This section attempts to outline such implications where appropriate.

The sample XML configuration file in the "etc" folder can be used as a template for configuring database settings. All settings are also available by means of the configuration API through the classes Configuration and ConfigurationDBRef.

<database-reference name="mydb1">
  <datasource-connection context-lookup-name="java:comp/env/jdbc/mydb">
    <env-property name="java.naming.factory.initial" value ="com.myclass.CtxFactory"/>
    <env-property name="java.naming.provider.url" value ="iiop://localhost:1050"/>
  </datasource-connection>
</database-reference>

if (envProperties.size() > 0) {
  initialContext = new InitialContext(envProperties);
}
else {
  initialContext = new InitialContext();
}
DataSource dataSource = (DataSource) initialContext.lookup(lookupName);
Connection connection = dataSource.getConnection();

<database-reference name="mydb3">
  <!-- For a complete list of properties see Apache DBCP. -->
  <datasourcefactory-connection class-name="org.apache.commons.dbcp.BasicDataSourceFactory">	
    <env-property name="username" value ="myusername"/>
    <env-property name="password" value ="mypassword"/>
    <env-property name="driverClassName" value ="com.mysql.jdbc.Driver"/>
    <env-property name="url" value ="jdbc:mysql://localhost/test"/>
    <env-property name="initialSize" value ="2"/>
    <env-property name="validationQuery" value ="select 1 from dual"/>
  </datasourcefactory-connection>
  <connection-lifecycle value="pooled"/>
</database-reference>

Properties props = new Properties();
props.put("username", "myusername");
props.put("password", "mypassword");
props.put("driverClassName", "com.mysql.jdbc.Driver");
props.put("url", "jdbc:mysql://localhost/test");
props.put("initialSize", 2);
props.put("validationQuery", "select 1 from dual");

ConfigurationDBRef configDB = new ConfigurationDBRef();
// BasicDataSourceFactory is an Apache DBCP import
configDB.setDataSourceFactory(props, BasicDataSourceFactory.class.getName());
configDB.setConnectionLifecycleEnum(ConfigurationDBRef.ConnectionLifecycleEnum.POOLED);

Configuration configuration = new Configuration();;
configuration.addDatabaseReference("mydb3", configDB);

configDB.setDataSourceFactory(props, MyOwnDataSourceFactory.class.getName());
...
class MyOwnDataSourceFactory {
  public static DataSource createDataSource(Properties properties) {
    return new MyDataSourceImpl(properties);
  }
}

<database-reference name="mydb2">
  <drivermanager-connection class-name="my.sql.Driver" 
        url="jdbc:mysql://localhost/test?user=root&amp;password=mypassword" 
        user="myuser" password="mypassword">
    <connection-arg name="user" value ="myuser"/>
    <connection-arg name="password" value ="mypassword"/>
    <connection-arg name="somearg" value ="someargvalue"/>
  </drivermanager-connection>
</database-reference>

<database-reference name="mydb2">
... configure data source or driver manager settings...
  <connection-settings auto-commit="true" catalog="mycatalog" 
      read-only="true" transaction-isolation="1" />
</database-reference>

<database-reference name="mydb2">
... configure data source or driver manager settings...
    <connection-lifecycle value="pooled"/>
</database-reference>

<database-reference name="mydb">
... configure data source or driver manager settings...
    <lru-cache size="1000"/>
</database-reference>

<database-reference name="mydb">
... configure data source or driver manager settings...
    <expiry-time-cache max-age-seconds="60" purge-interval-seconds="120" />
</database-reference>

<database-reference name="mydb">
... configure data source or driver manager settings...
    <expiry-time-cache max-age-seconds="60" purge-interval-seconds="120" ref-type="hard"/>
</database-reference>

<column-change-case value="lowercase"/>

<sql-types-mapping sql-type="2" java-type="int" />

You may configure a default script dialect as described herein. The default script dialect is js which stands for JavaScript, since most JVM ship with an integrated JavaScript engine.

A sample XML configuration for this setting is shown below:

<engine-settings>
<defaults>
  <scripts default-dialect="js"/>
</defaults>
</engine-settings>

A sample code snippet that sets a new script dialect is:

config.getEngineDefaults().getScripts().setDefaultDialect("js");

Please set the flag as described herein to have the engine report key counters and other processing information through the JMX mbean platform server. By default JMX is not enabled.

A sample XML configuration is shown below:

<engine-settings>
  <defaults>
    <metrics-reporting jmx-engine-metrics="true"/>
  </defaults>
</engine-settings>

A sample code snippet to set this configuration via the API follows:

configuration.getEngineDefaults().getMetricsReporting().setJmxEngineMetrics(true);

This section explains how to enable and configure metrics reporting, which is by default disabled. Please see Section 14.15, “Engine and Statement Metrics Reporting” for more information on the metrics data reported to your application.

The flag that enables metrics reporting is global to a Java virtual machine. If metrics reporting is enabled, the overhead incurred for reporting metrics is carried by all engine instances per Java VM.

Metrics reporting occurs by an engine-controlled separate daemon thread that each engine instance starts at engine initialization time, if metrics reporting and threading is enabled (threading enabled is the default).

Engine and statement metric intervals are in milliseconds. A negative or zero millisecond interval value may be provided to disable reporting.

To control statement metric reporting for individual statements or groups of statements, the engine provides a facility that groups statements by statement name. Each such statement group may have different reporting intervals configured, and intervals can be changed at runtime through runtime configuration. A statement group is assigned a group name at configuration time to identify the group.

Metrics reporting configuration is part of the engine default settings. All configuration options are also available via the Configuration API.

A sample XML configuration is shown below:

<engine-settings>
  <defaults>
    <metrics-reporting enabled="true" engine-interval="1000" statement-interval="1000" 
        threading="true"/>
  </defaults>
</engine-settings>

The engine-interval setting (defaults to 10 seconds) determines the frequency in milliseconds at which the engine reports engine metrics, in this example every 1 second. The statement-interval is for statement metrics. The threading flag is true by default since reporting takes place by a dedicated engine thread and can be set to false to use the external or internal timer thread instead.

The next example XML declares a statement group: The statements that have statement names that fall within the group follow a different reporting frequency:

<metrics-reporting enabled="true" statement-interval="0">
  <stmtgroup name="MyStmtGroup" interval="2000" default-include="true" num-stmts="100" 
        report-inactive="true">
    <exclude-regex>.*test.*</exclude-regex>
  </stmtgroup>
</metrics-reporting>

The above example configuration sets the statement-interval to zero to disable reporting for all statements. It defines a statement group by name MyStmtGroup and specifies a 2-second interval. The example sets the default-include flag to true (by default false) to include all statements in the statement group. The example also sets report-inactive to true (by default false) to report inactive statements.

The exclude-regex element may be used to specify a regular expression that serves to exclude statements from the group. Any statement whose statement name matches the exclude regular expression is not included in the group. In the above example, all statements with the characters 'test' inside their statement name are excluded from the group.

Any statement not belonging to any of the statement groups follow the configured statement interval.

There are additional elements available to include and exclude statements: include-regex, include-like and exclude-like. The latter two apply SQL-like matching. All patterns are case-sensitive.

Here is a further example of a possible statement group definition, which includes statements whose statement name have the characters @REPORT or @STREAM, and excludes statements whose statement name have the characters @IGNORE or @METRICS inside.

<metrics-reporting enabled="true">
  <stmtgroup name="MyStmtGroup" interval="1000">
    <include-like>%@REPORT%</include-like>
    <include-regex>.*@STREAM.*</include-like>
    <exclude-like>%@IGNORE%</exclude-like>
    <exclude-regex>.*@METRICS.*</exclude-regex>
  </stmtgroup>
</metrics-reporting>

Locale-dependence in Esper can be present in the sort order of string values by the order by clause and by the sort view.

By default, Esper sorts string values using the compare method that is not locale dependent. To enable local dependent sorting you must set the configuration flag as described below.

The XML configuration sets the locale dependent sorting as shown below:

<engine-settings>
  <defaults>
    <language sort-using-collator="true"/>
  </defaults>
</engine-settings>

The API to change the setting:

Configuration config = new Configuration();
config.getEngineDefaults().getLanguage().setSortUsingCollator(true);

Use the settings as described here to register an exception handler factory class that provides an exception handler. The engine invokes exception handlers in the order they are listed to handle a continues-query unchecked exception, as further described in Section 14.11, “Exception Handling”.

Please provide the full-qualified class name of each class that implements the com.espertech.esper.client.hook.ExceptionHandlerFactory interface in the engine defaults configuration as below.

The XML configuration is as follows:

<engine-settings>
  <defaults>
    <exceptionHandling>
      <handlerFactory class="my.company.cep.MyCEPEngineExceptionHandlerFactory"/>
    </exceptionHandling>
  </defaults>
</engine-settings>

The API calls to register an exception handler factory are as follows:

Configuration config = new Configuration();
config.getEngineDefaults().getExceptionHandling().addClass(MyCEPEngineExceptionHandlerFactory.class);

Use the settings as described here to register a condition handler factory class that provides a condition handler. The engine invokes condition handlers in the order they are listed to indicate conditions, which is the term used for notification when certain predefined limits are reached, as further described in Section 14.12, “Condition Handling”.

Please provide the full-qualified class name of each class that implements the com.espertech.esper.client.hook.ConditionHandlerFactory interface in the engine defaults configuration as below.

The XML configuration is as follows:

<engine-settings>
  <defaults>
    <conditionHandling>
      <handlerFactory class="my.company.cep.MyCEPEngineConditionHandlerFactory"/>
    </conditionHandling>
  </defaults>
</engine-settings>

The API calls to register a condition handler factory are as follows:

Configuration config = new Configuration();
config.getEngineDefaults().getConditionHandling().addClass(MyCEPEngineConditionHandlerFactory.class);

Revision event types reflect a versioning relationship between events of same or different event types. Please refer to Section 2.10, “Updating, Merging and Versioning Events” and Section 5.15.14, “Versioning and Revision Event Type Use with Named Windows”.

The configuration consists of the following:

The XML configuration for this setting is shown below:

<revision-event-type name="UserProfileRevisions">
  <base-event-type name="ProfileCreation"/>
  <delta-event-type name="ProfileUpdate"/>
  <key-property name="userid"/>
</revision-event-type>

If configuring via runtime or initialization-time API, this code snippet explains how:

Configuration config = new Configuration();
ConfigurationRevisionEventType configRev = new ConfigurationRevisionEventType();
configRev.setNameBaseEventType("ProfileCreation");
configRev.addNameDeltaEventType("ProfileUpdate");
configRev.setKeyPropertyNames(new String[] {"userid"});
config.addRevisionEventType("UserProfileRevisions", configRev);

As the configuration provides names of base and delta event types, such names must be configured for JavaBean, Map or XML events as the previous sections outline.

The next table outlines the available strategies:

A variant stream is a predefined stream into which events of multiple disparate event types can be inserted, and which can be selected from in patterns and the from clause.

The name of the variant stream and, optionally, the type of events that the stream may accept, are part of the stream definition. By default, the variant stream accepts only the predefined event types. The engine validates your insert into clause which inserts into the variant stream against the predefined types.

A variant stream can be set to accept any type of event, in which case all properties of the variant stream are effectively dynamic properties. Set the type variance flag to ANY to indicate the variant stream accepts any type of event.

The following XML configuration defines a variant stream by name OrderStream that carries only PartsOrder and ServiceOrder events:

<variant-stream name="OrderStream">
  <variant-event-type name="PartsOrder"/>
  <variant-event-type name="ServiceOrder"/>
</variant-stream>

This code snippet sets up a variant stream by name OutgoingEvent:

Configuration config = new Configuration();
ConfigurationVariantStream variant = new ConfigurationVariantStream();
variant.setTypeVariance(ConfigurationVariantStream.TypeVariance.ANY);
config.addVariantStream("OutgoingEvent", variant);

If specifying variant event type names, make sure such names have been configured for JavaBean, Map or XML events.

Log4j is the default logging component. Please find additional information for Log4j configuration and extension in http://logging.apache.org/log4j.

The easiest way to configure Log4j is by providing a Log4J configuration file, similar to the log4j.xml file shipped in the etc folder of the distribution.

Add the log4j.configuration system property to the java command line and provide the file name of the Log4j configuration file, making sure your classpath also includes the directory of the file:

java -Dlog4j.configuration=log4j.xml ...