[cdi-dev] Clarification on the difference on Vetoed and exclude filters regarding Java EE component classes

Emily Jiang EMIJIANG at uk.ibm.com
Tue Aug 11 05:16:20 EDT 2015


Hi Martin,
My comments in blue.

Many thanks,
Emily
===========================
Emily Jiang
WebSphere Application Server Liberty Profile development, CDI Development 
Lead
 
MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN
Phone:  +44 (0)1962 816278  Internal: 246278

Email: emijiang at uk.ibm.com 
Lotus Notes: Emily Jiang/UK/IBM at IBMGB




From:   Martin Kouba <mkouba at redhat.com>
To:     Emily Jiang/UK/IBM at IBMGB, 
Cc:     cdi-dev-bounces at lists.jboss.org, cdi-dev at lists.jboss.org
Date:   10/08/2015 07:52
Subject:        Re: [cdi-dev] Clarification on the difference on Vetoed 
and exclude filters regarding Java EE component classes
Sent by:        cdi-dev-bounces at lists.jboss.org



Dne 7.8.2015 v 10:29 Emily Jiang napsal(a):
> Thanks Martin for your reply! Your reply confirmed my understanding of
> @Vetoed.
>
> What is the expected behaviour if I exclude my JavaEE component class in
> the filter under beans.xml? Will this cause the JavaEE component class
> being ignored by CDI or this should have the same effect as being
> annotated as @Vetoed?

This should have the same effect as @Vetoed.
<ej>
In this case, the session 12.4.1 Type discovery should be enhanced,

that is not excluded from discovery by an exclude filter as defined in 
Section 12.4.2, “Exclude
filters”. 

should be changed to

that is not excluded from discovery by an exclude filter as defined in 
Section 12.4.2, “Exclude
filters”or annotated with @Vetoed (class level or package level).
<ej>
>
> "In the 12.4.2, it states: If the filter is active, and: .... then we
> say that the type is excluded from discovery."
>
> Does the above discovery mean both type and bean discovery or just bean
> discovery? If it means both type and bean discovery, the classes should
> be ignored by CDI. Please confirm.

@Veto, ProcessAnnotatedType.veto() and exclude filters are tied to Type 
discovery. Moreover, the Java EE components (like servlets) are not CDI 
beans and may not be vetoed at all.
<ej>
I think the @Vetoed is useful in the explicit bean discovery mode to 
exclude the JavaEE component classes from considering as beans. In the 
implicit bean archive, they are not beans anyway.

I have still further question on the following spec sections.


12.4.1. Type discovery
First the container must discover types. The container discovers:
• each Java class, interface (excluding the special kind of interface 
declaration annotation type)
or enum deployed in an explicit bean archive, and
• each Java class with a bean defining annotation in an implicit bean 
archive.
• each session bean
that is not excluded from discovery by an exclude filter as defined in 
Section 12.4.2, “Exclude
filters”.
12.4.3. Bean discovery
For every type in the set of discovered types (as defined in Section 
12.4.1, “Type discovery”), the
container must:
• inspect the type metadata to determine if it is a bean or other Java EE 
component class
supporting injection, and then
• detect definition errors by validating the class and its metadata, and 
then
• if the class is a managed bean, session bean, or other Java EE component 
class supporting
injection, fire an event of type ProcessInjectionPoint for each injection 
point in the class, as
defined in Section 11.5.7, “ProcessInjectionPoint event”, and then
• if the class is a managed bean, session bean, or other Java EE component 
class supporting
injection, fire an event of type ProcessInjectionTarget, as defined in 
Section 11.5.8,
“ProcessInjectionTarget event”, and then


The Bean discovery stage seems to suggest it only consider the types 
discovered in the type discovery. Considering a @Vetoed JavaEE component 
class or such class in an implicit bean archive, it won't be processed in 
the bean discovery stage as it opts out from type discovery. Neither 
processInjectionPoint nor ProcessInjectionTarget events can be fired. I 
think it is wrong.


Another query: would the Spec require JavaEE component classes to support 
injection in an non bean archive? 
</ej>
>
> Many thanks,
> Emily
> ===========================
> Emily Jiang
> WebSphere Application Server Liberty Profile development, CDI
> Development Lead
>
> MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN
> Phone:  +44 (0)1962 816278  Internal: 246278
>
> Email: emijiang at uk.ibm.com
> Lotus Notes: Emily Jiang/UK/IBM at IBMGB
>
>
>
>
> From: Martin Kouba <mkouba at redhat.com>
> To: Emily Jiang/UK/IBM at IBMGB, cdi-dev at lists.jboss.org,
> Date: 07/08/2015 03:40
> Subject: Re: [cdi-dev] Clarification on the difference on Vetoed and
> exclude filters regarding Java EE component classes
> Sent by: cdi-dev-bounces at lists.jboss.org
> ------------------------------------------------------------------------
>
>
>
> Dne 6.8.2015 v 15:55 Emily Jiang napsal(a):
>  > In the section 3.6. Java EE components of CDI 1.2 specification, it 
has
>  > the following statement:
>  >
>  > /It is safe to annotate Java EE components with //@Vetoed //to 
prevent
>  > them being considered beans./
>  >
>  > According to my understanding, the JavaEE component classes with 
@Vetoed
>  > should still support injections and *ProcessInjectionTarget*events
>  > should still be fired.
>  >
>  > In the 12.4.2, it states:
>  > /If the filter is active, and: .... then we say that the type is
>  > excluded from discovery./
>  >
>  > Does this mean if a JavaEE component class is excluded from the scan 
in
>  > the beans.xml, its CDI involvement should be ignored (@Inject would 
be
>  > ignored etc)?
>
> I don't think so. I believe the intent of "3.6. Java EE components" is
> to clarify that if a component class (e.g. a servlet class) is also
> recognized as a managed bean [1] there will be two different
> "components" in your applicaion, each managed by a different Java EE
> technology - e.g. a servlet managed by the servlet container and a CDI
> bean with servlet class in its set of bean types.
>
> The servlet has a different lifecycle, it's managed by a servlet
> container and as such must support injection (but cannot be injected, 
etc.).
>
> This might be confusing and therefore it's a good idea to veto the Java
> EE component classes -> there will be no CDI bean definitions based on
> the component classes.
>
> [1]
> http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#what_classes_are_beans
>
>
>  >
>  > Many thanks,
>  > Emily
>  > ===========================
>  > Emily Jiang
>  > WebSphere Application Server Liberty Profile development, CDI
>  > Development Lead
>  >
>  > MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN
>  > Phone:  +44 (0)1962 816278  Internal: 246278
>  >
>  > Email: emijiang at uk.ibm.com
>  > Lotus Notes: Emily Jiang/UK/IBM at IBMGB
>  >
>  > Unless stated otherwise above:
>  > IBM United Kingdom Limited - Registered in England and Wales with 
number
>  > 741598.
>  > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire
> PO6 3AU
>  >
>  >
>  > _______________________________________________
>  > cdi-dev mailing list
>  > cdi-dev at lists.jboss.org
>  > https://lists.jboss.org/mailman/listinfo/cdi-dev
>  >
>  > Note that for all code provided on this list, the provider licenses
> the code under the Apache License, Version 2
> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> provided on this list, the provider waives all patent and other
> intellectual property rights inherent in such information.
>  >
>
> --
> Martin Kouba
> Software Engineer
> Red Hat, Czech Republic
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the
> code under the Apache License, Version 2
> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> provided on this list, the provider waives all patent and other
> intellectual property rights inherent in such information.
>
>
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 
3AU

-- 
Martin Kouba
Software Engineer
Red Hat, Czech Republic
_______________________________________________
cdi-dev mailing list
cdi-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the 
code under the Apache License, Version 2 (
http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas 
provided on this list, the provider waives all patent and other 
intellectual property rights inherent in such information.



Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150811/0b3179d3/attachment-0001.html 


More information about the cdi-dev mailing list