what are proxing rules in CDI for beans when they have interceptor or decorator?



.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty height:90px;width:728px;box-sizing:border-box;








1















I ran 2 examples in weblogic ( I used a bean with dependent scope):



1)the bean has not any interceptors or decorators: the bean was not proxied



2)the bean has a interceptors : the bean was proxied



I think that there are two types of proxies in CDI:



1)client proxy: This proxy overrides all the non-private methods of the bean class, when these overridden methods are invoked the proxy looks up the correct instance( or proxy of second type) of the bean and then forwards the invocation onto the actual bean instance (based on this link). for dependent scope this proxy is not created



2)there is another proxy for applying interceptors and decorators and it is created when the bean has decorator or interceptors



Is my assumption about second type of proxy correct? Does the specification say anything about it?










share|improve this question






























    1















    I ran 2 examples in weblogic ( I used a bean with dependent scope):



    1)the bean has not any interceptors or decorators: the bean was not proxied



    2)the bean has a interceptors : the bean was proxied



    I think that there are two types of proxies in CDI:



    1)client proxy: This proxy overrides all the non-private methods of the bean class, when these overridden methods are invoked the proxy looks up the correct instance( or proxy of second type) of the bean and then forwards the invocation onto the actual bean instance (based on this link). for dependent scope this proxy is not created



    2)there is another proxy for applying interceptors and decorators and it is created when the bean has decorator or interceptors



    Is my assumption about second type of proxy correct? Does the specification say anything about it?










    share|improve this question


























      1












      1








      1








      I ran 2 examples in weblogic ( I used a bean with dependent scope):



      1)the bean has not any interceptors or decorators: the bean was not proxied



      2)the bean has a interceptors : the bean was proxied



      I think that there are two types of proxies in CDI:



      1)client proxy: This proxy overrides all the non-private methods of the bean class, when these overridden methods are invoked the proxy looks up the correct instance( or proxy of second type) of the bean and then forwards the invocation onto the actual bean instance (based on this link). for dependent scope this proxy is not created



      2)there is another proxy for applying interceptors and decorators and it is created when the bean has decorator or interceptors



      Is my assumption about second type of proxy correct? Does the specification say anything about it?










      share|improve this question
















      I ran 2 examples in weblogic ( I used a bean with dependent scope):



      1)the bean has not any interceptors or decorators: the bean was not proxied



      2)the bean has a interceptors : the bean was proxied



      I think that there are two types of proxies in CDI:



      1)client proxy: This proxy overrides all the non-private methods of the bean class, when these overridden methods are invoked the proxy looks up the correct instance( or proxy of second type) of the bean and then forwards the invocation onto the actual bean instance (based on this link). for dependent scope this proxy is not created



      2)there is another proxy for applying interceptors and decorators and it is created when the bean has decorator or interceptors



      Is my assumption about second type of proxy correct? Does the specification say anything about it?







      java proxy cdi






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Nov 14 '18 at 4:07







      Mehran Mastcheshmi

















      asked Oct 16 '18 at 7:56









      Mehran MastcheshmiMehran Mastcheshmi

      4281312




      4281312






















          1 Answer
          1






          active

          oldest

          votes


















          1














          You made a nice investigation indeed and you are right for the most part.
          Here are the details.



          Proxy



          Normal scoped beans (@ApplicationScoped, RequestScoped,...) are indeed proxied, you don't get hold of the actual instance and what you are getting is a client proxy.
          With @Dependent which is not normal scoped, you basically want to inject new instance every time so there is no need to have it proxied.



          The above has some mentions in CDI spec, albeit not precise to give implementation space in which they can manipulate - users should't really care if they have a proxy or not for calling their methods works just fine.



          Interceptors and Decorators



          Moving on to interceptors - spec says nothing about this from what I know and leaves implementations to choose freely what to do with it. Following details are Weld-specific although from what I recall, OWB has it similar. There aren't really many option how to achieve it anyway.



          For every interceptor/decorator, there is a "proxy" created, in fact a subclass, which allows to make interception/decoration happen. This subclass replaces the original bean and all calls go through it (e.g. it is in the underlying bean store instead of the original instance).



          Again, from user perspective, this makes no difference and you shouldn't be worried about it.



          Extra tooling for proxies/sublasses



          Sometimes, very rarely, and most likely only when you are developing a CDI library, you may truly need to see if the injected bean is a client proxy or a subclass.
          Weld offers tools for that, every bean which has a client proxy is implementing WeldClientProxy interface from Weld API. This interface allows you to grab the actual instance and some metadata.
          Likewise, every intercepted and decorated bean is implementing WeldContruct as a marker interface.






          share|improve this answer























          • awesome answer. thank you very much

            – Mehran Mastcheshmi
            Oct 17 '18 at 8:14











          Your Answer






          StackExchange.ifUsing("editor", function ()
          StackExchange.using("externalEditor", function ()
          StackExchange.using("snippets", function ()
          StackExchange.snippets.init();
          );
          );
          , "code-snippets");

          StackExchange.ready(function()
          var channelOptions =
          tags: "".split(" "),
          id: "1"
          ;
          initTagRenderer("".split(" "), "".split(" "), channelOptions);

          StackExchange.using("externalEditor", function()
          // Have to fire editor after snippets, if snippets enabled
          if (StackExchange.settings.snippets.snippetsEnabled)
          StackExchange.using("snippets", function()
          createEditor();
          );

          else
          createEditor();

          );

          function createEditor()
          StackExchange.prepareEditor(
          heartbeatType: 'answer',
          autoActivateHeartbeat: false,
          convertImagesToLinks: true,
          noModals: true,
          showLowRepImageUploadWarning: true,
          reputationToPostImages: 10,
          bindNavPrevention: true,
          postfix: "",
          imageUploader:
          brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
          contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
          allowUrls: true
          ,
          onDemand: true,
          discardSelector: ".discard-answer"
          ,immediatelyShowMarkdownHelp:true
          );



          );













          draft saved

          draft discarded


















          StackExchange.ready(
          function ()
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f52830541%2fwhat-are-proxing-rules-in-cdi-for-beans-when-they-have-interceptor-or-decorator%23new-answer', 'question_page');

          );

          Post as a guest















          Required, but never shown

























          1 Answer
          1






          active

          oldest

          votes








          1 Answer
          1






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes









          1














          You made a nice investigation indeed and you are right for the most part.
          Here are the details.



          Proxy



          Normal scoped beans (@ApplicationScoped, RequestScoped,...) are indeed proxied, you don't get hold of the actual instance and what you are getting is a client proxy.
          With @Dependent which is not normal scoped, you basically want to inject new instance every time so there is no need to have it proxied.



          The above has some mentions in CDI spec, albeit not precise to give implementation space in which they can manipulate - users should't really care if they have a proxy or not for calling their methods works just fine.



          Interceptors and Decorators



          Moving on to interceptors - spec says nothing about this from what I know and leaves implementations to choose freely what to do with it. Following details are Weld-specific although from what I recall, OWB has it similar. There aren't really many option how to achieve it anyway.



          For every interceptor/decorator, there is a "proxy" created, in fact a subclass, which allows to make interception/decoration happen. This subclass replaces the original bean and all calls go through it (e.g. it is in the underlying bean store instead of the original instance).



          Again, from user perspective, this makes no difference and you shouldn't be worried about it.



          Extra tooling for proxies/sublasses



          Sometimes, very rarely, and most likely only when you are developing a CDI library, you may truly need to see if the injected bean is a client proxy or a subclass.
          Weld offers tools for that, every bean which has a client proxy is implementing WeldClientProxy interface from Weld API. This interface allows you to grab the actual instance and some metadata.
          Likewise, every intercepted and decorated bean is implementing WeldContruct as a marker interface.






          share|improve this answer























          • awesome answer. thank you very much

            – Mehran Mastcheshmi
            Oct 17 '18 at 8:14















          1














          You made a nice investigation indeed and you are right for the most part.
          Here are the details.



          Proxy



          Normal scoped beans (@ApplicationScoped, RequestScoped,...) are indeed proxied, you don't get hold of the actual instance and what you are getting is a client proxy.
          With @Dependent which is not normal scoped, you basically want to inject new instance every time so there is no need to have it proxied.



          The above has some mentions in CDI spec, albeit not precise to give implementation space in which they can manipulate - users should't really care if they have a proxy or not for calling their methods works just fine.



          Interceptors and Decorators



          Moving on to interceptors - spec says nothing about this from what I know and leaves implementations to choose freely what to do with it. Following details are Weld-specific although from what I recall, OWB has it similar. There aren't really many option how to achieve it anyway.



          For every interceptor/decorator, there is a "proxy" created, in fact a subclass, which allows to make interception/decoration happen. This subclass replaces the original bean and all calls go through it (e.g. it is in the underlying bean store instead of the original instance).



          Again, from user perspective, this makes no difference and you shouldn't be worried about it.



          Extra tooling for proxies/sublasses



          Sometimes, very rarely, and most likely only when you are developing a CDI library, you may truly need to see if the injected bean is a client proxy or a subclass.
          Weld offers tools for that, every bean which has a client proxy is implementing WeldClientProxy interface from Weld API. This interface allows you to grab the actual instance and some metadata.
          Likewise, every intercepted and decorated bean is implementing WeldContruct as a marker interface.






          share|improve this answer























          • awesome answer. thank you very much

            – Mehran Mastcheshmi
            Oct 17 '18 at 8:14













          1












          1








          1







          You made a nice investigation indeed and you are right for the most part.
          Here are the details.



          Proxy



          Normal scoped beans (@ApplicationScoped, RequestScoped,...) are indeed proxied, you don't get hold of the actual instance and what you are getting is a client proxy.
          With @Dependent which is not normal scoped, you basically want to inject new instance every time so there is no need to have it proxied.



          The above has some mentions in CDI spec, albeit not precise to give implementation space in which they can manipulate - users should't really care if they have a proxy or not for calling their methods works just fine.



          Interceptors and Decorators



          Moving on to interceptors - spec says nothing about this from what I know and leaves implementations to choose freely what to do with it. Following details are Weld-specific although from what I recall, OWB has it similar. There aren't really many option how to achieve it anyway.



          For every interceptor/decorator, there is a "proxy" created, in fact a subclass, which allows to make interception/decoration happen. This subclass replaces the original bean and all calls go through it (e.g. it is in the underlying bean store instead of the original instance).



          Again, from user perspective, this makes no difference and you shouldn't be worried about it.



          Extra tooling for proxies/sublasses



          Sometimes, very rarely, and most likely only when you are developing a CDI library, you may truly need to see if the injected bean is a client proxy or a subclass.
          Weld offers tools for that, every bean which has a client proxy is implementing WeldClientProxy interface from Weld API. This interface allows you to grab the actual instance and some metadata.
          Likewise, every intercepted and decorated bean is implementing WeldContruct as a marker interface.






          share|improve this answer













          You made a nice investigation indeed and you are right for the most part.
          Here are the details.



          Proxy



          Normal scoped beans (@ApplicationScoped, RequestScoped,...) are indeed proxied, you don't get hold of the actual instance and what you are getting is a client proxy.
          With @Dependent which is not normal scoped, you basically want to inject new instance every time so there is no need to have it proxied.



          The above has some mentions in CDI spec, albeit not precise to give implementation space in which they can manipulate - users should't really care if they have a proxy or not for calling their methods works just fine.



          Interceptors and Decorators



          Moving on to interceptors - spec says nothing about this from what I know and leaves implementations to choose freely what to do with it. Following details are Weld-specific although from what I recall, OWB has it similar. There aren't really many option how to achieve it anyway.



          For every interceptor/decorator, there is a "proxy" created, in fact a subclass, which allows to make interception/decoration happen. This subclass replaces the original bean and all calls go through it (e.g. it is in the underlying bean store instead of the original instance).



          Again, from user perspective, this makes no difference and you shouldn't be worried about it.



          Extra tooling for proxies/sublasses



          Sometimes, very rarely, and most likely only when you are developing a CDI library, you may truly need to see if the injected bean is a client proxy or a subclass.
          Weld offers tools for that, every bean which has a client proxy is implementing WeldClientProxy interface from Weld API. This interface allows you to grab the actual instance and some metadata.
          Likewise, every intercepted and decorated bean is implementing WeldContruct as a marker interface.







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Oct 17 '18 at 7:23









          SiliarusSiliarus

          3,8821522




          3,8821522












          • awesome answer. thank you very much

            – Mehran Mastcheshmi
            Oct 17 '18 at 8:14

















          • awesome answer. thank you very much

            – Mehran Mastcheshmi
            Oct 17 '18 at 8:14
















          awesome answer. thank you very much

          – Mehran Mastcheshmi
          Oct 17 '18 at 8:14





          awesome answer. thank you very much

          – Mehran Mastcheshmi
          Oct 17 '18 at 8:14



















          draft saved

          draft discarded
















































          Thanks for contributing an answer to Stack Overflow!


          • Please be sure to answer the question. Provide details and share your research!

          But avoid


          • Asking for help, clarification, or responding to other answers.

          • Making statements based on opinion; back them up with references or personal experience.

          To learn more, see our tips on writing great answers.




          draft saved


          draft discarded














          StackExchange.ready(
          function ()
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f52830541%2fwhat-are-proxing-rules-in-cdi-for-beans-when-they-have-interceptor-or-decorator%23new-answer', 'question_page');

          );

          Post as a guest















          Required, but never shown





















































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown

































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown







          Popular posts from this blog

          𛂒𛀶,𛀽𛀑𛂀𛃧𛂓𛀙𛃆𛃑𛃷𛂟𛁡𛀢𛀟𛁤𛂽𛁕𛁪𛂟𛂯,𛁞𛂧𛀴𛁄𛁠𛁼𛂿𛀤 𛂘,𛁺𛂾𛃭𛃭𛃵𛀺,𛂣𛃍𛂖𛃶 𛀸𛃀𛂖𛁶𛁏𛁚 𛂢𛂞 𛁰𛂆𛀔,𛁸𛀽𛁓𛃋𛂇𛃧𛀧𛃣𛂐𛃇,𛂂𛃻𛃲𛁬𛃞𛀧𛃃𛀅 𛂭𛁠𛁡𛃇𛀷𛃓𛁥,𛁙𛁘𛁞𛃸𛁸𛃣𛁜,𛂛,𛃿,𛁯𛂘𛂌𛃛𛁱𛃌𛂈𛂇 𛁊𛃲,𛀕𛃴𛀜 𛀶𛂆𛀶𛃟𛂉𛀣,𛂐𛁞𛁾 𛁷𛂑𛁳𛂯𛀬𛃅,𛃶𛁼

          Edmonton

          Crossroads (UK TV series)