|  |  |  | License Codehaus OpenEJB OpenJMS OpenORB Tyrex
Old releases
General
Release 1.3
Release 1.3rc1
Release 1.2
Main
Home
About
Features
Download
Dependencies
Reference guide
Publications
JavaDoc
Maven 2 support
Maven 2 archetypes
DTD & Schemas
Recent HTML changes
News Archive
RSS news feed
Project Wiki
Development/Support
Mailing Lists
SVN/JIRA
Contributing
Support
Continuous builds
Prof. services
Related projects
Spring ORM support
Spring XML factories
WS frameworks
XML
XML
XML Code Generator
XML Code Generator
JDO
Introduction
First steps
Using JDO
JDO Config
Types
JDO Mapping
JDO FAQ
JDO Examples
JDO HOW-TOs
Tips & Tricks
Other Features
JDO sample JAR
Tools
Schema generator
Advanced JDO
Caching
OQL
Trans. & Locks
Design
KeyGen
Long Trans.
Nested Attrs.
Pooling Examples
LOBs
Best practice
DDL Generator
Using DDL Generator
Properties
Ant task
Type Mapping
More
The Examples
3rd Party Tools
JDO Tests
XML Tests
Configuration
About
License
User stories
Contributors
Marketplace
Status, Todo
Changelog
Library
Contact
Project Name
## 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 `Product`s including `Computer`s, 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:
- | DBCP
- | Oracle JDBC driver (Unable to locate 9.2.x docs)
- | PoolMan
- | PostgreSQL JDBC driver
- | Proxool
- | SQL Relay
### 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:
| Copyright © 1999-2005 ExoLab Group, Intalio Inc., and Contributors. 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. |