Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Subject: Re: Jakarta Persistence Framework?
From: Bryan Field-Elliot <bryan_lists@netmeme.org>
To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
In-Reply-To: <1008609076.24687.10.camel@c1593933-a.boulder1.co.home.com>
References: <1008609076.24687.10.camel@c1593933-a.boulder1.co.home.com>
Content-Type: multipart/alternative; boundary="=-F0b1nHl3aHL0xIzaA+hz"
Date: 17 Dec 2001 11:35:04 -0700
Message-Id: <1008614104.24691.35.camel@c1593933-a.boulder1.co.home.com>
Mime-Version: 1.0

--=-F0b1nHl3aHL0xIzaA+hz
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

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:

I, at least, am interested in something which integrates elegently with
Struts (in a clearly designed way), such that your Actions are doing
database work (with auto-commit and auto-rollback intelligently
integrated with how Struts Actions are laid out), and your Views can
view the same data (ideally, the same beans) in some kind of read-only
capacity.

The DynaBean discussion is interesting, because if Struts development is
moving in that direction to make the DynaBean an important piece, then
perhaps a Struts-friendly persistence mechanism should also use the
DynaBean, in which case, there's nothing yet built which fits the bill.

I wouldn't think of proposing anything which slows down the development
of Craig's DynaBean idea -- however I would be interested in,
concurrently, seeing if a nice persistence mechanism could be layered on
top of it or along side it.

Bryan

--=-F0b1nHl3aHL0xIzaA+hz--