I would also like to know about anyone else's experiences with JDO. Martin Farrell wrote:
> Hi > > I spent a lot of time looking into persistence frameworks and frameworks > following my decision to use struts. i eventually chose to use expresso > because it offered a persistence layer independent of the underlying > database, and provided me a suite of admin utilities that would save me time > in having to create these utilities myself. > > My other reason for choosing expresso is that the framework integrates into > struts, and also has an integration path if i need/want to grow my > application along the j2ee path. > > i would be interested in learning more about peoples experience with jdo - > i liked the approach, but feel i dont have enough time to build the > supporting admin utilities for my app > > Martin > > -----Original Message----- > From: Christopher Barham [mailto:[EMAIL PROTECTED]] > Sent: 23 January 2002 09:51 > To: Struts Users Mailing List > Subject: Re: Model Persistence Survey > > Hi, > I really think that Java Data Objects has a big future... see JSR012: > http://www.jcp.org/aboutJava/communityprocess/first/jsr012/index.html > Currently we are evaluating Forte Transparent Persistence, which is a > physical incarnation of Java Data Objects - see > http://java.sun.com/products/jdbc/related.html and > http://access1.sun.com/jdo/ > The Forte stuff (Transparent Persistence) is detailed here: > http://www.sun.com/forte/ffj/resources/articles/jdo.html > > So far it is working very well - Although I have some qualms about byte > code enhancement as the mechanism to get the TP activity into your classes. > If nothing else, it gives you an 'unknown area' to worry about in your code > - For every simple code bug so far we have immediately assumed it is to do > with the 'magic' of TP messing something up - however, in every case, (so > far), it has been a simple non-TP coding error that was the root cause - it > just took longer to track down :-) > > For quick and easy database adhoc code, I have also taken to using TableGen > now and then to ease generation of the JDBC aware base classes - it gives > connection pooling and so on.... It's fairly old, but works nicely with a > minimum of fuss. The only slight problem was that with Oracle you need to > explicitly close the Statement in the disconnect method of the generated > class DatabaseAccess - it took a bit of head scratching to work out where > the dreaded "too many open cursors" error was coming from :-( > http://freespace.virgin.net/joe.carter/TableGen/ > > Regards > > Chris > > > > Struts > > Newsgroup To: > [EMAIL PROTECTED] > (@Basebeans.c cc: > > om) <struts Subject: Re: Model Persistence > Survey > > > 22/01/02 > > 23:55 > > Please > > respond to > > "Struts Users > > Mailing List" > > > > > > Subject: Re: Model Persistence Survey > From: Vic Cekvenich <[EMAIL PROTECTED]> > === > Oh, yeah, Castor gets votes. > > Vic Cekvenich wrote: > > > I do not like surveys. But I would like to get a feel for "How are > > people implementing the model persistence". Sort of a popularity > > contest. Also if you did not like it, how would you do it next time. > > So if you would please respond. > > > > How do you implement model persistence to a SQL DB. > > > > EJB (even for non-midleware needed webapps) > > > > Expreso features > > > > JDBC ResultSet w/ own base class > > > > i Village /Tourge > > > > JDBC RowSet > > ( > http://download-west.oracle.com/otndoc/oracle9i/901_doc/java.901/a90211/rows > et.htm > ) > > > > > > Other? > > Is there another way? > > > > > > Right now I like RowSet, but what is popular out there? > > > > > > > > Currious, TIA > > Vic > > > > ps: maybe one day those "hooks" grow on Sturts, so Struts takes a stance > > on a good aproach for model persistance > > > > -- > To unsubscribe, e-mail: < > mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: < > mailto:[EMAIL PROTECTED]> > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > ** For great Emap magazine subscription & gift offers visit >http://www.emapmagazines.co.uk ** > > -------------------------------------------------------------------------------- > The information in this email is intended only for the addressee(s) named above. > Access to this email by anyone else is unauthorised. > If you are not the intended recipient of this message any disclosure, copying, > distribution or any action taken in reliance on it is prohibited and may be unlawful. > > Emap plc and or its subsidiaries do not warrant that any attachments are free from > viruses or other defects and accept no liability for any losses resulting from > infected email transmissions. > > Please note that any views expressed in this email may be those of the originator > and do not necessarily reflect those of this organisation. > -------------------------------------------------------------------------------- > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- Pete Carapetyan http://datafundamentals.com Java Development Services Open standards technology for commercial profitability -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
