[email protected]
[Top] [All Lists]

[OJB 1.1] Reworked OJB to use the ComponentContainer

Subject: [OJB 1.1] Reworked OJB to use the ComponentContainer
From: Thomas Dudziak
Date: Sun, 14 Nov 2004 11:09:04 +0100
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


To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

<Prev in Thread] Current Thread [Next in Thread>
  • [OJB 1.1] Reworked OJB to use the ComponentContainer, Thomas Dudziak <=