Changes to Apama client APIs between 4.3 and 5.0
This topic describes various changes to the Apama client APIs.
Event Parser API for Java generics warnings
In the Apama EventParser API for Java, the Field and FieldType classes now have a generic type parameter. This means that the compiler can assist with checking field types and eliminates the need for lots of type casts. The type parameter indicates the Java type used to represent field values, for example, for a sequence of integers the type parameter would be List<Long>.
Note, this change will not break existing code, but will cause warnings until the code is updated to specify the generic type parameters. You can also add the @SuppressWarnings("unchecked") annotation.
Event Parser removed methods
In the Apama API for Java, the following methods have been removed:
SequenceFieldType.setElementTypeDictionaryFieldType.setKeyType DictionaryFieldType.setValueType This means the types must be specified in the constructors. When creating events with sequences or dictionaries of that type, create the event type first, then the sequence or dictionary type, and then add that field to the EventType.
Similarly, in the .NET API, the SequenceFieldType.elementType, DictionaryFieldType.keyType, and DictionaryFieldType.valueType elements are now read-only.
Change in EventService and ScenarioService Destroy() and Dispose() semantics
The semantics of IEventService.destroy() and IScenarioService.destroy() have been changed and simplified. The caller is now responsible for destroying an event service or client bean passed into EventServiceFactory or ScenarioServiceFactory, respectively. The caller is never responsible for destroying any event service or client object implicitly created by the constructor as this will happen automatically. Apama recommends that you review existing code to check for compliance with these semantics, ensuring that the objects are correctly shut down. The Dispose() and Destroy() methods are now idempotent, so it is safe to call them repeatedly.
The IEventServiceChannel.destroy() method has been removed; the correct way to remove an event service channel is still to use the IEventService.removeChannel() method.
Change in engine client semantics
The following changes have been made to the semantics of the client API stacks for Java and .NET.
The
ALL_CONSUMERS_CONNECTED engine client property semantics have changed such that it will now always have the value 'false' if the bean itself is disconnected, even if no consumers are registered.
The engine client (
EngineClientBean) layer no longer guarantees order of event delivery for synchronous consumers across all engine client objects in the JVM. However, event delivery order is still guaranteed for each engine client object (bean) and this change is unlikely to have an impact on existing applications.
The EventService's reconnection interval is now identical to the engine client (that is, the beans layer) connection polling interval, instead of being hardcoded to 500ms. However, this interval respects any reconnection period limit specified by the engine client's
setReconnectPeriod() method.
Removal of deprecated items from APIs for Java and .NET
Removed several methods and classes from the APIs for .NET and Java that were deprecated or extremely unlikely to be used in customer code. The removed .NET methods are:
Apama.EngineException.getWarnings Apama.Event.Parser.FieldTypeFactory Apama.Event.Parser.ParserRuntimeException.#ctor Apama.Net.Client.IBaseClient.EngineManagement Apama.Net.Client.IBaseClient.ReleaseEngineManagement(Apama.Engine. EngineManagement) Apama.Util.Logger.WriteStackTrace(System.Exception,System.IO.TextWriter) Apama.Util.Logger.BaseSuppressConfigName and
LogSuppressPropertyName constants.
The following Java methods and classes were removed:
com.apama.event.parser.FieldTypeFactory com.apama.event.parser.ParserRuntimeException com.apama.engine.beans.AbstractEngineClientBean com.apama.event.EventReader.CommentStripper Default batching/non batching semantic of the sendEvents was changed
The default semantic of the sendEvents calls has been changed from non-batching to batching in all remote client APIs. A non batching version called sendEventsNoBatching has been added to the EngineManagement interface together with a flushEvents method. The sendEventsBatching method has been removed.
C client API changes
The signatures of attachAsEventConsumerTo and detachAsEventConsumerFrom were changed. The attachAsEventConsumerTo has two new arguments: persistent and disconnectSlow. The detachAsEventConsumerFrom has one new argument: persistent.
The new signatures are:
AP_bool (AP_ENGINE_CLIENT_CALL* attachAsEventConsumerTo)(
AP_EngineManagement* engine,
AP_EngineManagement* target,
const AP_char8* const* channels,
AP_bool persistent,
AP_bool disconnectSlow);
void (AP_ENGINE_CLIENT_CALL* detachAsEventConsumerFrom)(
AP_EngineManagement* engine,
AP_EngineManagement* target,
const AP_char8* const* channels,
AP_bool persistent);
Java classes built with Java 1.6
It is no longer possible to use a 1.5 JDK with Apama.
Remove Applet factory methods, constructors and getters and setters in API for Java
For historical reasons (CORBA required it) the constructors and factory methods for creating connections to other Apama systems have included an Applet parameter. This is no longer necessary and these APIs have been deprecated since 4.0. In Apama 5.0, these methods have been removed. This should not affect customer code.
