Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

On Castor XML we are currently working to introduce STaX as additional XML parsing technology and trying to improve Spring OXM support for Castor XML. Below packages can be seen as separate units of works that can and shall be designed and developed individually.

Title

Better integration of Castor XML and Spring OXM

Keywords

Java, XML, OXM, Spring

Description

Spring OXM currently has limited support for Castor XML for (un)marshalling, limited in the sense that only a few selected features of Castor are supported/documented. The idea here is to improve the current implementation of Spring OXM' CastorMarshaller class (framework) so that all (advanced) features of Castor XML can be used; the final artifact of this work package is a set of patches to be donated to Spring OXM (and/or Castor XML).

Mentor(s)

Werner Guttmann (wguttmn AT codehaus DOT org)

Title

StAX for marshalling

Keywords

Java, XML, StAX

Description

Currently Castor uses SAX for un-/marshalling, and offers partial support for using StaX to selectively stream XML 'fragments' into Castor's Unmarshaller. At the marshalling side of things, there's currently no support for StAX. The idea of this project is add support for StAX for marshalling to the XML data binding framework natively. As a result, it should be possible to switch between SAX and StAX. As such, it will be necessary to separate concerns in Castor XML and to refactor Castor internals.

Mentor(s)

Werner Guttmann (wguttmn AT codehaus DOT org)

...

Title

Refactor transformation of OQL to SQL queries

Keywords

Java, OQL, JDBC, SQL, Junit

Description

In a former GSoC we have implemented a class hierarchy to represent OQL queries. With this project parsers for CastorQL and EJBQL have also been implemented that transform query strings into this class hierarchy. What still is missing is the transformation of this class hierarchy into SQL queries. To achive this goal OQLQueryImpl and QueryResult have to be refactored.

Mentor(s)

Ralf Joachim (rjoachim AT codehaus DOT org)

...

Title

Refactor lock engine

Keywords

Java, concurency, multi threading, dead locks, JUnit

Description

Replace our current locking system by a new implementation based on java.util.concurent

Mentor(s)

Ralf Joachim (rjoachim AT codehaus DOT org)

Title

Inheritance

Keywords

Java, SQL, XML, JUnit

Description

To persist polymorpic objects, a hierarchy of objects that extend each other, one would want to choose between 3 different strategies:

  • a table for every class of the hierarchy
  • a table for every concrete class of the hierarchy
  • one table for all classes
    As of version 1.3 Castor supports only the first one (table per class). With this strategy Castor can evaluate the class of an object by looking in which of the tables an entry for the object to be loaded exists. While this would also be possible for the table per concrete class strategy, will the table per class hierarchy require a column that holds information to destinguish the class of the object.
    Our plan to improve the inheritance startegies Castor supports is, to move the logic that decides of which class an object loaded is into a new Disciminator class. Having said that this refactoring will be quite difficult and challenging.
    To add more strategies next, you will need to extend our mapping to be able to specify the strategy and other information required for them. If you have managed this, adding one or both of the missing strategies should be quite easy for you.

Mentor(s)

Ralf Joachim (rjoachim AT codehaus DOT org)

...