|
|
Hi folks,
I've just checked in my changes so that OJB uses the ComponentContainer
instead of the previous Factory/Configurator strategy (btw, I would have
done that gradually but honestly even after I've implemented thos
changes I still don't know how I could have introduced the
ComponentContainer gradually).
As a sideeffect I had to remove most of the static calls (e.g.
PBF#defaultPersistenceBroker etc.), so OJB should be a lot nearer to the
point where different OJB instances can run within the same thread.
There are only a few static calls/caches left, e.g. the LocalTxManager.
I also had to make a few 'semantic' changes:
* StatementsForClassFactory created a new SqlGenerator object for a new
StatementsForClassIF instance. This is now moved to the PC so that the
class descriptors are now independent from the PB.
* SqlGenerator instances are no longer cached (were cached per Platform
in SqlGeneratorFactory), and creation is moved up into the PC (as the
SqlGenerator is independent of the PB); everytime a PB instance is
created it gets the same sql generator instance ("singleton" per PC)
* PersistenceBrokerFactoryDefaultImpl is no longer dependant upon
PBPoolInfo but only upon PoolConfiguration, though the PBPoolInfo class
is defined as the default implementation for PoolConfiguration
* The specialized collection proxies have now their own interfaces
(ListProxy, SetProxy) so configuration of the implementation classes is
easer.
* RowReader instances are now created in the PB (declared by interface
PBInternal) which delegates to its PC (row reader objects are
independent of the PB). Also the row reader instances are no longer
stored in the class descriptors but in the PC.
* The object creation (row reader) is now externalized into an object
factory which extends the ObjectFactory idea from Leandro (which are now
called ObjectCreator); the object factory is now a service of the PC
that is used by the row reader, and there object creators can be
registered for individual types (the corresponding setting in the class
descriptor is no longer necessary). This allows for definition of a
ObjectFactory per PersistenceConfiguration and ObjectCreators per
persistent class
* The old DListImpl with related classes are removed, and the new
DListImpl_2 has been renamed to DListImpl. Similar, the DMapImpl has
been reworked in a way similar to the new DListImpl.
The "D" classes also no longer generate ids on their own (which also
means removal of a static dependency to the PersistentFieldFactory)
* PersistentFieldFactory is no longer static since it is now only used
within the MetadataManager which means it can be used as an instance
* Removed AnonymousObjectReferenceDescriptor as the same function can
also be performed by a plain ObjectReferenceDescriptor
* Removed setPersistentField(Class c, String fieldname) method from the
descriptors in favor of the setPersistentField(PersistentField) so that
the field objects are now only created within the RepositoryPersistor
* Introduced the PersistenceBrokerInternal interface into the PB
hierarchy; all PB implementations should now implement the PBInternal
interface (which extents the PB interface). Some internal services are
declared in this new interface (batch manager, row reader creation)
* ProxyFactory is no longer static which makes it necessary to hold one
instance per OJB instance. Also the VirtualProxy.createProxy method was
moved to PBImpl because it must reach the ProxyFactory instance (and
every usage of this method is within reach of a PBImpl instance).
* Introduced ImplementationInternal interface (similar to PBInternal)
that provides access to additional services like the tx manager and the
lock manager
* User-defined proxies that derive from VirtualProxy now get an
IndirectionHandler instance, not an InvocationHandler
A few things are left to be done:
* removal of the old PersistentField implementations
* a consistent naming sceme of the interfaces is necessary
(PersistenceBrokerFactoryIF vs. PersistenceBroker vs.
IRemovalAwareCollection)
* removal of the remaining static calls within OJB
regards,
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@xxxxxxxxxxxxx
For additional commands, e-mail: ojb-dev-help@xxxxxxxxxxxxx
|
|