commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Scott Sanders" <>
Subject RE: Jakarta Persistence Framework?
Date Mon, 17 Dec 2001 19:15:22 GMT
> From: Bryan Field-Elliot [] 
> First, let me clarify, I'm not interested in re-inventing the 
> connection pool.

Thank goodness ;-)
> What I _am_ interested in, is a simple framework which maps 
> JDBC tables to Java classes, with getters and setters, which 
> roughly meets these
> goals:
> - Ability to easy create a new class which models a table 
> (or, if not a POJO (Plain Old Java Object), then the new DynaBean)


> - Easily model the concepts of a "finder" (execute a query, 
> return many entity objects)

Like the Criteria in Turbine Peers?

> - Easily handle creations/deletions/updates, with the 
> framework communicating your changes to the database

Like almost every other framework.

> - Easily wrap up transactions from within Struts' way of 
> doing things (begin tran before executing an Action, and 
> commit tran at it's conclusion; rollback if an exception is 
> thrown; allow the Action to explicitly rollback).


> - Easily allow Struts Actions to hand these entities (or 
> collections of
> them) to the View for rendering into HTML etc -- in a way 
> that makes these entities read-only and detached


> - Easily handle some of the more ugly, common tasks in JDBC 
> development
> - namely, (1) primary key generation, and (2) optimistic 
> concurrency locking

Like IDs in Turbine Peers?

> - Keep It Simple - this should NOT balloon into a huge 
> framework - it's source should always be readable and 
> understandable by most - if you need something more complex, 
> go get JBoss or one of the bigger frameworks recently mentioned here.

Are Peers in Turbine too big or coupled to Turbine?  Jason might have
some insight on this one...

> Other "sliding scale" factors include:
> - How easy do you want to make it for developers to build 
> their entity classes? The easier you make it, the more 
> complex the underlying framework is likely to become. Do you 
> do automatic class generation (from an XML file), or can you 
> declare everything within your own classes (which perhaps 
> extend a framework base class)? 

Peers do both auto-generation, and a class that is left untouched for
the developer to add their own business logic...

> - Is there automatic "change detection" (ala EJB), or must 
> the developer execute some kind of "update()" method after 
> changing a bean? Automatic change detection would give the 
> developer one less thing to remember/worry about, however, it 
> can really balloon the framework. Personally I lean towards 
> leaving out change detection and letting the user (me) 
> remember to call update() before my bean goes out of scope.

Nice idea, though I don't think it would balloon the framework, as much
as create less-performant code.  But the tradeoff between performance
and simplicity is a project by project thing.

> Everyone (and every framework) strikes its own balance, 
> roughly, between ease of use vs. framework simplicity. I've 
> found a balance point which feels right to me but may not for 
> others. I'd be happy to put something up here in the next few 
> days to show where it lies, if there's interest. If, instead, 
> I get cries of "stop reinventing the wheel" then perhaps it 
> had better be put to rest. But in any case I do see value in 
> providing the option of a Struts-friendly, 
> far-lighter-than-EJB (but more meaty than simple JDBC 
> wrapping) framework.

Reinvent the wheel if you must.  I have no objections to that.  Toss it
in the sandbox, and see if you get some traction to get out ;-)


> Bryan
> On Mon, 2001-12-17 at 11:40, Jason van Zyl wrote:
>     On 12/17/01 1:35 PM, "Bryan Field-Elliot" 
> <> wrote:
>     > Well, I certainly don't like to see work duplicated, 
> and it seems that
>     > there are many other efforts under way (some of them 
> within Jakarta) to
>     > build a generic persistence framework. That said, however, some
>     > additional considerations might still point towards the 
> usefulness of a
>     > new framework:
>     > 
>     That's certainly true, there are a couple webapp 
> frameworks here, three
>     connection pools, two service frameworks and now one in 
> the sandbox so if
>     you need a persistence layer and you feel none of them 
> satisfy your needs
>     than you won't be starting any new trends. If you find it 
> easier working in
>     a smaller group with people that have similar needs 
> (which I find working
>     within the turbine world, and you may find the same 
> working with struts
>     developers) than that's what you have to do. No one here 
> has really tried
>     that hard to unify everything, and in reality that's 
> probably not ever going
>     to happen and diversity is a great thing
>     If you have ideas, than put them in the sandbox and let 
> people look at them.
>     -- 
>     jvz.
>     Jason van Zyl
    To unsubscribe, e-mail:
    For additional commands, e-mail:

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

View raw message