All Packages from ojb.broker.* to ojb.tools.*

Home >> All

•	ojb.broker.* (208)	•	ojb.connector.* (6)	•	ojb.jdo.* (15)	•	ojb.odmg.* (63)
•	ojb.server.* (28)	•	ojb.soda.* (4)	•	ojb.tools.* (32)

Package Samples:

• ojb.broker.util.configuration.impl: This package contains classes that provide the OJB configuration API.
• ojb.broker.accesslayer
• ojb.broker
• ojb.broker.metadata
• ojb.server
• ojb.server.states
• ojb.server.lockstrategy
• ojb.odmg.lockstrategy
• ojb.odmg
• ojb.odmg.states
• ojb.odmg.collections
• ojb.odmg.oql
• ojb.broker.query
• ojb.jdo.metadata
• ojb.jdo.state
• ojb.jdo
• ojb.odmg.locking
• ojb.soda
• ojb.tools.swing
• ojb.tools.mapping.reversedb.gui.actions

Classes:

• LockManagerDefaultImpl: The OJB default implementation of a Locking mechanism. This Implementation supports 4 transaction isolation levels as specified in the interface ojb.broker.metadata.IsolationLevels: public final int IL_READ_UNCOMMITTED = 0; public final int IL_READ_COMMITTED = 1; public final int IL_REPEATABLE_READ = 2; public final int IL_SERIALIZABLE = 3; Isolationlevels can be adjusted per class. The proper lockhandling is done in the respective LockStrategy implementation. This default implementation provides persistent Locks that are stored in a special database table. To keep the locks in the database and ...
• TransactionAware: TransactionAware is an interface that can be implemented to provide hooks into the Transaction interface provided by ObJectBridge. Only objects which have a write lock acquired on them can participate in a transaction. To kill a transaction, implement beforeCommit() and throw a TransactionAbortedException. This will force the entire transaction to rollback. To rebuild an object after a rollback use the afterAbort() call. This is a good place to populate transient or other variables. beforeAbort and afterCommit are there for informational purposes. Here are some common ways you can expect this interface ...
• TransactionAware: TransactionAware is an interface that can be implemented to provide hooks into the Transaction interface provided by ObJectRelationalBridge. Only objects which have a write lock acquired on them can participate in a transaction. To kill a transaction, implement beforeCommit() and throw a TransactionAbortedException. This will force the entire transaction to rollback. To rebuild an object after a rollback use the afterAbort() call. This is a good place to populate transient or other variables. beforeAbort and afterCommit are there for informational purposes. Here are some common ways you can expect ...
• Query: represents Queries that can be used by the OJB PersistenceBroker to retrieve Objects from the underlying DB. Until now there are two implementations: 1. QueryByCriteria, represents SELECT * FROM ... WHERE ... queries 2. QueryByExample, uses Example objects or OIDs as templates for the db lookup there could additional implementations, e.g for user defined SQL For the Criteria API I reused code from the COBRA project, as you will see by their class comments. I removed all stuff that relies on knowlegde of the DataDictionary or MetaData layer. The Query and Criteria classes thus don't know how to ...
• ObjectCache: The ObjectCache stores all Objects loaded by the PersistenceBroker from a DB. When the PersistenceBroker tries to get an Object by its Primary key values it first lookups the cache if the object has been already loaded and cached. Using an ObjectCache has several advantages: - it increases performance as it reduces DB lookups. - it allows to perform circular lookups (as by crossreferenced objects) that would result in non-terminating loops without such a cache. - it maintains the uniqueness of objects as any Db row will be mapped to exactly one object. This interface allows to have userdefined ...
• ObjectCache: The ObjectCache stores all Objects loaded by the PersistenceBroker from a DB. When the PersistenceBroker tries to get an Object by its Primary key values it first lookups the cache if the object has been already loaded and cached. Using an ObjectCache has several advantages: - it increases performance as it reduces DB lookups. - it allows to perform circular lookups (as by crossreferenced objects) that would result in non-terminating loops without such a cache. - it maintains the uniqueness of objects as any Db row will be mapped to exactly one object. The cache uses soft-references which allows ...
• ObjectCacheDefaultImpl: The ObjectCache stores all Objects loaded by the PersistenceBroker from a DB. When the PersistenceBroker tries to get an Object by its Primary key values it first lookups the cache if the object has been already loaded and cached. Using an ObjectCache has several advantages: - it increases performance as it reduces DB lookups. - it allows to perform circular lookups (as by crossreferenced objects) that would result in non-terminating loops without such a cache. - it maintains the uniqueness of objects as any Db row will be mapped to exactly one object. The cache uses soft-references which allows ...
• SequenceManager: SequenceManagers are responsible for creating new unique ID's for primary columns containing integer or String values. There is a simple Default implementation SequenceManagerDefaultImpl that provides rudimentary unique numbering. SequenceManager Objects are obtained from a Factory SequenceManagerFactory. This Factory can be configured to provide instances of user defined implementors of this interface. SequenceManagers should be aware of extends, that is: if you ask for an uid for an Interface with several implementor classes, or a baseclass with several subclasses the returned uid should be unique ...
• RepositoryTags: this class maintains a table mapping the xml-tags used in the repository.dtd to their corresponding ids used within OJB. This table is used in 1. the RepositoryXmlHandler to identify tags on parsing the repository.xml in a large switch statement. 2. in the RepositoryPersistor to get the proper tag for a given XmlCapable id during assembling the repository.xml for output. Important note: This class is the only place where XML tags from the repository.dtd are maintained. All usages of these tags within OJB must use this table to ease changes of the DTD.
• QueryByExample: represents a search by example. "find the article with id 7" could be represented as: Article example = new Article(); example.setId(7); Query qry = new QueryByExample(example); The PersistenceBroker can retrieve Objects by examples as follows: PersistenceBroker broker = PersistenceBrokerFactory.createPersistenceBroker(); Collection col = broker.getObjectByQuery(qry); This Class can also handle working with OJB Identity objects: "find the article with Identity xyz" could be represnted as Identity xyz = new Identity(example); Query qry = new QueryByExample(xyz);
• Log4jLoggerImpl: This is a Logger implementation based on Log4j. It can be enabled by putting LoggerClass=ojb.broker.util.logging.Log4jLoggerImpl in the OJB .properties file. If you want log4j to initialize from a property file you can add LoggerConfigFile=log4j.properties to the ojb.properties file. the logger only initializes log4j if the application hasn't done it yet You can find sample log4j.properties file in the log4j web site http://jakarta.apache.org/log4j in the javadoc look for org.apache.log4j.examples
• LockManager: This interface declares the functionality of the OJB internal Locking mechanism. A default implementaion LockManagerDefaultImpl is provided. This implementaion keeps distributed locks in the database. The locking mechanisms thus involves a lot of database lookups and writes. For some environments this solution may not be adequate. OJB allows to provide user defined implementations of this interface. To activate a user defined LockManagerDefaultImpl it must be configured in the OJB.properties file.
• MetaObjectCacheImpl: This cache makes it possible to have separate cache implementations for each class. When an object is cached / looked up the MetaObjectCacheImpl checks if a special ObjectCache has been set for this class. It recursively looks up the superclasses of the given object to look for a special cache. If no special cache is found it uses the ObjectCacheDefaultImpl to cache the object. It is also possible to switch off caching for a specific class by setting the object cache to null.
• RsIterator: RsIterator can be used to iterate over a jdbc ResultSet to retrieve persistent objects step-by-step and not all at once. In fact the PersistenceBroker::getCollectionByQuery(...) method uses a RsIterator internally to build up a Collection of objects NOTE: this code uses features that only JDBC 2.0 compliant Drivers support. It will NOT work with JDBC 1.0 Drivers (e.g. SUN's JdbcOdbcDriver) If you are forced to use such a driver, you can use code from the 0.1.30 release.
• QueryByCriteria: represents a search by criteria. "find all articles where article.price > 100" could be represented as: Criteria crit = new Criteria(); crit.addGreaterThan("price", new Double(100)); Query qry = new QueryByCriteria(Article.class, crit); The PersistenceBroker can retrieve Objects by Queries as follows: PersistenceBroker broker = PersistenceBrokerFactory.createPersistenceBroker(); Collection col = broker.getCollectionByQuery(qry); Creation date: (24.01.2001 21:45:46)
• QueryByMtoNCriteria: represents a search by criteria. "find all articles where article.price > 100" could be represented as: Criteria crit = new Criteria(); crit.addGreaterThan("price", new Double(100)); Query qry = new QueryByCriteria(Article.class, crit); The PersistenceBroker can retrieve Objects by Queries as follows: PersistenceBroker broker = PersistenceBrokerFactory.createPersistenceBroker(); Collection col = broker.getCollectionByQuery(qry); Creation date: (24.01.2001 21:45:46)
• ReadUncommittedStrategy: The implementation of the Uncommited Reads Locking strategy. This strategy is the loosest of them all. It says you shouldn't need to get any Read locks whatsoever, but since it will probably try to get them, it will always give it to them. Locks are obtained on modifications to the database and held until end of transaction (EOT). Reading from the database does not involve any locking. Allows: Dirty Reads Non-Repeatable Reads Phantom Reads
• ManageableCollection: OJB can handle java.util.Collection as well as user defined collection classes as collection attributes in persistent classes. In order to collaborate with the OJB mechanisms these collection must provide a minimum protocol as defined by this interface ManageableCollection. The methods have a prefix "ojb" that indicates that these methods are "technical" methods, required by OJB and not to be used in business code.
• PermanentObjectCacheImpl: This is an implementation of the ObjectCache interface that caches all objects in memory regardless of memory consumption. It is not intended to be used as the main ObjectCache but only to be used in conjunction with the MultipleObjectCacheImpl for special object classes. It should only be used for objects which are few in number and not too big in size but expensive to re-create from the DB.
• SequenceManager: A simple SequenceManager. This class is responsible for creating new unique ID's for primary columns containing integer values. The SequenceManager is aware of extends, that is: if you ask for an uid for an Interface with several implementor classes, or a baseclass with several subclasses the returned uid will unique accross all tables representing objects of the extent in question.
• Configurator: Interface f�r Konfiguratoren, sprich Objekte, die andere Objekte konfigurieren k�nnen. Ablauf: Eine Komponente (ein Objekt) holt sich einen Konfigurator (z.B. �ber eine Factory) und bittet den Konfigurator "lieber Konfigurator konfiguriere mich": Configurable obj = ... Configurator configurator = new FileBasedConfigurator(); configurator.configure(obj);
• SequenceManagerDefaultImpl: A simple SequenceManager. This class is responsible for creating new unique ID's for primary columns containing integer values. The SequenceManager is aware of extends, that is: if you ask for an uid for an Interface with several implementor classes, or a baseclass with several subclasses the returned uid will unique accross all tables representing objects of the extent in question.
• FieldConversion: FieldConversion declares a protocol for type and value conversions between persistent classes attributes and the columns of the RDBMS. The default implementation does not modify its input. OJB users can use predefined implementation and can also build their own conversions that perform arbitrary mappings. the mapping has to defined in the xml repository in the FieldDescriptor.
• SearchFilter: Class to build selection criteria for searches Search Filter Class (Abstract) This class builds a search filter tree, specifing how names and values are to be compared when searching a database. It just builds internal structures, and needs to be extended to return a search filter string or other object that can be used by the database to perform the actual search.
• PersistentObject: The PersistenceBroker allows to make objects of arbitrary classes persistent. They don't have to be derived from PersistentObject. But when Business-objects are not to be derived from a special class it may be a good idea to use PersistentObject as the base class. Persistent Objects manages the persistence brokers functionalities with convenient wrapper methods

Home | Contact Us | Privacy Policy | Terms of Service