> Is there a good reason to switch from Torque to OJB? Or should I just go > straight for EJB and container-managed persistence?
I don't have any experience with EJB/container-managed stuff, but I don't think I've found an Apache person yet who does like them (or perhaps maybe only the people that don't like EJB speak up). Torque's future is a little hazy in that the 3.0 version is great for most situations. But when you get into advanced stuff like inheritance and the like, Torque needs more finessing, perhaps even on the level of a v4 near rewrite to make it fully mature. This finessing could be done, but the question is whether the rewrite is worth it considering OJB already exists as a mature object persistence framework. In the end, it would be like Regexp and ORO. They both do the same thing, just a little differently, and might as well be the same project. Torque and OJB might as well be the same project, we're just still trying to figure out how to get there. My current approach would be to move all of OJB fledgling forward/reverse SQL generation into Torque, have Torque continue to generate OM classes, but have the guts of the OM classes being driven by OJB calls. I don't know how this will work out project-wise. A new project might be created devoted solely to forward/reverse SQL generation, then both Torque and OJB would use them. Torque would retain the OM generation stuff, but then whether it used the old Peer-based model or deferred to OJB for persistence would still be up in the air. Torque v3 will be around; if you like it, definitely keep using it. We'll still do bug fixes, minor refactorings and what not. And whatever happens, we'll provide some sort of migration path to OJB for Torque users, should it come to that. - Stephen -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
