Abstract superclass of all CGIN array iterators.
A NodeIterator for an AbstractFieldsObject.
A NodePointer for an AbstractFieldsObject.
A NodeIterator for an ArrayDataObject.
A NodePointer for an ArrayDataObject.
A NodeIterator for an array.
A NodePointer for an array.
A NodePointer for an ASN1Null.
A NodePointer for a BitString.
A NodePointer for a Boolean.
A NodePointer for a byte.
A NodePointer for a Byte.
Abstract superclass of all CGIN NodeIterators.
Abstract superclass of NodePointers for CGIN data structures.
Creates NodePointers for CGIN data structures.
Abstract superclass of NodePointers for collections.
A NodePointer for a Double.
|EnumIterator<E extends Enum<E>>||
A NodeIterator for an enum.
A NodePointer for an enum.
A NodePointer for a Float.
A NodePointer for an Integer.
Abstract superclass of NodePointers for leaves.
A NodePointer for a Long.
A NodeIterator for a NamedInteger.
A NodePointer for a NamedInteger.
A NodePointer for an ObjectID.
A NodePointer for a Short.
A NodePointer for a String.
Static utility methods.
Supports the use of XPath expressions on CGIN data structures such as operation arguments, results and errors. It is based on Apache's JXPath - see http://commons.apache.org/jxpath - initially version 1.3.
Here's an example of selecting components from an idpArg.
OCJXPathContext jXPathContext = OCJXPathContext.newContext(idpArg); String xPathQuery = "calledPartyNumber/address"; String address = (String)jXPathContext.getValue(xPathQuery);
idpArg.getCalledPartyNumber().getAddress()One reason for using XPath rather than Java code is that the query expression doesn't need to be known at compile time. Further advantages come from further features of the XPath query language, such as predicates for choosing from alternatives, as illustrated here.
OCJXPathContext jXPathContext = OCJXPathContext.newContext(requestReportBCSMEventArg); String xPathQuery = "bcsmEvents[legID/receivingSideID/encodedValue/intValue=1]/eventTypeBCSM"; CCEventTypeBCSM eventTypeBCSM = (CCEventTypeBCSM)jXPathContext.getValue(xPathQuery);
The components that can be selected from a CGIN data structure depend on the type of structure.
|Type of structure||Components|
|SEQUENCE and CHOICE (AbstractFieldsObjects)||The named fields|
|array||[indexing] of elements numbered from 1|
|ArrayDataObject||[indexing] of elements numbered from 1|
|NamedInteger||byteValue, shortValue, intValue, longValue, floatValue, doubleValue|
All other types (INTEGERs, BIT STRINGs, OCTET STRINGs, etc) are currently regarded as leaves from the cgin-xpath perspective.
The treatment of arrays deserves explanation, as it might surprise. Suppose the context is a CCRequestReportBCSMEventArg whose bcsmEvents array has two elements. jXPathContext.getValue("bcsmEvents") and jXPathContext.getValue("bcsmEvents") work as you'd expect, bearing in mind that indexing is from 1 not 0. But jXPathContext.getValue("bcsmEvents") returns the first element, not the whole array. This behaviour originates in XML, where elements can have multiple occurrences (think books in library, from the traditional example), and there are no arrays as such. The context's getValue() method is just returning the first element that it finds with the right name. To access all the elements that have the same name, such as the elements of a CGIN array, the context provides a different method that returns an iterator.
Iterator iterator = jXPathContext.iterate("bcsmEvents");
An SBB that uses cgin-xpath needs to declare dependencies on a couple of libraries in its deployment descriptor.
library-name="CGIN XPath" library-version="@cgin-xpath.library.version@" library-vendor="OpenCloud" library-name="commons-jxpath" library-version="@commons-jxpath.version@" library-vendor="apache"These libraries are deployed as part of the CGIN RA, so no special action is required.
Only getting of components is supported by cgin-xpath; setting is there in JXPath, but hasn't been implemented in cgin-xpath yet.