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]>
