I believe the Composable/ServiceManager interfaces should be used.
- Dan
Quinton McCombs wrote:
How are you providing access to components/services?
-----Original Message-----
From: Dan Diephouse [mailto:[EMAIL PROTECTED]]
Sent: Sunday, January 26, 2003 8:02 PM
To: [EMAIL PROTECTED]
Subject: Re: Turbine, Fulcrum, and Avalon
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:
<mailto:turbine-dev-> [EMAIL PROTECTED]>
For
additional commands,
e-mail: <mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
