Castor JDO Refactoring Project Plan
Documentation Author(s): Bruce Snyder
Introduction Tasks Modularization of Castor JDO Logging Refactoring CTF-JDO Improvements Refactor for Correct Use of JDBC Tx Isolation Levels Query Engine Refactoring Refactor the SQLTypeConvertors Query Externalization ClassMolder Refactoring J2EE Transaction Factory Possible TransactionContext Replacement Cache Engine Refactoring Polymorphism Integrated Connection Pooling JCA Research Logos Timestampable Dynamic Proxy Must Fix Bugs Javadoc improvements
Introduction
Below is a list of tasks that have been identified for refactoring
in Castor JDO. This list is continually evolving and should be checked
often. There are no scheduled release dates for these items. This
is because Castor JDO is entirely a volunteer effort and team members
contribute in their spare time. Some of these tasks are in progress
and some have not been started at all.
There is always plenty of work to be done. If you would like to
participate, please let us know. If you see a task that you would
like to work on please let us know. I you see a task that you would
like to work on but has already been assigned to someone, that doesn't
mean that you can't help out or even take it over. Simply contact the
JDO project leader (available
here).
Tasks
Modularization of Castor JDO
Description:
Castor is very tightly coupled in it's design. This tight coupling
leads to maintainence trouble, difficult to understand code, etc.
Volunteer:
Status: not started
Date Started:
Notes:
See the mail list threads titled
Castor JDO Status and
Strategy Proposal.
These threads are especially long and tend to be broken on
mail-archive.com. But there are some very good ideas amongst these two
threads concerning the modularization of Castor JDO.
This is a high-level architectural change that includes many of the
items in this list.
Logging Refactoring
Description:
Switching the logging mechanism in Castor
over to using the
Jakarta Commons Logging with Log4J as the default logger.
Not only will this help to improve the logging quality, but it will
also allow users to choose their logging framework of choice.
Volunteer: Bruce Snyder
Status: completed
Date Started: 5 May 2003
Notes:
Not sure if Jakarta Commons Logging should be used in Castor
because of the inability to configure some finer features in Log4J.
See this
article for some info. This article may be talking about
programmatic configuration of Log4J which I'm not really worried
about. All of the configuration in Castor will take place in a
properties or XML file.
Post Mortem:
Jakarta Commons Logging was used with Log4J as the default logger. Now
the amount of logging just needs to be increase and configurations
offered in the default properties files for ease of disabling stuff
that's spewing. I'll be adding a class to support the TRACE level as
well.
CTF-JDO Improvements
Description:
Writing test cases is a critical effort to the
evolution of Castor JDO. All bug fixes and new functionality must contain
test cases unless the bug fix is trivial. All test cases are written
using the Castor Test Framework for JDO
(CTF-JDO).
The verison of JUnit used by Castor is
quite outdated (version 3.5). This needs to be updated to the latest
version (as of this writing, version 3.8.1). There is a certain amount
of work involved with this in changing all assert() calls to the
newer, more specific assert calls (e.g. assertTrue(), assertEquals(),
assertNull(), assertNotNull(), etc.). Also look into the use of
Log4Unit as opposed
to JUnit. Log4Unit is an extension to JUnit that provides a logging
component to JUnit to provide better logging for both failures and
successes.
In addition to using JUnit, a database specific extension to JUnit
called DbUnit should be
considered. DbUnit helps to manage test data sets by
importing/exporting flat XML data sets to/from a database for each
test or set of tests being executed.
Volunteer: Bruce Snyder
Status: not started
Date Started:
Notes:
Refactor for Correct Use of JDBC Tx Isolation Levels
Description:
Currently Castor JDO does not make any use of JDBC tx isolation levels
and this needs to be corrected.
Volunteer:
Status:
Date Started:
Notes:
This impacts Connection duration and needs to be investigated further.
Query Engine Refactoring
Description:
The Castor OQL engine should be refactored to make us of a parser
generator like ANTLR or JavaCC.
This will make maintenance and adding features incredibly easier.
Volunteer: Paul Botta
Status: ANTLR implemenation complete
Date Started:
Notes:
Many thanks to Paul Botta for his hard work on the ANTLR implemenation.
Now this implementation just needs some tests to prove it so that it can
be committted it to CVS.
This layer should also be made pluggable allowing one or more query
engines to plugged in simultaneously (e.g. OQL, XQuery, EJBQL, etc.).
The tests.jdo.OqlTests class needs to be completed before
this work can take place. This will provide a baseline before the
removal of the current OQL engine.
Tranql may be used to achieve this task. As a side affect, Tranql may
be also do a couple other jobs as well (e.g. caching and transaction
context). There will also be a programmtic query API for this.
Refactor the SQLTypeConvertors
Description:
The SQLTypeConvertors inner class of SQLTypes should be refactored to
make it easier to plug in additional convertors.
Volunteer:
Status: not started
Date Started:
Notes:
Query Externalization
Description:
Castor should include a mechanism for queries to be externalized in the
object mapping descriptor.
Volunteer:
Status: not started
Date Started:
Notes:
This would allow for named queries that do not require recompilation
for changes. These queries would be included automatically via the
Castor XML unmarshalling of the object mapping descriptor via the
<includes> element.
This may not be able to be accomplished at all with new programmtic
query API.
ClassMolder Refactoring
Description:
The ClassMolder should be broken up into several classes to make use
of a dual strategy pattern.
Volunteer:
Status: not started
Date Started:
Notes:
The relationship type (e.g. one-to-one, one-to-many, many-to-many) is
the first strategy layer. The implementation type (e.g. interface,
abstract, concrete) is the second strategy layer.
J2EE Transaction Factory
Description:
In 2002 I started adding an API for a TransactionManagerFactory so that
Castor JDO can make use of a J2EE container's transaction manager
(e.g. JBoss, Weblogic, Websphere, etc.).
Volunteer: Werner Guttmann/Bruce Snyder
Status: completed
Date Started: Apr 2004
Notes:
Possible TransactionContext Replacement
Description:
Investigate whether the TransactionContext class can be replaced
through the use of ThreadLocal.
Volunteer: Bruce Snyder
Status: completed
Date Started: Apr 2004
Notes:
Cache Engine Refactoring
Description:
Castor's current cache implemenation is not very robust. It lacks any
procedure for manual object eviction and it should really be using
some sort of balanced tree (e.g. java.util.TreeMap) for reasons of
speed, etc., etc.
Note that Vince Adamo has posted a
patch for
object eviction in the current Castor API.
Volunteer:
Status: open
Date Started:
Notes:
There should really be a cache API. This would abstract the entire cache
engine allowing it to be made pluggable. In fact, I would much rather
consider using a JSR 107
implementation than writing our own API. Because this layer will be
pluggable, a distributed cache implementation should be provided using
JavaGroups.
Also, the dirty checking needs to be refactored so it's cleaner and
more straightforward in its duties.
Tranql may be used to achieve this task.
Polymorphism
Description:
Handling of interfaces and abstract classes with regard to both object
mapping and queries.
Volunteer:
Status: not started
Date Started:
Notes:
Maybe this could be handled for the object mapping by using nested
<class> elements???
Interface idea - introduce the 'implements' attribute to the
<class> element:
<class name="myapp.Foo" ... >
<class name="myapp.FooBar" implements="myapp.Foo" ...>
</class>
</class>
Obviously an interface can be determined by using java.lang.Class#isInterfaces() and/or
java.lang.Class#isInterface().
Abstract class idea - make use of the 'extends' element plus
some code testing:
<class name="myapp.Foo" ... >
<class name="myapp.FooBar" extends="myapp.Foo" ...>
</class>
</class>
The use of the 'extends' attribute for the abstract class is not
unique enough to determine that the class is abstract or concrete.
But by using java.lang.Class#isAssignableFrom() and/or
java.lang.Class#getSuperclass() will work.
Queries - objects should already be cast properly:
SELECT p FROM myapp.Product p
The above query would return all Products including
Computers, etc.
Another item that will need to be added is a mapping for interfaces
and abstract classes. The <class> element could certainly be used
for this possibly by introducing another attribute to the <class>
element. I'm thinking about an attribute named 'abstract' that
is simply a boolean whose default is false so that it won't affect
concrete classes. Then it serves as a marker for interfaces and
abstract classes only.
Not sure if this will really work. It will need experimentation to
determine.
Integrated Connection Pooling
Description:
A database connection pooler should be integrated directly into
Castor. This would limit us to supporting JDBC 3.0
compliant drivers. Anything that's not JDBC 3.0 compliant would
still be supported via an implemention within the driver for a
pooled DataSource.
Volunteer:
Status: not started
Date Started:
Notes:
Here is a list of database connection poolers:
JCA Research
Description:
Research the possibility of creating a JCA Connector for Castor to
hook into application servers that support JCA.
Volunteer:
Status:
Date Started: not started
Notes:
Logos
Description:
This task covers two topics:
|
- | Logos for Castor users to display on their websites |
- | Logos of projects that Castor uses or with which Castor integrates |
Volunteer:
Status:
Date Started: not started
Notes:
This is to increase awareness of Castor's use as well as Castor's
awareness of other projects.
Timestampable Dynamic Proxy
Description:
Remove the requirement of all objects to explicitly implement the
Timestampable interface.
Volunteer:
Status:
Date Started:
Notes:
Currently Castor requires all objects involved in a long transaction
to implement the Timestampable
interface. This requirement can easily be removed via a dymanic proxy
implementation.
Must Fix Bugs
Description:
There are a few bugs that *must* be fixed, specifically
986,
925,
These bugs have been around for quite a while and should have been
fixed long ago.
Volunteer:
Status: not started
Date Started:
Notes:
Javadoc improvements
Description:
This task surrounds the effort to continually improve the code
documentation including code examples, adding an @author tag
to any class you modify, etc. This task must be carried
out by everyone.
Volunteer:
Status: ongoing
Date Started:
Notes:
|