[JBoss JIRA] (CDI-10) Add ability to access a bean instance from a proxy
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-10?page=com.atlassian.jira.plugin.sys... ]
Martin Kouba commented on CDI-10:
---------------------------------
Good points Mark. We should also keep in mind that a contextual instance is an internal container construct. For example in Weld, if Foo is intercepted/decorated then Foo contextual instance is an instance of a Foo's subclass (internal Weld construct).
> Add ability to access a bean instance from a proxy
> --------------------------------------------------
>
> Key: CDI-10
> URL: https://issues.jboss.org/browse/CDI-10
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Beans
> Affects Versions: 1.0
> Reporter: Stuart Douglas
> Fix For: 2.0 (discussion)
>
>
> There are occasions when it would be useful to access a bean instance directly from a proxy. This could be achieved by making all proxies assignable to an interface (say BeanProxy) that provides a getBeanInstance() method.
> Client code that needs access to the actual instance can check if the object is assignable to the BeanProxy interface and then call getBeanInstance() to get the actual instance if required.
> This is something that is probably more useful to extension writers than the end user, but there have already been a few requests on the weld forum about this so it is probably worth considering.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (CDI-561) Add the possibility to unmanage a bean instance
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-561?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba commented on CDI-561:
----------------------------------
bq. Accessing the true class of the instance in a clean way...
Just note that the class of a contextual instance might not be the class one would expect because a contextual instance is an internal container construct (for example in Weld it might be a subclass).
> Add the possibility to unmanage a bean instance
> -----------------------------------------------
>
> Key: CDI-561
> URL: https://issues.jboss.org/browse/CDI-561
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Beans
> Affects Versions: 1.2.Final, 1.1.Final, 2.0-EDR1
> Reporter: Antoine Sabot-Durand
> Fix For: 2.0 (discussion)
>
>
> CDI implementations make heavy uses of proxies to support normal scope and interceptor decorators. There are use case where being able to have a bean instance without its proxy could be useful
> * Accessing the true class of the instance in a clean way
> * Being able to capture an instance state to use its information outside CDI or as an event payload
> The limitation we have on Async event is probably a good example. As we don't propagate active normal context at firing time, it's not possible to inject a bean with such a scope (except {{@ApplicationScoped}} since Application context is shared), it could be useful to give the possibility to copy such a bean instance to a standard pojo instance so it could be used as event payload for instance.
> We could even imagine that the mechanism could be transparently activated if an asynchronous observer inject a {{@RequestScoped}} or {{@SessionScoped}} bean.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (CDI-10) Add ability to access a bean instance from a proxy
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-10?page=com.atlassian.jira.plugin.sys... ]
Antoine Sabot-Durand updated CDI-10:
------------------------------------
Fix Version/s: 2.0 (discussion)
> Add ability to access a bean instance from a proxy
> --------------------------------------------------
>
> Key: CDI-10
> URL: https://issues.jboss.org/browse/CDI-10
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Beans
> Affects Versions: 1.0
> Reporter: Stuart Douglas
> Fix For: 2.0 (discussion)
>
>
> There are occasions when it would be useful to access a bean instance directly from a proxy. This could be achieved by making all proxies assignable to an interface (say BeanProxy) that provides a getBeanInstance() method.
> Client code that needs access to the actual instance can check if the object is assignable to the BeanProxy interface and then call getBeanInstance() to get the actual instance if required.
> This is something that is probably more useful to extension writers than the end user, but there have already been a few requests on the weld forum about this so it is probably worth considering.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (CDI-10) Add ability to access a bean instance from a proxy
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-10?page=com.atlassian.jira.plugin.sys... ]
Mark Struberg commented on CDI-10:
----------------------------------
We would also need to clarify what kind of unwrapping needs to be performed.
In OWB-1.2.x ++ we have a stack of proxies on top of each other. In the maximum scenario we could get a
1.) NormalScoping Proxy
2.) Interceptor/Decorator Proxy
3.) subclassing proxy if there are abstract Decorators involved
Sometimes you like to get the Contextual Instance with all it's Interceptors and Decorators, but at some other time you need the real underlying delegation instance (the _native_ instance without anything else).
The second case is needed if you e.g. like to perform JSR-303 validation on the whole bean. Or if you like to call private methods on that bean (e.g. delivering messages, etc).
Please note that we need to think about security as well! This needs to be done as doPrivileged block at least. Not sure what else is necessary to prevent abuse.
> Add ability to access a bean instance from a proxy
> --------------------------------------------------
>
> Key: CDI-10
> URL: https://issues.jboss.org/browse/CDI-10
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Beans
> Affects Versions: 1.0
> Reporter: Stuart Douglas
>
> There are occasions when it would be useful to access a bean instance directly from a proxy. This could be achieved by making all proxies assignable to an interface (say BeanProxy) that provides a getBeanInstance() method.
> Client code that needs access to the actual instance can check if the object is assignable to the BeanProxy interface and then call getBeanInstance() to get the actual instance if required.
> This is something that is probably more useful to extension writers than the end user, but there have already been a few requests on the weld forum about this so it is probably worth considering.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (CDI-541) Ordering of async observers (vs sync observers) is not specified
by Stephan Knitelius (JIRA)
[ https://issues.jboss.org/browse/CDI-541?page=com.atlassian.jira.plugin.sy... ]
Stephan Knitelius commented on CDI-541:
---------------------------------------
The idea of calling Async observers serially seems a bit odd to me.
As pointed out by Matej, it kind of breaks the idea of loose coupling and async processing.
> Ordering of async observers (vs sync observers) is not specified
> ----------------------------------------------------------------
>
> Key: CDI-541
> URL: https://issues.jboss.org/browse/CDI-541
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Events
> Affects Versions: 2.0-EDR1
> Reporter: Tomas Remes
> Fix For: 2.0-EDR2
>
>
> I think this needs to be specified. E.g. what happens if I fire async event and have more matching sync and async observers? Are all sync observes called first in given order with no regard to async observers priority?
> For example:
> {{event.fireAsync(new Message());}}
> {code}
> public class First {
>
> void observeMessage(@Observes @Priority(2000) Message message){}
> }
> {code}
> {code}
> public class Second {
>
> void observeMessage(@ObservesAsync @Priority(2100) Message message){}
> }
> {code}
> {code}
> public class Third {
>
> void observeMessage(@Observes @Priority(2200) Message message){}
> }
> {code}
> {code}
> public class Fourth {
>
> void observeMessage(@ObservesAsync @Priority(2300) Message message){}
> }
> {code}
> What will be the order in this case? First, Third, Second, Fourth?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (CDI-37) Stateless scope
by Stephan Knitelius (JIRA)
[ https://issues.jboss.org/browse/CDI-37?page=com.atlassian.jira.plugin.sys... ]
Stephan Knitelius commented on CDI-37:
--------------------------------------
I think this issue should be closed, as it really just comes down to semantics.
> 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.4.11#64026)
8 years, 5 months
[JBoss JIRA] (CDI-10) Add ability to access a bean instance from a proxy
by Stephan Knitelius (JIRA)
[ https://issues.jboss.org/browse/CDI-10?page=com.atlassian.jira.plugin.sys... ]
Stephan Knitelius commented on CDI-10:
--------------------------------------
I believe this is also an issue with Vaadin CDI integration.
At the moment all Vaadin UI components are not allowed to have a normal scope since Vaadin cannot handle CDI proxies.
Vaadin CDI has solves this, at the moment by providing all supported scopes once as normal scope and once as pseudo scoped.
JavaDoc from @NormalViewScoped:
{quote}
* You cannot use this scope with Vaadin Components. Proxy Components do not
* work correctly within the Vaadin framework, so as a precaution the Vaadin
* CDI plugin will not deploy if any such beans are discovered.
{quote}
> Add ability to access a bean instance from a proxy
> --------------------------------------------------
>
> Key: CDI-10
> URL: https://issues.jboss.org/browse/CDI-10
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Beans
> Affects Versions: 1.0
> Reporter: Stuart Douglas
>
> There are occasions when it would be useful to access a bean instance directly from a proxy. This could be achieved by making all proxies assignable to an interface (say BeanProxy) that provides a getBeanInstance() method.
> Client code that needs access to the actual instance can check if the object is assignable to the BeanProxy interface and then call getBeanInstance() to get the actual instance if required.
> This is something that is probably more useful to extension writers than the end user, but there have already been a few requests on the weld forum about this so it is probably worth considering.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (CDI-570) Weld shutdown in Java SE during asynch event calling
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-570?page=com.atlassian.jira.plugin.sy... ]
Mark Struberg commented on CDI-570:
-----------------------------------
Many server have a thread stuck warning. That is causes enerving warnings if the job in question is especially designed to be long running (and properly shuts down itself on request). Something in the spec which could denote such a thread would be welcome. Of course that is not a CDI problem otoh but such feature should be a more generic one.
> Weld shutdown in Java SE during asynch event calling
> ----------------------------------------------------
>
> Key: CDI-570
> URL: https://issues.jboss.org/browse/CDI-570
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Events
> Affects Versions: 2.0-EDR1
> Reporter: Michael Remijan
>
> In a Java SE environment, there is no way to tell if there are async observers are in the process of being called when the time comes for the JVM to shut down. My assumption is the JVM should wait until all the async observers are complete before shutting down. Or perhaps this behavior can be configured through the CDI object, system property, or beans.xml
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (CDI-570) Weld shutdown in Java SE during asynch event calling
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-570?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba commented on CDI-570:
----------------------------------
Well, event payload mutability/synchronization is also a user problem. I think it's a kind of problem users should be aware of when using async events. +1 for adding some (probably non-normative) info about this stuff.
> Weld shutdown in Java SE during asynch event calling
> ----------------------------------------------------
>
> Key: CDI-570
> URL: https://issues.jboss.org/browse/CDI-570
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Events
> Affects Versions: 2.0-EDR1
> Reporter: Michael Remijan
>
> In a Java SE environment, there is no way to tell if there are async observers are in the process of being called when the time comes for the JVM to shut down. My assumption is the JVM should wait until all the async observers are complete before shutting down. Or perhaps this behavior can be configured through the CDI object, system property, or beans.xml
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (CDI-570) Weld shutdown in Java SE during asynch event calling
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-570?page=com.atlassian.jira.plugin.sy... ]
Mark Struberg commented on CDI-570:
-----------------------------------
But we at least must make users aware that it is THEIR problem to track those things? Not as nice...
> Weld shutdown in Java SE during asynch event calling
> ----------------------------------------------------
>
> Key: CDI-570
> URL: https://issues.jboss.org/browse/CDI-570
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Events
> Affects Versions: 2.0-EDR1
> Reporter: Michael Remijan
>
> In a Java SE environment, there is no way to tell if there are async observers are in the process of being called when the time comes for the JVM to shut down. My assumption is the JVM should wait until all the async observers are complete before shutting down. Or perhaps this behavior can be configured through the CDI object, system property, or beans.xml
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months