Ok, I would think that some language in the spec to hint at this might be good, as instances of session beans elsewhere in the spec implies a EJB reference. On 29 Mar 2009, at 18:04, Gavin King wrote: > Yes, this is a good question - the 299 implementation would need > direct integration with the EJB container for this. (Not the only > place this is needed.) > > > On Sat, Mar 28, 2009 at 7:18 PM, Pete Muir <pmuir(a)redhat.com&gt; wrote: >> Hey >> >> Not quite sure how this is supposed to work as everywhere we hold a >> reference (proxy) to the EJB, and therefore don't have access to the >> instance and therefore can't get hold of the fields. Any pointers? >> >> Thanks! >> >> >> -- >> Pete Muir >> http://www.seamframework.org >> http://in.relation.to/Bloggers/Pete >> >> > > > > -- > Gavin King > gavin.king(a)gmail.com > http://in.relation.to/Bloggers/Gavin > http://hibernate.org > http://seamframework.org -- Pete Muir http://www.seamframework.org http://in.relation.to/Bloggers/Pete _______________________________________________ webbeans-dev mailing list webbeans-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/webbeans-dev

On Apr 6, 2009, at 12:31 PM, Pete Muir wrote: > Carlo, Ken, Andrew, > > JSR-299 supports the notion of a producer field. By adding the > annotation @Produces to a field, you make it into a bean, which can > be used as the source of injections. The field can also be > associated with a scope. When you first look up an instance of a > bean, the field value is accessed, and stored in the context for > it's lifetime. > > As we deal with EJB references, we can't directly access the field > value (using reflection) so I think we should use the SPI here. > > I propose we add a method with this signature to the > SessionObjectReference we previously created for the purpose of > casting/removing EJBs https://svn.jboss.org/repos/webbeans/ri/trunk/spi/src/main/java/org/jboss... There isn't necessarily a one-to-one relationship between an ejb reference and a bean instance. For stateless session beans, any one of the bean instances can be used for any invocation. Can't this behavior be handled by the web beans interceptor? By definition, each interceptor instance has the same life cycle as its associated bean instance, and the bean instance is available via the Interceptor InvocationContext.

> > /** > * Retrieve the value of a (possibly private) field > * > * @param field > * the field to retrieve the value of > * @return the retrieved value > * @throws IllegalArgumentException > * if the field doesn't exist on this session object > instance > */ > public Object getFieldValue(Field field); > > Any comments? > > > On 29 Mar 2009, at 22:57, Pete Muir wrote: > >> Ok, I would think that some language in the spec to hint at this >> might be good, as instances of session beans elsewhere in the spec >> implies a EJB reference. >> >> On 29 Mar 2009, at 18:04, Gavin King wrote: >> >>> Yes, this is a good question - the 299 implementation would need >>> direct integration with the EJB container for this. (Not the only >>> place this is needed.) >>> >>> >>> On Sat, Mar 28, 2009 at 7:18 PM, Pete Muir <pmuir(a)redhat.com&gt; >>> wrote: >>>> Hey >>>> >>>> Not quite sure how this is supposed to work as everywhere we >>>> hold a >>>> reference (proxy) to the EJB, and therefore don't have access to >>>> the >>>> instance and therefore can't get hold of the fields. Any pointers? >>>> >>>> Thanks! >>>> >>>> >>>> -- >>>> Pete Muir >>>> http://www.seamframework.org >>>> http://in.relation.to/Bloggers/Pete >>>> >>>> >>> >>> >>> >>> -- >>> Gavin King >>> gavin.king(a)gmail.com >>> http://in.relation.to/Bloggers/Gavin >>> http://hibernate.org >>> http://seamframework.org >> >> -- >> Pete Muir >> http://www.seamframework.org >> http://in.relation.to/Bloggers/Pete >> >> _______________________________________________ >> webbeans-dev mailing list >> webbeans-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/webbeans-dev > > -- > Pete Muir > http://www.seamframework.org > http://in.relation.to/Bloggers/Pete > _______________________________________________ webbeans-dev mailing list webbeans-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/webbeans-dev

I thought through this some, and bounced ideas off Andy. Gavin, I'm not sure that producer fields on SLSBs makes much sense - SLSBs instance state is undefined I think (some EJB expert correct if I'm wrong ;-). I think the spec should say that the behaviour of producer fields on SLSBs is undefined. Assuming the above, I would still argue for a getFieldValue SPI that throws IllegalStateException if invoked on an SLSB reference - and I think this removes the issue Ken has with a many-to-one instances.

I'm slipping this for the upcoming release as we are too far from consensus. On 6 Apr 2009, at 18:22, Pete Muir wrote: > > On 6 Apr 2009, at 18:00, Kenneth Saks wrote: > >> >> On Apr 6, 2009, at 12:31 PM, Pete Muir wrote: >> >>> Carlo, Ken, Andrew, >>> >>> JSR-299 supports the notion of a producer field. By adding the >>> annotation @Produces to a field, you make it into a bean, which can >>> be used as the source of injections. The field can also be >>> associated with a scope. When you first look up an instance of a >>> bean, the field value is accessed, and stored in the context for >>> it's lifetime. >>> >>> As we deal with EJB references, we can't directly access the field >>> value (using reflection) so I think we should use the SPI here. >>> >>> I propose we add a method with this signature to the >>> SessionObjectReference we previously created for the purpose of >>> casting/removing EJBs >>> https://svn.jboss.org/repos/webbeans/ri/trunk/spi/src/main/java/org/jboss... >>> >> >> There isn't necessarily a one-to-one relationship between an ejb >> reference and a bean instance. For stateless session beans, any one >> of the bean instances can be used for any invocation. >> >> Can't this behavior be handled by the web beans interceptor? By >> definition, each interceptor instance has the same life cycle as its >> associated bean instance, and the bean instance is available via the >> Interceptor InvocationContext. > > I did consider this, but not sure how to retrieve the result > invocationContext.getTarget() at the time it is needed for accessing > the producer field. We can't just store it from the construction point > onwards (serializability) and I can't see a way to access it at some > other point in the lifecycle - the only way to run an @AroundInvoke is > to call a method, and in this case which method would you run, and how > would you guarantee it has no side effects? > >> >> >>> >>> /** >>> * Retrieve the value of a (possibly private) field >>> * >>> * @param field >>> * the field to retrieve the value of >>> * @return the retrieved value >>> * @throws IllegalArgumentException >>> * if the field doesn't exist on this session object >>> instance >>> */ >>> public Object getFieldValue(Field field); >>> >>> Any comments? >>> >>> >>> On 29 Mar 2009, at 22:57, Pete Muir wrote: >>> >>>> Ok, I would think that some language in the spec to hint at this >>>> might be good, as instances of session beans elsewhere in the spec >>>> implies a EJB reference. >>>> >>>> On 29 Mar 2009, at 18:04, Gavin King wrote: >>>> >>>>> Yes, this is a good question - the 299 implementation would need >>>>> direct integration with the EJB container for this. (Not the only >>>>> place this is needed.) >>>>> >>>>> >>>>> On Sat, Mar 28, 2009 at 7:18 PM, Pete Muir <pmuir(a)redhat.com&gt; wrote: >>>>>> Hey >>>>>> >>>>>> Not quite sure how this is supposed to work as everywhere we hold a >>>>>> reference (proxy) to the EJB, and therefore don't have access to the >>>>>> instance and therefore can't get hold of the fields. Any pointers? >>>>>> >>>>>> Thanks! >>>>>> >>>>>> >>>>>> -- >>>>>> Pete Muir >>>>>> http://www.seamframework.org >>>>>> http://in.relation.to/Bloggers/Pete >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Gavin King >>>>> gavin.king(a)gmail.com >>>>> http://in.relation.to/Bloggers/Gavin >>>>> http://hibernate.org >>>>> http://seamframework.org >>>> >>>> -- >>>> Pete Muir >>>> http://www.seamframework.org >>>> http://in.relation.to/Bloggers/Pete >>>> >>>> _______________________________________________ >>>> webbeans-dev mailing list >>>> webbeans-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/webbeans-dev >>> >>> -- >>> Pete Muir >>> http://www.seamframework.org >>> http://in.relation.to/Bloggers/Pete >>> >> >> _______________________________________________ >> webbeans-dev mailing list >> webbeans-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/webbeans-dev > > -- > Pete Muir > http://www.seamframework.org > http://in.relation.to/Bloggers/Pete > > _______________________________________________ > webbeans-dev mailing list > webbeans-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/webbeans-dev -- Pete Muir http://www.seamframework.org http://in.relation.to/Bloggers/Pete _______________________________________________ webbeans-dev mailing list webbeans-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/webbeans-dev

Hi Guys, We need to resurrect this discussion.

I've committed a proposed SPI getFieldValue() method to http://anonsvn.jboss.org/repos/webbeans/ri/trunk/spi/src/main/java/org/jb... which I will wire into Web Beans now. Can anyone say if they vehemently disagree with this approach, or have some improvements to suggest? :-) Thanks! Pete On 16 Apr 2009, at 07:51, Andrew Lee Rubinger wrote: > Pete Muir wrote: >> I thought through this some, and bounced ideas off Andy. >> Gavin, I'm not sure that producer fields on SLSBs makes much sense >> - SLSBs instance state is undefined I think (some EJB expert >> correct if I'm wrong ;-). I think the spec should say that the >> behaviour of producer fields on SLSBs is undefined. >> Assuming the above, I would still argue for a getFieldValue SPI >> that throws IllegalStateException if invoked on an SLSB reference >> - and I think this removes the issue Ken has with a many-to-one >> instances. > > UnsupportedOperationException perhaps? > >> I'm slipping this for the upcoming release as we are too far from >> consensus. >> On 6 Apr 2009, at 18:22, Pete Muir wrote: >>> >>> On 6 Apr 2009, at 18:00, Kenneth Saks wrote: >>> >>>> >>>> On Apr 6, 2009, at 12:31 PM, Pete Muir wrote: >>>> >>>>> Carlo, Ken, Andrew, >>>>> >>>>> JSR-299 supports the notion of a producer field. By adding the >>>>> annotation @Produces to a field, you make it into a bean, which >>>>> can be used as the source of injections. The field can also be >>>>> associated with a scope. When you first look up an instance of >>>>> a bean, the field value is accessed, and stored in the context >>>>> for it's lifetime. >>>>> >>>>> As we deal with EJB references, we can't directly access the >>>>> field value (using reflection) so I think we should use the SPI >>>>> here. >>>>> >>>>> I propose we add a method with this signature to the >>>>> SessionObjectReference we previously created for the purpose of >>>>> casting/removing EJBs https://svn.jboss.org/repos/webbeans/ri/trunk/spi/src/main/java/org/jboss... >>>> >>>> There isn't necessarily a one-to-one relationship between an ejb >>>> reference and a bean instance. For stateless session beans, >>>> any one of the bean instances can be used for any invocation. >>>> >>>> Can't this behavior be handled by the web beans interceptor? By >>>> definition, each interceptor instance has the same life cycle as >>>> its associated bean instance, and the bean instance is available >>>> via the Interceptor InvocationContext. >>> >>> I did consider this, but not sure how to retrieve the result >>> invocationContext.getTarget() at the time it is needed for >>> accessing the producer field. We can't just store it from the >>> construction point onwards (serializability) and I can't see a >>> way to access it at some other point in the lifecycle - the only >>> way to run an @AroundInvoke is to call a method, and in this case >>> which method would you run, and how would you guarantee it has no >>> side effects? >>> >>>> >>>> >>>>> >>>>> /** >>>>> * Retrieve the value of a (possibly private) field >>>>> * >>>>> * @param field >>>>> * the field to retrieve the value of >>>>> * @return the retrieved value >>>>> * @throws IllegalArgumentException >>>>> * if the field doesn't exist on this session object >>>>> instance >>>>> */ >>>>> public Object getFieldValue(Field field); >>>>> >>>>> Any comments? >>>>> >>>>> >>>>> On 29 Mar 2009, at 22:57, Pete Muir wrote: >>>>> >>>>>> Ok, I would think that some language in the spec to hint at >>>>>> this might be good, as instances of session beans elsewhere in >>>>>> the spec implies a EJB reference. >>>>>> >>>>>> On 29 Mar 2009, at 18:04, Gavin King wrote: >>>>>> >>>>>>> Yes, this is a good question - the 299 implementation would >>>>>>> need >>>>>>> direct integration with the EJB container for this. (Not the >>>>>>> only >>>>>>> place this is needed.) >>>>>>> >>>>>>> >>>>>>> On Sat, Mar 28, 2009 at 7:18 PM, Pete Muir <pmuir(a)redhat.com&gt; >>>>>>> wrote: >>>>>>>> Hey >>>>>>>> >>>>>>>> Not quite sure how this is supposed to work as everywhere we >>>>>>>> hold a >>>>>>>> reference (proxy) to the EJB, and therefore don't have >>>>>>>> access to the >>>>>>>> instance and therefore can't get hold of the fields. Any >>>>>>>> pointers? >>>>>>>> >>>>>>>> Thanks! >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Pete Muir >>>>>>>> http://www.seamframework.org >>>>>>>> http://in.relation.to/Bloggers/Pete >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Gavin King >>>>>>> gavin.king(a)gmail.com >>>>>>> http://in.relation.to/Bloggers/Gavin >>>>>>> http://hibernate.org >>>>>>> http://seamframework.org >>>>>> >>>>>> -- >>>>>> Pete Muir >>>>>> http://www.seamframework.org >>>>>> http://in.relation.to/Bloggers/Pete >>>>>> >>>>>> _______________________________________________ >>>>>> webbeans-dev mailing list >>>>>> webbeans-dev(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/webbeans-dev >>>>> >>>>> -- >>>>> Pete Muir >>>>> http://www.seamframework.org >>>>> http://in.relation.to/Bloggers/Pete >>>>> >>>> >>>> _______________________________________________ >>>> webbeans-dev mailing list >>>> webbeans-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/webbeans-dev >>> >>> -- >>> Pete Muir >>> http://www.seamframework.org >>> http://in.relation.to/Bloggers/Pete >>> >>> _______________________________________________ >>> webbeans-dev mailing list >>> webbeans-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/webbeans-dev >> -- >> Pete Muir >> http://www.seamframework.org >> http://in.relation.to/Bloggers/Pete >> _______________________________________________ >> webbeans-dev mailing list >> webbeans-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/webbeans-dev > > -- > Andrew Lee Rubinger > Sr. Software Engineer > JBoss, a division of Red Hat, Inc. > http://exitcondition.alrubinger.com > _______________________________________________ > webbeans-dev mailing list > webbeans-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/webbeans-dev

ALR, Carlo, Jaikiran, can one of you join? It's at > Date: Jul 31st 2009 > Time: 9:30 to 10:30am PST > > Dial-in number: > (866) 839-8145 > Intl: (865)524-6352 > Access code: 9032012 On 31 Jul 2009, at 15:57, Kenneth Saks wrote: > > On Jul 31, 2009, at 10:52 AM, Pete Muir wrote: > >> Hi Guys, >> >> We need to resurrect this discussion. > > Why don't we go over this on today's concall. > >> >> I've committed a proposed SPI getFieldValue() method to >> http://anonsvn.jboss.org/repos/webbeans/ri/trunk/spi/src/main/java/org/jb... >> which I will wire into Web Beans now. >> >> Can anyone say if they vehemently disagree with this approach, or >> have some improvements to suggest? :-) >> >> Thanks! >> >> Pete >> >> On 16 Apr 2009, at 07:51, Andrew Lee Rubinger wrote: >> >>> Pete Muir wrote: >>>> I thought through this some, and bounced ideas off Andy. >>>> Gavin, I'm not sure that producer fields on SLSBs makes much sense >>>> - SLSBs instance state is undefined I think (some EJB expert >>>> correct if I'm wrong ;-). I think the spec should say that the >>>> behaviour of producer fields on SLSBs is undefined. >>>> Assuming the above, I would still argue for a getFieldValue SPI >>>> that throws IllegalStateException if invoked on an SLSB reference - >>>> and I think this removes the issue Ken has with a many-to-one >>>> instances. >>> >>> UnsupportedOperationException perhaps? >>> >>>> I'm slipping this for the upcoming release as we are too far from >>>> consensus. >>>> On 6 Apr 2009, at 18:22, Pete Muir wrote: >>>>> >>>>> On 6 Apr 2009, at 18:00, Kenneth Saks wrote: >>>>> >>>>>> >>>>>> On Apr 6, 2009, at 12:31 PM, Pete Muir wrote: >>>>>> >>>>>>> Carlo, Ken, Andrew, >>>>>>> >>>>>>> JSR-299 supports the notion of a producer field. By adding the >>>>>>> annotation @Produces to a field, you make it into a bean, which >>>>>>> can be used as the source of injections. The field can also be >>>>>>> associated with a scope. When you first look up an instance of a >>>>>>> bean, the field value is accessed, and stored in the context for >>>>>>> it's lifetime. >>>>>>> >>>>>>> As we deal with EJB references, we can't directly access the >>>>>>> field value (using reflection) so I think we should use the SPI >>>>>>> here. >>>>>>> >>>>>>> I propose we add a method with this signature to the >>>>>>> SessionObjectReference we previously created for the purpose of >>>>>>> casting/removing EJBs >>>>>>> https://svn.jboss.org/repos/webbeans/ri/trunk/spi/src/main/java/org/jboss... >>>>>>> >>>>>> >>>>>> There isn't necessarily a one-to-one relationship between an ejb >>>>>> reference and a bean instance. For stateless session beans, any >>>>>> one of the bean instances can be used for any invocation. >>>>>> >>>>>> Can't this behavior be handled by the web beans interceptor? By >>>>>> definition, each interceptor instance has the same life cycle as >>>>>> its associated bean instance, and the bean instance is available >>>>>> via the Interceptor InvocationContext. >>>>> >>>>> I did consider this, but not sure how to retrieve the result >>>>> invocationContext.getTarget() at the time it is needed for >>>>> accessing the producer field. We can't just store it from the >>>>> construction point onwards (serializability) and I can't see a way >>>>> to access it at some other point in the lifecycle - the only way >>>>> to run an @AroundInvoke is to call a method, and in this case >>>>> which method would you run, and how would you guarantee it has no >>>>> side effects? >>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> /** >>>>>>> * Retrieve the value of a (possibly private) field >>>>>>> * >>>>>>> * @param field >>>>>>> * the field to retrieve the value of >>>>>>> * @return the retrieved value >>>>>>> * @throws IllegalArgumentException >>>>>>> * if the field doesn't exist on this session object instance >>>>>>> */ >>>>>>> public Object getFieldValue(Field field); >>>>>>> >>>>>>> Any comments? >>>>>>> >>>>>>> >>>>>>> On 29 Mar 2009, at 22:57, Pete Muir wrote: >>>>>>> >>>>>>>> Ok, I would think that some language in the spec to hint at >>>>>>>> this might be good, as instances of session beans elsewhere in >>>>>>>> the spec implies a EJB reference. >>>>>>>> >>>>>>>> On 29 Mar 2009, at 18:04, Gavin King wrote: >>>>>>>> >>>>>>>>> Yes, this is a good question - the 299 implementation would need >>>>>>>>> direct integration with the EJB container for this. (Not the only >>>>>>>>> place this is needed.) >>>>>>>>> >>>>>>>>> >>>>>>>>> On Sat, Mar 28, 2009 at 7:18 PM, Pete Muir <pmuir(a)redhat.com&gt; >>>>>>>>> wrote: >>>>>>>>>> Hey >>>>>>>>>> >>>>>>>>>> Not quite sure how this is supposed to work as everywhere we >>>>>>>>>> hold a >>>>>>>>>> reference (proxy) to the EJB, and therefore don't have access >>>>>>>>>> to the >>>>>>>>>> instance and therefore can't get hold of the fields. Any >>>>>>>>>> pointers? >>>>>>>>>> >>>>>>>>>> Thanks! >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Pete Muir >>>>>>>>>> http://www.seamframework.org >>>>>>>>>> http://in.relation.to/Bloggers/Pete >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Gavin King >>>>>>>>> gavin.king(a)gmail.com >>>>>>>>> http://in.relation.to/Bloggers/Gavin >>>>>>>>> http://hibernate.org >>>>>>>>> http://seamframework.org >>>>>>>> >>>>>>>> -- >>>>>>>> Pete Muir >>>>>>>> http://www.seamframework.org >>>>>>>> http://in.relation.to/Bloggers/Pete >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> webbeans-dev mailing list >>>>>>>> webbeans-dev(a)lists.jboss.org >>>>>>>> https://lists.jboss.org/mailman/listinfo/webbeans-dev >>>>>>> >>>>>>> -- >>>>>>> Pete Muir >>>>>>> http://www.seamframework.org >>>>>>> http://in.relation.to/Bloggers/Pete >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> webbeans-dev mailing list >>>>>> webbeans-dev(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/webbeans-dev >>>>> >>>>> -- >>>>> Pete Muir >>>>> http://www.seamframework.org >>>>> http://in.relation.to/Bloggers/Pete >>>>> >>>>> _______________________________________________ >>>>> webbeans-dev mailing list >>>>> webbeans-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/webbeans-dev >>>> -- >>>> Pete Muir >>>> http://www.seamframework.org >>>> http://in.relation.to/Bloggers/Pete >>>> _______________________________________________ >>>> webbeans-dev mailing list >>>> webbeans-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/webbeans-dev >>> >>> -- >>> Andrew Lee Rubinger >>> Sr. Software Engineer >>> JBoss, a division of Red Hat, Inc. >>> http://exitcondition.alrubinger.com >>> _______________________________________________ >>> webbeans-dev mailing list >>> webbeans-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/webbeans-dev >> >