[cdi-dev] [JBoss JIRA] (CDI-10) Add ability to access a bean instance from a proxy

Bauke Scholtz (JIRA) issues at jboss.org
Fri Mar 11 10:09:00 EST 2016


    [ https://issues.jboss.org/browse/CDI-10?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13175437#comment-13175437 ] 

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)


More information about the cdi-dev mailing list