From jharting at redhat.com  Thu Oct  2 12:57:16 2014
From: jharting at redhat.com (Jozef Hartinger)
Date: Thu, 02 Oct 2014 18:57:16 +0200
Subject: [weld-dev] Weld 3.0.0.Alpha1 released
Message-ID: <542D83EC.7000006@redhat.com>

http://weld.cdi-spec.org/news/2014/10/02/weld-300Alpha1/

From jharting at redhat.com  Fri Oct 17 16:22:01 2014
From: jharting at redhat.com (Jozef Hartinger)
Date: Fri, 17 Oct 2014 22:22:01 +0200
Subject: [weld-dev] Weld 2.2.6.Final released
Message-ID: <54417A69.9030903@redhat.com>

http://weld.cdi-spec.org/download/

From struberg at yahoo.de  Tue Oct 21 07:01:21 2014
From: struberg at yahoo.de (Mark Struberg)
Date: Tue, 21 Oct 2014 12:01:21 +0100
Subject: [weld-dev] [cdi-dev] microbenchmark for CDI performance
In-Reply-To: <CAOqetn_ycq58nR02y7sniE1i4KqCaZi+nQ908NAiyS06OM585w@mail.gmail.com>
References: <1413885572.13711.YahooMailNeo@web28905.mail.ir2.yahoo.com>
	<CAOqetn_ycq58nR02y7sniE1i4KqCaZi+nQ908NAiyS06OM585w@mail.gmail.com>
Message-ID: <1413889281.4878.YahooMailNeo@web28906.mail.ir2.yahoo.com>

I was under the impression that weld-dev just got renamed to cdi-dev.

I also got another issue while quickly starting up new threads:

88 [main] INFO org.jboss.weld.Bootstrap - WELD-000101 Transactional services not available. Injection of @Inject UserTransaction not available. Transactional observers will be invoked synchronously.
Exception in thread "Thread-3" java.lang.NullPointerException
    at org.apache.deltaspike.cdise.weld.ContextController.startRequestScope(ContextController.java:147)
    at org.apache.deltaspike.cdise.weld.WeldContextControl.startRequestScope(WeldContextControl.java:161)
    at org.apache.deltaspike.cdise.weld.WeldContextControl.startContext(WeldContextControl.java:70)
    at at.struct.cdi.performance.CdiPerformanceTest$1.run(CdiPerformanceTest.java:56)
    at java.lang.Thread.run(Thread.java:745)

is this a concurrency issue under high load? Or am I just doing something wrong?


LieGrue,
strub





On Tuesday, 21 October 2014, 12:49, John D. Ament <john.d.ament at gmail.com> wrote:


>
>
>Mark,
>
>
>Did you mean to send this to weld-dev instead of cdi-dev? (though I'm not sure if that list is still maintained)
>
>
>At first glance, these look odd:
>
>
>persistence-api-1.0.2.jar
>validation-api-1.0.0.GA.jar
>jboss-ejb-api_3.1_spec-1.0.2.Final.jar
>jboss-el-api_3.0_spec-1.0.0.Alpha1.jar
>
>
>I don't recall them coming in when running SE.
>
>
>On Tue, Oct 21, 2014 at 5:59 AM, Mark Struberg <struberg at yahoo.de> 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 at 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.
>>
>
>
>

From jharting at redhat.com  Tue Oct 21 08:07:04 2014
From: jharting at redhat.com (Jozef Hartinger)
Date: Tue, 21 Oct 2014 14:07:04 +0200
Subject: [weld-dev] [cdi-dev] microbenchmark for CDI performance
In-Reply-To: <544646FD.7090801@redhat.com>
References: <1413885572.13711.YahooMailNeo@web28905.mail.ir2.yahoo.com>
	<544646FD.7090801@redhat.com>
Message-ID: <54464C68.5020105@redhat.com>

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 at 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 at 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 at 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.


From struberg at yahoo.de  Tue Oct 21 08:46:26 2014
From: struberg at yahoo.de (Mark Struberg)
Date: Tue, 21 Oct 2014 13:46:26 +0100
Subject: [weld-dev] [cdi-dev] microbenchmark for CDI performance
In-Reply-To: <54464C68.5020105@redhat.com>
References: <1413885572.13711.YahooMailNeo@web28905.mail.ir2.yahoo.com>
	<544646FD.7090801@redhat.com> <54464C68.5020105@redhat.com>
Message-ID: <1413895586.91151.YahooMailNeo@web28902.mail.ir2.yahoo.com>

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 at 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 at 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 at 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 at 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.
> 

From jharting at redhat.com  Tue Oct 21 08:56:18 2014
From: jharting at redhat.com (Jozef Hartinger)
Date: Tue, 21 Oct 2014 14:56:18 +0200
Subject: [weld-dev] [cdi-dev] microbenchmark for CDI performance
In-Reply-To: <1413895586.91151.YahooMailNeo@web28902.mail.ir2.yahoo.com>
References: <1413885572.13711.YahooMailNeo@web28905.mail.ir2.yahoo.com>
	<544646FD.7090801@redhat.com> <54464C68.5020105@redhat.com>
	<1413895586.91151.YahooMailNeo@web28902.mail.ir2.yahoo.com>
Message-ID: <544657F2.3050604@redhat.com>

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 at 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 at 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 at 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 at 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.
>>


From struberg at yahoo.de  Tue Oct 21 09:24:32 2014
From: struberg at yahoo.de (Mark Struberg)
Date: Tue, 21 Oct 2014 14:24:32 +0100
Subject: [weld-dev] [cdi-dev] microbenchmark for CDI performance
In-Reply-To: <544657F2.3050604@redhat.com>
References: <1413885572.13711.YahooMailNeo@web28905.mail.ir2.yahoo.com>
	<544646FD.7090801@redhat.com> <54464C68.5020105@redhat.com>
	<1413895586.91151.YahooMailNeo@web28902.mail.ir2.yahoo.com>
	<544657F2.3050604@redhat.com>
Message-ID: <1413897872.19084.YahooMailNeo@web28902.mail.ir2.yahoo.com>

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 at 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 at 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 at 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 at 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 at 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.
>>> 
>