<br><br><div class="gmail_quote">On Fri, Jan 14, 2011 at 10:13 AM, Adam Warski <span dir="ltr">&lt;<a href="mailto:adam@warski.org">adam@warski.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

Hello,<br>
<br>
have you considered adding a stateless scope to Weld?<br></blockquote><div><br></div><div>I&#39;ve definitely felt the paint of not having this, for all the reasons stated.   </div><div><br></div><div>-Clint</div><div><br>

</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Here&#39;s my use-case:<br>
I have some beans which are inherently stateless, e.g. &quot;services&quot; 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<br>


(a) be normal-scoped (proxyable)<br>
(b) implement Serializable and leave the bean dependent-scoped<br>
<br>
If I go with (a) this means that I&#39;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&#39;t, as it is stateless.<br>


<br>
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&#39;t have any state?<br>


<br>
Hence what I&#39;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&#39;t want to make my bean an EJB).<br>


<br>
--<br>
Adam Warski<br>
<a href="http://www.warski.org" target="_blank">http://www.warski.org</a><br>
<a href="http://www.softwaremill.eu" target="_blank">http://www.softwaremill.eu</a><br>
<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
weld-dev mailing list<br>
<a href="mailto:weld-dev@lists.jboss.org">weld-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/weld-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/weld-dev</a><br>
</blockquote></div><br><br clear="all"><br>-- <br>Clint Popetz<br><a href="http://42lines.net">http://42lines.net</a><br>Scalable Web Application Development<br>