I can speak for OJB:
Reliability: Very reliable in my experience, and in reports from users. I have used it in high-availability cluster situations and never had cause for complaint.
Performance: Very performant for an O/R mapper, you will always see better performance if you have time to hand craft all your sql though.
Integration with Cocoon: There is a Cocoon block, though I don't use it for using OJB in my Cocoon apps.
Ease of Use: I like using the XDoclet module to make it simple, Antonio is big on generating mappings via Druid, I think, there are additional tools to help with mapping, many of which are described at http://db.apache.org/ojb/howto-build-mappings.html . The client API's are pretty straightforward -- the PB API is the easiest to use, probably, though the ODMG is frequently more comfortable for people who have noever worked with O/R Mapping tools before. Either way, I suggest using either of them against the OTM layer, I am working on expanding OTM docs right now and a few updates are in CVS. Had hoped to check in a good OTM tutorial and overview over the weekend, but it wasn't finished before monday hit. The code is good and works well, the OTM docs are just lacking at the moment because until recently we hadn't decided whether to publicize it or not in 1.0 (we are).
Thank you. It was exactly what I wanted. The best would be to gather similiar opinions and putting them on Wiki.
Sorry, but what is OTM (Object Transaction Manager) layer? I'll check CVS right now and look for the docs.
I've found something interesting in OJB FAQ:
"The OJB JDO implementation is not finished, how can I start using OJB?"
And the answer says about implementing own interface to abstract from persistance API (ODMG, JDO). I like it and also the idea of entities and acitivites, is there example how to implement it in this way?
Regards, mirko
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
