Sure the instance or the instances if multiple qualifiers are available but basically local storage without eviction yes.
Romain Manni-Bucau @rmannibucau http://www.tomitribe.com http://rmannibucau.wordpress.com https://github.com/rmannibucau 2014-11-17 17:45 GMT+01:00 Mark Struberg <[email protected]>: > 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. >>>> > >>>> > >>
