> -----Original Message----- > From: Age Mooy [mailto:[EMAIL PROTECTED] > Sent: Thursday, March 13, 2003 4:17 AM > To: [EMAIL PROTECTED] > Subject: Torque as an Avalon component ? > > > Hi, > > I would like to start converting Torque to Avalon. I know > this topic has been discussed before on torque-dev and > turbine-dev, but I don't think any conclusions have been > reached. Is anyone working on this ?
I was but I have not had time to finish it. Trying to keep full backwards compatibility made it a more involved task than I had originally expected. > As I see it, there are three basic options for making Torque > compatible with Avalon: > > 1) > Write a simple component wrapper around Torque that takes > care of configuration and initialization and delegates all > method calls to the static Torque class. > > 2) > Redesign the current Torque class into a "real" avalon > component implementation, getting rid of all static methods > and Stratum interfaces. This would severely break backwards > compatibility and would need a lot of work, esspecially on > the whole concept of static Peer classes, because then Torque > can only be accessed with the aid of an Avalon > ServiceManager/ServiceSelector > > 3) > Combine 1) and 2) by doing a full implementation not named > Torque.java and making the Torque class a simple static > wrapper that ensures backwards compatibility. The problems > mentioned for option 2 still apply here though. > > Option 3 would keep the most people happy I guess. But option > 2 and 3 require a lot of discussion about the use of static > methods and static Peer classes in Torque, not to mention a > lot of work. One of the biggest questions is: how would > client code that doesn't have access to an Avalon > ServiceManager get access to Torque ? Maybe we could write a > very simple Avalon container You would need one additional class to function as a simple container for Torque when used standalone. > What do you all think ? > > I have time to implement at least option 1 and I need some > way to load torque as a component anyway, so I volunteer for > that. This is what I > propose: > > - a TorqueService interface with non-static versions of the > relevant methods in the Torque class > - a DefaultTorqueService class that implements the Avalon > lifecycle interfaces, and delegates everything to the Torque class > > Would this be acceptable ? Should this go in the > org.apache.torque package or in a sub-package ? TorqueService would go in org.apache.torque. DefaultTorqueService would typically go in a sub-package. I don't think that it really matter right now though. I would say get it working and then look at how things fall out. I would be happy to assist with this. > > Regards, > Age > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
