commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan" <>
Subject Re: [Simper] Re: Bean storage in database
Date Sun, 03 Feb 2002 18:34:57 GMT
Cool. BTW I could maybe help with the Digester & XML stuff if you like.

One other thing to keep in the back of your mind when you're
refactoring things. Once its in CVS somewhere - hopefully the sandbox or
failing that sourceforge - I'd be quite interested in adding support for
'real' beans.

I think DynaBeans are perfect for queries and for when the Java object model
is dictated by the database schema. Its also very common to need to write a
web app for an existing database, where hand coding beans to represent the
database is a wasted effort. Though it would be nice to support the other
way around as well, that Java business objects are written first and Simper
gets used to persist them and that the database schema comes secondary.

The Simper code is mostly based on DynaBeans and its pretty easy to wrap a
DynaBean around a real bean so I'm hoping that mostly Simper won't really
know if real or dyna beans are being used. To get the 'mark as dirty'
features in your SimperBean we could use BCEL or JDK1.3's dynamic proxy
to generate wrappers that detect when bean setters are called. The nice
thing about this would be we could
use Simper to persist any Java Bean, as well as DynaBeans. There's an
object-relational can of worms that this could open but hopefully we'll be
able to keep it simple.

BTW I keep wanting to type Simpler rather than Simper. The project name
didn't start out as a typeo did it ;-)

----- Original Message -----
From: "Bryan Field-Elliot" <>
To: "Jakarta Commons Developers List" <>
Sent: Sunday, February 03, 2002 2:57 PM
Subject: [Simper] Re: Bean storage in database

> Hi James,
> Thanks for the great feedback!
> Yes, I identified early on that I'd like to move the initialization to
> an XML file using Digester (a tool I admittedly haven't had time to
> learn), rather than force the user to implement a Simper.IInit class.
> One possible caveat however, is that sometimes you actually have to
> write code in order to grab a DataSource from whatever connection pool
> you're using, rather than just refer to it in the XML file. However,
> careful use of adaptor classes could be thrown into the mix here (e.g. a
> class which gets the DataSource from Struts, another one which gets it
> from DBCP, etc).
> We are also on the same wavelength regarding the transaction
> startup/commit logic, and that it shouldn't necessarily be tied directly
> to the Servlet 2.3 Filter mechanism. I've already had an eye on
> extracting that as well into something more generic, and then providing
> an adaptor class which wraps it into a Servlet Filter. This is an easy
> one to knock off and I may do it this coming week.
> I'd also like to set up a CVS repository and mailing list (and a
> slightly more interesting website) this week in order to let others Ted
> really contribute. Ultimately I'd be happy to see this adopted into
> Jakarta somewhere (Commons, Sandbox, whatever), but I'm in no hurry and
> certainly don't want to cause an uproar regarding the bending of rules
> (since I'm not a committer).
> Thanks,
> Bryan

Do You Yahoo!?
Get your free address at

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message