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.
What is JAMSEL?
class throws a
JAMSEL provides value extractors to extract values from
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
. This should fix the problem.
How can the application pass identifier values to the framework during selector evaluation ?
The framework parses the
selector expression and generates a in-memory representation of the expression. This
in-memory representation is returned as an instance of
. When a
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
instance. Once the application
has the names of all identifiers, it can create a
with the the values of the identifiers - the key into the
is the identifier name. After constructing and populating the
the applciation can call
. In the second option, the application creates an instance of a
class that implements
and then invoked
. During evaluation of the selector instance, the framework
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
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
. That is, if an identifer value is not required during
evaluation then it is not requested by the framework. In contrast, the
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
used to extract values from TIBCO/RV and JMS messages without any additional coding.
I have a
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
content fields and even to reference fields within nested messages. For example, the identifier
'.Quantity' will be interpreted by an instance of the
class as a top-level content field named
'Quantity'. The identifier '.Nested.Quantity' will be interpreted by an instance of
as a content
field named 'Quantity' within a nested
content field named 'Nested'.
I have a
that contains application fields. How can I filter messages based on content ?
The '.' notation can be used to reference
fields and even to reference fields within nested messages. For
example, the identifier '.Quantity' will be interpreted by an instance of the
class as a top-level
field named 'Quantity'. The identifier '.Nested.Quantity' will be interpreted by an instance of
as a field named 'Quantity' within a nested
field named 'Nested'. In fact, since there is no distinction
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
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
world there is no distinction
between header fields, properties, or content fields. However, to maintain syntactic compatibility between JMS and
the framework allows applications to preface
identifiers with a '.'. As a result, the same selector can be used
by JMS and
implementations. However, the '.' prefix is optional for
implementations. In other
implementations, the identifiers 'Quantity' and '.Quantity' are identical.
I have a
that contains a top-level application field named '.Quantity'. When I used the
class, the selector
.Quantity IS NOT NULL
even though the application clearly sets the
field. Why ?
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
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
at a rate of
evaluations per second on a low-end machine
running Windows 2000. Contrast this with the selector implementation found in
The JBOSS implementation will evaluate the same selector expression at a rate of about
evaluation per second.