Stateless scope
---------------

                 Key: WELD-830
                 URL: https://issues.jboss.org/browse/WELD-830
             Project: Weld
          Issue Type: Feature Request
          Components: Scopes & Contexts
            Reporter: Adam Warski


>From a discussion on weld-dev 
>(http://lists.jboss.org/pipermail/weld-dev/2011-January/002825.html):

Here's my use-case:
I have some beans which are inherently stateless, e.g. "services" or factory 
methods. The only fields they have are injected. I am using these beans in 
normal-scoped passivation-capable beans, e.g. session or conversation scoped. 
In such case, they also have to be passivation-capable, which means either
(a) be normal-scoped (proxyable)
(b) implement Serializable and leave the bean dependent-scoped

If I go with (a) this means that I'd have to put my bean in the request, 
session, conversation or application scope. However none of these choices make 
much sense, as they indicate the my beans holds request/session/etc-scoped data 
- which it doesn't, as it is stateless.

So I am left with (b) - implement Serializable + dependent scope. But is that 
the right thing to do always? Firstly, if I have a lot of such stateless beans, 
which are injected one into another, serializing a simple session-scope bean 
may mean that half the beans in my application get serialized. Secondly, a 
developer looking at such a bean could wonder why is this bean serializable? 
Esp if it doesn't have any state?

Hence what I'd like in fact is a proxyable scope (normal), which on 
serialization would only write the proxy information, on de-serialization would 
inject a new instance of the bean (or from a pool), and on injection would 
either behave as dependent (new instance), or take beans from a pool. Just as 
the EJB Stateless scope (except that I don't want to make my bean an EJB).

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        
_______________________________________________
weld-issues mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/weld-issues

Reply via email to