Yes, it works fine on both 2.2.7.Final and 2.2.8.Final
On 12/09/2014 11:22 AM, Steve Millidge wrote:
Hi Jozef,
Thanks for that is it passing on 2.2.7.Final ?
Steve
*From:*Jozef Hartinger [mailto:jharting@redhat.com]
*Sent:* 09 December 2014 09:24
*To:* arjan tijms
*Cc:* Steve Millidge; cdi-dev(a)lists.jboss.org
*Subject:* Re: [cdi-dev] Unexplained change in behavior between Java
EE 6 and Java EE 7
Actually it passes on WF8/9 with the latest version of Weld but fails
with older ones so it seems that it was a regression in Weld after
all. Sorry for confusion.
On 12/08/2014 07:20 PM, arjan tijms wrote:
Hi,
I agree that there should be two instances of the stateful bean,
so GF3/EAP6 is correct.
It's remarkable then that seemingly GF4 and WF8 have the exact
same integration regression.
At any length this would be a good case for adding an extra test
to the TCK ;)
Kind regards,
Arjan
On Monday, December 8, 2014, Jozef Hartinger <jharting(a)redhat.com
<mailto:jharting@redhat.com>> wrote:
Hi Steve,
this is not caused by a change in the specification nor in
Weld. It is probably a regression in GlassFish integration.
The correct behavior is the former (2 instances) as that is
aligned with how @Dependent instances work in general. If you
need the bean instance to be shared across injection points,
you can give it a scope other than @Dependent.
HTH,
Jozef
On 12/08/2014 06:08 PM, Steve Millidge wrote:
Hi
We are investigating a change in behaviour between Java EE
6 and Java EE 7 and were wondering if this is a bug or a
specification change;
If there is a RequestScoped bean and SFSB like below, and
I call invokeStatefulService() on the Request Scoped Bean
the behaviour changes depending on Java EE version;
On GFv3 and JBoss EAP 6 the method returns "init" implying
we have 2 separate SFSB instances.
and on GFv4 and WildFly the method returns
"stateFromFirst" implying there is 1 SFSB instance.
I would’ve imagined that the second result i.e. 1 SFSB as
there is 1 client bean which exists for the duration of
the call is the correct behaviour. However I am not sure.
As both appservers above use JBoss Weld for CDI is this a
Weld bug or did the behaviour change between Java EE 6 and
Java EE 7?
@RequestScoped
public class Injection {
@Inject
StatefulService first;
@Inject
StatefulService second;
public String invokeStatefulService(){
first.setState("stateFromFirst");
return second.getState();
}
}
@Stateful
public class StatefulService {
private String state;
@PostConstruct
public void init(){
this.state = "init";
}
public void setState(String state) {
this.state = state;
}
public String getState() {
return state;
}
}
Steve Millidge
Director
C2B2
*The Leading Independent Middleware Experts.*
T: 08450 539457*|* M: 07920 100626*|* W:
www.c2b2.co.uk
<
http://www.c2b2.co.uk/>*|* E: smillidge(a)c2b2.co.uk
<javascript:_e(%7B%7D,'cvml','smillidge@c2b2.co.uk');>
Main SIgnature May 14
---------------------------------------------------------------------------------------------------------------
C2B2 Consulting Limited, Malvern Hills Science Park,
Geraldine Road, Malvern, Worcestershire, WR14 3SZ
Registered in England and Wales: 4563419, Registered
Office: Ardendale, Old Hollow, Malvern, Worcestershire
_______________________________________________
cdi-dev mailing list
cdi-dev(a)lists.jboss.org
<javascript:_e(%7B%7D,'cvml','cdi-dev@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.