Would it be possible to implement a scope that just doesn't store the
instance? It would be like a request scope, except it would just skip adding
it to the context so a new one each time it's accessed.
That's basically how the stateless scope was done in Seam 2. The @Unwrap was
something extra in Seam 2 since the injections were not proxy-based. We can
merge the two ideas into a truly stateless scope since producers create
first-class beans in CDI.
-Dan
On Tue, Jun 8, 2010 at 6:09 AM, Stuart Douglas
<stuart(a)baileyroberts.com.au>wrote:
I just tried to implement this and it did not work, and after looking at
the spec even if it did work I don't think it would be portable due to the
following language:
*Suppose beans **A**, **B **and **Z **all have normal scopes. Suppose **A
**has an injection point **x**, and **B **has an injection point **y**.
Suppose*
*further that both **x **and **y **resolve to bean **Z **according to the
rules of typesafe resolution. If **a **is the current instance of*
*A**, and **b **is the current instance of **B**, then both **a.x **and **b.y
**refer to the same instance of **Z**. This instance is the current
instance*
*of **Z**.*
*
*
*
*
The other way of providing this is to provide an extension that uses
javassist to create @Dependent scoped proxies, these proxies could then call
the producer method on every invocation, however it requires a dependency on
javassist.
Stuart
On 08/06/2010, at 3:19 AM, Pete Muir wrote:
On 7 Jun 2010, at 12:19, Stuart Douglas wrote:
I have been thinking about adding a stateless scope to weld extensions,
that would allow for a similar construct to @Unwrap from seam 2. Basically
if you have a Stateless producer method the the producer will be called
every time a method on the proxy is invoked.
The main downside that I can see is that beans that have a stateless scope
no longer have a well defined lifecycle, so disposal methods etc will not be
called, however as long as this is documented I don't think that this is
much of a problem.
Yeah, I think there is a strong case for providing this.
_______________________________________________
seam-dev mailing list
seam-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://www.google.com/profiles/dan.j.allen