-
1. Re: producing instance to alternate scope
Weld isn't designed for this.
Even if you would hack the session attributes, the bean itself would still be conversation scoped and looked for in the conversation scope on next reference.
I guess it's theoretically possible to change the scope of the bean through hacks but in the future beans will probably be immutable in Weld. Then you might still be able to do it through an extension (or reflection hacks) but the Weld-way would probably be to have a separate session-scoped bean for that usage. Contexts in Seam 2 were more like plain hashmaps that held... whatever they happened to hold at the moment.
-
2. Re: producing instance to alternate scope
Nik, I think you are talking about changing the scope of the produced bean
mid-flight
, when I think@ConversationScoped class Foo { @Produces @SessionScoped Bar bar = new Bar(); }will suffice Arbi's requirements.
-
3. Re: producing instance to alternate scope
Yes, PMuir's solution is basically what I was wondering about. That would work. And what about an API for determining what scope a particular object is in? Or at least viewing all the objects in a specified scope? thx.
-
4. Re: producing instance to alternate scope
Let's say in the same session, I produce Foo instance to conversation context and another Foo instance to session context.
Then later in the same LRC, in a different session-scoped managed bean, session bean, etc. I @Inject Foo foo. But I want to inject the Foo instance in the conversation context. Is this possible?
@SessionScoped class Foo { @Produces @ConversationScoped Bar getBar1() { return new Bar(); } @Produces Bar getBar2() { return new Bar(); } }@SessionScoped class Boo { @Inject Bar bar; // how can I inject the instance from conversation context? } -
5. Re: producing instance to alternate scope
Scope isn't considered in typesafe resolves. Therefore you need some additional qualifier, you can't just @Produces @RequestScoped Foo and @Produces @SessionScoped Foo.
-
6. Re: producing instance to alternate scope
Hmm, can't think of any clean ways of determining the scope of an instance. Short of doing something really ugly involving iterating over the contexts to see where the instance can be found.
-
7. Re: producing instance to alternate scope
how about (via a proxy?) decorating a managed bean with additional behavior like getScope() which allows us to get additional metadata about the managed bean?
Every managed bean should know intrinsically what scope it lives in...
-
8. Re: producing instance to alternate scope
Every managed bean should know intrinsically what scope it lives in...Every strange idea needs one advocate ;-)
-
9. Re: producing instance to alternate scope
Arbi Sookazian wrote on Apr 27, 2010 22:14:
Every managed bean should know intrinsically what scope it lives in...Every Managed Bean does know what scope it lives in. However there is no easy way in the CDI API to discover what Bean<> the current instance is created from. This goes back to adding something like Stuart proposed
@Inject @This Bean bean;