db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Armin Waibel <ar...@code-au-lait.de>
Subject Re: OJB usability - part 3 of 5: lack of extensibility
Date Wed, 15 Oct 2003 18:16:11 GMT
Hi Chris,

that's something I don't understand. Why you don't send a
patch to dev-list asking to introduce such a method when needed?
This would be the way to make an open source project become
better.

regards,
Armin



On Wed, 15 Oct 2003 09:50:51 -0500, Chris Giordano <giordano@more.net> 
wrote:

> OJB developers:
>
> The following feedback intends to provide constructive comments to the
> OJB developers to improve the project as a whole.  The experiences and
> observations are meant to stimulate development of world class software.
> An open source dB persistence layer solution is needed and OJB may be
> positioned to provide this in the future.
>
> During our development with OJB, we found a need to create a custom
> PersistenceBroker factory class.  It appeared this was going to be really
> easy given that the class was pluggable and configurable through the
> OJB.properties file.
>
> Specifically, we wanted to customize the behavior of OJB when the
> PersistenceBrokerFactoryDefaultImpl.createPersistenceBroker() method was
> called.  Unfortunately, we were not able extend this class and override 
> this
> one single method.  Though this method itself has public scope, it uses a
> private variable directly for referencing the brokerPool.  Here's the 
> excerpt
> directly from the source:
>
> public PersistenceBroker createPersistenceBroker(PBKey pbKey)
> throws PBFactoryException
> {
>   ...
>
>   /*
>    * brokerPool is accessed directly in a public method
>    * and it has private scope
>    */
>   broker = new PersistenceBrokerHandle(
>                    (PersistenceBroker)brokerPool.borrowObject(pbKey));
>   ...
> }
>
> There is no protected method for acquiring the reference to the 
> brokerPool for
> our replacement implementation and we were attempting to use OJB without
> modifying the codebase.  As a result, we were forced to come up with a
> different solution to our design.  Needless to say, we were very 
> disappointed
> to realize that a class such as this-- pluggable by design, did not 
> allow such
> a simple re-use of existing code.
>
> Generally, we would have liked to see the OJB classes designed with the 
> thought
> in mind that the object oriented hierarchy they are built upon will be 
> exploited
> efficiently for code re-use.
>
> Chris Giordano
> giordano@more.net
>
>
>
> ---------------------------------------------------------------------
> 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


Mime
View raw message