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 <prachi.da...@citrix.com> 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: dev@cloudstack.apache.org > 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:darren.s.sheph...@gmail.com] > Sent: Tuesday, November 05, 2013 10:09 PM > To: dev@cloudstack.apache.org > 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 <prachi.da...@citrix.com>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:darren.s.sheph...@gmail.com] >> Sent: Tuesday, November 05, 2013 4:40 PM >> To: dev@cloudstack.apache.org >> Cc: dev@cloudstack.apache.org >> 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 <prachi.da...@citrix.com> >>> 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 >>
