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 *|* E: smillidge(a)c2b2.co.uk <javascript:_e(%7B%7D,'cvml','smillidge@c2b2.co.uk');> [image: 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 listcdi-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.

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.

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.