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:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
