[JBoss JIRA] (CDI-10) Add ability to access a bean instance from a proxy
by Bauke Scholtz (JIRA)
[ https://issues.jboss.org/browse/CDI-10?page=com.atlassian.jira.plugin.sys... ]
Bauke Scholtz edited comment on CDI-10 at 3/11/16 10:09 AM:
------------------------------------------------------------
Another use case I discovered during developing JSF <f:websocket>: being able to use package private methods (or fields) among CDI beans.
Imagine a session scoped CDI bean and a dependent CDI producer in same package which needs to reference a mutable property of the session scoped CDI bean during inject time (which is necessary as the CDI session scope is not necessarily active during actual usage of the mutable object). As this mutable object is hidden/constrained from public usage, I'd rather keep it package private.
Based on among others https://issues.apache.org/jira/browse/OWB-931 I understand that package private instance methods in CDI beans are subject to serious memory leaks, so I'd rather not have them. The only possibility is having a package private static method which takes the instance and then returns the private field.
{code:java}
@SessionScoped
public class SomeSessionScopedBean {
private Map<String, Object> map;
static Map<String, Object> getMap(SomeSessionScopedBean instance) {
return instance.map;
}
}
{code}
This only doesn't work if the passed-in argument is actually a proxy instance obtained via {{@Inject}}. I had to work around it with {{context.get(bean)}}, but this theoretically less efficient than just unwrapping the proxy instance.
was (Author: bauke):
Another use case I discovered during developing JSF <f:websocket>: being able to use package private methods (or fields) among CDI beans.
Imagine a session scoped CDI bean and a dependent CDI producer in same package which needs to reference a mutable property of the session scoped CDI bean during inject time (which is necessary as the CDI session scope is not necessarily active during actual usage of the mutable object). As this object is mutable, I'd rather keep it package private.
Based on among others https://issues.apache.org/jira/browse/OWB-931 I understand that package private instance methods in CDI beans are subject to serious memory leaks, so I'd rather not have them. The only possibility is having a package private static method which takes the instance and then returns the private field.
{code:java}
@SessionScoped
public class SomeSessionScopedBean {
private Map<String, Object> map;
static Map<String, Object> getMap(SomeSessionScopedBean instance) {
return instance.map;
}
}
{code}
This only doesn't work if the passed-in argument is actually a proxy instance obtained via {{@Inject}}. I had to work around it with {{context.get(bean)}}, but this theoretically less efficient than just unwrapping the proxy instance.
> 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, 1 month
[JBoss JIRA] (CDI-10) Add ability to access a bean instance from a proxy
by Bauke Scholtz (JIRA)
[ https://issues.jboss.org/browse/CDI-10?page=com.atlassian.jira.plugin.sys... ]
Bauke Scholtz edited comment on CDI-10 at 3/11/16 10:08 AM:
------------------------------------------------------------
Another use case I discovered during developing JSF <f:websocket>: being able to use package private methods (or fields) among CDI beans.
Imagine a session scoped CDI bean and a dependent CDI producer in same package which needs to reference a mutable property of the session scoped CDI bean during inject time (which is necessary as the CDI session scope is not necessarily active during actual usage of the mutable object). As this object is mutable, I'd rather keep it package private.
Based on among others https://issues.apache.org/jira/browse/OWB-931 I understand that package private instance methods in CDI beans are subject to serious memory leaks, so I'd rather not have them. The only possibility is having a package private static method which takes the instance and then returns the private field.
{code:java}
@SessionScoped
public class SomeSessionScopedBean {
private Map<String, Object> map;
static Map<String, Object> getMap(SomeSessionScopedBean instance) {
return instance.map;
}
}
{code}
This only doesn't work if the passed-in argument is actually a proxy instance obtained via {{@Inject}}. I had to work around it with {{context.get(bean)}}, but this theoretically less efficient than just unwrapping the proxy instance.
was (Author: bauke):
Another use case I discovered during developing JSF <f:websocket>: being able to use package private methods (or fields) among CDI beans.
Imagine a session scoped CDI bean and a dependent CDI producer in same package which needs to reference a mutable field of the session scoped CDI bean during inject time (which is necessary as the CDI session scope is not necessarily active during actual usage of the mutable field). As this field is mutable, I'd rather keep it package private.
Based on among others https://issues.apache.org/jira/browse/OWB-931 I understand that package private instance methods in CDI beans are subject to serious memory leaks, so I'd rather not have them. The only possibility is having a package private static method which takes the instance and then returns the private field.
{code:java}
@SessionScoped
public class SomeSessionScopedBean {
private Map<String, Object> map;
static Map<String, Object> getMap(SomeSessionScopedBean instance) {
return instance.map;
}
}
{code}
This only doesn't work if the passed-in argument is actually a proxy instance obtained via {{@Inject}}. I had to work around it with {{context.get(bean)}}, but this theoretically less efficient than just unwrapping the proxy instance.
> 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, 1 month
[JBoss JIRA] (CDI-10) Add ability to access a bean instance from a proxy
by Bauke Scholtz (JIRA)
[ https://issues.jboss.org/browse/CDI-10?page=com.atlassian.jira.plugin.sys... ]
Bauke Scholtz edited comment on CDI-10 at 3/11/16 10:07 AM:
------------------------------------------------------------
Another use case I discovered during developing JSF <f:websocket>: being able to use package private methods (or fields) among CDI beans.
Imagine a session scoped CDI bean and a dependent CDI producer in same package which needs to reference a mutable field of the session scoped CDI bean during inject time (which is necessary as the CDI session scope is not necessarily active during actual usage of the mutable field). As this field is mutable, I'd rather keep it package private.
Based on among others https://issues.apache.org/jira/browse/OWB-931 I understand that package private instance methods in CDI beans are subject to serious memory leaks, so I'd rather not have them. The only possibility is having a package private static method which takes the instance and then returns the private field.
{code:java}
@SessionScoped
public class SomeSessionScopedBean {
private Map<String, Object> map;
static Map<String, Object> getMap(SomeSessionScopedBean instance) {
return instance.map;
}
}
{code}
This only doesn't work if the passed-in argument is actually a proxy instance obtained via {{@Inject}}. I had to work around it with {{context.get(bean)}}, but this theoretically less efficient than just unwrapping the proxy instance.
was (Author: bauke):
Another use case I discovered during developing JSF <f:websocket>: being able to use package private methods (or fields) among CDI beans.
Imagine a session scoped CDI bean and a dependent CDI producer in same package which needs to reference a mutable field of the session scoped CDI bean during inject time (which is necessary as the CDI session scope is not necessarily active during actual usage of the mutable field). As this object is mutable, I'd rather keep it package private.
Based on among others https://issues.apache.org/jira/browse/OWB-931 I understand that package private instance methods in CDI beans are subject to serious memory leaks, so I'd rather not have them. The only possibility is having a package private static method which takes the instance and then returns the private field.
{code:java}
@SessionScoped
public class SomeSessionScopedBean {
private Map<String, Object> map;
static Map<String, Object> getMap(SomeSessionScopedBean instance) {
return instance.map;
}
}
{code}
This only doesn't work if the passed-in argument is actually a proxy instance obtained via {{@Inject}}. I had to work around it with {{context.get(bean)}}, but this theoretically less efficient than just unwrapping the proxy instance.
> 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, 1 month
[JBoss JIRA] (CDI-10) Add ability to access a bean instance from a proxy
by Bauke Scholtz (JIRA)
[ https://issues.jboss.org/browse/CDI-10?page=com.atlassian.jira.plugin.sys... ]
Bauke Scholtz edited comment on CDI-10 at 3/11/16 10:05 AM:
------------------------------------------------------------
Another use case I discovered during developing JSF <f:websocket>: being able to use package private methods (or fields) among CDI beans.
Imagine a session scoped CDI bean and a dependent CDI producer in same package which needs to reference a mutable field of the session scoped CDI bean during inject time (which is necessary as the CDI session scope is not necessarily active during actual usage of the mutable field). As this object is mutable, I'd rather keep it package private.
Based on among others https://issues.apache.org/jira/browse/OWB-931 I understand that package private instance methods in CDI beans are subject to serious memory leaks, so I'd rather not have them. The only possibility is having a package private static method which takes the instance and then returns the private field.
{code:java}
@SessionScoped
public class SomeSessionScopedBean {
private Map<String, Object> map;
static Map<String, Object> getMap(SomeSessionScopedBean instance) {
return instance.map;
}
}
{code}
This only doesn't work if the passed-in argument is actually a proxy instance obtained via {{@Inject}}. I had to work around it with {{context.get(bean)}}, but this theoretically less efficient than just unwrapping the proxy instance.
was (Author: bauke):
Another use case I discovered during developing JSF <f:websocket>: being able to use package private methods (or fields) among CDI beans.
Imagine a session scoped CDI bean and a dependent CDI producer in same package which needs to reference a mutable field of the session scoped CDI bean during inject time (which is necessary as the CDI session scope is not necessarily active during actual usage of the mutable field). As this object is mutable, I'd rather keep it package private.
Based on among others https://issues.apache.org/jira/browse/OWB-931 I understand that package private instance methods in CDI beans are subject to serious memory leaks, so I'd rather not have them. The only possibility is having a package private static method which takes the instance and then returns the private field.
{code:java}
@SessionScoped
public class SomeSessionScopedBean {
private Map<String, Object> map;
static Map<String, Object> getMap(SomeSessionScopedBean instance) {
return instance.map;
}
}
{code}
This only doesn't work if the passed-in argument is actually a proxy instance obtained via `@Inject`. I had to work around it with `context.get(bean)`, but this theoretically less efficient than just unwrapping the proxy instance.
> 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, 1 month
[JBoss JIRA] (CDI-10) Add ability to access a bean instance from a proxy
by Bauke Scholtz (JIRA)
[ https://issues.jboss.org/browse/CDI-10?page=com.atlassian.jira.plugin.sys... ]
Bauke Scholtz commented on CDI-10:
----------------------------------
Another use case I discovered during developing JSF <f:websocket>: being able to use package private methods (or fields) among CDI beans.
Imagine a session scoped CDI bean and a dependent CDI producer in same package which needs to reference a mutable field of the session scoped CDI bean during inject time (which is necessary as the CDI session scope is not necessarily active during actual usage of the mutable field). As this object is mutable, I'd rather keep it package private.
Based on among others https://issues.apache.org/jira/browse/OWB-931 I understand that package private instance methods in CDI beans are subject to serious memory leaks, so I'd rather not have them. The only possibility is having a package private static method which takes the instance and then returns the private field.
{code:java}
@SessionScoped
public class SomeSessionScopedBean {
private Map<String, Object> map;
static Map<String, Object> getMap(SomeSessionScopedBean instance) {
return instance.map;
}
}
{code}
This only doesn't work if the passed-in argument is actually a proxy instance obtained via `@Inject`. I had to work around it with `context.get(bean)`, but this theoretically less efficient than just unwrapping the proxy instance.
> 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, 1 month
[JBoss JIRA] (CDI-508) Nested classes except for static nested classes should not be managed beans
by Tomas Remes (JIRA)
[ https://issues.jboss.org/browse/CDI-508?page=com.atlassian.jira.plugin.sy... ]
Tomas Remes commented on CDI-508:
---------------------------------
I created https://github.com/cdi-spec/cdi/pull/282
> Nested classes except for static nested classes should not be managed beans
> ---------------------------------------------------------------------------
>
> Key: CDI-508
> URL: https://issues.jboss.org/browse/CDI-508
> Project: CDI Specification Issues
> Issue Type: Clarification
> Affects Versions: 1.2.Final
> Reporter: Martin Kouba
>
> The spec should explicitly state that all nested classes (inner, anonymous, local) except for static nested classes are not managed beans.
> *3.1.1. Which Java classes are managed beans?* is confusing:
> {quote}
> A *top-level* Java class is a managed bean if it is defined to be a managed bean by any other Java EE specification, or if it meets all of the following conditions:
> * It is not a *non-static inner class*.
> * It is a concrete class, or is annotated @Decorator.
> * ...
> {quote}
> # A *top-level* Java class is never nested
> # Term *non-static inner class* is inaccurate, static nested classes are not inner
> # It seems that *concrete class* is not defined in JLS, it should be probably replaced with something like non-abstract...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 1 month
[JBoss JIRA] (CDI-479) How to identify the bean a static observer method belongs to
by Tomas Remes (JIRA)
[ https://issues.jboss.org/browse/CDI-479?page=com.atlassian.jira.plugin.sy... ]
Tomas Remes commented on CDI-479:
---------------------------------
I've found this.
# We have {{org.jboss.cdi.tck.tests.event.broken.observer.beanNotManaged.ObserverMethodOnIncorrectBeanTest}} where we check that observer is disabled (not resolved) at non-managed bean and at abstract class with abstract method observer which is overriden in extending class.
# We have {{org.jboss.cdi.tck.tests.event.observer.ObserverNotificationTest#testObserversNotified}} where we check that observer is disabled at bean which is not selected alternative.
I think we can expand both cases in TCK and probably close this issue. What do you think [~antoinesabot-durand]?
> How to identify the bean a static observer method belongs to
> ------------------------------------------------------------
>
> Key: CDI-479
> URL: https://issues.jboss.org/browse/CDI-479
> Project: CDI Specification Issues
> Issue Type: Clarification
> Reporter: Martin Kouba
>
> Let's sum up some parts of the spec which are relevant to static observer methods:
> "10.4. Observer methods":
> {quote}
> An observer method is a non-abstract method of a managed bean class or session bean class...
> An observer method may be either static or non-static.
> {quote}
> "10.3. Observer resolution":
> {quote}
> An event is delivered to an observer method if:
> * The observer method belongs to an enabled bean.
> * ...
> {quote}
> "12.4.3. Bean discovery":
> {quote}
> For each observer method of every enabled bean, the container registers an instance of the ObserverMethod interface defined in The ObserverMethod interface.
> {quote}
> Now what is the algorithm to *identify the bean a static observer method belongs to*? Is is bound to all beans whose Bean.getBeanClass() declares the method? There are two special scenarios I have in mind:
> h3. Static observer method on an abstract class
> {code:java}
> public abstract class Foo {
> public static observe1(@Observes Event1 event1) {
> }
> }
> public class Bar extends Foo {
> }
> {code}
> Foo is not a bean. Foo.observe1() is not a method of managed bean class Bar (if we strictly follow the JSL). Is the observer method detected? Does it belong to Bar? What if there are several subclasses of Foo?
> h3. Specialization
> {code:java}
> public class Foo {
> public static observe1(@Observes Event2 event2) {
> }
> }
> @Specializes
> public class Bar extends Foo {
> }
> {code}
> Foo is specialized by Bar and thus it's disabled. Is the observer method detected? Does it belong to Bar?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 1 month
[JBoss JIRA] (CDI-479) How to identify the bean a static observer method belongs to
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-479?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba commented on CDI-479:
----------------------------------
Ok, so I've read the spec again and I also think both the observer methods from examples should be ignored because:
1. in example one it's not a method of a managed bean class
2. in example two the method does not belong to an enabled bean
On the other hand, it might confusing for users as they might expect them to work. I suppose we don't have a TCK test for this, do we?
> How to identify the bean a static observer method belongs to
> ------------------------------------------------------------
>
> Key: CDI-479
> URL: https://issues.jboss.org/browse/CDI-479
> Project: CDI Specification Issues
> Issue Type: Clarification
> Reporter: Martin Kouba
>
> Let's sum up some parts of the spec which are relevant to static observer methods:
> "10.4. Observer methods":
> {quote}
> An observer method is a non-abstract method of a managed bean class or session bean class...
> An observer method may be either static or non-static.
> {quote}
> "10.3. Observer resolution":
> {quote}
> An event is delivered to an observer method if:
> * The observer method belongs to an enabled bean.
> * ...
> {quote}
> "12.4.3. Bean discovery":
> {quote}
> For each observer method of every enabled bean, the container registers an instance of the ObserverMethod interface defined in The ObserverMethod interface.
> {quote}
> Now what is the algorithm to *identify the bean a static observer method belongs to*? Is is bound to all beans whose Bean.getBeanClass() declares the method? There are two special scenarios I have in mind:
> h3. Static observer method on an abstract class
> {code:java}
> public abstract class Foo {
> public static observe1(@Observes Event1 event1) {
> }
> }
> public class Bar extends Foo {
> }
> {code}
> Foo is not a bean. Foo.observe1() is not a method of managed bean class Bar (if we strictly follow the JSL). Is the observer method detected? Does it belong to Bar? What if there are several subclasses of Foo?
> h3. Specialization
> {code:java}
> public class Foo {
> public static observe1(@Observes Event2 event2) {
> }
> }
> @Specializes
> public class Bar extends Foo {
> }
> {code}
> Foo is specialized by Bar and thus it's disabled. Is the observer method detected? Does it belong to Bar?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 1 month
[JBoss JIRA] (CDI-479) How to identify the bean a static observer method belongs to
by Tomas Remes (JIRA)
[ https://issues.jboss.org/browse/CDI-479?page=com.atlassian.jira.plugin.sy... ]
Tomas Remes edited comment on CDI-479 at 3/10/16 10:00 AM:
-----------------------------------------------------------
I am not sure but isn't the answer for the first question in {{4.2. Inheritance of member-level metadata}}:
{quote}
If X declares an initializer, non-static observer, @PostConstruct or @PreDestroy method x()
then Y inherits x() if and only if neither Y nor any intermediate class that is a subclass of X
and a superclass of Y overrides the method x()
{quote}
>From this I would say the observer shouldn't be detected (because is static) in the first case.
was (Author: tremes):
I am not sure but isn't the answer for the first question in `4.2. Inheritance of member-level metadata`:
{quote}
If X declares an initializer, non-static observer, @PostConstruct or @PreDestroy method x()
then Y inherits x() if and only if neither Y nor any intermediate class that is a subclass of X
and a superclass of Y overrides the method x()
{quote}
>From this I would say the observer shouldn't be detected (because is static) in the first case.
> How to identify the bean a static observer method belongs to
> ------------------------------------------------------------
>
> Key: CDI-479
> URL: https://issues.jboss.org/browse/CDI-479
> Project: CDI Specification Issues
> Issue Type: Clarification
> Reporter: Martin Kouba
>
> Let's sum up some parts of the spec which are relevant to static observer methods:
> "10.4. Observer methods":
> {quote}
> An observer method is a non-abstract method of a managed bean class or session bean class...
> An observer method may be either static or non-static.
> {quote}
> "10.3. Observer resolution":
> {quote}
> An event is delivered to an observer method if:
> * The observer method belongs to an enabled bean.
> * ...
> {quote}
> "12.4.3. Bean discovery":
> {quote}
> For each observer method of every enabled bean, the container registers an instance of the ObserverMethod interface defined in The ObserverMethod interface.
> {quote}
> Now what is the algorithm to *identify the bean a static observer method belongs to*? Is is bound to all beans whose Bean.getBeanClass() declares the method? There are two special scenarios I have in mind:
> h3. Static observer method on an abstract class
> {code:java}
> public abstract class Foo {
> public static observe1(@Observes Event1 event1) {
> }
> }
> public class Bar extends Foo {
> }
> {code}
> Foo is not a bean. Foo.observe1() is not a method of managed bean class Bar (if we strictly follow the JSL). Is the observer method detected? Does it belong to Bar? What if there are several subclasses of Foo?
> h3. Specialization
> {code:java}
> public class Foo {
> public static observe1(@Observes Event2 event2) {
> }
> }
> @Specializes
> public class Bar extends Foo {
> }
> {code}
> Foo is specialized by Bar and thus it's disabled. Is the observer method detected? Does it belong to Bar?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 1 month