Hi both will have the same perf more or less. I recommand you to cache the result in another bean if you care since it can be expensive if done by request.
About the algorithm you can have a look to org.apache.webbeans.container.InjectionResolver#implResolveByType(...). Mainly loop over all beans and keep the ones matching the required type. Then we select by qualifier. Romain Manni-Bucau @rmannibucau http://www.tomitribe.com http://rmannibucau.wordpress.com https://github.com/rmannibucau 2014-11-17 12:00 GMT+01:00 Lars-Fredrik Smedberg <[email protected]>: > Hi Mark > > Thanks for your reply, we use the BeanProvider approach for Wink and a > custom UserHandleFactory (since WebSphere 8.5.5 uses Wink) since Wink > creates the factory using new. > > Can you explain how the getBeans lookup works in BeanProvider works? Also > performance wise which is the best would you say? Provider<...> or > BeanProvider? > > Regards > LF > > On Nov 17, 2014 11:23 AM, "Mark Struberg" <[email protected]> wrote: >> >> Hi Lars-Fredrik! >> >> >> The biggest benefit of DeltaSpike BeanProvider is that it uses >> BeanManagerProvider to get the BeanManager. This is really cool if you do >> NOT have access to the BeanManager at first hand. E.g. if you are in places >> where there is no injection available by default, e.g. in a JPA-2.0 >> EntityListener. >> >> The get-me-the-instance-from-the-beanmanager part of DeltaSpike is pretty >> much the same like with Instance<T>. >> How do testimpl1 and testimpl2 look like? You could even @Inject those >> directly. If this is more dynamic then use @Inject Instance<Test> provider; >> for them. Instance extends Provider and adds the ability to dynamically >> iterate over them, etc. >> >> LieGrue, >> strub >> >> >> >> >________________________________ >> > From: Lars-Fredrik Smedberg <[email protected]> >> >To: "[email protected]" <[email protected]> >> >Sent: Monday, 17 November 2014, 9:36 >> >Subject: Performance/design question >> > >> > >> > >> >Hi! >> > >> > >> >We have a @Produces method that produces dependent CDI beans. The objects >> > we produce are depenend since we need to use InjectionPoint to get to the >> > annotations at the injection point. >> > >> > >> >Depending on which annotations are present and their attribute values we >> > choose which implementation to return. >> > >> > >> >Pseudocode, TestImpl1/2 both implement Test ofcourse, we use >> > Provider<...> since we do not want to init both 1 and 2 when we only will >> > return one of them. The implementations both injects other beans, thats why >> > we not create them using "new". >> > >> > >> >@Produces >> >public static Test createTest(Provider<TestImpl1> testImpl1, >> > Provider<TestImpl2> testImpl2, InjectionPoint injectionPoint) { >> > >> > >> > if >> > (injectionPoint.getAnnotated().getAnnotation(TestAnnotation.class).getAttribute().equals(....)) >> > { >> > return testImpl1.get(); >> > } >> > >> > else { >> > return testImpl2.get(); >> > } >> >} >> > >> > >> > >> >Question: >> > >> > >> >1. What is the overhead of using the above approach with Provider<...> >> > and get() on the implementation we eventually will use compared to e.g. >> > DeltaSpikes BeanProvider.getContextualReference ? >> >2. In OWB can someone explain the process that OWB uses internally when >> > getBeans() is called? >> > >> > >> >Regards >> >LF >> > >> >-- >> > >> >Med vänlig hälsning / Best regards >> > >> >Lars-Fredrik Smedberg >> > >> >STATEMENT OF CONFIDENTIALITY: >> >The information contained in this electronic message and any >> >attachments to this message are intended for the exclusive use of the >> >address(es) and may contain confidential or privileged information. If >> >you are not the intended recipient, please notify Lars-Fredrik Smedberg >> >immediately at [email protected], and destroy all copies of this >> >message and any attachments. >> > >> >
