You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Bryan Field-Elliot <br...@netmeme.org> on 2001/12/17 18:11:16 UTC
Jakarta Persistence Framework?
Is there a (or plans for a) standardize Jakarta Persistence Framework?
I've built about 7 projects now on EJB, about 4 of them on top of Struts
as well. I consider myself an expert at EJB, and I'm also at the point
where I'm sick of it -- too overkill a framework, too much work to
establish your entity framework (CMP), and too much "black magic" under
the hood of your EJB server.
I've built my own persistence framework which, in my opinion,
accomplishes the important goals of EJB (from a web app developer
perspective), and strikes my own balance in terms of what's important in
a framework vs. not. Particularly:
- Tied to JDBC, vs. EJB's attempt to abstract it
- One class per entity, vs. EJB's 3-5 (Home Interface, Remote Interface,
Local Interface, Bean Class, and Primary Key)
- Implicit transaction wrapping at the Struts Action level (including
commit if the Action succeeds, and rollback if the Action throws an
exception).
- Explicit transaction rollback from the Struts Action if desired
- The same beans can be passed to the View (by way of Request attributes
or otherwise), where they become detached and read-only.
- ~90% of the framework is contained in a single class which any JDBC
developer should be able to read and understand (vs. EJB -- how many
classes are there in the JBoss project?)
- The design goal is, Keep It Simple and underStandable. If you need
EJB's more advanced features, then go out and use EJB.
- Data Caching at the app server level should be easy to implement
within this framework (a least-recently-used and/or a time-to-live
algorithm, using custom sizes and timeout values which make sense to the
developer).
Is there already a Jakarta persistence framework which roughly
accomplishes these goals? If not, is there interest in starting one?
Regards,
Bryan
Re: Jakarta Persistence Framework?
Posted by Jon Scott Stevens <jo...@latchkey.com>.
on 12/31/01 9:44 AM, "Ted Husted" <hu...@apache.org> wrote:
> But, seriously, is the CVS snapshot the best way to peek at Scarab now?
Yes.
I also have a nightly re-built runbox...
http://scarab.whichever.com/
We are getting closer all the time...
-jon
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Jakarta Persistence Framework?
Posted by Ted Husted <hu...@apache.org>.
Jon Scott Stevens wrote:
> <teasing>
> I wonder when Craig will tie Struts to JDO so that his Sun stock will raise
> when people have to buy JDO to use Struts. :-)
> </teasing>
Not to worry, Jon, we've learned the Lessons of Turbine, and so long as
my veto any good, Struts will never be tied to a particular persistence
layer or authentification module or anything like that ;-) It's a very
competent front controller, and we should continue to play to our
strengths.
And, heck, now that we're making Velocity templates first class
citizens, I'm sure there will be a great whooooosh as the JSP developers
realize the errors of their ways ;-)
But, seriously, is the CVS snapshot the best way to peek at Scarab now?
-T.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Jakarta Persistence Framework?
Posted by Jon Scott Stevens <jo...@latchkey.com>.
on 12/17/01 11:51 AM, "Martin Cooper" <ma...@tumbleweed.com> wrote:
> Aha! Then I'd better keep my eye on Torque. ;-) Having the framework handle
> the more complex situations, such as joined tables, is what would make it
> really valuable. Avoiding the grunt work for the easy stuff is nice, but
> doing the same for the complex stuff is much more compelling. (Any idea on
> timeframe, Jason?)
>
> --
> Martin Cooper
Torque handle's joined tables just fine.
Torque can do almost everything one could possibly need. It isn't always the
cleanest, but it does a shit load more than coding it by hand...and it is
open source...you can always modify and contribute to it.
We have proven the Torque model in Scarab which has a fairly complex
database Schema with some pretty heavy joins and database logic in places.
Torque has held up quite well.
<teasing>
I wonder when Craig will tie Struts to JDO so that his Sun stock will raise
when people have to buy JDO to use Struts. :-)
</teasing>
-jon
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Jakarta Persistence Framework?
Posted by Martin Cooper <ma...@tumbleweed.com>.
----- Original Message -----
From: "Jason van Zyl" <jv...@zenplex.com>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Monday, December 17, 2001 11:13 AM
Subject: Re: Jakarta Persistence Framework?
> On 12/17/01 2:08 PM, "Bryan Field-Elliot" <br...@netmeme.org> wrote:
>
> > First, let me clarify, I'm not interested in re-inventing the connection
> > pool.
> >
> > 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:
>
> This is what Torque currently does but will be expanded as the
table->object
> mapping rarely is enough for an application unless you are starting from
> scratch and have full control over the project. Many times your
application
> object may consist of fields that are potentially pulled from multiple
> sources.
Aha! Then I'd better keep my eye on Torque. ;-) Having the framework handle
the more complex situations, such as joined tables, is what would make it
really valuable. Avoiding the grunt work for the easy stuff is nice, but
doing the same for the complex stuff is much more compelling. (Any idea on
timeframe, Jason?)
--
Martin Cooper
>
> But Torque definitely does the table->object mapping now and has for a
long
> while and is very stable.
>
> > - 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)
> > - Easily handle creations/deletions/updates, with the framework
> > communicating your changes to the database
> > - 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
> > - 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.
> >
> > 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)?
> > - 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.
> >
> > 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.
> >
> > Bryan
> >
> >
> > On Mon, 2001-12-17 at 11:40, Jason van Zyl wrote:
> >
> > On 12/17/01 1:35 PM, "Bryan Field-Elliot" <br...@netmeme.org>
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
> >
> > http://tambora.zenplex.org
> > http://jakarta.apache.org/turbine
> > http://jakarta.apache.org/velocity
> > http://jakarta.apache.org/alexandria
> > http://jakarta.apache.org/commons
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> >
> >
> >
> >
>
> --
>
> jvz.
>
> Jason van Zyl
>
> http://tambora.zenplex.org
> http://jakarta.apache.org/turbine
> http://jakarta.apache.org/velocity
> http://jakarta.apache.org/alexandria
> http://jakarta.apache.org/commons
>
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Jakarta Persistence Framework?
Posted by Jason van Zyl <jv...@zenplex.com>.
On 12/17/01 2:08 PM, "Bryan Field-Elliot" <br...@netmeme.org> wrote:
> First, let me clarify, I'm not interested in re-inventing the connection
> pool.
>
> 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:
This is what Torque currently does but will be expanded as the table->object
mapping rarely is enough for an application unless you are starting from
scratch and have full control over the project. Many times your application
object may consist of fields that are potentially pulled from multiple
sources.
But Torque definitely does the table->object mapping now and has for a long
while and is very stable.
> - 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)
> - Easily handle creations/deletions/updates, with the framework
> communicating your changes to the database
> - 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
> - 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.
>
> 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)?
> - 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.
>
> 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.
>
> Bryan
>
>
> On Mon, 2001-12-17 at 11:40, Jason van Zyl wrote:
>
> On 12/17/01 1:35 PM, "Bryan Field-Elliot" <br...@netmeme.org> 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
>
> http://tambora.zenplex.org
> http://jakarta.apache.org/turbine
> http://jakarta.apache.org/velocity
> http://jakarta.apache.org/alexandria
> http://jakarta.apache.org/commons
>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
>
>
--
jvz.
Jason van Zyl
http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Jakarta Persistence Framework?
Posted by Jon Scott Stevens <jo...@latchkey.com>.
on 12/17/01 11:15 AM, "Scott Sanders" <ss...@nextance.com> wrote:
> Are Peers in Turbine too big or coupled to Turbine? Jason might have
> some insight on this one...
Torque is not coupled to Turbine at all.
If you all want to see how it is done and used, look at Scarab's code.
-jon
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Jakarta Persistence Framework?
Posted by Scott Sanders <ss...@nextance.com>.
> From: Bryan Field-Elliot [mailto:bryan_lists@netmeme.org]
>
> 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)
OK
> - 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).
Agreed
> - 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
OK
> - 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 ;-)
Scott
>
> Bryan
>
>
> On Mon, 2001-12-17 at 11:40, Jason van Zyl wrote:
>
> On 12/17/01 1:35 PM, "Bryan Field-Elliot"
> <br...@netmeme.org> 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
>
http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons
--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Jakarta Persistence Framework?
Posted by David Winterfeldt <dw...@yahoo.com>.
I had started on auto-generating classes based on a
database table as a proof of concept, but I haven't
worked on it anymore since I found out it about
Torque, Castor, etc. I liked the idea of keeping
things very simple and generating jdbc code that you
would have written yourself so it would be easy to
look at and edit. I thought that one of the
transformation packages could be used to copy to and
from the ActionForm and the PK and Data classes.
http://home.earthlink.net/~dwinterfeldt/generator/
Overview
http://home.earthlink.net/~dwinterfeldt/generator/overview.html
I just thought I'd mention this in case you want to
look at it.
David
--- Bryan Field-Elliot <br...@netmeme.org>
wrote:
> First, let me clarify, I'm not interested in
> re-inventing the connection
> pool.
>
> 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)
> - Easily handle creations/deletions/updates, with
> the framework
> communicating your changes to the database
> - 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
> - 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.
>
> 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)?
> - 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.
>
> 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.
>
> Bryan
>
>
> On Mon, 2001-12-17 at 11:40, Jason van Zyl wrote:
>
> On 12/17/01 1:35 PM, "Bryan Field-Elliot"
> <br...@netmeme.org> 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
>
> http://tambora.zenplex.org
> http://jakarta.apache.org/turbine
> http://jakarta.apache.org/velocity
> http://jakarta.apache.org/alexandria
> http://jakarta.apache.org/commons
>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
>
>
__________________________________________________
Do You Yahoo!?
Check out Yahoo! Shopping and Yahoo! Auctions for all of
your unique holiday gifts! Buy at http://shopping.yahoo.com
or bid at http://auctions.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Jakarta Persistence Framework?
Posted by Bryan Field-Elliot <br...@netmeme.org>.
First, let me clarify, I'm not interested in re-inventing the connection
pool.
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)
- Easily handle creations/deletions/updates, with the framework
communicating your changes to the database
- 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
- 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.
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)?
- 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.
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.
Bryan
On Mon, 2001-12-17 at 11:40, Jason van Zyl wrote:
On 12/17/01 1:35 PM, "Bryan Field-Elliot" <br...@netmeme.org> 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
http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Jakarta Persistence Framework?
Posted by Jason van Zyl <jv...@zenplex.com>.
On 12/17/01 1:35 PM, "Bryan Field-Elliot" <br...@netmeme.org> 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
http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Jakarta Persistence Framework?
Posted by Bryan Field-Elliot <br...@netmeme.org>.
On Mon, 2001-12-17 at 11:36, Craig R. McClanahan wrote:
Having nice persistence frameworks is a good idea. It's not clear to me
that this is a "one size fits all" situation (although it might be). But,
it seems to me that it's mostly independent of the DynaBean discussions
which are focused more on generalizing ActionForm (from a Struts
perspective) and facilitating value objects -- I hadn't really considered
it to be directly applicable to persistence layers. Do you think it
should be?
Per my prior postings -- in no way do I claim that a "one size fits all"
persistence mechanism can be built. Instead, what I'm interested in is
one which is tight, elegent, saves the user a lot of work, and fits
nicely with Struts.
I realize you may not have thought of DynaBeans in the context of a
persistence mechanism, but there seem to be some nice connections..
You're trying to make a nice Value Object system for Struts, and of
course a good persistence mechanism needs an easy way to break entities
off into Value Objects too (or, as the case may be, detach the original
bean from the database, enforce a read-only semantic, and voila, there's
your Value Object).
You also planned for registration of property change listeners -- this
would be useful in any "change detecting" persistence mechanism.
In short, I'd like to see what you come up with with respect to the
DynaBean, and then see what I can come up with in terms of layering a
simple persistence framework on top of it, and throw it in the Sandbox.
It would be nice to see one elegently designed system for shuffling data
all the way from the database, through Struts Actions and JSP pages, to
the user, and back again (through Struts Forms as well), in a way which
reduces the number of classes you have to build, yet still upholds the
ideas of MVC.
Bryan
Re: Jakarta Persistence Framework?
Posted by Jason van Zyl <jv...@zenplex.com>.
On 12/17/01 1:36 PM, "Craig R. McClanahan" <cr...@apache.org> wrote:
> As additional pointers to persistence layer information, the J2EE docs
> (Blueprints and "Core J2EE Patters") talk about "Data Access Object"
> design patterns that address persistence issues.
Scott Ambler probably has the best collection of links:
http://www.ambysoft.com/persistenceLayer.html
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
jvz.
Jason van Zyl
http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Jakarta Persistence Framework?
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On 17 Dec 2001, Bryan Field-Elliot wrote:
> Date: 17 Dec 2001 11:35:04 -0700
> From: Bryan Field-Elliot <br...@netmeme.org>
> Reply-To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> Subject: Re: Jakarta Persistence Framework?
>
> 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.
Having nice persistence frameworks is a good idea. It's not clear to me
that this is a "one size fits all" situation (although it might be). But,
it seems to me that it's mostly independent of the DynaBean discussions
which are focused more on generalizing ActionForm (from a Struts
perspective) and facilitating value objects -- I hadn't really considered
it to be directly applicable to persistence layers. Do you think it
should be?
As additional pointers to persistence layer information, the J2EE docs
(Blueprints and "Core J2EE Patters") talk about "Data Access Object"
design patterns that address persistence issues.
>
> Bryan
>
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Jakarta Persistence Framework?
Posted by Bryan Field-Elliot <br...@netmeme.org>.
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
Re: Jakarta Persistence Framework?
Posted by Ted Husted <hu...@apache.org>.
Something that I've been playing with that would probably work well with
the DynaBean is the "ModelBean" package that Vincent mentioned. This
really isn't a persistence framework at all, but simply an organized way
to quickly move a ResultSet into a collection of beans.
It uses reflection to do all this, and so it jives well with Struts and
other JavaBean-centric applications. It does not try to shield the
developer from SQL, except to encapsulate the statements in their own
class(es). I had a solo develper in mind when I wrote it, but I'm told
that it does work well with systems that have already been defined, and
there is some DBA writing the SQL queries for you.
The basic idea is that you define a bean that describes a table or
logical view, and then subclass this for each query that uses the bean
(or view). The bean executes the query, and returns a collection of
beans (usually of its own class) as the result. There are some simple
but specialized classes, which map roughly to those described by Scott
Ambler.
ModelBean - PersistenceObject - Provides behavior needed by the business
domain
Access - PersistenceCriteria - Provides behavior needed to retrieve,
update, or delete collections of objects.
StatementUtils, Statements - PersistenceMechanism - Provides access to
the data services (database, search engine, et cetera).
Command - SqlStatement - Provides SQL statements
ConnectionPool - PersistenceBroker - Provides connections to the
persistence mechanisms (StatementUtils).
There's a sample application ("Artimus")
http://husted.com/struts/resources/artimus.zip
using this on the Struts resource page, which is also available in the
contrib folder. It's still pre-release though. The source for the
ModelBean part is in the Scaffolding package.
http://husted.com/struts/resources/scaffold.zip
The only documentation (outside of JavaDoc) that I have right now is
part of a chapter for a book, but I can correspond with you privately
about that. I also have a gaping hole in that chapter with Torque's name
on it.
Vincent recently uploaded some changes to the CVS version, to bring it
more in line with Avalon, but I haven't had a chance to study those yet.
-T.
Bryan Field-Elliot wrote:
>
> Ted,
>
> I may or may not look at Torque, Peers, etc. I'm not interested in
> re-inventing the wheel, but really, I'm looking to have (in other words,
> build) a persistence framework that takes up 3-5 classes at most, and
> will likely be built using the new DynaBean. Experimental, yes, but
> darnit, it's got to be simple. If I want complex, believe me, I'd go
> back to EJB/CMP (where I am very proficient, but dissatistied).
>
> Bryan
>
> On Mon, 2001-12-31 at 10:47, Ted Husted wrote:
>
> Vincent Massol wrote:
> > Have you checked Scaffold (built by Ted Husted) in the contrib directory
> > of Struts (http://cvs.apache.org/viewcvs/jakarta-struts/contrib/) ? It
> > does a bit of what you'd like although maybe not everything.
>
> No! Stop! -- Let Bryan hook up Torque to Struts -- so he can tell me how
> to do it too ;-)
>
> I'm *very* interested in doing more work with Torque, but coming from
> outside a Turbine background, I just don't know where to start ;-(
>
> Calling any persistence layer from a Struts Action should not be
> difficult. The Action just pulls out what is needed from the http layer,
> passes it up, and passes back the result. The trick is often finding a
> simple enough example. I'm sure Scarab puts Torque through its paces,
> but a "Hello World" would be very helpful for a newcomer. (And, of
> course, if I ever get past the curve, I'll eagerly provide one of my own
> ;0)
>
> Most of *really* aren't interested in re-inventing the wheel. Sometimes
> it's just hard to find out how the lugnuts are threaded.
>
> -- Ted Husted, Husted dot Com, Fairport NY USA.
> -- Building Java web applications with Struts.
> -- Tel +1 585 737-3463.
> -- Web http://www.husted.com/struts/
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Building Java web applications with Struts.
-- Tel +1 585 737-3463.
-- Web http://www.husted.com/struts/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Jakarta Persistence Framework?
Posted by Bryan Field-Elliot <br...@netmeme.org>.
Ted,
I may or may not look at Torque, Peers, etc. I'm not interested in
re-inventing the wheel, but really, I'm looking to have (in other words,
build) a persistence framework that takes up 3-5 classes at most, and
will likely be built using the new DynaBean. Experimental, yes, but
darnit, it's got to be simple. If I want complex, believe me, I'd go
back to EJB/CMP (where I am very proficient, but dissatistied).
Bryan
On Mon, 2001-12-31 at 10:47, Ted Husted wrote:
Vincent Massol wrote:
> Have you checked Scaffold (built by Ted Husted) in the contrib directory
> of Struts (http://cvs.apache.org/viewcvs/jakarta-struts/contrib/) ? It
> does a bit of what you'd like although maybe not everything.
No! Stop! -- Let Bryan hook up Torque to Struts -- so he can tell me how
to do it too ;-)
I'm *very* interested in doing more work with Torque, but coming from
outside a Turbine background, I just don't know where to start ;-(
Calling any persistence layer from a Struts Action should not be
difficult. The Action just pulls out what is needed from the http layer,
passes it up, and passes back the result. The trick is often finding a
simple enough example. I'm sure Scarab puts Torque through its paces,
but a "Hello World" would be very helpful for a newcomer. (And, of
course, if I ever get past the curve, I'll eagerly provide one of my own
;0)
Most of *really* aren't interested in re-inventing the wheel. Sometimes
it's just hard to find out how the lugnuts are threaded.
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Building Java web applications with Struts.
-- Tel +1 585 737-3463.
-- Web http://www.husted.com/struts/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Jakarta Persistence Framework?
Posted by "Kevin A. Burton" <bu...@openprivacy.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Ted Husted <hu...@apache.org> writes:
> Vincent Massol wrote:
> > Have you checked Scaffold (built by Ted Husted) in the contrib directory
> > of Struts (http://cvs.apache.org/viewcvs/jakarta-struts/contrib/) ? It
> > does a bit of what you'd like although maybe not everything.
>
> No! Stop! -- Let Bryan hook up Torque to Struts -- so he can tell me how
> to do it too ;-)
>
> I'm *very* interested in doing more work with Torque, but coming from
> outside a Turbine background, I just don't know where to start ;-(
<snip/>
Hm... I thought it was documented somewhere. I can't find the URL now.
Just initialize Turbine servlet and you can use the Peers normally.
We are doing this in Reptile and we don't use a line from Turbine.
Kevin
- --
Kevin A. Burton ( burton@apache.org, burton@openprivacy.org, burtonator@acm.org )
Location - San Francisco, CA, Cell - 415.595.9965
Jabber - burtonator@jabber.org, Web - http://relativity.yi.org/
You have no chance to survive, make your time. ha ha ha
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Get my public key at: http://relativity.yi.org/pgpkey.txt
iD8DBQE8M+x9AwM6xb2dfE0RAm+qAKCUdlPT1EbpfWjxXuBap79uhnpyxwCglvlk
x3fGOPR9gz5DHodBtKcN0zg=
=qXfL
-----END PGP SIGNATURE-----
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Torque learning curve WAS: RE: Jakarta Persistence Framework?
Posted by Ted Husted <hu...@apache.org>.
Thanks, Erik, that did help. I got Torque to build, but the build-test
failed. I may have to go back and be sure I have the right versions of
all the JARs. It wanted a later version of Village for example, along
with some others that I didn't have handy.
D:\jakarta\CVS\jakarta-turbine-torque\bin\test\rttest\build-torque.xml:97:
taskdef class org.apache.torque.task.TorqueDocumentationTask cannot be
found
--- Nested Exception ---
java.lang.ClassNotFoundException:
org.apache.torque.task.TorqueDocumentationTask
-Ted.
Erik Hatcher wrote:
>
> While I did refer Nick to Torque, I have not had the pleasure of using it
> yet, although I have seen a very impressive demo of it and highly recommend
> it over any of the alternatives I've seen.
>
> Ted, will the JAR's in the lib directory of the torque-2.1 download at
> http://jakarta.apache.org/builds/jakarta-turbine/release/2.1/ do the trick
> for you?
>
> Erik
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Torque learning curve WAS: RE: Jakarta Persistence Framework?
Posted by Erik Hatcher <ja...@ehatchersolutions.com>.
While I did refer Nick to Torque, I have not had the pleasure of using it
yet, although I have seen a very impressive demo of it and highly recommend
it over any of the alternatives I've seen.
Ted, will the JAR's in the lib directory of the torque-2.1 download at
http://jakarta.apache.org/builds/jakarta-turbine/release/2.1/ do the trick
for you?
Erik
----- Original Message -----
From: "Ted Husted" <hu...@apache.org>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Tuesday, January 01, 2002 9:42 AM
Subject: Re: Torque learning curve WAS: RE: Jakarta Persistence Framework?
> Martin Poeschl wrote:
> > there is a testbed in torque cvs (/src/rttest)) ... it runs all
generation tasks and includes a
> > simple app which adds data to the db ...
>
> Has www.working-dogs.com moved? Is that were Village lives? I don't have
> the JAR handy, and the build file wants it. Or is there a WAR for the
> testbed someplace?
>
> -- Ted Husted, Husted dot Com, Fairport NY USA.
> -- Building Java web applications with Struts.
> -- Tel +1 585 737-3463.
> -- Web http://www.husted.com/struts/
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Torque learning curve WAS: RE: Jakarta Persistence Framework?
Posted by Jason van Zyl <jv...@zenplex.com>.
On 1/2/02 2:43 PM, "Ted Husted" <hu...@apache.org> wrote:
> Perhaps you might consider starting a top-level Torque sub-project
> sooner than later, in the hope of attracting volunteers from outside the
> Turbine community, who could help broaden the package.
>
It's definitely part of the overall plan, the decoupling has of course taken
longer than I expected but I do feel it requires some work before even
trying to promote it to top-level subproject. We are actually trying to get
a comprehensive testbed in place so that we can prepare for some aggressive
refactoring and also allow others to contribute in a way where they can be
assured they haven't broken anything. This will definitely help to allow
more people to contribute and hopefully push Torque to critical mass where
it can be a subproject in its own right.
--
jvz.
Jason van Zyl
http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Torque learning curve WAS: RE: Jakarta Persistence Framework?
Posted by Ted Husted <hu...@apache.org>.
Perhaps you might consider starting a top-level Torque sub-project
sooner than later, in the hope of attracting volunteers from outside the
Turbine community, who could help broaden the package.
-Ted.
Jason van Zyl wrote:
>
> On 1/2/02 1:49 PM, "Ted Husted" <hu...@apache.org> wrote:
>
> > Martin Poeschl wrote:
> >>
> >> i send a copy to the turbine list, so we can discuss on the right list ;-)
> >>
> >
> > If the Torque dependancies on Turbine have been removed, perhaps its
> > time to consider transferring Torque et al to the Commons -- then this
> > would be the right list ;-)
>
> Possibly, IMO Torque still has some issues that need to be worked out before
> widespread use. Pluggable connection pools, some very strange initialization
> patterns have to be removed, and the collection of single RDB's peculiar
> features into one location as they are in a couple now. I also have some
> serious problems with it's mode of usage, Torque primarily being a
> datamodel-centric tool as opposed a persistence layer for an object model.
> Right now the object model produced is really a thin veneer over top the
> datamodel (an object produced for each table) which can certainly work in a
> lot of cases but I don't think that's anywhere close to being usable in many
> real world situations.
>
> I also feel that Torque is a little out of scope for a commons package and
> the general feeling within the Turbine group is that Torque should
> eventually become its own project when it leaves the Turbine fold.
>
> > As mentioned, I would be happy to help with the packaging and additional
> > documentation, especially if it were distributed through the Commons.
> >
> >
> > -- Ted Husted, Husted dot Com, Fairport NY USA.
> > -- Building Java web applications with Struts.
> > -- Tel +1 585 737-3463.
> > -- Web http://www.husted.com/struts/
> >
> > --
> > To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> > For additional commands, e-mail: <ma...@jakarta.apache.org>
>
> --
>
> jvz.
>
> Jason van Zyl
>
> http://tambora.zenplex.org
> http://jakarta.apache.org/turbine
> http://jakarta.apache.org/velocity
> http://jakarta.apache.org/alexandria
> http://jakarta.apache.org/commons
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Torque learning curve WAS: RE: Jakarta Persistence Framework?
Posted by "Kevin A. Burton" <bu...@openprivacy.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jason van Zyl <jv...@zenplex.com> writes:
<snip/>
> I also feel that Torque is a little out of scope for a commons package and
> the general feeling within the Turbine group is that Torque should
> eventually become its own project when it leaves the Turbine fold.
<snip/>
I would agree here. Torques complexities really deserve its own 'focus' group,
separation of concerns and all.
- --
Kevin A. Burton ( burton@apache.org, burton@openprivacy.org, burtonator@acm.org )
Location - San Francisco, CA, Cell - 415.595.9965
Jabber - burtonator@jabber.org, Web - http://relativity.yi.org/
We can plant a house, we can build a tree
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Get my public key at: http://relativity.yi.org/pgpkey.txt
iD8DBQE8M+5zAwM6xb2dfE0RAgGVAJ99v3glJxT9nTeLVQ6wR2iKayXCjQCdGvdc
Ibkc8NVEhxfvfUxrD+YjsSk=
=ataD
-----END PGP SIGNATURE-----
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Torque learning curve WAS: RE: Jakarta Persistence Framework?
Posted by Paulo Gaspar <pa...@krankikom.de>.
> Pluggable connection pools...
If you make it use a DataSource to obtain connections then you can use
a DataSource wrapper for the pool and a Connection wrapper for the
pooled connection.
Obvious advantages:
- That is what most database connection pools already do;
- You can always wrap other database connection pools this way;
- You can also use Application Server DataSources.
Have fun,
Paulo Gaspar
http://www.krankikom.de
http://www.ruhronline.de
> -----Original Message-----
> From: Jason van Zyl [mailto:jvanzyl@zenplex.com]
> Sent: Wednesday, January 02, 2002 8:39 PM
> To: Jakarta Commons Developers List
> Subject: Re: Torque learning curve WAS: RE: Jakarta Persistence
> Framework?
>
>
> On 1/2/02 1:49 PM, "Ted Husted" <hu...@apache.org> wrote:
>
> > Martin Poeschl wrote:
> >>
> >> i send a copy to the turbine list, so we can discuss on the
> right list ;-)
> >>
> >
> > If the Torque dependancies on Turbine have been removed, perhaps its
> > time to consider transferring Torque et al to the Commons -- then this
> > would be the right list ;-)
>
> Possibly, IMO Torque still has some issues that need to be worked
> out before
> widespread use. Pluggable connection pools, some very strange
> initialization
> patterns have to be removed, and the collection of single RDB's peculiar
> features into one location as they are in a couple now. I also have some
> serious problems with it's mode of usage, Torque primarily being a
> datamodel-centric tool as opposed a persistence layer for an object model.
> Right now the object model produced is really a thin veneer over top the
> datamodel (an object produced for each table) which can certainly
> work in a
> lot of cases but I don't think that's anywhere close to being
> usable in many
> real world situations.
>
> I also feel that Torque is a little out of scope for a commons package and
> the general feeling within the Turbine group is that Torque should
> eventually become its own project when it leaves the Turbine fold.
>
> > As mentioned, I would be happy to help with the packaging and additional
> > documentation, especially if it were distributed through the Commons.
> >
> >
> > -- Ted Husted, Husted dot Com, Fairport NY USA.
> > -- Building Java web applications with Struts.
> > -- Tel +1 585 737-3463.
> > -- Web http://www.husted.com/struts/
> >
> > --
> > To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
jvz.
Jason van Zyl
http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons
--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Torque learning curve WAS: RE: Jakarta Persistence Framework?
Posted by Jason van Zyl <jv...@zenplex.com>.
On 1/2/02 1:49 PM, "Ted Husted" <hu...@apache.org> wrote:
> Martin Poeschl wrote:
>>
>> i send a copy to the turbine list, so we can discuss on the right list ;-)
>>
>
> If the Torque dependancies on Turbine have been removed, perhaps its
> time to consider transferring Torque et al to the Commons -- then this
> would be the right list ;-)
Possibly, IMO Torque still has some issues that need to be worked out before
widespread use. Pluggable connection pools, some very strange initialization
patterns have to be removed, and the collection of single RDB's peculiar
features into one location as they are in a couple now. I also have some
serious problems with it's mode of usage, Torque primarily being a
datamodel-centric tool as opposed a persistence layer for an object model.
Right now the object model produced is really a thin veneer over top the
datamodel (an object produced for each table) which can certainly work in a
lot of cases but I don't think that's anywhere close to being usable in many
real world situations.
I also feel that Torque is a little out of scope for a commons package and
the general feeling within the Turbine group is that Torque should
eventually become its own project when it leaves the Turbine fold.
> As mentioned, I would be happy to help with the packaging and additional
> documentation, especially if it were distributed through the Commons.
>
>
> -- Ted Husted, Husted dot Com, Fairport NY USA.
> -- Building Java web applications with Struts.
> -- Tel +1 585 737-3463.
> -- Web http://www.husted.com/struts/
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
jvz.
Jason van Zyl
http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Torque learning curve WAS: RE: Jakarta Persistence Framework?
Posted by Ted Husted <hu...@apache.org>.
Martin Poeschl wrote:
>
> i send a copy to the turbine list, so we can discuss on the right list ;-)
>
If the Torque dependancies on Turbine have been removed, perhaps its
time to consider transferring Torque et al to the Commons -- then this
would be the right list ;-)
As mentioned, I would be happy to help with the packaging and additional
documentation, especially if it were distributed through the Commons.
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Building Java web applications with Struts.
-- Tel +1 585 737-3463.
-- Web http://www.husted.com/struts/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Torque learning curve WAS: RE: Jakarta Persistence Framework?
Posted by Martin Poeschl <mp...@marmot.at>.
i send a copy to the turbine list, so we can discuss on the right list ;-)
Ted Husted wrote:
> Thanks, Martin.
>
> Personally, I would say its not so much a documentation issue, as a
> big-picture example issue. I've read the documention, and it looks like
> all the pieces are are there, but I can't see the forest for the trees.
>
> Something I find helpful is to "walk-through" an application. One of the
> first things I did on Struts is do a tour of Craig's example.
>
> http://husted.com/about/scaffolding/example-tour.html
>
> We now bundle this with the example itself in the distribution.
>
> If someone could do a standalone Turbine example in a WAR, I'd be happy
> to do the same here.
i'd be happy to help with the app ;-)
>
> Another early document that I found helpful was a brief but complete
> overview, again to help with the big picture.
>
> http://husted.com/about/scaffolding/overview.htm
>
> If you like, I have a small "article posting" application available.
> Perhaps we could convert this to Torque?
>
> http://husted.com/struts/resources/artimus.zip
i'm converting a swing app i wrote 2 years ago at the moment and it works fine.
if it's finnished i'll take a look at your app
martin
>
>
> -- Ted Husted, Husted dot Com, Fairport NY USA.
> -- Building Java web applications with Struts.
> -- Tel +1 585 737-3463.
> -- Web http://www.husted.com/struts/
>
>
> Martin Poeschl wrote:
>
>>>Has www.working-dogs.com moved? Is that were Village lives? I don't have
>>>the JAR handy, and the build file wants it. Or is there a WAR for the
>>>testbed someplace?
>>>
>>yes village is now on share.whichever.com
>>you should use the latest version from cvs
>>
>>i'll do some documentation work for torque ... it must be easier to start using it!!
>>
>>martin
>>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Torque learning curve WAS: RE: Jakarta Persistence Framework?
Posted by Martin Poeschl <mp...@marmot.at>.
i send a copy to the turbine list, so we can discuss on the right list ;-)
Ted Husted wrote:
> Thanks, Martin.
>
> Personally, I would say its not so much a documentation issue, as a
> big-picture example issue. I've read the documention, and it looks like
> all the pieces are are there, but I can't see the forest for the trees.
>
> Something I find helpful is to "walk-through" an application. One of the
> first things I did on Struts is do a tour of Craig's example.
>
> http://husted.com/about/scaffolding/example-tour.html
>
> We now bundle this with the example itself in the distribution.
>
> If someone could do a standalone Turbine example in a WAR, I'd be happy
> to do the same here.
i'd be happy to help with the app ;-)
>
> Another early document that I found helpful was a brief but complete
> overview, again to help with the big picture.
>
> http://husted.com/about/scaffolding/overview.htm
>
> If you like, I have a small "article posting" application available.
> Perhaps we could convert this to Torque?
>
> http://husted.com/struts/resources/artimus.zip
i'm converting a swing app i wrote 2 years ago at the moment and it works fine.
if it's finnished i'll take a look at your app
martin
>
>
> -- Ted Husted, Husted dot Com, Fairport NY USA.
> -- Building Java web applications with Struts.
> -- Tel +1 585 737-3463.
> -- Web http://www.husted.com/struts/
>
>
> Martin Poeschl wrote:
>
>>>Has www.working-dogs.com moved? Is that were Village lives? I don't have
>>>the JAR handy, and the build file wants it. Or is there a WAR for the
>>>testbed someplace?
>>>
>>yes village is now on share.whichever.com
>>you should use the latest version from cvs
>>
>>i'll do some documentation work for torque ... it must be easier to start using it!!
>>
>>martin
>>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Torque learning curve WAS: RE: Jakarta Persistence Framework?
Posted by Ted Husted <hu...@apache.org>.
Thanks, Martin.
Personally, I would say its not so much a documentation issue, as a
big-picture example issue. I've read the documention, and it looks like
all the pieces are are there, but I can't see the forest for the trees.
Something I find helpful is to "walk-through" an application. One of the
first things I did on Struts is do a tour of Craig's example.
http://husted.com/about/scaffolding/example-tour.html
We now bundle this with the example itself in the distribution.
If someone could do a standalone Turbine example in a WAR, I'd be happy
to do the same here.
Another early document that I found helpful was a brief but complete
overview, again to help with the big picture.
http://husted.com/about/scaffolding/overview.htm
If you like, I have a small "article posting" application available.
Perhaps we could convert this to Torque?
http://husted.com/struts/resources/artimus.zip
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Building Java web applications with Struts.
-- Tel +1 585 737-3463.
-- Web http://www.husted.com/struts/
Martin Poeschl wrote:
> > Has www.working-dogs.com moved? Is that were Village lives? I don't have
> > the JAR handy, and the build file wants it. Or is there a WAR for the
> > testbed someplace?
>
> yes village is now on share.whichever.com
> you should use the latest version from cvs
>
> i'll do some documentation work for torque ... it must be easier to start using it!!
>
> martin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Torque learning curve WAS: RE: Jakarta Persistence Framework?
Posted by Martin Poeschl <mp...@marmot.at>.
Ted Husted wrote:
> Martin Poeschl wrote:
>
>>there is a testbed in torque cvs (/src/rttest)) ... it runs all generation tasks and includes a
>>simple app which adds data to the db ...
>>
>
> Has www.working-dogs.com moved? Is that were Village lives? I don't have
> the JAR handy, and the build file wants it. Or is there a WAR for the
> testbed someplace?
yes village is now on share.whichever.com
you should use the latest version from cvs
i'll do some documentation work for torque ... it must be easier to start using it!!
martin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Torque learning curve WAS: RE: Jakarta Persistence Framework?
Posted by Ted Husted <hu...@apache.org>.
Martin Poeschl wrote:
> there is a testbed in torque cvs (/src/rttest)) ... it runs all generation tasks and includes a
> simple app which adds data to the db ...
Has www.working-dogs.com moved? Is that were Village lives? I don't have
the JAR handy, and the build file wants it. Or is there a WAR for the
testbed someplace?
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Building Java web applications with Struts.
-- Tel +1 585 737-3463.
-- Web http://www.husted.com/struts/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Torque learning curve WAS: RE: Jakarta Persistence Framework?
Posted by Martin Poeschl <mp...@marmot.at>.
Ted Husted wrote:
> Jon Scott Stevens wrote:
>
>>Look at Scarab.
>>
>
> I've got the CVS snapshot from 12/31. There are 193 classes.
>
> Which of those should I look at first if my goal is to use Torque and
> Peers in a simple test project, with maybe one table and no security?
>
> I would in fact like to spend some quality time with Scarab, but that's
> outside the scope of simply learning to use Torque and Peers, which is
> what I would really, really like to do first. (I'm quite sincere about
> all this. I just have to be careful about how I spend my time right
> now.)
>
> If anyone has a simple application that they have done using Torque and
> Peers (perhaps when they were learning it themselves) that they can send
> me in confidence, I will be very eager to use as the base of another
> "cleanroom" example that we could make available publically, and include
> a "tour" as I did with the Struts example application. It's obvious that
> there is some great technology here, and I would love to make it more
> accessible to busy developers (and which of us is not one of those?).
there is a testbed in torque cvs (/src/rttest)) ... it runs all generation tasks and includes a
simple app which adds data to the db ...
martin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Torque learning curve WAS: RE: Jakarta Persistence Framework?
Posted by "Kevin A. Burton" <bu...@openprivacy.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jason van Zyl <jv...@zenplex.com> writes:
<snip/>
> > <snip/>
> >
> > http://reptile.openprivacy.org
> >
> > Doesn't use any Turbine code (we don't need any) and uses Torque by itself.
> >
> > The only thing I did was download torque, symlink the 'src' directory to
> > Reptile's 'src', edited build.properties to reflect my install and just ran
> > 'ant'.
> >
> > The only thing you need to do is init Turbine.
> >
> > TurbineConfig config = new TurbineConfig( ".",
> > "webapps/reptile/WEB-INF/etc/TurbineResources.properties" );
> >
> > config.init();
>
> This is not the correct way to use Torque in a stand-alone fashion, look at
> the tests in the decoupled torque for an example of how to do. I've been
> trying to get rid of TurbineConfig forever.
<snip/>
We are running an older version of Torque..
Kevin
- --
Kevin A. Burton ( burton@apache.org, burton@openprivacy.org, burtonator@acm.org )
Location - San Francisco, CA, Cell - 415.595.9965
Jabber - burtonator@jabber.org, Web - http://relativity.yi.org/
$_='while(read+STDIN,$_,2048){$a=29;$c=142;if((@a=unx"C*",$_)[20]&48){$h=5;
$_=unxb24,join
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Get my public key at: http://relativity.yi.org/pgpkey.txt
iD8DBQE8NLDfAwM6xb2dfE0RAlsdAJ9ZkpEE1HwfEwtVYlmzb2YNTzvyAQCgwdUd
MXJl8L5Id7FJqngh7p2wBwg=
=qiI1
-----END PGP SIGNATURE-----
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Torque learning curve WAS: RE: Jakarta Persistence Framework?
Posted by Jason van Zyl <jv...@zenplex.com>.
On 1/3/02 12:35 AM, "Kevin A. Burton" <bu...@openprivacy.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Ted Husted <hu...@apache.org> writes:
> <snip/>
>
>> If anyone has a simple application that they have done using Torque and
>> Peers (perhaps when they were learning it themselves) that they can send
>> me in confidence, I will be very eager to use as the base of another
>> "cleanroom" example that we could make available publically, and include
>> a "tour" as I did with the Struts example application.
>
> <snip/>
>
> http://reptile.openprivacy.org
>
> Doesn't use any Turbine code (we don't need any) and uses Torque by itself.
>
> The only thing I did was download torque, symlink the 'src' directory to
> Reptile's 'src', edited build.properties to reflect my install and just ran
> 'ant'.
>
> The only thing you need to do is init Turbine.
>
> TurbineConfig config = new TurbineConfig( ".",
> "webapps/reptile/WEB-INF/etc/TurbineResources.properties" );
>
> config.init();
This is not the correct way to use Torque in a stand-alone fashion, look at
the tests in the decoupled torque for an example of how to do. I've been
trying to get rid of TurbineConfig forever.
> Have fun! :)
>
> - --
> Kevin A. Burton ( burton@apache.org, burton@openprivacy.org,
> burtonator@acm.org )
> Location - San Francisco, CA, Cell - 415.595.9965
> Jabber - burtonator@jabber.org, Web - http://relativity.yi.org/
>
> Hiroshima 1945, Czernobyl 1986, Windows 2000
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.6 (GNU/Linux)
> Comment: Get my public key at: http://relativity.yi.org/pgpkey.txt
>
> iD8DBQE8M+2oAwM6xb2dfE0RAqvvAJ4ySVNFupWPrv2U7A+L7NDsxbCQkACgvlgH
> LhM1/rmg3+JVq2nj8k+9AGg=
> =hqSL
> -----END PGP SIGNATURE-----
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
jvz.
Jason van Zyl
http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Torque learning curve WAS: RE: Jakarta Persistence Framework?
Posted by "Kevin A. Burton" <bu...@openprivacy.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Ted Husted <hu...@apache.org> writes:
<snip/>
> If anyone has a simple application that they have done using Torque and
> Peers (perhaps when they were learning it themselves) that they can send
> me in confidence, I will be very eager to use as the base of another
> "cleanroom" example that we could make available publically, and include
> a "tour" as I did with the Struts example application.
<snip/>
http://reptile.openprivacy.org
Doesn't use any Turbine code (we don't need any) and uses Torque by itself.
The only thing I did was download torque, symlink the 'src' directory to
Reptile's 'src', edited build.properties to reflect my install and just ran
'ant'.
The only thing you need to do is init Turbine.
TurbineConfig config = new TurbineConfig( ".", "webapps/reptile/WEB-INF/etc/TurbineResources.properties" );
config.init();
Have fun! :)
- --
Kevin A. Burton ( burton@apache.org, burton@openprivacy.org, burtonator@acm.org )
Location - San Francisco, CA, Cell - 415.595.9965
Jabber - burtonator@jabber.org, Web - http://relativity.yi.org/
Hiroshima 1945, Czernobyl 1986, Windows 2000
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Get my public key at: http://relativity.yi.org/pgpkey.txt
iD8DBQE8M+2oAwM6xb2dfE0RAqvvAJ4ySVNFupWPrv2U7A+L7NDsxbCQkACgvlgH
LhM1/rmg3+JVq2nj8k+9AGg=
=hqSL
-----END PGP SIGNATURE-----
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Torque learning curve WAS: RE: Jakarta Persistence Framework?
Posted by Ted Husted <hu...@apache.org>.
Jon Scott Stevens wrote:
> Look at Scarab.
I've got the CVS snapshot from 12/31. There are 193 classes.
Which of those should I look at first if my goal is to use Torque and
Peers in a simple test project, with maybe one table and no security?
I would in fact like to spend some quality time with Scarab, but that's
outside the scope of simply learning to use Torque and Peers, which is
what I would really, really like to do first. (I'm quite sincere about
all this. I just have to be careful about how I spend my time right
now.)
If anyone has a simple application that they have done using Torque and
Peers (perhaps when they were learning it themselves) that they can send
me in confidence, I will be very eager to use as the base of another
"cleanroom" example that we could make available publically, and include
a "tour" as I did with the Struts example application. It's obvious that
there is some great technology here, and I would love to make it more
accessible to busy developers (and which of us is not one of those?).
-Ted.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Torque learning curve WAS: RE: Jakarta Persistence Framework?
Posted by Jon Scott Stevens <jo...@latchkey.com>.
on 12/31/01 10:06 AM, "Nicholas Lesiecki" <ni...@eblox.com> wrote:
> Amen on the learning curve. Erik Hatcher recommended Torque to me, and I
> tried checking it out...I had no idea where to start.
Look at Scarab.
-jon
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Torque learning curve WAS: RE: Jakarta Persistence Framework?
Posted by Nicholas Lesiecki <ni...@eblox.com>.
Amen on the learning curve. Erik Hatcher recommended Torque to me, and I
tried checking it out...I had no idea where to start. So I'm continuing to
use EJB/CMP--which does in fact work just fine with Struts.
Kudos to all committers on keeping Struts' domain of expertise limited.
Cheers,
nick
-----Original Message-----
From: Ted Husted [mailto:husted@apache.org]
Sent: Monday, December 31, 2001 10:47 AM
To: Jakarta Commons Developers List
Subject: Re: Jakarta Persistence Framework?
Vincent Massol wrote:
> Have you checked Scaffold (built by Ted Husted) in the contrib directory
> of Struts (http://cvs.apache.org/viewcvs/jakarta-struts/contrib/) ? It
> does a bit of what you'd like although maybe not everything.
No! Stop! -- Let Bryan hook up Torque to Struts -- so he can tell me how
to do it too ;-)
I'm *very* interested in doing more work with Torque, but coming from
outside a Turbine background, I just don't know where to start ;-(
Calling any persistence layer from a Struts Action should not be
difficult. The Action just pulls out what is needed from the http layer,
passes it up, and passes back the result. The trick is often finding a
simple enough example. I'm sure Scarab puts Torque through its paces,
but a "Hello World" would be very helpful for a newcomer. (And, of
course, if I ever get past the curve, I'll eagerly provide one of my own
;0)
Most of *really* aren't interested in re-inventing the wheel. Sometimes
it's just hard to find out how the lugnuts are threaded.
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Building Java web applications with Struts.
-- Tel +1 585 737-3463.
-- Web http://www.husted.com/struts/
--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Jakarta Persistence Framework?
Posted by Ted Husted <hu...@apache.org>.
Vincent Massol wrote:
> Have you checked Scaffold (built by Ted Husted) in the contrib directory
> of Struts (http://cvs.apache.org/viewcvs/jakarta-struts/contrib/) ? It
> does a bit of what you'd like although maybe not everything.
No! Stop! -- Let Bryan hook up Torque to Struts -- so he can tell me how
to do it too ;-)
I'm *very* interested in doing more work with Torque, but coming from
outside a Turbine background, I just don't know where to start ;-(
Calling any persistence layer from a Struts Action should not be
difficult. The Action just pulls out what is needed from the http layer,
passes it up, and passes back the result. The trick is often finding a
simple enough example. I'm sure Scarab puts Torque through its paces,
but a "Hello World" would be very helpful for a newcomer. (And, of
course, if I ever get past the curve, I'll eagerly provide one of my own
;0)
Most of *really* aren't interested in re-inventing the wheel. Sometimes
it's just hard to find out how the lugnuts are threaded.
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Building Java web applications with Struts.
-- Tel +1 585 737-3463.
-- Web http://www.husted.com/struts/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Jakarta Persistence Framework?
Posted by Vincent Massol <vm...@octo.com>.
Bryan,
Just some ideas and pointers.
Have you checked Scaffold (built by Ted Husted) in the contrib directory
of Struts (http://cvs.apache.org/viewcvs/jakarta-struts/contrib/) ? It
does a bit of what you'd like although maybe not everything.
It also seems to me that you could use Avalon as the base for your
framework as it already provides the foundation and some services (like
a database connection pool, ...). If you don't know it, I think you
should definitely have a look at it.
My £0.2
-Vincent
> -----Original Message-----
> From: Bryan Field-Elliot [mailto:bryan_lists@netmeme.org]
> Sent: 17 December 2001 17:11
> To: Jakarta Commons Developers List
> Subject: Jakarta Persistence Framework?
>
> Is there a (or plans for a) standardize Jakarta Persistence Framework?
>
> I've built about 7 projects now on EJB, about 4 of them on top of
Struts
> as well. I consider myself an expert at EJB, and I'm also at the point
> where I'm sick of it -- too overkill a framework, too much work to
> establish your entity framework (CMP), and too much "black magic"
under
> the hood of your EJB server.
>
> I've built my own persistence framework which, in my opinion,
> accomplishes the important goals of EJB (from a web app developer
> perspective), and strikes my own balance in terms of what's important
in
> a framework vs. not. Particularly:
>
> - Tied to JDBC, vs. EJB's attempt to abstract it
> - One class per entity, vs. EJB's 3-5 (Home Interface, Remote
Interface,
> Local Interface, Bean Class, and Primary Key)
> - Implicit transaction wrapping at the Struts Action level (including
> commit if the Action succeeds, and rollback if the Action throws an
> exception).
> - Explicit transaction rollback from the Struts Action if desired
> - The same beans can be passed to the View (by way of Request
attributes
> or otherwise), where they become detached and read-only.
> - ~90% of the framework is contained in a single class which any JDBC
> developer should be able to read and understand (vs. EJB -- how many
> classes are there in the JBoss project?)
> - The design goal is, Keep It Simple and underStandable. If you need
> EJB's more advanced features, then go out and use EJB.
> - Data Caching at the app server level should be easy to implement
> within this framework (a least-recently-used and/or a time-to-live
> algorithm, using custom sizes and timeout values which make sense to
the
> developer).
>
> Is there already a Jakarta persistence framework which roughly
> accomplishes these goals? If not, is there interest in starting one?
>
> Regards,
>
> Bryan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Jakarta Persistence Framework?
Posted by Jason van Zyl <jv...@zenplex.com>.
On 12/17/01 1:18 PM, "Bryan Field-Elliot" <br...@netmeme.org> wrote:
> Interesting, I didn't know there were pieces of Turbine which have been
> decoupled from Turbine "proper". It seems like Torque, their persistence
> layer, has been thusly decoupled. I'll take a look.
The services have also been decoupled:
jakarta-turbine-fulcrum
jakarta-turbine-torque
Are the respective repositories. Neither of them have been released though
they have been used in Turbine for a long time. We're trying to clean up the
API and add full unit testing before releasing.
> Thanks,
>
> Bryan
>
>
> On Mon, 2001-12-17 at 11:01, Scott Sanders wrote:
>
>> From: Bryan Field-Elliot [mailto:bryan_lists@netmeme.org]
>> I see where you're going with that...
>>
>> If I understand you correctly, your framework is simpler than
>> mine even
>> -- a pretty thin layer over JDBC, whereby all table access is
>> via generic functions to open a table (or maybe a query?) and
>> iterate through it's raw rows.
>>
>> My framework is closer to EJB -- you end up implementing a
>> class for each table of your database, with getters/setters
>> for every field.
>>
>> However, in the case where you want to iterate through the
>> results of a complex query (perhaps a join across multiple
>> tables), a raw query and iterate over results (like yours)
>> might be more appropriate than an "entity" based approach
>> like mine (and EJB).
>>
>> Still I'm hoping to hear from others as to whether there
>> already is something like this in one of the other Jakarta
>> projects, or maybe even already in the commons/sandbox.
>
> Did you check into Peers in Turbine? Turbine also has a product called
> Torque which generates all the Peer code from an XML file. Perhaps
> there are other solutions in Avalon land?
>
>>
>> Thanks,
>>
>> Bryan
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
>
>
--
jvz.
Jason van Zyl
http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Jakarta Persistence Framework?
Posted by Bryan Field-Elliot <br...@netmeme.org>.
Interesting, I didn't know there were pieces of Turbine which have been
decoupled from Turbine "proper". It seems like Torque, their persistence
layer, has been thusly decoupled. I'll take a look.
Thanks,
Bryan
On Mon, 2001-12-17 at 11:01, Scott Sanders wrote:
> From: Bryan Field-Elliot [mailto:bryan_lists@netmeme.org]
> I see where you're going with that...
>
> If I understand you correctly, your framework is simpler than
> mine even
> -- a pretty thin layer over JDBC, whereby all table access is
> via generic functions to open a table (or maybe a query?) and
> iterate through it's raw rows.
>
> My framework is closer to EJB -- you end up implementing a
> class for each table of your database, with getters/setters
> for every field.
>
> However, in the case where you want to iterate through the
> results of a complex query (perhaps a join across multiple
> tables), a raw query and iterate over results (like yours)
> might be more appropriate than an "entity" based approach
> like mine (and EJB).
>
> Still I'm hoping to hear from others as to whether there
> already is something like this in one of the other Jakarta
> projects, or maybe even already in the commons/sandbox.
Did you check into Peers in Turbine? Turbine also has a product called
Torque which generates all the Peer code from an XML file. Perhaps
there are other solutions in Avalon land?
>
> Thanks,
>
> Bryan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Jakarta Persistence Framework?
Posted by Bryan Field-Elliot <br...@netmeme.org>.
Interesting, I didn't know there were pieces of Turbine which have been
decoupled from Turbine "proper". It seems like Torque, their persistence
layer, has been thusly decoupled. I'll take a look.
Thanks,
Bryan
On Mon, 2001-12-17 at 11:01, Scott Sanders wrote:
> From: Bryan Field-Elliot [mailto:bryan_lists@netmeme.org]
> I see where you're going with that...
>
> If I understand you correctly, your framework is simpler than
> mine even
> -- a pretty thin layer over JDBC, whereby all table access is
> via generic functions to open a table (or maybe a query?) and
> iterate through it's raw rows.
>
> My framework is closer to EJB -- you end up implementing a
> class for each table of your database, with getters/setters
> for every field.
>
> However, in the case where you want to iterate through the
> results of a complex query (perhaps a join across multiple
> tables), a raw query and iterate over results (like yours)
> might be more appropriate than an "entity" based approach
> like mine (and EJB).
>
> Still I'm hoping to hear from others as to whether there
> already is something like this in one of the other Jakarta
> projects, or maybe even already in the commons/sandbox.
Did you check into Peers in Turbine? Turbine also has a product called
Torque which generates all the Peer code from an XML file. Perhaps
there are other solutions in Avalon land?
>
> Thanks,
>
> Bryan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Jakarta Persistence Framework?
Posted by Scott Sanders <ss...@nextance.com>.
> From: Bryan Field-Elliot [mailto:bryan_lists@netmeme.org]
> I see where you're going with that...
>
> If I understand you correctly, your framework is simpler than
> mine even
> -- a pretty thin layer over JDBC, whereby all table access is
> via generic functions to open a table (or maybe a query?) and
> iterate through it's raw rows.
>
> My framework is closer to EJB -- you end up implementing a
> class for each table of your database, with getters/setters
> for every field.
>
> However, in the case where you want to iterate through the
> results of a complex query (perhaps a join across multiple
> tables), a raw query and iterate over results (like yours)
> might be more appropriate than an "entity" based approach
> like mine (and EJB).
>
> Still I'm hoping to hear from others as to whether there
> already is something like this in one of the other Jakarta
> projects, or maybe even already in the commons/sandbox.
Did you check into Peers in Turbine? Turbine also has a product called
Torque which generates all the Peer code from an XML file. Perhaps
there are other solutions in Avalon land?
>
> Thanks,
>
> Bryan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Jakarta Persistence Framework?
Posted by ba...@generationjava.com.
Yeah, my plan for Store was just to model JDBC in an OO way. Anythin table
like.
It's basically to hide SQL. Really just a toy though.
I've done things similar to your system in the past and would be
interested in having such a framework as standard if one doesn't exist.
I'd like to make it one of the outputs from a code generation framework I
have.
Bay
On 17 Dec 2001, Bryan Field-Elliot wrote:
> I see where you're going with that...
>
> If I understand you correctly, your framework is simpler than mine even
> -- a pretty thin layer over JDBC, whereby all table access is via
> generic functions to open a table (or maybe a query?) and iterate
> through it's raw rows.
>
> My framework is closer to EJB -- you end up implementing a class for
> each table of your database, with getters/setters for every field.
>
> However, in the case where you want to iterate through the results of a
> complex query (perhaps a join across multiple tables), a raw query and
> iterate over results (like yours) might be more appropriate than an
> "entity" based approach like mine (and EJB).
>
> Still I'm hoping to hear from others as to whether there already is
> something like this in one of the other Jakarta projects, or maybe even
> already in the commons/sandbox.
>
> Thanks,
>
> Bryan
>
>
>
> On Mon, 2001-12-17 at 10:44, bayard@generationjava.com wrote:
>
> I'm very interested in such a thing. I'm in much of a similar position and
> would like to try and submit design ideas into it.
>
> My biggest problem with Struts was that coders kept passing Form objects
> down to the EJBs, thus tying the EJBs to Struts. So my design there used a
> generic Namespace interface. BeanNamespace, ServletNamespace, MapNamespace
> etc to form nice ways of passing information down to the DAO/EJB/Whatever
> your name is. As a Form is just a Bean, you wrap the Form in a
> BeanNamespace, and pass it to the EJB which takes a Namespace interface.
> It does create a loosely typed system however.
>
> I've been working on a generic Store API with the plan of making life
> amazingly simple. ie) it sits on top of new database format and allows a
> user to do something like:
>
> Store store = new Store(connection);
> Table table = store.open("people");
> RowIterator rows = table.iterator();
> while(rows.hasNext()) {
> Row row = rows.nextRow();
> String name = row.getValue("name");
> }
>
> etc etc. Anyways, currently it sits on top of jdbc and is happy except for
> primary keys which are a bitch.
>
> Namespaces come back into play here to do:
>
> table.storeFromRequest( new ServletNamespace( request ) );
>
> etc etc.
>
> I'm not suggesting this is a good system, just to throw notice of my
> interest in your project into the pot.
>
> Bay
>
> On 17 Dec 2001, Bryan Field-Elliot wrote:
>
> > Is there a (or plans for a) standardize Jakarta Persistence Framework?
> >
> > I've built about 7 projects now on EJB, about 4 of them on top of Struts
> > as well. I consider myself an expert at EJB, and I'm also at the point
> > where I'm sick of it -- too overkill a framework, too much work to
> > establish your entity framework (CMP), and too much "black magic" under
> > the hood of your EJB server.
> >
> > I've built my own persistence framework which, in my opinion,
> > accomplishes the important goals of EJB (from a web app developer
> > perspective), and strikes my own balance in terms of what's important in
> > a framework vs. not. Particularly:
> >
> > - Tied to JDBC, vs. EJB's attempt to abstract it
> > - One class per entity, vs. EJB's 3-5 (Home Interface, Remote Interface,
> > Local Interface, Bean Class, and Primary Key)
> > - Implicit transaction wrapping at the Struts Action level (including
> > commit if the Action succeeds, and rollback if the Action throws an
> > exception).
> > - Explicit transaction rollback from the Struts Action if desired
> > - The same beans can be passed to the View (by way of Request attributes
> > or otherwise), where they become detached and read-only.
> > - ~90% of the framework is contained in a single class which any JDBC
> > developer should be able to read and understand (vs. EJB -- how many
> > classes are there in the JBoss project?)
> > - The design goal is, Keep It Simple and underStandable. If you need
> > EJB's more advanced features, then go out and use EJB.
> > - Data Caching at the app server level should be easy to implement
> > within this framework (a least-recently-used and/or a time-to-live
> > algorithm, using custom sizes and timeout values which make sense to the
> > developer).
> >
> > Is there already a Jakarta persistence framework which roughly
> > accomplishes these goals? If not, is there interest in starting one?
> >
> > Regards,
> >
> > Bryan
> >
> >
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Jakarta Persistence Framework?
Posted by Bryan Field-Elliot <br...@netmeme.org>.
I see where you're going with that...
If I understand you correctly, your framework is simpler than mine even
-- a pretty thin layer over JDBC, whereby all table access is via
generic functions to open a table (or maybe a query?) and iterate
through it's raw rows.
My framework is closer to EJB -- you end up implementing a class for
each table of your database, with getters/setters for every field.
However, in the case where you want to iterate through the results of a
complex query (perhaps a join across multiple tables), a raw query and
iterate over results (like yours) might be more appropriate than an
"entity" based approach like mine (and EJB).
Still I'm hoping to hear from others as to whether there already is
something like this in one of the other Jakarta projects, or maybe even
already in the commons/sandbox.
Thanks,
Bryan
On Mon, 2001-12-17 at 10:44, bayard@generationjava.com wrote:
I'm very interested in such a thing. I'm in much of a similar position and
would like to try and submit design ideas into it.
My biggest problem with Struts was that coders kept passing Form objects
down to the EJBs, thus tying the EJBs to Struts. So my design there used a
generic Namespace interface. BeanNamespace, ServletNamespace, MapNamespace
etc to form nice ways of passing information down to the DAO/EJB/Whatever
your name is. As a Form is just a Bean, you wrap the Form in a
BeanNamespace, and pass it to the EJB which takes a Namespace interface.
It does create a loosely typed system however.
I've been working on a generic Store API with the plan of making life
amazingly simple. ie) it sits on top of new database format and allows a
user to do something like:
Store store = new Store(connection);
Table table = store.open("people");
RowIterator rows = table.iterator();
while(rows.hasNext()) {
Row row = rows.nextRow();
String name = row.getValue("name");
}
etc etc. Anyways, currently it sits on top of jdbc and is happy except for
primary keys which are a bitch.
Namespaces come back into play here to do:
table.storeFromRequest( new ServletNamespace( request ) );
etc etc.
I'm not suggesting this is a good system, just to throw notice of my
interest in your project into the pot.
Bay
On 17 Dec 2001, Bryan Field-Elliot wrote:
> Is there a (or plans for a) standardize Jakarta Persistence Framework?
>
> I've built about 7 projects now on EJB, about 4 of them on top of Struts
> as well. I consider myself an expert at EJB, and I'm also at the point
> where I'm sick of it -- too overkill a framework, too much work to
> establish your entity framework (CMP), and too much "black magic" under
> the hood of your EJB server.
>
> I've built my own persistence framework which, in my opinion,
> accomplishes the important goals of EJB (from a web app developer
> perspective), and strikes my own balance in terms of what's important in
> a framework vs. not. Particularly:
>
> - Tied to JDBC, vs. EJB's attempt to abstract it
> - One class per entity, vs. EJB's 3-5 (Home Interface, Remote Interface,
> Local Interface, Bean Class, and Primary Key)
> - Implicit transaction wrapping at the Struts Action level (including
> commit if the Action succeeds, and rollback if the Action throws an
> exception).
> - Explicit transaction rollback from the Struts Action if desired
> - The same beans can be passed to the View (by way of Request attributes
> or otherwise), where they become detached and read-only.
> - ~90% of the framework is contained in a single class which any JDBC
> developer should be able to read and understand (vs. EJB -- how many
> classes are there in the JBoss project?)
> - The design goal is, Keep It Simple and underStandable. If you need
> EJB's more advanced features, then go out and use EJB.
> - Data Caching at the app server level should be easy to implement
> within this framework (a least-recently-used and/or a time-to-live
> algorithm, using custom sizes and timeout values which make sense to the
> developer).
>
> Is there already a Jakarta persistence framework which roughly
> accomplishes these goals? If not, is there interest in starting one?
>
> Regards,
>
> Bryan
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Jakarta Persistence Framework?
Posted by ba...@generationjava.com.
I'm very interested in such a thing. I'm in much of a similar position and
would like to try and submit design ideas into it.
My biggest problem with Struts was that coders kept passing Form objects
down to the EJBs, thus tying the EJBs to Struts. So my design there used a
generic Namespace interface. BeanNamespace, ServletNamespace, MapNamespace
etc to form nice ways of passing information down to the DAO/EJB/Whatever
your name is. As a Form is just a Bean, you wrap the Form in a
BeanNamespace, and pass it to the EJB which takes a Namespace interface.
It does create a loosely typed system however.
I've been working on a generic Store API with the plan of making life
amazingly simple. ie) it sits on top of new database format and allows a
user to do something like:
Store store = new Store(connection);
Table table = store.open("people");
RowIterator rows = table.iterator();
while(rows.hasNext()) {
Row row = rows.nextRow();
String name = row.getValue("name");
}
etc etc. Anyways, currently it sits on top of jdbc and is happy except for
primary keys which are a bitch.
Namespaces come back into play here to do:
table.storeFromRequest( new ServletNamespace( request ) );
etc etc.
I'm not suggesting this is a good system, just to throw notice of my
interest in your project into the pot.
Bay
On 17 Dec 2001, Bryan Field-Elliot wrote:
> Is there a (or plans for a) standardize Jakarta Persistence Framework?
>
> I've built about 7 projects now on EJB, about 4 of them on top of Struts
> as well. I consider myself an expert at EJB, and I'm also at the point
> where I'm sick of it -- too overkill a framework, too much work to
> establish your entity framework (CMP), and too much "black magic" under
> the hood of your EJB server.
>
> I've built my own persistence framework which, in my opinion,
> accomplishes the important goals of EJB (from a web app developer
> perspective), and strikes my own balance in terms of what's important in
> a framework vs. not. Particularly:
>
> - Tied to JDBC, vs. EJB's attempt to abstract it
> - One class per entity, vs. EJB's 3-5 (Home Interface, Remote Interface,
> Local Interface, Bean Class, and Primary Key)
> - Implicit transaction wrapping at the Struts Action level (including
> commit if the Action succeeds, and rollback if the Action throws an
> exception).
> - Explicit transaction rollback from the Struts Action if desired
> - The same beans can be passed to the View (by way of Request attributes
> or otherwise), where they become detached and read-only.
> - ~90% of the framework is contained in a single class which any JDBC
> developer should be able to read and understand (vs. EJB -- how many
> classes are there in the JBoss project?)
> - The design goal is, Keep It Simple and underStandable. If you need
> EJB's more advanced features, then go out and use EJB.
> - Data Caching at the app server level should be easy to implement
> within this framework (a least-recently-used and/or a time-to-live
> algorithm, using custom sizes and timeout values which make sense to the
> developer).
>
> Is there already a Jakarta persistence framework which roughly
> accomplishes these goals? If not, is there interest in starting one?
>
> Regards,
>
> Bryan
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>