ExoLab     OpenEJB     OpenJMS     OpenORB     Castor     Tyrex     
 

Main
  Home
  Download
  API
  Schema
  Mailing Lists
  CVS / Bugzilla
  Support

XML
  Using XML
  Source Generator
  Schema Support
  XML Mapping
  XML FAQ

JDO
  Using JDO
  JDO Config
  Types
  JDO Mapping
  JDO FAQ
  Other Features

Advanced JDO
  OQL
  Trans. & Locks
  Design
  KeyGen
  Long Trans.
  Nested Attrs.
  Pooling Examples
  Blobs and PostgreSQL

More
  Presentations
  The Examples
  Extras and 3rd Party Tools
  Test Framework -- JDO
  Test Framework -- XML
  Configuration
  Tips & Tricks
  Full JavaDoc

About
  License
  Contributors
  Status, Todo
  Changelog
  Library
  Contact

  



Castor JDO Project Plan

Introduction
Tasks
Logging Refactoring
CTF-JDO Improvements
Query Engine Refactoring
Query Externalization
ClassMolder Refactoring
J2EE Transaction Factory
Cache Engine Refactoring
Polymorphism
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

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: started
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.

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:

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.).

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.

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 already determined by the FieldMolder.

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: started
Date Started: Apr 2003
Notes:
Werner and I have been working together to get this implemenation working. It's proceeding and I expect that it will be working by the end of May 2003.

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.

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.

Not sure if this will really work. It will need experimentation to determine.

Must Fix Bugs

Description:
There are a few bugs that *must* be fixed, specifically 986, 925, 997. 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:

 
   
  
   
 


Copyright ) 1999-2003 ExoLab Group. All rights reserved.
 
Java, EJB, JDBC, JNDI, JTA, Sun, Sun Microsystems are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and in other countries. XML, XML Schema, XSLT and related standards are trademarks or registered trademarks of MIT, INRIA, Keio or others, and a product of the World Wide Web Consortium. All other product names mentioned herein are trademarks of their respective owners.