1 Reply Latest reply on Mar 28, 2014 4:03 AM by mkouba

    Managed beans and custom proxies.


      I am currently converting some internal libraries to use CDI. In part, the function of this library is to track changes to an object and "flush" these modifications to a backing object when the caller is ready to do so. This saves a lot of work for data intensive applications when a screen component is tied to an object and the user is making modifications to. They may not want to save those modifications, so instead of creating value objects that are cleared and/or reset back to their original state, we use proxies that contain the context of the changes made. In the current implementation, the developer calls a static helper to create a proxy for the object given, or they may call the helper to create a new instance of the object as proxied. These proxies may also return proxies of associated objects when calling the getter. We us an interceptor that is inserted into the seam interceptor chain when the proxy is created.


      This works fine with CDI until an object is injected. That object could be a weld proxy and I don't want to lose the functionality that the weld proxy provides. So, I am not sure of the best approach to use in CDI.

      Do I replace the Bean instance in my Extension with a custom Bean implementation that creates the proxy in the create method? 

           I am not sure how I would replace the current Bean, and making the developer use a qualifier when creating or retrieving the bean seems awkward.


      Do I add an AnnotatedType in the extension?

           How would I keep context for the bean instance, if I don't own the proxy?


      Can safely wrap the weld proxy with my own?

           This seems ugly and bound to be problematic.


      Any suggestions, help or insight is greatly appreciated.