db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Armin Waibel <arm...@apache.org>
Subject Re: [OJB 1.1] Initial version check in
Date Wed, 11 Aug 2004 10:25:25 GMT
Thomas Dudziak wrote:
>> Most factory classes now available via OJB.getFactories(), which returns
>> a Factories.java class instance. This class provide most used factories
>> (IdentityFactory, ConnectionManagerFactory, ConnectionFactoryFactory,
>> ...). Seems to me the easiest way to replace the singletons - Comments
>> are welcome.
> How many factories are there, anyway ? Could we merge some into other 
> objects, e.g. PBF into OJB.java or similar ?

First I have put most factories in OJB class, but to make OJB.java more 
clean I move them into a separate class. Seems to me a good idea to keep 
factories separate till you reworked the  OJB configuration.
Most factories used at initialization of PB instances.
We can move
- JdbcAccessFactory to PBF
- StatementManagerFactory to PBF
- IdentityFactory to PBF

But for each PC we create a separate PBF, thus for each PC we create the 
factories again (if we keep them in OJB Factory class only once) and 
each PBF has its own factory instances.

>> The ConnectionManager/ConnectionFactory/ConnectionFactoryFactory 
>> classes are reworked too.
>> Each PB instance was associated with an ConnectionManager (done in PB 
>> constructor). The ConnectionManager use the JCD of the associated PC 
>> (remember each PB was bind to one PC) to lookup a ConnectionFactory 
>> from the ConnectionFactoryFactory. So each JCD (defined in repository) 
>> represents one ConnectionFactory and different PC can share the same JCD
>> respectively the same ConnectionFactory. In the connection-pool 
>> element it is now possible to declare the ConnectionFactory 
>> implementation, thus it will be possible to use a separate 
>> ConnectionFactory implementation class for each JCD.
> So we should have something like a connectionfactory-class attribute at 
> the JCD ?

I add an 'connection-factory' attribute to 'connection-pool' element. 
But this was only made to make it work. I think we should refactor the 
connection-pool element, because most attributes are implementation 
dependent. Think I will be a better approach to pass the proprietary 
attributes via custom-attribute.

* Attributes supported by ConnectionFactoryPooledImpl + 
** only supported by ConnectionFactoryDBCPImpl and deprecated. Should be 

<!ATTLIST connection-pool
     connection-factory              CDATA #IMPLIED
     *maxActive                       CDATA #IMPLIED
     *maxIdle                         CDATA #IMPLIED
     *maxWait                         CDATA #IMPLIED
     *minEvictableIdleTimeMillis      CDATA #IMPLIED
     *numTestsPerEvictionRun          CDATA #IMPLIED
     *testOnBorrow                    (true|false) #IMPLIED
     *testOnReturn                    (true|false) #IMPLIED
     *testWhileIdle                   (true|false) #IMPLIED
     *timeBetweenEvictionRunsMillis   CDATA #IMPLIED
     *whenExhaustedAction             (0|1|2) #IMPLIED
     validationQuery                 CDATA #IMPLIED

     **logAbandoned                    (true|false) #IMPLIED
     **removeAbandoned                 (true|false) #IMPLIED
     **removeAbandonedTimeout          CDATA #IMPLIED

Maybe it will be better to rename connection-pool to connection-factory 
and specify the connection-factory class by a 'name' or 'class' attribute.

> I was wondering how the OJB configuration (OJB.properties) should be 
> handled then. My initial idea is like this:
> The complete configuration is done via the OJB object and sub-objects. 
> For backwards-compatible operation, a static method is probably needed 
> (e.g. PersistenceBrokerFactory.defaultPersistenceBroker() ) which 
> creates a static OJB instance, and also configures this instance from 
> OJB.properties

I add a static method PBF#setOjb(...) to set the OJB instance. So user 
has to set this instance at startup of OJB.

> A helper configurator bean (e.g. OJBConfigurator) can be used to 
> configure an OJB object by reading a properties file and setting the 
> properties accordingly. It translates (for compatibility) the current 
> unqualified property names to fully qualified ones, and uses these 
> qualified properties to intialize the factories, create instances as 
> needed, and set properties on them.
> Does that sound reasonable ?

Sounds good. So all Factories have to know about OJB instance?


> Tom
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org

To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org

View raw message