]
Adam Warski commented on CDI-37:
--------------------------------
I think that a normal non-passivation capable scope would to the trick. Then the bean
would be proxied, making it possible to inject it into passivation-capable beans and
serialize when needed. The only thing is that it would be nice to instantiate the
stateless bean only once (either on injection or on first invocation), much like a
dependent bean behaves.
Stateless scope
---------------
Key: CDI-37
URL:
https://issues.jboss.org/browse/CDI-37
Project: CDI Specification Issues
Issue Type: Feature Request
Components: Specification
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: