I guess with 'caching' you mean just storing the Contextual Reference you get from BeanProvider#getContextualReference. In that case +1.
LieGrue, strub ----- Original Message ----- > From: Romain Manni-Bucau <[email protected]> > To: "[email protected]" <[email protected]> > Cc: Mark Struberg <[email protected]> > Sent: Monday, 17 November 2014, 12:03 > Subject: Re: Performance/design question > > 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. >>> > >>> > >
