True. I was more asking about how someone would access the Security component. Without the existing Services framework, how would one get the component? Perhaps the Turbine servlet would serve as a fascade to the container for the sole purpose of getting instance of the component and releasing them?
> -----Original Message----- > From: Dan Diephouse [mailto:[EMAIL PROTECTED]] > Sent: Monday, January 27, 2003 9:33 AM > To: [EMAIL PROTECTED] > Subject: Re: Turbine, Fulcrum, and Avalon > > > 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: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]>
