empire-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eike Kettner (JIRA)" <empire-db-...@incubator.apache.org>
Subject [jira] Created: (EMPIREDB-73) spring example
Date Sun, 07 Feb 2010 20:29:28 GMT
spring example

                 Key: EMPIREDB-73
                 URL: https://issues.apache.org/jira/browse/EMPIREDB-73
             Project: Empire-DB
          Issue Type: Task
            Reporter: Eike Kettner
         Attachments: empire-db-example-basic-spring.zip

I had a look at the example and build a simple spring version from it
(see attachment). Basically I just split up the SampleApp class into
some pieces and let spring reassemble it again. The class EmpireApp
contains all the code from SampleApp. The classes in support package are
needed to have an easy spring integration, and it would be great to have
those classes provided by empiredb  :)  - maybe in some
empire-db-spring-support subproject...

The EmpireDriverFactory class creates DBDatabaseDriver instances and I
used the driver classname instead of a provider-string to decide. Reason
to this is that imho I think its easier for people to get the classname
string than an arbitary provider string (I always don't know for example
if it's now "hsql" or "hsqldb", "derby" or maybe "apache-derby". The
classname exactly identifies what I want, it's somewhat similiar to the
*Dialect classes from hibernate.).

The class EmpireDBException just wraps the EmpireException to integrate
in springs exception hierarchy. Some applications might look
for the base "DataAccessException", so EmpireException extends a spring
exception to fit in this scenario. Another idea would be to provide an
AOP advice that will wrap the EmpireException if it occurs, so the DAO
implementations are free from this code.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message