[seam-dev] Stateless scope

[Dan Allen]

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 at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20100608/1c2e7cce/attachment.html