You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@turbine.apache.org by Quinton McCombs <qu...@bellsouth.net> on 2003/01/26 19:20:34 UTC
Turbine, Fulcrum, and Avalon
I would like to propose that we drop stop using the strutum lifecyle
interfaces altogether in favor of Avalon's interfaces. Right now
Turbine only using the component loader (Stratum based) for loading
Torque and Fulcrum. To replace this, we should use ECM for loading of
Torque and Fulcrum.
Torque would need to implement Avalon's lifecycle interfaces instead of
Stratum's. A separate message was just posted to the torque-dev about
this.
Turbine's core services could also be loaded as components. This would
virtually do away with the current service loading scheme. All of the
current logic in TurbineServices (and all related service management
code) would be handled by ECM (Avalon's component manager).
Fulcrum currently has it's own ECM that is used load load it's services.
This can still remain in place. When a service is loaded from within
Turbine, the request would go to Turbine's instance of the ECM. If
there is no component loaded with Turbine's ECM that matched the role,
the request would be passed to Fulcrum's ECM.
I think that this can be done without affecting the way that services
are used within Turbine. We can still keep the abstract classes with
static methods that we have in place right now. They will simply pass
the request to obtain a reference to the service to Turbine's ECM.
Since all of our current services are thread safe, there is no need to
pass the component back to the ECM after each use.
The next issue is that of logging. Although ECM 4.1 will not make use
of log4j, the latest development version does appear to do so. I have
played around with this a little but I don't have that working yet.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Turbine, Fulcrum, and Avalon
Posted by Dan Diephouse <da...@envoisolutions.com>.
Leandro Rodrigo Saad Cruz wrote:
>>Fulcrum currently has it's own ECM that is used load load it's services.
>>This can still remain in place. When a service is loaded from within
>>Turbine, the request would go to Turbine's instance of the ECM. If
>>there is no component loaded with Turbine's ECM that matched the role,
>>the request would be passed to Fulcrum's ECM.
>
>
> Why not use only one container ?
>
One container is bad. The user specifies the container to load the
components. Fulcrum is a component repository and not a container
provider. This is especially important because the container situation
is always going to be changing. What happens when the new Avalon 5
container comes out? What about Plexus?
>>I think that this can be done without affecting the way that services
>>are used within Turbine. We can still keep the abstract classes with
>>static methods that we have in place right now. They will simply pass
>>the request to obtain a reference to the service to Turbine's ECM.
>
>
> I think this static accessor should be dropped ! We should use component
> composition instead !
Definitely. See my other message regarding this. Although, I've come
to the conclusion that the security service needs to be totally
rewritten. It uses TurbineSecurity.getXXX() everywhere. This is
horrible component design.
- Dan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Turbine, Fulcrum, and Avalon
Posted by Jason van Zyl <ja...@zenplex.com>.
On Mon, 2003-01-27 at 08:09, Leandro Rodrigo Saad Cruz wrote:
> On Sun, 2003-01-26 at 16:20, Quinton McCombs wrote:
> > I would like to propose that we drop stop using the strutum lifecyle
> > interfaces altogether in favor of Avalon's interfaces.
>
> +++++1
>
> >
> > Fulcrum currently has it's own ECM that is used load load it's services.
> > This can still remain in place. When a service is loaded from within
> > Turbine, the request would go to Turbine's instance of the ECM. If
> > there is no component loaded with Turbine's ECM that matched the role,
> > the request would be passed to Fulcrum's ECM.
>
> Why not use only one container ?
+1
> >
> > I think that this can be done without affecting the way that services
> > are used within Turbine. We can still keep the abstract classes with
> > static methods that we have in place right now. They will simply pass
> > the request to obtain a reference to the service to Turbine's ECM.
>
> I think this static accessor should be dropped ! We should use component
> composition instead !
+1
The static accessors should be dropped ASAP.
--
jvz.
Jason van Zyl
jason@zenplex.com
http://tambora.zenplex.org
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Turbine, Fulcrum, and Avalon
Posted by Gonzalo Diethelm <go...@aditiva.com>.
> On Sun, 2003-01-26 at 16:20, Quinton McCombs wrote:
> > I would like to propose that we drop stop using the stratum lifecyle
> > interfaces altogether in favor of Avalon's interfaces.
+1 (although I think I'm still a committer, I consider my vote
to be non-binding, since it's been REALLY long since I have
contributed anything to Turbine).
>>From what little I understand about all the issues here, I
would try to go with Fortress as a single, unified container
for Turbine; initially, I would keep the static accessors as
a facade, for compatibility reasons, but I think those should
eventually be deprecated.
Regards,
--
Gonzalo A. Diethelm
gonzalo.diethelm@aditiva.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Turbine, Fulcrum, and Avalon
Posted by Leandro Rodrigo Saad Cruz <le...@ibnetwork.com.br>.
On Sun, 2003-01-26 at 16:20, Quinton McCombs wrote:
> I would like to propose that we drop stop using the strutum lifecyle
> interfaces altogether in favor of Avalon's interfaces.
+++++1
>
> Fulcrum currently has it's own ECM that is used load load it's services.
> This can still remain in place. When a service is loaded from within
> Turbine, the request would go to Turbine's instance of the ECM. If
> there is no component loaded with Turbine's ECM that matched the role,
> the request would be passed to Fulcrum's ECM.
Why not use only one container ?
>
> I think that this can be done without affecting the way that services
> are used within Turbine. We can still keep the abstract classes with
> static methods that we have in place right now. They will simply pass
> the request to obtain a reference to the service to Turbine's ECM.
I think this static accessor should be dropped ! We should use component
composition instead !
>
> The next issue is that of logging. Although ECM 4.1 will not make use
> of log4j, the latest development version does appear to do so. I have
> played around with this a little but I don't have that working yet.
I have a LoggerFactory component to use, instead of subclassing
AbstractLogEnabled, but it uses Log4j interfaces and not
commons-logging.
The change from log4j -> commons-logging is in my todo list for a while
now. If its decided that a logger component should be used , I will
change my component to be used inside turbine !
--
Leandro Rodrigo Saad Cruz
IT - Inter Business Tecnologia e Servicos (IB)
http://www.ibnetwork.com.br
http://jakarta.apache.org/ojb
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Turbine, Fulcrum, and Avalon
Posted by Jason van Zyl <ja...@zenplex.com>.
On Sun, 2003-01-26 at 13:20, Quinton McCombs wrote:
> I would like to propose that we drop stop using the strutum lifecyle
> interfaces altogether in favor of Avalon's interfaces.
+1
They should never have been used. I should have used Avalon's lifecycle
interfaces from the start. I have a different opinion of Avalon now :-)
> Right now
> Turbine only using the component loader (Stratum based) for loading
> Torque and Fulcrum. To replace this, we should use ECM for loading of
> Torque and Fulcrum.
Using an existing container for loading components/services is a far
better idea. Remember there is also Plexus which currently supports the
newer Avalon lifecycle (the only change being Serviceable for Compose)
and will be augmented to run ECM and Phoenix components.
There's a Maven plugin for Plexus which allows you to assemble runtimes
from configuration. The plugin also has stubs for components and testing
mechanism for each component you generate using the plugin.
Plexus can run as the whole environment, like an application server, or
you can embed it in something like a servlet. Summit, the refactoring of
t3, can run inside Plexus or have Plexus work inside it which is how
Turbine currently works.
> Torque would need to implement Avalon's lifecycle interfaces instead of
> Stratum's. A separate message was just posted to the torque-dev about
> this.
The more Avalon the better.
> Turbine's core services could also be loaded as components. This would
> virtually do away with the current service loading scheme. All of the
> current logic in TurbineServices (and all related service management
> code) would be handled by ECM (Avalon's component manager).
You could probably get rid of it all together.
>
>
> The next issue is that of logging. Although ECM 4.1 will not make use
> of log4j, the latest development version does appear to do so. I have
> played around with this a little but I don't have that working yet.
Log4j is supported in Plexus.
I haven't taken a look at Fulcrum in a while, but I have ported the
XMLRPC service to Plexus, there's a Scheduler based on Quartz. An EbXml
capable Messenger, a Petrinet-based Workflow Engine, Summit of course, a
Velocity component, and a Jetty component.
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
jvz.
Jason van Zyl
jason@zenplex.com
http://tambora.zenplex.org
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Turbine, Fulcrum, and Avalon
Posted by Dan Diephouse <da...@envoisolutions.com>.
One other thing. Everyone is in for a rude awakening on how much
Fulcrum depends of TurbineServices and TurbineXXX being around.
For example, the Group class in Intake:
TurbineIntake.getGroup(name).init(oids[i], pp)
or the Intake class itself:
String inputKey = TurbineIntake.getGroupKey(groupName)
or DefaultParameterParser:
ArrayList items = TurbineUpload.parseRequest(req);
or TurbineAccessControlList:
return getRoles(TurbineSecurity.getGlobalGroup());
hopefully you get the idea.
- Dan
Dan Diephouse wrote:
> Quinton et al,
>
> I've already started the avalonization. I'm converting the rest of the
> services and doing away with TurbineServices. I'm like 30-40% done. I
> need to still write tests to test all the components and finish
> converting a component or two. It should be done in a few days. I need
> to be able to use it in other containers besides ECM (ie: Plexus which
> Jason is working on) along side my own components.
>
> For the moment I'm using a seperate Torque properties file until the
> Torque people get their thing going with avalon's configuration or some
> other solution is worked out. However, the rest of the properties are
> going to be in the XML file. A properties to XML converter needs to be
> written yet. Maybe someone could start? I won't get around to it for a
> couple days.
>
> - Dan
>
> Quinton McCombs wrote:
>
>> I would like to propose that we drop stop using the strutum lifecyle
>> interfaces altogether in favor of Avalon's interfaces. Right now
>> Turbine only using the component loader (Stratum based) for loading
>> Torque and Fulcrum. To replace this, we should use ECM for loading of
>> Torque and Fulcrum.
>>
>> Torque would need to implement Avalon's lifecycle interfaces instead of
>> Stratum's. A separate message was just posted to the torque-dev about
>> this.
>>
>> Turbine's core services could also be loaded as components. This would
>> virtually do away with the current service loading scheme. All of the
>> current logic in TurbineServices (and all related service management
>> code) would be handled by ECM (Avalon's component manager).
>>
>> Fulcrum currently has it's own ECM that is used load load it's services.
>> This can still remain in place. When a service is loaded from within
>> Turbine, the request would go to Turbine's instance of the ECM. If
>> there is no component loaded with Turbine's ECM that matched the role,
>> the request would be passed to Fulcrum's ECM.
>>
>> I think that this can be done without affecting the way that services
>> are used within Turbine. We can still keep the abstract classes with
>> static methods that we have in place right now. They will simply pass
>> the request to obtain a reference to the service to Turbine's ECM.
>> Since all of our current services are thread safe, there is no need to
>> pass the component back to the ECM after each use.
>>
>>
>>
>> The next issue is that of logging. Although ECM 4.1 will not make use
>> of log4j, the latest development version does appear to do so. I have
>> played around with this a little but I don't have that working yet.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Turbine, Fulcrum, and Avalon
Posted by Dan Diephouse <da...@envoisolutions.com>.
Quinton et al,
I've already started the avalonization. I'm converting the rest of the
services and doing away with TurbineServices. I'm like 30-40% done. I
need to still write tests to test all the components and finish
converting a component or two. It should be done in a few days. I need
to be able to use it in other containers besides ECM (ie: Plexus which
Jason is working on) along side my own components.
For the moment I'm using a seperate Torque properties file until the
Torque people get their thing going with avalon's configuration or some
other solution is worked out. However, the rest of the properties are
going to be in the XML file. A properties to XML converter needs to be
written yet. Maybe someone could start? I won't get around to it for a
couple days.
- Dan
Quinton McCombs wrote:
> I would like to propose that we drop stop using the strutum lifecyle
> interfaces altogether in favor of Avalon's interfaces. Right now
> Turbine only using the component loader (Stratum based) for loading
> Torque and Fulcrum. To replace this, we should use ECM for loading of
> Torque and Fulcrum.
>
> Torque would need to implement Avalon's lifecycle interfaces instead of
> Stratum's. A separate message was just posted to the torque-dev about
> this.
>
> Turbine's core services could also be loaded as components. This would
> virtually do away with the current service loading scheme. All of the
> current logic in TurbineServices (and all related service management
> code) would be handled by ECM (Avalon's component manager).
>
> Fulcrum currently has it's own ECM that is used load load it's services.
> This can still remain in place. When a service is loaded from within
> Turbine, the request would go to Turbine's instance of the ECM. If
> there is no component loaded with Turbine's ECM that matched the role,
> the request would be passed to Fulcrum's ECM.
>
> I think that this can be done without affecting the way that services
> are used within Turbine. We can still keep the abstract classes with
> static methods that we have in place right now. They will simply pass
> the request to obtain a reference to the service to Turbine's ECM.
>
> Since all of our current services are thread safe, there is no need to
> pass the component back to the ECM after each use.
>
>
>
> The next issue is that of logging. Although ECM 4.1 will not make use
> of log4j, the latest development version does appear to do so. I have
> played around with this a little but I don't have that working yet.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>