I think though that the shortterm path needs to be removing all the extranous service from Turbine, and getting them all to run as Avalon components in the Fulcrum cvs...
I think we talked about this a while ago, but it kinda fell by the wayside.. Eric -----Original Message----- From: Leandro Rodrigo Saad Cruz [mailto:[EMAIL PROTECTED] Sent: Friday, August 15, 2003 2:25 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [PROPOSAL] Move Torque related classes to seperate turbinemodule. Not a commiter, but here goes my +1. I think turbine should concentrate on routing the process to fulfill the request (Say, using the pipeline metaphore, request dispatcher, etc) and provide a configurable container for components using an arbitrary component model, ala Avalon. The basic configuration should support today's turbine specification (http://jakarta.apache.org/turbine/fsd.html) This is much easier to customize and extend. Do you want a JMX enabled container ? you can ! Do you want another scheduler ? you can ! Do you want another user manager ? you can have it.. Basically the Turbine servlet would initialize the container, the pipelines, etc and route the requests through the right pipeline. The pipeline manager itself could be a component inside the container. The same goes to the request dispatcher, etc ! I've never worked with T3, but I think that was the general idea, and I think it was right, but all services on fulcrum could only be used on turbine+fulcrum (not sure). I think all components developed to be pluged into turbine should be used by other applications too ! On Fri, 2003-08-15 at 08:59, Eric Pugh wrote: > Hi all, > > I have been watching the large numbers of posts about not being able to > build Turbine due to the Torque plugin problems. And while granted, it is > an issue with Maven, I also want to remove the torque jars from my > project.xml since I don't use Turbine's security or the scheduler service. > However, this causes problems because Turbine needs Torque, even when you > don't use it. > > What is stopping us from removing the security code and scheduler service > from Turbine, and putting them in Fulcrum's core? Is it because we are > trying to get to 2.3? Or because no one has tackled the effort? it seems > that now that Torque has been Avalonized (thanks henning) that we should do > the same with the components that use Torque. > > I am willing to signup my name next to this, but I need some confirmation > that this is the path we want, and that we will remove the code from Turbine > that is in Fulcrum. > > As an aside, the duplicated code in Turbine and Fulcrum means that in > Eclipse, when I popup my imports, I am constantly guessing which jar to > import my classes from, Turbine or Fulcrum! > > On a related note, when can we remove the Criteria object from the > interfaces for security like UserManager? I would be willing to live with > Criteria just being an Object, not a criteria, and casting it one way in > DBUserManager, and another way in PassiveUserManager. Heck, then if we had > HibernateUserManager then the criteria object could be a Hibernate HQL > query! > > Frustrated with polluted interfaces, > Eric Pugh > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Leandro Rodrigo Saad Cruz IT - Inter Business Tecnologia e Servicos (IB) http://www.ibnetwork.com.br http://db.apache.org/ojb http://xingu.sourceforge.net --------------------------------------------------------------------- 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]
