The jaxor home page has been upgraded to run on mysql 4.1. You may have noticed the site was down for a few days. Sourceforge dropped support for Mysql 3.2.

The conversion just took a few minutes thanks to this article. Please drop me an email if you notice any problems.

The jaxor development team is proud to announce the release of 3.5. The release includes many enhancements to functionality and performance.

Jaxor Generation Directly from Database Schema

Now Jaxor users can generate jaxor mapping files directly from a database schema. An Ant Task can be used to read a database schema and generate the Jaxor mapping files. Then the Jaxor task can be used to convert the mapping files into the associated objects. A full persistence layer without writing a line of code.

<target name="schema2jaxor">
 <taskdef name="schema2jaxor" classname="net.sourceforge.jaxor.generator.MappingGeneratorTask"
  classpathref="jaxor.run.path"/>
  <schema2jaxor destdir="build/generated"
   packagename="net.jaxor.testgen" verbose = "false"
   schema="" catalog="" user="jaxor_test" password="jaxor_test"
   url="jdbc:mysql://192.168.1.101/test"
   driver="com.mysql.jdbc.Driver"/>
</target>

Foreign Field Mapping Metadata Available at Runtime

This release adds the ability to use foreign field metadata at runtime. This allows developers to work with objects at the interface and metadata levels. For example, this example is the implementation of cascading deletes for entities.

Any Jdbc datasource!

If there is a jdbc compliant driver for your datasource, Jaxor will work. Jaxor is completely database independent so it can run with any datasource. The integration suite is run against every build to ensure that the jaxor codebase remains database independent. You don't have to worry about Jaxor breaking when you want to change or upgrade your database. Choose any database vendor, version or platform, Jaxor will work.

Jaxor Compatibility Test Suite

The Jaxor codebase includes a compatibility test suite that can be run against any database to ensure compatibility. If you have a question about the test suite or want to see a particular database included, please post a message to the Mailing List or the User Forums. The current integration suite that is run with every code change includes the folowing databases:

• Mckoi
• Axion
• Hypersonic
• MySql
• PostgresSql
• Oracle
• Microsoft SqlServer

Jaxor is a good candidate for a lightweight container since it is customizable, extensible, and needs to be lifecycle aware. In an integrated environment, a container allows Jaxor to integrate well with other components. For instance, the container might provide a connection pool or transactional services (JTA) that Jaxor can integrate with. Beyond integration, lightweight containers also provide dynamic assembly for runtime configuration.

Pico Container is a very elegant lightweight container. It uses Dependency Injection to integrate components. The most elegant aspect of the design is that it does not create dependencies on itself. Also, with constructor based injection, the container actually encourages sound design. Objects are created in a known, stable, immutable state. The Jaxor codebase attempts to adhere to this design, making pico a natural choice for a container.

Jaxor's test code coverage currently sits a shade under 90%. For a non-trivial framework, this is a reasonably high percentage. A quick check of Clover examples shows that Jaxor testing compares favorably. Also, it should probably be mentioned that the unit tests are run 3 separate times (Hypersonic, Axion, and Mckoi). Since the public release of Jaxor, the number of production bugs that have been found can be counted on one hand.

The challenge to the rest of the open source community is to provide examples of other projects that meet or exceed this level of testing. With a quick look through the clover "testimonials" I found icu4j. Nice work to the icu4j team. Anyone know of any other OSS that can provide such high code coverage?

Jaxor provides many different ways to create and execute queries. Jaxor uses SQL for queries for several reasons.

• Proven - Most developers are already comfortable with using SQL
• Powerful
• Concise
• Stable
• Object Query Languages (OQL) are often very limiting, and end up looking nearly the same as SQL.
• OQL is based upon properties and classnames. Which is more stable, your classes or the db schema? Most likely it is the DB schema. It hinders refactoring if you have to worry about breaking queries when you change a class.
• Performance - Developers can use vendor extensions (such as oracle hints) to optimize queries. DBA's can optimize queries without having to learn OQL.
• Do not duplicate functionality that Databases already do perfectly well on their own.
• 3rd party tools - You can use 3rd party tools to create and test the sql that Jaxor uses for resolving objects.

Jaxor provides a streamlined, generative architecture that provides a clean separation between architecture concerns. The jaxor mapping files provide a clear, concise xml syntax for defining all persistence requirements for an entity. Domain logic is a separate concern from persistence logic. Jaxor provides an easy way to extend peristent entities with domain code.

For our example, we'll look at adding an order total to the entity object. The persitent entity contains methods for several monetary amounts for the entity.

  public MoneyWithCurrency getEquipmentCost();
  public void setEquipmentCost(MoneyWithCurrency arg);
  public Money getSalesTax();
  public void setSalesTax(Money arg);
  public Money getShippingCharge();
  public void setShippingCharge(Money arg);

For each entity, Jaxor generates a base entity (in this case OrdersBase). This object implements the generated Entity interface (OrdersEntity). Now to create a domain object for this entity, we simply have to extend the base Entity.

The Jaxor unit test suite was recently overhauled to run against Axion. The tests are now run twice - once with hypersonic and once with Axion. The unit test suite is now completely pluggable. Any JDBC compliant connection can be used to run the suite.

Concurrency can be a difficult part of persistence. Often, concurrency problems only occur in very rare occasions. The most common example involves multiple users updating the same row in the database. Without concurrency checking, lost updates can occur when a second user overwrites the first users data. By definition this is a normal update. However, a problem can occur if the second user updates the row without first viewing the edits by the first user. Depending on the data, many systems will handle this as a concurrency error and force the user to redo the update using the most recent data. This is known as optimistic concurrency. It is optimistic because we are assuming that concurrency conflicts are going to be rare, but we want to catch them. The downside is that the user typicaly must redo their transaction from the beginning.

Jaxor gives you the ability to resolve foreign keys in a myriad of ways. The examples here demonstrate the most common usages.

Most of the examples use a simple users and groups table schema. There are three tables: User, Groups, and Group_Member. Users can be a member of any group, and each group has an admin user. The entire example is packaged in the source code in net.sourceforge.jaxor.example.users.

One to One Simple Lookup

The entity-ref element is defined within the entity element of a mapping file. In a very concise syntax, the element defines the target table ("user") and the source column ("admin_user_name"). The target column("user_name") is required if the source and target columns have different names.

     <entity-ref table="user" alias="AdminUser">
            <key source="admin_user_name" target="user_name"/>
      </entity-ref>

public interface GroupEntity....
public UserEntity getAdminUser();
public void setAdminUser(UserEntity param);