[JBoss JIRA] (CDI-37) Stateless scope
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-37?page=com.atlassian.jira.plugin.sys... ]
Martin Kouba commented on CDI-37:
---------------------------------
[~arnelim] Agreed. This does not make much sense if there is no state at all.
> Stateless scope
> ---------------
>
> Key: CDI-37
> URL: https://issues.jboss.org/browse/CDI-37
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Contexts
> Affects Versions: 1.0
> Reporter: Adam Warski
> Fix For: 2.0 (discussion)
>
>
> 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 was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 4 months
[JBoss JIRA] (CDI-37) Stateless scope
by Arne Limburg (JIRA)
[ https://issues.jboss.org/browse/CDI-37?page=com.atlassian.jira.plugin.sys... ]
Arne Limburg commented on CDI-37:
---------------------------------
OK, I understand, what he means, but I don't understand why it is needed. In what way does an @ApplicationScoped bean not fulfill the mentioned requirements
> Stateless scope
> ---------------
>
> Key: CDI-37
> URL: https://issues.jboss.org/browse/CDI-37
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Contexts
> Affects Versions: 1.0
> Reporter: Adam Warski
> Fix For: 2.0 (discussion)
>
>
> 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 was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 4 months
[JBoss JIRA] (CDI-450) support Dagger 2.x style APT generated bytecode to avoid reflection or proxying for faster injection
by James Strachan (JIRA)
James Strachan created CDI-450:
----------------------------------
Summary: support Dagger 2.x style APT generated bytecode to avoid reflection or proxying for faster injection
Key: CDI-450
URL: https://issues.jboss.org/browse/CDI-450
Project: CDI Specification Issues
Issue Type: Feature Request
Reporter: James Strachan
this is particularly useful if you wanted to do per-request/per-message/per-operation injection.
The Dagger approach to DI lets you code generate the DI wiring code at compile time avoiding any reflection etc. The primary use case driving Dagger is performance on Android but I can see that being generically useful on all Java platforms.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 4 months
[JBoss JIRA] (CDI-449) beans.xml examples are not valid
by Martin Kouba (JIRA)
Martin Kouba created CDI-449:
--------------------------------
Summary: beans.xml examples are not valid
Key: CDI-449
URL: https://issues.jboss.org/browse/CDI-449
Project: CDI Specification Issues
Issue Type: Bug
Affects Versions: 1.2.Final
Reporter: Martin Kouba
The {{beans.xml}} examples in "5.1.1. Declaring selected alternatives", "8.2.2. Decorator enablement and ordering for a bean archive" and "9.4. Interceptor enablement and ordering" (which contain a reference to beans_1_1.xsd) are not valid - {{bean-discovery-mode}} attribute is required. I think it would be appropriate to specify the version attribute as well.
The last {{beans.xml}} example in "12.4.2. Exclude filters" does not even define the reference to an XSD. Again, I believe the version and bean-discovery-mode attributes should be specified.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 4 months
[JBoss JIRA] (CDI-37) Stateless scope
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-37?page=com.atlassian.jira.plugin.sys... ]
Martin Kouba commented on CDI-37:
---------------------------------
{quote}
I don't really get, why @ApplicationScoped is a problem in that use case.
{quote}
I think that Adam meant something like a "proxied dependent bean", i.e. bound to the to the lifecycle of the injected object but not serialized during passivation - only the proxy is serialized and a new instance is created on demand (probably lazily). I'm not sure "stateless" is a good name though - these instances may be stateless but their scope is another thing.
> Stateless scope
> ---------------
>
> Key: CDI-37
> URL: https://issues.jboss.org/browse/CDI-37
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Contexts
> Affects Versions: 1.0
> Reporter: Adam Warski
> Fix For: 2.0 (discussion)
>
>
> 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 was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 4 months
[JBoss JIRA] (CDI-37) Stateless scope
by Arne Limburg (JIRA)
[ https://issues.jboss.org/browse/CDI-37?page=com.atlassian.jira.plugin.sys... ]
Arne Limburg commented on CDI-37:
---------------------------------
We have to be careful using @javax.inject.Singleton. We have to be backward compatible with JSR-330.
I don't really get, why @ApplicationScoped is a problem in that use case.
> Stateless scope
> ---------------
>
> Key: CDI-37
> URL: https://issues.jboss.org/browse/CDI-37
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Contexts
> Affects Versions: 1.0
> Reporter: Adam Warski
> Fix For: 2.0 (discussion)
>
>
> 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 was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 4 months
[JBoss JIRA] (CDI-37) Stateless scope
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-37?page=com.atlassian.jira.plugin.sys... ]
Antoine Sabot-Durand updated CDI-37:
------------------------------------
Fix Version/s: 2.0 (discussion)
(was: TBD)
> Stateless scope
> ---------------
>
> Key: CDI-37
> URL: https://issues.jboss.org/browse/CDI-37
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Contexts
> Affects Versions: 1.0
> Reporter: Adam Warski
> Fix For: 2.0 (discussion)
>
>
> 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 was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 4 months
[JBoss JIRA] (CDI-37) Stateless scope
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-37?page=com.atlassian.jira.plugin.sys... ]
Antoine Sabot-Durand commented on CDI-37:
-----------------------------------------
Perhaps we should use the {{@Singleton}} pseudo scope. Right now there's absolutely no mention of it in the spec (except in one example). All the occurrences of _singleton_ is to mention EJB (stateless session bean).
> Stateless scope
> ---------------
>
> Key: CDI-37
> URL: https://issues.jboss.org/browse/CDI-37
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Contexts
> Affects Versions: 1.0
> Reporter: Adam Warski
> Fix For: 2.0 (discussion)
>
>
> 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 was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 4 months