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;
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
add a comment |
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
add a comment |
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
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
java proxy cdi
edited Nov 14 '18 at 4:07
Mehran Mastcheshmi
asked Oct 16 '18 at 7:56
Mehran MastcheshmiMehran Mastcheshmi
4281312
4281312
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
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.
awesome answer. thank you very much
– Mehran Mastcheshmi
Oct 17 '18 at 8:14
add a comment |
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
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
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.
awesome answer. thank you very much
– Mehran Mastcheshmi
Oct 17 '18 at 8:14
add a comment |
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.
awesome answer. thank you very much
– Mehran Mastcheshmi
Oct 17 '18 at 8:14
add a comment |
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.
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.
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
add a comment |
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
add a comment |
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.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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