Thanks Will see if we can use something like that for our case.
/LF On Mon, Nov 17, 2014 at 1:25 PM, Romain Manni-Bucau <[email protected]> wrote: > public class Foo { > @Inject > private Instance<Bar> barInstance; > private Bar theBar; > > @PostConstruct > private void init() { > thebar = barInstance......get(); > } > } > > > Romain Manni-Bucau > @rmannibucau > http://www.tomitribe.com > http://rmannibucau.wordpress.com > https://github.com/rmannibucau > > > 2014-11-17 13:23 GMT+01:00 Lars-Fredrik Smedberg <[email protected]>: > > Hi Romain > > > > When you say "cache the result in another bean" could you give an > example? > > I'm not sure exactly what you mean and if its applicable in our case. > > > > Regards > > LF > > > > On Mon, Nov 17, 2014 at 12:03 PM, Romain Manni-Bucau < > [email protected]> > > wrote: > >> > >> 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. > >> >> > > >> >> > > > > > > > > > > > -- > > 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. > -- 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.
