>From what I can tell, code that used to do:    manager.getInstanceByType(clazz) now need to do:    manager.getReference(manager.getBeans(clazz).iterator().next(),clazz); (plus checking that the set contains only one element and throwing an exception if not.) Is that really true?  Is there no more direct way to obtain this in the SPI?  It seems like a pretty common case.  If not, I can have a utility method to do the above in the core, as many things don't cast to ManagerImpl, so I'd rather not put it there. -Clint -- Clint Popetz http://42lines.net Scalable Web Application Development _______________________________________________ webbeans-dev mailing list webbeans-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/webbeans-dev

On Tue, 2009-05-26 at 20:42 -0500, Clint Popetz wrote: > >From what I can tell, code that used to do: > >    manager.getInstanceByType(clazz) > > now need to do: > > > manager.getReference(manager.getBeans(clazz).iterator().next(),clazz); > > (plus checking that the set contains only one element and throwing an > exception if not.) Yes, this is the first case I mentioned earlier that I postponed yesterday.  This is a drastic API difference that does affect many of the other projects too. For the TCK, I was thinking of just adding the corresponding behavior into the abstract test class we use so that the changes are localized to a single line of code (each call to getInstanceByType). Outside of the TCK, I am not sure how much it is used.  And since there will be less of a framework involved in some cases, many instances of the call will need to be replaced with a number of lines of code (a lot of duplicate code as you mentioned above). > > Is that really true?  Is there no more direct way to obtain this in > the SPI?  It seems like a pretty common case.  If not, I can have a > utility method to do the above in the core, as many things don't cast > to ManagerImpl, so I'd rather not put it there. > > -Clint > > > -- > Clint Popetz > http://42lines.net > Scalable Web Application Development > _______________________________________________ > webbeans-dev mailing list > webbeans-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/webbeans-dev _______________________________________________ webbeans-dev mailing list webbeans-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/webbeans-dev

A complex factory method? On 5/27/09, Gavin King <gavin.king(a)gmail.com&gt; wrote: > I don't understand what you would be wanting to do this yourself all > over the place. > > Why on earth are you going to be performing typesafe resolution > manually yourself instead of letting 299 do the injection?! > > What is the usecase for this? Why do you do typesafe resolution at > anything other than an injection point? > > On Wed, May 27, 2009 at 1:15 AM, David Allen <drallendc(a)gmail.com&gt; > wrote: >> On Tue, 2009-05-26 at 20:42 -0500, Clint Popetz wrote: >>>> From what I can tell, code that used to do: >>> >>> manager.getInstanceByType(clazz) >>> >>> now need to do: >>> >>> >>> manager.getReference(manager.getBeans(clazz).iterator().next >>> (),clazz); >>> >>> (plus checking that the set contains only one element and >>> throwing an >>> exception if not.) >> >> Yes, this is the first case I mentioned earlier that I postponed >> yesterday. This is a drastic API difference that does affect many >> of >> the other projects too. >> >> For the TCK, I was thinking of just adding the corresponding >> behavior >> into the abstract test class we use so that the changes are >> localized to >> a single line of code (each call to getInstanceByType). >> >> Outside of the TCK, I am not sure how much it is used. And since >> there >> will be less of a framework involved in some cases, many instances >> of >> the call will need to be replaced with a number of lines of code >> (a lot >> of duplicate code as you mentioned above). >> >>> >>> Is that really true? Is there no more direct way to obtain this in >>> the SPI? It seems like a pretty common case. If not, I can have a >>> utility method to do the above in the core, as many things don't >>> cast >>> to ManagerImpl, so I'd rather not put it there. >>> >>> -Clint >>> >>> >>> -- >>> Clint Popetz >>> http://42lines.net >>> Scalable Web Application Development >>> _______________________________________________ >>> webbeans-dev mailing list >>> webbeans-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/webbeans-dev >> >> _______________________________________________ >> webbeans-dev mailing list >> webbeans-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/webbeans-dev >> > > > > -- > Gavin King > gavin.king(a)gmail.com > http://in.relation.to/Bloggers/Gavin > http://hibernate.org > http://seamframework.org > > _______________________________________________ > webbeans-dev mailing list > webbeans-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/webbeans-dev > -- Sent from my mobile device --- Nik

On Thu, May 28, 2009 at 7:59 AM, Gavin King <gavin.king(a)gmail.com&gt; wrote: > What is a factory method? Why would it not be a producer method that injects > Instance? I meant producer method, of course. I was just looking for a scenario where you would need to examine the existence of several beans before determining what to actually produce. --- Nik

I think the only real use case was more internal. The TCK uses it heavily, so that is where some careful refactoring is needed. It would seem that the core should only be using it for injection. Outside of these cases, I am hoping it was never used since clearly 299 injection would be the correct thing to use. Other than some complicated refactoring, this should not be a real problem. On Thu, 2009-05-28 at 00:28 -0700, Gavin King wrote: > you mean you want to examine the attributes of the Bean object? > > I dunno - I would recommend against writing code like that. > > On Wed, May 27, 2009 at 10:39 PM, Nicklas Karlsson <nickarls(a)gmail.com > > wrote: >> On Thu, May 28, 2009 at 7:59 AM, Gavin King <gavin.king(a)gmail.com&gt; >> wrote: >>> What is a factory method? Why would it not be a producer method >>> that injects >>> Instance? >> >> I meant producer method, of course. >> >> I was just looking for a scenario where you would need to examine >> the >> existence of several beans before determining what to actually >> produce. >> >> --- >> Nik >> > > > _______________________________________________ webbeans-dev mailing list webbeans-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/webbeans-dev

On Thu, May 28, 2009 at 6:35 AM, Pete Muir <pmuir(a)redhat.com&gt; wrote: Yeah, this is used a lot in the TCK, and maybe a bit in addons which enable injection in types WB doesn't know about (?), but I don't think users will hit it. Correct, users really should hit this. It's used heavily in tests, for instance in AbstractWebBeans tests.

It is also used when you are entering from outside the WB environment. You get a handle to manager and lookup the type that gives you entry. For instance, you might look up the Identity component and then invoke some method on it which may trigger a chain of WB injections once "inside".

-Dan -- Dan Allen Senior Software Engineer, Red Hat | Author of Seam in Action http://mojavelinux.com http://mojavelinux.com/seaminaction http://in.relation.to/Bloggers/Dan NOTE: While I make a strong effort to keep up with my email on a daily basis, personal or other work matters can sometimes keep me away from my email. If you contact me, but don't hear back for more than a week, it is very likely that I am excessively backlogged or the message was caught in the spam filters. Please don't hesitate to resend a message if you feel that it did not reach my attention.

On 28 May 2009, at 16:04, Dan Allen wrote: On Thu, May 28, 2009 at 6:35 AM, Pete Muir <pmuir(a)redhat.com&gt; wrote: > Yeah, this is used a lot in the TCK, and maybe a bit in addons which > enable injection in types WB doesn't know about (?), but I don't think users > will hit it. Correct, users really should hit this. It's used heavily in tests, for instance in AbstractWebBeans tests. Hmm, yes you might well want to use this in a standalone, unit test, environment as an entry point.

It is also used when you are entering from outside the WB environment. You get a handle to manager and lookup the type that gives you entry. For instance, you might look up the Identity component and then invoke some method on it which may trigger a chain of WB injections once "inside". Yes, this is addon frameworks, not end users.

On Thu, May 28, 2009 at 11:14 AM, Pete Muir <pmuir(a)redhat.com&gt; wrote: On 28 May 2009, at 16:04, Dan Allen wrote: > On Thu, May 28, 2009 at 6:35 AM, Pete Muir > <pmuir(a)redhat.com&gt; wrote: > Yeah, this is used a lot in the TCK, and maybe a bit > in addons which enable injection in types WB doesn't > know about (?), but I don't think users will hit it. > > Correct, users really should hit this. It's used heavily in > tests, for instance in AbstractWebBeans tests. Hmm, yes you might well want to use this in a standalone, unit test, environment as an entry point. It would be great if we can add a convenience method to AbstractWebBeansTest. That would pretty much clear up any annoyances.

> It is also used when you are entering from outside the WB > environment. You get a handle to manager and lookup the type > that gives you entry. For instance, you might look up the > Identity component and then invoke some method on it which > may trigger a chain of WB injections once "inside". Yes, this is addon frameworks, not end users. Yep, agreed. I've found that injection is sufficient for all but those "entry point" cases. -Dan -- Dan Allen Senior Software Engineer, Red Hat | Author of Seam in Action http://mojavelinux.com http://mojavelinux.com/seaminaction http://in.relation.to/Bloggers/Dan NOTE: While I make a strong effort to keep up with my email on a daily basis, personal or other work matters can sometimes keep me away from my email. If you contact me, but don't hear back for more than a week, it is very likely that I am excessively backlogged or the message was caught in the spam filters. Please don't hesitate to resend a message if you feel that it did not reach my attention.

On Thu, May 28, 2009 at 10:51 AM, David Allen <drallendc(a)gmail.com&gt; wrote: On Thu, 2009-05-28 at 11:43 -0400, Dan Allen wrote: > On Thu, May 28, 2009 at 11:14 AM, Pete Muir <pmuir(a)redhat.com&gt; wrote: > > On 28 May 2009, at 16:04, Dan Allen wrote: > > > On Thu, May 28, 2009 at 6:35 AM, Pete Muir > > <pmuir(a)redhat.com&gt; wrote: > > Yeah, this is used a lot in the TCK, and maybe a bit > > in addons which enable injection in types WB doesn't > > know about (?), but I don't think users will hit it. > > > > Correct, users really should hit this. It's used heavily in > > tests, for instance in AbstractWebBeans tests. > > > Hmm, yes you might well want to use this in a standalone, unit > test, environment as an entry point. > > It would be great if we can add a convenience method to > AbstractWebBeansTest. That would pretty much clear up any annoyances. Yes, that is the plan. Ditto for the TCK abstract test class. I got the TCK compiling locally with the new BeanManager interface, but rather than adding the bridge methods to the old SPI methods in the abstract test class, I added them to a separate utility class, because several things in the TCK that aren't test subclasses use this functionality as well. I can also add a method to the abstract test class to delegate to the utility class. Is that ok?

-Clint > > > > > > It is also used when you are entering from outside the WB > > environment. You get a handle to manager and lookup the type > > that gives you entry. For instance, you might look up the > > Identity component and then invoke some method on it which > > may trigger a chain of WB injections once "inside". > > > Yes, this is addon frameworks, not end users. > > Yep, agreed. I've found that injection is sufficient for all but those > "entry point" cases. > > -Dan > > > -- > Dan Allen > Senior Software Engineer, Red Hat | Author of Seam in Action > > http://mojavelinux.com > http://mojavelinux.com/seaminaction > http://in.relation.to/Bloggers/Dan > > NOTE: While I make a strong effort to keep up with my email on a daily > basis, personal or other work matters can sometimes keep me away > from my email. If you contact me, but don't hear back for more than a > week, > it is very likely that I am excessively backlogged or the message was > caught in the spam filters. Please don't hesitate to resend a message > if > you feel that it did not reach my attention. _______________________________________________ webbeans-dev mailing list webbeans-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/webbeans-dev -- Clint Popetz http://42lines.net Scalable Web Application Development

Sorry to drag this up again, but this has changed now that manager.getReference(...) requires a CreationalContext, about which I know very little. I'll try reading the latest spec soon, but in the meantime if anyone has any silver bullets please let me know. I'm currently using this utility method: public static <T> T getInstanceByType(BeanManager manager, Class<T> type, Annotation... bindings) { return (T)manager.getReference( manager.getBeans(type).iterator().next(), type, null); } Obviously it's that null at the end (where CreationalContext should be) that's causing the problem. Cheers, Pete. On 29/05/2009, at 2:02 AM, David Allen wrote: > On Thu, 2009-05-28 at 10:52 -0500, Clint Popetz wrote: >> >> >> On Thu, May 28, 2009 at 10:51 AM, David Allen <drallendc(a)gmail.com&gt; >> wrote: >> On Thu, 2009-05-28 at 11:43 -0400, Dan Allen wrote: >>> On Thu, May 28, 2009 at 11:14 AM, Pete Muir >> <pmuir(a)redhat.com&gt; wrote: >>> >>> On 28 May 2009, at 16:04, Dan Allen wrote: >>> >>>> On Thu, May 28, 2009 at 6:35 AM, Pete Muir >>>> <pmuir(a)redhat.com&gt; wrote: >>>> Yeah, this is used a lot in the TCK, and >> maybe a bit >>>> in addons which enable injection in types >> WB doesn't >>>> know about (?), but I don't think users >> will hit it. >>>> >>>> Correct, users really should hit this. It's used >> heavily in >>>> tests, for instance in AbstractWebBeans tests. >>> >>> >>> Hmm, yes you might well want to use this in a >> standalone, unit >>> test, environment as an entry point. >>> >>> It would be great if we can add a convenience method to >>> AbstractWebBeansTest. That would pretty much clear up any >> annoyances. >> >> >> Yes, that is the plan. Ditto for the TCK abstract test class. >> >> >> >> I got the TCK compiling locally with the new BeanManager interface, >> but rather than adding the bridge methods to the old SPI methods in >> the abstract test class, I added them to a separate utility class, >> because several things in the TCK that aren't test subclasses use >> this >> functionality as well. >> >> I can also add a method to the abstract test class to delegate to >> the >> utility class. >> >> Is that ok? > > Yeah, that sounds good. Most of our tests do extend an abstract > class, > so I just thought that would be a little cleaner in the code to use a > member method. > >> >> -Clint >> >> >> >>> >>> >>> >>> >>>> It is also used when you are entering from outside >> the WB >>>> environment. You get a handle to manager and >> lookup the type >>>> that gives you entry. For instance, you might look >> up the >>>> Identity component and then invoke some method on >> it which >>>> may trigger a chain of WB injections once >> "inside". >>> >>> >>> Yes, this is addon frameworks, not end users. >>> >>> Yep, agreed. I've found that injection is sufficient for all >> but those >>> "entry point" cases. >>> >>> -Dan >>> >>> >>> -- >>> Dan Allen >>> Senior Software Engineer, Red Hat | Author of Seam in Action >>> >>> http://mojavelinux.com >>> http://mojavelinux.com/seaminaction >>> http://in.relation.to/Bloggers/Dan >>> >>> NOTE: While I make a strong effort to keep up with my email >> on a daily >>> basis, personal or other work matters can sometimes keep me >> away >>> from my email. If you contact me, but don't hear back for >> more than a >>> week, >>> it is very likely that I am excessively backlogged or the >> message was >>> caught in the spam filters. Please don't hesitate to resend >> a message >>> if >>> you feel that it did not reach my attention. >> >> >> >> _______________________________________________ >> webbeans-dev mailing list >> webbeans-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/webbeans-dev >> >> >> >> >> -- >> Clint Popetz >> http://42lines.net >> Scalable Web Application Development > > _______________________________________________ > webbeans-dev mailing list > webbeans-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/webbeans-dev _______________________________________________ webbeans-dev mailing list webbeans-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/webbeans-dev

On Tue, Jul 21, 2009 at 10:50 AM, Peter Royle <howardmoon(a)screamingcoder.com > wrote: Sorry to drag this up again, but this has changed now that manager.getReference(...) requires a CreationalContext, about which I know very little. I'll try reading the latest spec soon, but in the meantime if anyone has any silver bullets please let me know. I'm currently using this utility method: public static <T> T getInstanceByType(BeanManager manager, Class<T> type, Annotation... bindings) { return (T)manager.getReference( manager.getBeans(type).iterator().next(), type, null); } Obviously it's that null at the end (where CreationalContext should be) that's causing the problem. You just use the manager to create a CreationalContext for the bean. beanManager.createCreationalContext(bean) If an instance already exists, the CreationalContext is not used. Someone correct me if I am wrong. -Dan -- Dan Allen Senior Software Engineer, Red Hat | Author of Seam in Action Registered Linux User #231597 http://mojavelinux.com http://mojavelinux.com/seaminaction http://in.relation.to/Bloggers/Dan _______________________________________________ webbeans-dev mailing list webbeans-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/webbeans-dev

>> You just use the manager to create a CreationalContext for the bean. >> >> beanManager.createCreationalContext(bean) >> Sounds like just what I need, thanks. > You should always use the same creational context for the lifecycle > of > the bean instance (for creation and destruction) otherwise generate a > new one. I'm only going to generate the bean once during the life of the app (it's @ApplicationScoped). IIUC, thereafter the CreationalContext should be ignored.

Now, is the CreationalContext then stored with the bean instance and used for destruction automatically (seems that way in AbstractMapContext.destroy(Contexual) )?

Thanks, Pete. > > On 21 Jul 2009, at 16:18, Dan Allen wrote: > >> On Tue, Jul 21, 2009 at 10:50 AM, Peter Royle <howardmoon(a)screamingcoder.com >>> wrote: >> Sorry to drag this up again, but this has changed now that >> manager.getReference(...) requires a CreationalContext, about >> which I >> know very little. I'll try reading the latest spec soon, but in the >> meantime if anyone has any silver bullets please let me know. >> >> I'm currently using this utility method: >> >> public static <T> T getInstanceByType(BeanManager manager, >> Class<T> type, Annotation... bindings) { >> return (T)manager.getReference( >> manager.getBeans(type).iterator().next(), type, >> null); >> } >> >> Obviously it's that null at the end (where CreationalContext should >> be) that's causing the problem. >> >> You just use the manager to create a CreationalContext for the bean. >> >> beanManager.createCreationalContext(bean) >> >> If an instance already exists, the CreationalContext is not used. >> Someone correct me if I am wrong. >> >> -Dan >> >> -- >> Dan Allen >> Senior Software Engineer, Red Hat | Author of Seam in Action >> Registered Linux User #231597 >> >> http://mojavelinux.com >> http://mojavelinux.com/seaminaction >> http://in.relation.to/Bloggers/Dan >> _______________________________________________ >> webbeans-dev mailing list >> webbeans-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/webbeans-dev >