Frequently Asked Questions

This document attempts to answer some of the more frequently asked questions regarding various aspects of JAMSEL. These questions are typically asked over and over again on the mailing lists, as a courtesy to the developers, we ask that you read this document before posting to the mailing lists.

General

  1. What is JAMSEL?

General

What is JAMSEL?
Please see the Goals and Features documents.

Using JAMSEL

Using the CSRvValueProvider class throws a ClassNotFound: com.tibco.tibrv.TibrvMsg exception ?
JAMSEL provides value extractors to extract values from TIBCO/RV . Since RV is a commercial product you must puchase it separately. Once you have purchased the product or downloaded an evaluation copy, make sure it is in your CLASSPATH . This should fix the problem.
How can the application pass identifier values to the framework during selector evaluation ?
The framework parses the String selector expression and generates a in-memory representation of the expression. This in-memory representation is returned as an instance of ICSSelector . When a ICSSelector instance has to be evaluated, the application has a couple of options. In the first option, the application can retrieve all the identifiers that were found during the parse by invoking getIdentifiers() on the ICSSelector instance. Once the application has the names of all identifiers, it can create a Map with the the values of the identifiers - the key into the Map is the identifier name. After constructing and populating the Map the applciation can call eval(map) . In the second option, the application creates an instance of a callback class that implements ICSValueProvider and then invoked eval(vp, corr) . During evaluation of the selector instance, the framework calls the ICSValueProvider instance to get the value of the desired identifier.
Which evaluation stretegy should the application use ?
If the selector expression has a large number of identifiers and sub-expressions then the callback option may yield better performance under certain conditions. For example, if sub-expressions are highly discriminating then using a callback is better since identifier values are requested as needed . That is, if an identifer value is not required during evaluation then it is not requested by the framework. In contrast, the Map options forces the application to provide values for all identifiers regardless of whether the values are actually used during evaluation. Another benefit of using the callback strategy is that the value provider implementations CSRvValueProvider and CSJmsValueProvider can be used to extract values from TIBCO/RV and JMS messages without any additional coding.
I have a MapMessage that contains application fields. These application fields are not properties of the message. How can I filter messages based on content ?
The JMS 1.1 selector specification allows selectors to filter messages based on either header fields or properties. However, applications frequently require message selection based on content. The framework provides an extension of the JMS specification to provide content-based selection. Specifically, the framework allows '.' in the identifier name. The notation '.' can be used to reference MapMessage content fields and even to reference fields within nested messages. For example, the identifier '.Quantity' will be interpreted by an instance of the CSJmsValueProvider class as a top-level content field named 'Quantity'. The identifier '.Nested.Quantity' will be interpreted by an instance of CSJmsValueProvider as a content field named 'Quantity' within a nested MapMessage content field named 'Nested'.
I have a TibrvMsg that contains application fields. How can I filter messages based on content ?
The '.' notation can be used to reference TibrvMsg fields and even to reference fields within nested messages. For example, the identifier '.Quantity' will be interpreted by an instance of the CSRvValueProvider class as a top-level field named 'Quantity'. The identifier '.Nested.Quantity' will be interpreted by an instance of CSRvValueProvider as a field named 'Quantity' within a nested TibrvMsg field named 'Nested'. In fact, since there is no distinction in TibrvMsg between header fields, properties, and content fields, applications can skip the leading '.' in the selector. Specificaly, the identifiers '.Quantity' and 'Quantity' are treated identically.
I have a TibrvMsg that contains top-level application fields. Why do I have to preface the identifier names with a '.' ?
The '.' notation is used to reference content fields. In JMS, the '.' notation is used to specify content fields - any identifier without a '.' can refer only to header fields or message properties. In the TibrvMsg world there is no distinction between header fields, properties, or content fields. However, to maintain syntactic compatibility between JMS and TibrvMsg , the framework allows applications to preface TibrvMsg identifiers with a '.'. As a result, the same selector can be used by JMS and TibrvMsg implementations. However, the '.' prefix is optional for TibrvMsg implementations. In other words, in TibrvMsg implementations, the identifiers 'Quantity' and '.Quantity' are identical.
I have a TibrvMsg that contains a top-level application field named '.Quantity'. When I used the CSRvValueProvider class, the selector .Quantity IS NOT NULL evaluates to false even though the application clearly sets the field. Why ?
The CSRvValueProvider class treats the '.' as a meta-character. Specifically, it skips over the leading '.'. If your application has '.' as a valid character within field names then you must code your own ICSValueProvider that does the right thing.
How efficient is the JAMSEL framework ?
The JAMSEL framework is highly efficient both in terms of object creation and evaluation. For example, the selector expression JMSPriority >= 0 AND Quantity > 100 AND MessageName in ('foo', 'goo', 'too', 'CreateOrder', 'last', '1', '2', '3', '4', '5', 'a', 'b', 'c', 'd') can be evaluated using the CSRvValueProvider at a rate of 225,000 evaluations per second on a low-end machine running Windows 2000. Contrast this with the selector implementation found in JBOSS . The JBOSS implementation will evaluate the same selector expression at a rate of about 90,000 evaluation per second.