You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@turbine.apache.org by Leandro Rodrigo Saad Cruz <le...@ibnetwork.com.br> on 2003/08/15 14:25:05 UTC
Re: [PROPOSAL] Move Torque related classes to seperate turbine
module.
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: turbine-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
>
>
--
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: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
[FULCRUM] Migrate Fulcrum components to Avalon... WAS [PROPOSAL] Move Torque related classes to seperate turbine module.
Posted by Eric Pugh <ep...@upstate.com>.
Hi all,
I did a fresh checkout of Fulcrum.. And there are errors all over the
place.. I am somewhat of the opinion that if we can make the consensus that
using components via Avalon is the way forward, then we should delete all
the components that don't compile in Fulcrum, and then start moving
components over from Turbine-2 as a fresh start. While is seems like all
the code in /src/ is some what trashed, it seems like someone (Quinton?) was
setting Fulcrum up to use the maven reactor setup, because there are /pull,
/testcontainer, and /xmlrpc subprojects.
This follows somewhat the pattern of the Xingu project that uses a reactor
to build each component. It means you have lots of little jars, and seems
to help with breaking up all the components, so that Fulcrum doesn't end up
as one "super build"...
To see where this would lead me, I converted the various components that had
unit tests into reactor driven subprojects.
Converted:
/dvsl
/localization
/crypto
I was basically following the style that Quinton established with
testcomponent, pull, and xmlrpc. I fixed a stack of small bugs with those
as well. The whole fulcrum container with the whacky
ServiceBroker/ServiceManager stuff brought over from Turbine core I just
couldn't figure out. So, at this point there are now 5 components that run
as Avalon components, and don't have any dependencies on Turbine. I ended
up not converting the Facade classes for dvsl, localization, and crypto, as
I just could not get my head around them.
To see the build happen, from jakarta-turbine-fulcrum/ run maven build to
see the reactor work. For some reason the reactor can't build the docs, but
you can from each individual directory.
I think this is a viable path forward. I think getting anything that works
in Fulcrum is miles better then the current amazingly sophicsticated and
amazingly broken, hard to grok code in /src/java and /src/test.
I don't know what the deprecation rules are.. But I can't imagine anyone is
successfully using Fulcrum, at least judging by the state of CVS head.
Any feed back would be much appreciated...
Sincerely,
Eric Pugh
-----Original Message-----
From: Eric Pugh [mailto:epugh@upstate.com]
Sent: Friday, August 15, 2003 11:34 PM
To: 'Turbine Developers List'
Subject: RE: [PROPOSAL] Move Torque related classes to seperate
turbinemodule.
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:leandro@ibnetwork.com.br]
Sent: Friday, August 15, 2003 2:25 PM
To: turbine-dev@jakarta.apache.org
Cc: epugh@upstate.com
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: turbine-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
>
>
--
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: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
[FULCRUM] Migrate Fulcrum components to Avalon... WAS [PROPOSAL] Move Torque related classes to seperate turbine module.
Posted by Eric Pugh <ep...@upstate.com>.
Hi all,
I did a fresh checkout of Fulcrum.. And there are errors all over the
place.. I am somewhat of the opinion that if we can make the consensus that
using components via Avalon is the way forward, then we should delete all
the components that don't compile in Fulcrum, and then start moving
components over from Turbine-2 as a fresh start. While is seems like all
the code in /src/ is some what trashed, it seems like someone (Quinton?) was
setting Fulcrum up to use the maven reactor setup, because there are /pull,
/testcontainer, and /xmlrpc subprojects.
This follows somewhat the pattern of the Xingu project that uses a reactor
to build each component. It means you have lots of little jars, and seems
to help with breaking up all the components, so that Fulcrum doesn't end up
as one "super build"...
To see where this would lead me, I converted the various components that had
unit tests into reactor driven subprojects.
Converted:
/dvsl
/localization
/crypto
I was basically following the style that Quinton established with
testcomponent, pull, and xmlrpc. I fixed a stack of small bugs with those
as well. The whole fulcrum container with the whacky
ServiceBroker/ServiceManager stuff brought over from Turbine core I just
couldn't figure out. So, at this point there are now 5 components that run
as Avalon components, and don't have any dependencies on Turbine. I ended
up not converting the Facade classes for dvsl, localization, and crypto, as
I just could not get my head around them.
To see the build happen, from jakarta-turbine-fulcrum/ run maven build to
see the reactor work. For some reason the reactor can't build the docs, but
you can from each individual directory.
I think this is a viable path forward. I think getting anything that works
in Fulcrum is miles better then the current amazingly sophicsticated and
amazingly broken, hard to grok code in /src/java and /src/test.
I don't know what the deprecation rules are.. But I can't imagine anyone is
successfully using Fulcrum, at least judging by the state of CVS head.
Any feed back would be much appreciated...
Sincerely,
Eric Pugh
-----Original Message-----
From: Eric Pugh [mailto:epugh@upstate.com]
Sent: Friday, August 15, 2003 11:34 PM
To: 'Turbine Developers List'
Subject: RE: [PROPOSAL] Move Torque related classes to seperate
turbinemodule.
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:leandro@ibnetwork.com.br]
Sent: Friday, August 15, 2003 2:25 PM
To: turbine-dev@jakarta.apache.org
Cc: epugh@upstate.com
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: turbine-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
>
>
--
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: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
RE: [PROPOSAL] Move Torque related classes to seperate turbinemodule.
Posted by Eric Pugh <ep...@upstate.com>.
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:leandro@ibnetwork.com.br]
Sent: Friday, August 15, 2003 2:25 PM
To: turbine-dev@jakarta.apache.org
Cc: epugh@upstate.com
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: turbine-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
>
>
--
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: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
RE: [PROPOSAL] Move Torque related classes to seperate turbinemodule.
Posted by Eric Pugh <ep...@upstate.com>.
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:leandro@ibnetwork.com.br]
Sent: Friday, August 15, 2003 2:25 PM
To: turbine-dev@jakarta.apache.org
Cc: epugh@upstate.com
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: turbine-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
>
>
--
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: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org