Thank you Martin! I think if I specifiy a class level interceptor,
service(ServiceRequest, ServletResponse) will be intercepted but not
doGet(), as doGet will be called by .service(ServletRequest,
ServletResponse) directly not via a proxy. Did I miss anything?
Yes, the HttpServlet.doGet() invocation itself will not be intercepted,
but the interceptor will be called for the "outer" service() method. So
from the user point of view the result will be similar.
On Fri, May 15, 2015 at 11:45 AM, Martin Kouba <mkouba(a)redhat.com
<mailto:mkouba@redhat.com>> wrote:
Dne 13.5.2015 v 00:27 Emily Jiang napsal(a):
Thank you Jozef for the helpful info. I have another question on
interceptor:
EE7 spec states the JavaEE component classes, listed in Table
EE.5-1,
need to support interceptors. Take servlet for an example, which
methods
can be intercepted?
As the servlet classes are invoked by the container, according
to CDI1.2
spec, it seems only service(ServletRequest, ServletResponse) can be
intercepted. No other methods can be intercepted.
Normally customer applications override doPost or doGet, but
they cannot
be intercepted. I cannot see any value of support interceptors on
Servlet. Anything I missed?
The serlet container always invokes Servlet.service(ServletRequest,
ServletResponse)() which delegates to one of those convenient
methods (doGet() etc.) in case of javax.servlet.http.HttpServlet. So
if you extend HttpServlet and only override doGet() it would be
"intercepted" if you annotate the servlet class with an interceptor
binding. If you only annotate the doGet() method an interceptor will
not be invoked.
On Tue, May 12, 2015 at 7:50 AM, Jozef Hartinger
<jharting(a)redhat.com <mailto:jharting@redhat.com>
<mailto:jharting@redhat.com <mailto:jharting@redhat.com>>> wrote:
On 05/11/2015 03:47 PM, Emily Jiang wrote:
I have a few questions on interceptors:
1. CDI Interceptors on cdi beans
Will the interceptors share the same creational context
as the
bean it is associated with?
Yes. It is not the very same creational context but a new
one with a
parent-child relationship to the one of the associated
bean. This is
the same as for @Dependent dependencies
Will Weld managed the cdi interceptors as well as the
old-styled
interceptors?
Yes, Weld manages interceptor bindings associated using
interceptor
bindings as well as those associated using @Interceptors
@Interceptors don't work on other cdi beans except ejb
and managed
beans, right?
"Managed bean" is ambiguous. Weld support interceptors on
all CDI
managed beans (not on producer fields/methods nor
extension-provided
beans).
2. Interceptors on ejb beans or managed beans
I think the integrator needs to create these
@Interceptors and cdi
interceptors.
Yes, for EJBs and EE managed beans it is integrator's job
to handle
those. Weld can handle @AroundConstruct interceptors if
needed. I've
updated the docs on this topic recently:
https://github.com/jharting/core/blob/a1eb6194be36ded86dc9709c6767f5016fb...
Will these interceptors use the non-contextual
creational context
(scope @Dependent) or use the ejb or managed bean's
creational
context?
ejb or managed bean's creational context
Will Weld destroy the interceptors when the associated
beans are
destroyed or the integrator need to destroy them? This
logic
applicable to both cdi interceptors and @Interceptors style
interceptors, right?
Any time the parent (bean's) creational context is
destroyed, the
children creational contexts (interceptors') are destroyed
also by Weld.
3. Interceptors on JavaEE components
I think this interceptors are created by Weld when the
JavaEE
component classes are created, right? By the way, how
can the
container make sure to destroy the interceptors?
This depends on how the component classes are managed.
Assuming the
components are managed using Weld-provided InjectionTarget
then it
is up to the integrator to decide whether it provides
interception
support or whether it should be provided by Weld. This can be
configured for each InjectionTarget individually using this
builder:
http://docs.jboss.org/weld/javadoc/2.2/weld-spi/org/jboss/weld/manager/ap...
--
Thanks
Emily
=================
Emily Jiang
ejiang(a)apache.org <mailto:ejiang@apache.org>
<mailto:ejiang@apache.org <mailto:ejiang@apache.org>>
_______________________________________________
weld-dev mailing list
weld-dev(a)lists.jboss.org <mailto:weld-dev@lists.jboss.org>
<mailto:weld-dev@lists.jboss.org
<mailto:weld-dev@lists.jboss.org>>
https://lists.jboss.org/mailman/listinfo/weld-dev
--
Thanks
Emily
=================
Emily Jiang
ejiang(a)apache.org <mailto:ejiang@apache.org>
<mailto:ejiang@apache.org <mailto:ejiang@apache.org>>
_______________________________________________
weld-dev mailing list
weld-dev(a)lists.jboss.org <mailto:weld-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/weld-dev
--
Thanks
Emily
=================
Emily Jiang
ejiang(a)apache.org <mailto:ejiang@apache.org>