openwebbeans-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Romain Manni-Bucau <rmannibu...@gmail.com>
Subject Re: Performance/design question
Date Mon, 17 Nov 2014 11:03:01 GMT
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 <itsmeden@gmail.com>:
> 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" <struberg@yahoo.de> 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 <itsmeden@gmail.com>
>> >To: "user@openwebbeans.apache.org" <user@openwebbeans.apache.org>
>> >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 itsmeden@gmail.com, and destroy all copies of this
>> >message and any attachments.
>> >
>> >

Mime
View raw message