db-torque-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Quinton McCombs" <qmcco...@nequalsone.com>
Subject RE: Torque as an Avalon component ?
Date Thu, 13 Mar 2003 16:25:53 GMT
> -----Original Message-----
> From: Age Mooy [mailto:amooy@home.nl] 
> Sent: Thursday, March 13, 2003 4:17 AM
> To: torque-dev@db.apache.org
> 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: torque-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: torque-dev-help@db.apache.org
> 
> 

Mime
View raw message