Not really. There is a away but it's intended for only framework code. The API framework uses it. For regular business logic, I've yet to see any good reason on why you need to look up things in the application context. There is typically a cleaner way.
Darren > On Nov 6, 2013, at 2:19 PM, Prachi Damle <[email protected]> wrote: > > But in general, is there a way to get hold of a particular bean by name or > type? > > -----Original Message----- > From: Prachi Damle > Sent: Wednesday, November 06, 2013 1:19 PM > To: [email protected] > Subject: RE: ComponentContext :: getComponent() ? > > I used to call getComponent() to get the current list of > AffinityGroupProcessors enabled by the admin. The injected processor list was > added later to the class, I think I can use that for this purpose. > > Thanks, > Prachi > -----Original Message----- > From: Darren Shepherd [mailto:[email protected]] > Sent: Tuesday, November 05, 2013 10:09 PM > To: [email protected] > Subject: Re: ComponentContext :: getComponent() ? > > All other uses of getComponent() you listed should work fine. > > In org.apache.cloudstack.affinity.AffinityGroupServiceImpl, why do you even > call getComponent()? You already have a list of AffinityGroupProcessors > injected to the class. Can't you just loop through those? > > Darren > > > On Tue, Nov 5, 2013 at 5:49 PM, Prachi Damle <[email protected]>wrote: > >> Thanks Darren, it is the listAffinityGroupTypes API, specific code is >> in AffinityGroupServiceImpl :: listAffinityGroupTypes() Code lists the >> beans implementing 'AffinityGroupProcessor' adapter interface. >> >> >> I also dug up few other callers that rely on ComponentContext :: >> getComponent()... >> >> com.cloud.baremetal.networkservice.BareMetalResourceBase.fullSync() >> com.cloud.network.NetworkStateListener.pubishOnEventBus(String, >> String, Network, State, State) >> com.cloud.storage.listener.SnapshotStateListener.pubishOnEventBus(Stri >> ng, >> String, Snapshot, State, State) >> com.cloud.vm.UserVmStateListener.pubishOnEventBus(String, String, >> VirtualMachine, State, State) >> com.cloud.storage.listener.VolumeStateListener.pubishOnEventBus(String >> , >> String, Volume, State, State) >> com.cloud.event.AlertGenerator.publishAlertOnEventBus(String, long, >> Long, String, String) >> com.cloud.event.ActionEventUtils.publishOnEventBus(long, long, String, >> String, State, String) >> com.cloud.event.UsageEventUtils.publishUsageEvent(String, Long, Long, >> String, String) >> >> -----Original Message----- >> From: Darren Shepherd [mailto:[email protected]] >> Sent: Tuesday, November 05, 2013 4:40 PM >> To: [email protected] >> Cc: [email protected] >> Subject: Re: ComponentContext :: getComponent() ? >> >> Can you point me to the code that is failing. The short of it is that >> you shouldn't use ComponentContext. If you show me the failing code I >> can offer a better solution or if needed a work around. >> >> Darren >> >>>> On Nov 5, 2013, at 4:18 PM, Prachi Damle <[email protected]> >>> wrote: >>> >>> Hi, >>> >>> Before the Spring modularization, we have some usecases that were >>> using >> the com.cloud.utils.component.ComponentContext class directly to >> inject or to find a bean of given type or name by invoking ComponentContext >> :: >> getComponent(). >>> How should these usecases be ported now after the modularization >> changes? What should we use instead of ComponentContext, to say find >> beans of certain type. >>> >>> This is the root cause for bug >> https://issues.apache.org/jira/browse/CLOUDSTACK-5045 as the code is >> still relying on ComponentContext >>> >>> Thanks, >>> Prachi >>
