EsperTech-BlogAuthor

Introduction

Configuration now has 3 sections:

1. Common section: All configuration common to the compiler and the runtime
2. Compiler section: Configuration that applies to the compiler only
3. Runtime section: Configuration that applies to the runtime only

The compiler ignores the runtime section of the configuration, and the runtime ignores the compiler section of the configuration.

Configuration Object Class and Package Name

Esper-8 moved configuration classes to com.espertech.esper.common.client.configuration and the common, compiler and runtime packages.

Esper-8 renamed configuration classes. A table of renamed classes can be found below. Certain configuration inner classes have been moved to com.espertech.esper.common.client.util.

Migrating XML files

The new schema is esper-configuration-8-0.xsd .

NOTE: The new schema is not compatible with the version 7 schema.

The new schema moves all configuration to <common>, <compiler> and <runtime> elements.

EsperTech provides an online cloud-based application that can read an existing Esper-7 XML configuration and produce an Esper-8 XML configuration. The link is http://esper-config-upgrade7to8.appspot.com.
The class that provides the functionality is com.espertech.esper.common.client.configuration.ConfigurationSchema7To8Upgrade.

Table of Updates

The below table is structured by configuration topic. Within the topic the table describes into which section (common, compiler, runtime) the configuration moves.

In some cases, specifically for engine settings, multiple sections may apply. In this case the table provides instructions which subset of properties belongs to which section.

Removed Configuration

• The view resources configuration removes the share-views setting and the allow-multiple-expiry-policy setting.
• The execution configuration removes the allow-isolated-service setting.
• The runtime threading engine-fairlock is now runtime-fairlock.
• The runtime metrics reporting engine-interval is now runtime-interval.
• The runtime metrics reporting jmx-engine-metrics is now jmx-runtime-metrics.
• The HA-configuration enginelock-settings is now runtimelock-settings.

This section overviews conceptual changes and is not an all-inclusive statement of changes. It is intended to provide background information.

Removed CGLIB Dependency

As the compiler generates all the byte code to access event properties and call methods we removed the CGLIB library as a dependency entirely.

ANTLR Jar Dependency Only at Compile-Time

Only the compiler needs the ANTLR library and the runtime does not need ANTLR anymore. The only dependency of the runtime is the SLF4J library.

Public API Names

In Esper 8 the compiler and runtime and replace the service provider of Esper 7. The term "service provider" and "engine" were thus replaced by runtime. The resulting name changes in the public API are substantial. Some of the renamed classes are listed below. Please consult the API-migration doc for a table on impacted classes.

• EPServiceProviderManager is now EPRuntimeProvider
• EPServiceProvider is now EPRuntime
• EPRuntime is now EPEventService
• EPAdministrator is now EPDeploymentService

Names for Statements, Event Types, Named Windows, Tables, Variables, Contexts, Expressions, Scripts and Indexes

The compiler does not have access to deployment-time names and therefore cannot determine whether a name is already used or not.

For example, an EPL module defines a statement by name "A" using "@name('A')". The statement name may already be used by another statement in the runtime environment. In Esper-7 a statement name was unique across the runtime and Esper-7 simply generated a new statement name. Generating a new name however is not an option for variable names, context names, named window names and others.

Therefore in Esper-8 a name is unique in combination with the deployment-id. This is true for all names such as statement name, context name, variable name and others.

For example, an EPL module may define a statement by name "A". The compiler compiles the module to byte code. The runtime deploys the byte code using deployment id 'D1'. The statement is uniquely named as a combination of deployment id and statement name. The combined key is {deploymentId='D1', statementName='A'}.

This change meant that all APIs that handle names must take the deployment id as an additional parameter or must return the deployment id as part of the result. Your application must iterate and find statements using deployment ids.

EPL Module as the Source Code Unit

EPL modules consist of EPL statements. The compiler compiles EPL modules to byte code and you can deploy that byte code to the runtime. Any single EPL statement must be part of a module for compiling and deploying.

Esper-8 thus removes the single EPL statement as a unit and removes the "createEPL" methods for creating a single statement. It also removes the statement lifecycle, therefore the statement "stop", "start" and "destroy" methods are removed. They are replaced by "deploy" and "undeploy" for byte code and deployment lifecycle.

Configuration

The compiler and runtime are now completely separated. This meant that the configuration that applies to the compiler needed to be separated from the configuration that applies to the runtime. There are some common parts to configuration that can apply at compile-time and at runtime.

Keeping one configuration object that contains a common, a compiler and a runtime configuration is easiest to use. It however means that existing configuration must all migrate to one of the 3 sections.

In effect this means the configuration XML now has a <common>, <compiler> and <runtime>. In turn the configuration class offers Configuration#getCommon, Configuration#getCompiler and Configuration#getRuntime.

Bean Event Types

One of the issues that users of Esper-7 had trouble with was the fact that Esper-7 identified Bean-style event types by class disallowing use of the same class to represent multiple event types without subclassing. Esper-8 identifies a Bean-style event type by name that consistent with all other event types.

In Esper-7 the from-clause could specify a full-qualified or otherwise resolvable class name and Esper-7 would dynamically allocate a bean event type for the same fully-qualified class name. With the compiler architecture this behavior would cause implicit type references.

In Esper-8 all event types are either preconfigured or allocated using create schema or insert into.

Duplicate Listener Interfaces

In Esper-7 there were two types of listeners. Esper-8 simplifies the listener interface into a single UpdateListener interface.

Subscribers

As the compiler produces byte code for delivering results to subscribers, that byte code is unnecessary for applications that don't use subscribers. In Esper-8 there is a new setting to control whether the compile produces byte code for subscribers.

Substitution Parameters

In many cases the compiler must know the type of the substitution parameter to ensure type-safety. Therefore Esper-8 supports a type name for substitution parameters, using "?:name:type". The compiler must assume Object-type in case the EPL does not provide a type.