Hi!
Yes, I missed that you changed the test target. It is now not testing proxies but how fast
ApplicationScoped beans injected into other ApplicationScoped beans work.
I agree that this might be a valid performance optimisation, but people should be aware
that this is done. Have seen quite a few 'ServiceHolder' with getters to the
actual services in projects where CDI gets used in companion with legacy frameworks.
I will add this as another use case to the test suite.
LieGrue,
strub
On Tuesday, 21 October 2014, 14:56, Jozef Hartinger
<jharting(a)redhat.com> wrote:
> For certain combinations of scopes this is a perfectly legal
optimization ;-) It's even mentioned in the spec (see 6.5.5).
On 10/21/2014 02:46 PM, Mark Struberg wrote:
> Folks, you really scare me a bit!
>
> I debugged into it and for the first BeanManger#getReference I get a proxy.
>
> But for all other BeanManager#getReference I get the bare metal
SimpleBeanWithoutInterceptor WITHOUT ANY PROXY.
> Can you confirm this?
> If so, then please tell me how you make this Serializable if it gets stored
e.g in a Http Session?
>
>
> This is just not conform to the CDI spec I fear. I even consider this a
blocker bug...
>
> LieGrue,
> strub
>
>
>
>> On Tuesday, 21 October 2014, 14:07, Jozef Hartinger
<jharting(a)redhat.com> wrote:
>>> Btw I've run your benchmark locally and observed the following
results:
>> OWB 1.2.6: 9827ms
>> Weld 2.2.5.Final: 20ms
>>
>> ;-)
>>
>> I did however tweak the test a bit so that Weld's optimizations can
be
>> leveraged[1]. I admit that in certain situations (like your test
without
>> my change) Weld performs worse than it should and this is a good input
>> for us.
>>
>> As for the NPE you observed not sure what is going on there. Perhaps
>> WeldContextControl implementation in DeltaSpike is not really thread
safe?
>>
>> Jozef
>>
>> [1]
https://github.com/jharting/cdi-performance/commits/weld
>>
>> On 10/21/2014 01:43 PM, Jozef Hartinger wrote:
>>> Hi Mark,
>>>
>>> thanks for showcasting your new feature. Great to see OWB getting
>>> faster! As for the micro benchmark I suggest that you check out
JMH[1].
>>>
>>> If you need an input from the Weld team, use
weld-dev(a)lists.jboss.org
>>>
>>> [1]
http://openjdk.java.net/projects/code-tools/jmh/
>>>
>>> On 10/21/2014 11:59 AM, Mark Struberg wrote:
>>>> Hi!
>>>>
>>>> Weld folks, I need some help with a micro benchmark:
>>>>
>>>> You know we've talked about disk footprint in SE, so I
hacked
>> together a small microbenchmark and as a side effect we also got what
is really
>> needed to have CDI running
>>>>
https://github.com/struberg/cdi-performance
>>>>
>>>> I'm curious about missing some dependency excludes for
Weld.
>>>>
>>>> could you please run
>>>>
>>>> $> mvn clean dependency:copy-dependencies
-DincludeScope=compile
>> -PWeld -Dweld.version=2.2.5.Final
>>>> $> ls -al target/dependency/
>>>>
>>>> and tell me which dependencies can be without having some CDI
>> functionality missing?
>>>> Feel free to pimp the pom and ship a pull request.
>>>>
>>>>
>>>> txs and LieGrue,
>>>> strub
>>>> _______________________________________________
>>>> cdi-dev mailing list
>>>> cdi-dev(a)lists.jboss.org
>>>>
https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>
>>>> Note that for all code provided on this list, the provider
licenses the
>> code under the Apache License, Version 2
>> (
http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
provided
>> on this list, the provider waives all patent and other intellectual
property
>> rights inherent in such information.
>>
>>> _______________________________________________
>>> cdi-dev mailing list
>>> cdi-dev(a)lists.jboss.org
>>>
https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>
>>> Note that for all code provided on this list, the provider
licenses the
>> code under the Apache License, Version 2
>> (
http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
provided
>> on this list, the provider waives all patent and other intellectual
property
>> rights inherent in such information.
>>