Mailing-List: contact ojb-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "OJB Developers List" <ojb-dev@db.apache.org>
Message-ID: <3F8D5ED2.2000906@more.net>
Date: Wed, 15 Oct 2003 09:50:58 -0500
From: Chris Giordano <giordano@more.net>
Reply-To: giordano@mail.more.net
User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.4) Gecko/20030630
MIME-Version: 1.0
To: ojb-dev@db.apache.org
Subject: OJB usability - part 4 of 5: need for refactoring
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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.

Our intention to use OJB has been in the context of running within the 
Tomcat
application server enabled with the Security Manager in a virtual hosting
environment.  Therefore, OJB was installed globally within Tomcat (i.e.
installed in the container's common/lib repository location) to provide
access to the persistence layer across multiple web applications.  But, 
we also
needed to restrict access to specific Broker keys used by the web 
applications
per virtual host.

We accomplished this by creating wrapper classes that allowed a web
application access to a Persistence Broker via the wrapper.  The wrapper was
granted permission to handle Persistence Broker functionality on behalf 
of the
web application.  And, the web application was disallowed direct access to
Persistence Broker functionality.

This should have been much easier than it turned out to be.  Though we
succeeded at writing the wrapper functionality, there were two areas of
the OJB codebase that made the process frustrating.

First, the class packaging needs refactoring.  To disallow direct access to
the PersistenceBroker via the web application, we originally wanted to
restrict access by the web applications to all classes in the
org.apache.ojb.broker package (see the java.security file).  But, there were
classes in sub-packages that we needed to allow access to via the web
application.  For example, Query and Criteria classes.  These classes are
functionally unrelated to a PersistenceBroker and, therefore, don't belong
in a sub-package of broker.  They are consumed by a PersistenceBroker 
but are
created and used as completely independent entities.

We created a wrapper class for org.apache.ojb.odmg.OJB which itself makes a
call to the method: PersistenceBrokerFactory.createPersistenceBroker().
But, strangely, the dependent DatabaseImpl class does this again as does
PBCapsule and TransactionImpl.  Largely, the OJB implementation is a 
composition
of classes that ar all performing repetitive code.  Several calls to
createPersistenceBroker() all during the execution of just a single query?
There is an implication here that some refactoring is in order.

For our Security Manager implementation, we had to create more than one
wrapper class for the OQL implementation when one should have accomplished
the task.

Though we've backed out of using OJB entirely, we'd be happy to provide 
back to
the project the wrapper classes described here that were developed using the
Security Manager with OJB.

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