| Home >> All >> org >> springframework >> jca |
Package Samples:
• org.springframework.jca.cci.object: This package contains Spring's support for the Common Client Interface (CCI), as defined by the J2EE Connector Architecture.
• org.springframework.jca.cci.core.support: Provides the core JCA CCI support, based on CciTemplate and its associated callback interfaces.
• org.springframework.jca.cci.connection
• org.springframework.jca.cci.core
• org.springframework.jca.cci
• org.springframework.jca.support
Classes:
• TransactionAwareConnectionFactoryProxy: Proxy for a target ConnectionFactory, adding awareness of Spring-managed transactions. Similar to a transactional JNDI ConnectionFactory as provided by a J2EE server. Data access code that should remain unaware of Spring's data access support can work with this proxy to seamlessly participate in Spring-managed transactions. Note that the transaction manager, for example the CciLocalTransactionManager, still needs to work with underlying ConnectionFactory, not with this proxy. Make sure that TransactionAwareConnectionFactoryProxy is the outermost ConnectionFactory of a chain of ConnectionFactory ...
• ConnectionSpecConnectionFactoryAdapter: An adapter for a target ConnectionFacory, applying the given ConnectionSpec to every standard getConnection() call, that is, implicitly invoking getConnection(ConnectionSpec) on the target. All other methods simply delegate to the corresponding methods of the target ConnectionFactory. Can be used to proxy a target JNDI ConnectionFactory that does not have a ConnectionSpec configured. Client code can work with the ConnectionFactory without passing in a ConnectionSpec on every getConnection() call. In the following example, client code can simply transparently work with the preconfigured "myConnectionFactory", ...
• CciLocalTransactionManager: PlatformTransactionManager implementation that performs local transactions on a single CCI ConnectionFactory. Binds a CCI connection from the specified ConnectionFactory to the thread, potentially allowing for one thread Connection per ConnectionFactory. Application code is required to retrieve the CCI Connection via ConnectionFactoryUtils.getConnection(ConnectionFactory) instead of J2EE's standard ConnectionFactory.getConnection() . This is recommended anyway, as it throws unchecked org.springframework.dao exceptions instead of the checked JCA ResourceException. All framework classes like CciTemplate ...
• CciTemplate: This is the central class in the CCI core package. It simplifies the use of CCI and helps to avoid common errors. It executes core CCI workflow, leaving application code to provide parameters to CCI and extract results. This class executes EIS queries or updates, catching ResourceExceptions and translating them to the generic exception hierarchy defined in the org.springframework.dao package. Code using this class can pass in and receive CCI Record instances, or alternatively implement callback interfaces for creating input Records and extracting result objects from output Records (or CCI ResultSets). ...
• LocalConnectionFactoryBean: This FactoryBean creates a local JCA connection factory in non-managed mode. The type of the connection factory is dependent on the actual connector: the connector can either expose its native API or follow the standard Common Client Interface (CCI), as defined by the JCA spec. In the latter case, the exposed interface is javax.resource.cci.ConnectionFactory . In such a scenario, the connector uses a local ConnectionManager and you can't participate in global transactions because the connector will never be enlist/delist in the current JTA transaction. In non-managed mode, a connector is not deployed ...
• RecordExtractor: Callback interface for extracting a result object from a CCI Record instance. Used for output object creation in CciTemplate. Alternatively, output Records can also be returned to client code as-is. In case of a CCI ResultSet as execution result, you will almost always want to implement a RecordExtractor, to be able to read the ResultSet in a managed fashion, with the CCI Connection still open while reading the ResultSet. Implementations of this interface perform the actual work of extracting results, but don't need to worry about exception handling. ResourceExceptions will be caught and handled ...
• RecordCreator: Callback interface for creating a CCI Record instance, usually based on the passed-in CCI RecordFactory. Used for input Record creation in CciTemplate. Alternatively, Record instances can be passed into CciTemplate's corresponding execute methods directly, either instantiated manually or created through CciTemplate's Record factory methods. Also used for creating default output Records in CciTemplate. This is useful when the JCA connector needs an explicit output Record instance, but no output Records should be passed into CciTemplate's execute methods.
• SingleConnectionFactory: A CCI ConnectionFactory adapter that returns the same Connection on all getConnection calls, and ignores calls to close . Useful for testing and standalone environemtns, to keep using the same Connection for multiple CciTemplate calls, without having a pooling ConnectionFactory, also spanning any number of transactions. You can either pass in a CCI Connection directly, or let this factory lazily create a Connection via a given target ConnectionFactory.
• InteractionCallback: Generic callback interface for code that operates on a CCI Interaction. Allows to execute any number of operations on a single Interaction, for example a single execute call or repeated execute calls with varying parameters. This is particularly useful for delegating to existing data access code that expects an Interaction to work on and throws ResourceException. For newly written code, it is strongly recommended to use CciTemplate's more specific execute variants.
• ConnectionCallback: Generic callback interface for code that operates on a CCI Connection. Allows to execute any number of operations on a single Connection, using any type and number of Interaction. This is particularly useful for delegating to existing data access code that expects a Connection to work on and throws ResourceException. For newly written code, it is strongly recommended to use CciTemplate's more specific execute variants.
• ConnectionFactoryUtils: Helper class that provides static methods to obtain CCI Connections from a ConnectionFactory, and to close Connections if necessary. Has special support for Spring-managed connections, e.g. for use with CciLocalTransactionManager. Used internally by CciTemplate, CCI operation objects and the CciLocalTransactionManager. Can also be used directly in application code.
• MappingRecordOperation: EIS operation object that expects mapped input and output objects, converting to and from CCI Records. Concrete subclasses must implement the abstract createInputRecord(RecordFactory, Object) and extractOutputData(Record) methods, to create an input Record from an object and to convert an output Record into an object, respectively.
• CciOperations: Interface that specifies a basic set of CCI operations on an EIS. Implemented by CciTemplate. Not often used, but a useful option to enhance testability, as it can easily be mocked or stubbed. Alternatively, the standard CCI infrastructure can be mocked. However, mocking this interface constitutes significantly less work.
• CciDaoSupport: Convenient super class for CCI data access objects. Requires a ConnectionFactory to be set, providing a CciTemplate based on it to subclasses. This base class is mainly intended for CciTemplate usage but can also be used when working with ConnectionFactoryUtils directly or with org.springframework.cci.object classes.
• EisOperation: Base class for EIS operation objects that work with the CCI API. Encapsulates a CCI ConnectionFactory and a CCI InteractionSpec. Works with a CciTemplate instance underneath. EIS operation objects are an alternative to working with a CciTemplate directly.
• InvalidResultSetAccessException: Exception thrown when a ResultSet has been accessed in an invalid fashion. Such exceptions always have a java.sql.SQLException root cause. This typically happens when an invalid ResultSet column index or name has been specified.
• ConnectionHolder: Connection holder, wrapping a CCI Connection. CciLocalTransactionManager binds instances of this class to the thread, for a given ConnectionFactory. Note: This is an SPI class, not intended to be used by applications.
• DelegatingConnectionFactory: ConnectionFactory implementation that delegates all calls to a given target ConnectionFactory. Abstract because it is meant to be to be subclasses, overriding specific methods that should not simply delegate to the target.
• RecordTypeNotSupportedException: Exception thrown when the creating of a CCI Record failed because the connector doesn't support the desired CCI Record type.
• SimpleRecordOperation: EIS operation object that accepts a passed-in CCI input Record and returns a corresponding CCI output Record.
| Home | Contact Us | Privacy Policy | Terms of Service |