DescriptorRepository instances per thread: // e.g we get a coppy of the global repository DescriptorRepository dr = mm.copyOfGlobalRepository(); // now we can manipulate the persistent object metadata of the copy ...... // set the changed repository for this thread mm.setDescriptor(dr); // now let this thread lookup a PersistenceBroker instance // with the modified metadata // all other threads use the global metadata PersistenceBroker broker = Persis......Note: Change metadata before lookup the {@link org.apache.ojb.broker.PersistenceBroker}instance for current thread, because the metadata was bound to the PB at lookup.
How to use different metadata profiles
MetadataManager was shipped with a simple mechanism to add, remove and load different persistent objects metadata profiles (different {@link org.apache.ojb.broker.metadata.DescriptorRepository}instances) in a per thread manner. Use
Metadata can be loaded into the MetaDataManager in two ways
Acts as a registry of metadata so that metadata files don't need to be parsed multiple times. MetaData is stored as a FileMetaData, which contains PackageMetaData, which contains ClassMetaData, and so on. This maps exactly to the users model of their metadata. The users access point is getMetaDataForClass() which will check the known classes without metadata, then check the existing registered metdata, then check the valid locations for metdata files. This way, the metadata is managed from this single point.
Maintains a list of all classes that have been checked for MetaData and don't have any available. This avoids the needs to look up MetaData multiple times finding the same result. Currently this list is for all ClassMetaData objects keyed by the class name.
Users can register interest in knowing when metadata for classes are loaded by registering a listener using the addListener method. This will then notify the listener when metadata for any class is initialised. This provides the opportunity to reject the metadata where particular features are not supported. For example a StoreManager could register a listener where it doesn't support datastore identity and throw an InvalidMetaDataException. This would then filter back out to the user for the operation they invoked
A MetaDataManager can be "initialised" to start with particular MetaData. This is typically performed when the operation has a "persistence-unit", which defines the classes/jars/mapping-files to use. Alternatively, it can be initialised using a set of classes and mapping-files (for use by SchemaTool and the Enhancer when specifying the files as input).
Acts as a registry of metadata so that metadata files don't need to be parsed multiple times. MetaData is stored as a FileMetaData, which contains PackageMetaData, which contains ClassMetaData, and so on. This maps exactly to the users model of their metadata. The users access point is getMetaDataForClass() which will check the known classes without metadata, then check the existing registered metdata, then check the valid locations for metdata files. This way, the metadata is managed from this single point.
Maintains a list of all classes that have been checked for MetaData and don't have any available. This avoids the needs to look up MetaData multiple times finding the same result. Currently this list is for all ClassMetaData objects keyed by the class name.
TODO Update MetaDataManager to be able to share ClassMetaData with other MetaDataManager so we need a central (singleton/static) registry that allows such communication. @version $Revision: 1.170 $The class is synchronized using in internal ReentrantReadWriteLock.
All metadata providers are kept in two groups - available providers - which contain all the ones users have registered, and active providers - all those which passed validation. List of active providers is updated during each refresh. @author Vladimir Schaefer
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |