| Package Name | Comment |
| org.jpox |
This package provides classes that are typically client-facing. That is, they are used as the primary interface
to JPOX "core".
|
| org.jpox.api |
Provides adapters for different client APIs, like JDO, JPA and so on.
|
| org.jpox.cache |
This package provides classes implementing caching within JPOX.
There are 2 caches in JPOX.
The first is within the PersistenceManager
and is the Level 1 Cache. There are 3 available implementations
of a Level 1 Cache here :- SoftRefCache, WeakRefCache
and HardRefCache. They provide varying degrees of object retention
during the garbage collection process.
The second is across multiple PersistenceManagers within the same
PersistenceManagerFactory, and is the Level 2 Cache. There is
one implementation of a Level 2 Cache here :- DefaultLevel2Cache.
Alternatively, there is the TangosolCache plugin that can be used
in conjunction with the commercial Tangosol Coherence product.
|
| org.jpox.exceptions |
This package provides exceptions thrown by the core (client-facing) parts of the JPOX system.
|
| org.jpox.identity |
Package defining object identity classes. These are used where an API doesnt define its own inbuilt identities.
|
| org.jpox.jdo |
Package providing components specific to JDO persistence.
|
| org.jpox.jdo.exceptions |
Package containing exceptions thrown that are specific to JDO persistence
|
| org.jpox.jdo.metadata |
Package providing classes specific to processing of JDO XML MetaData and annotations, building on
the generic code under the package org.jpox.metadata
|
| org.jpox.jdo.state |
Definition of lifecycle states when providing JDO persistence
|
| org.jpox.jta |
Package providing handlers for JTA transactions
|
| org.jpox.management |
This package provides classes for management
|
| org.jpox.management.runtime | |
| org.jpox.metadata |
Provides classes representing the MetaData for files, packages, classes, fields, containers, etc.
Structured to map to the JDO2 Meta-Data file structure, though also now maps to the JPA Meta-Data structure
approximately.
Key aspects of this package are
- MetaDataManager is the entry point into this package. A call is typically made to getMetaDataForClass
and the MetaDataManager will take care of finding the MetaData, parsing any files, and populating the MetaData.
- MetaDataMerger is responsible for merging annotations with metadata, and JDO MetaData with ORM MetaData
- FileMetaData is the top level of a metadata representation, represening the actual file. It will contain
metadata for a series of packages, etc. The components are laid out in a tree
- ClassMetaData is the most used class, and is the representation of the persistence of a class.
It contains a series of FieldMetaData/PropertyMetaDataobjects, representing the fields and properties
of the class.
The "data" classes have a lifecycle, being created, then populated, and finally initialised. When a file is read in
all classes are read and populated at that time.
|
| org.jpox.metadata.annotations |
Provides classes for parsing annotations input data and converting into org.jpox.metadata input data for
the JPOX persistence process.
|
| org.jpox.metadata.xml |
Provides classes for parsing XML input data and converting into org.jpox.metadata input data for
the JPOX persistence process.
|
| org.jpox.plugin |
Package providing the plugin mechanism utilised by JPOX. The mechanism is based on OSGi technology and provides
support for using the Eclipse plugin registry as well as a non-managed registry when not operating under Eclipse.
|
| org.jpox.sco |
Provides implementations of the wrappers for the mutable Second Class Objects (SCO's) supported by JPOX.
Please refer to section 6.3 of the JDO 1.0 spec.
|
| org.jpox.sco.exceptions |
Provides exceptions that can be thrown when handling Second Class Objects (SCO's).
|
| org.jpox.sco.queued |
This package provides classes allowing SCO containers to queue mutating commands (add, remove, clear etc).
When a SCO is operating in "queued" mode it saves the operation for processing at some later point.
This is to cater for optimistic transactions where we want to delay all datastore updates until the
commit stage and do it later.
All operations implement QueuedOperation and have a perform() method to actually perform the operation on
the backing store it was required for.
|
| org.jpox.sco.simple |
Provides implementations of the "simple" wrappers for the mutable Second Class Objects (SCO's) supported by JPOX.
Please refer to section 6.3 of the JDO 1.0 spec.
This "simple" form of the SCO wrapper has a delegate and intercepts any mutating methods, marking the field as dirty.
There is no "backing store" or lazy loading like in the "full" wrapper.
|
| org.jpox.state |
Provides classes relating to the life cycle state of a persistable object. Refer to section 5.5 of the JDO 1.0 specification.
|
| org.jpox.store |
Definition of the storage of the classes. The StoreManager controls the persistence to the datastore. This package provides generic functionality for all datastore types. Each datastore type will have its own subpackage(s) (e.g rdbms) that cater for the specifics of that datastore.
The DatastoreAdapter represents the interface to that datastore. This is typically extended for particular datastore types (e.g RDBMS) to provide the specifics for that datastore.
Each class is persisted to a datastore table, and each persistable field is mapped to a datastore column. With RDBMS, these are ClassBaseTable, and Column.
Queries are mapped to the datastore type in question. With the case of RDBMS, we allow 3 query languages ... JDOQL, SQL, and JPOXSQL. With others we will likely just allow JDOQL. The QueryStatement currently contains RDBMS functionality and will be subclassed when we have alternative datastores.
|
| org.jpox.store.exceptions |
Provides exceptions that can be thrown when communicating with the datastore.
|
| org.jpox.store.expression |
This package provides a series of expressions and literals used in the conversion of a JDOQL query into the resultant SQL that
is required to be executed in the datastore. The components are finely grained. These expressions are used within, for example, a QueryStatement.
|
| org.jpox.store.fieldmanager |
Package providing managers for fields which give a mechanism for navigating through fields of a class and
performing operations based on the type of the field.
See PersistenceCapable.ObjectIdFieldManager in the JDO specification.
|
| org.jpox.store.mapping |
Package providing mappings for all supported Java types in JPOX. A JavaTypeMapping provides a mapping from the Java type
to the associated RDBMS type(s). At the class side we have a field, and at the datastore side we have datastore column(s).
|
| org.jpox.store.poid |
POID - Persistent Id Generation.
This package provides a series of classes providing generation of identities.
The entry point is PoidManager which is used for creating and managing the
various PoidGenerators. All generators are known by a symbolic name and can
be accessed from the PoidManager via that name once created. All PoidGenerators
copy the JDO2 "javax.jdo.datastore.Sequence" interface method names and hence
can be easily extended and implement that interface.
|
| org.jpox.store.query |
Package providing generic methods for use by queries.
Queries such as JDOQL will typically be implemented by datastore packages since
each has its own internal query language.
|
| org.jpox.store.scostore |
Package providing backing store definitions for SCO stores. Intended to be implemented
by datastore specific stores.
|
| org.jpox.transaction | |
| org.jpox.util |
Provides utility classes used in the implementation that don't fit in a particular functional part of the system.
|