[cdi-dev] O Captain! My Captain!
Werner Keil
werner.keil at gmail.com
Fri Aug 7 04:52:56 EDT 2015
Pete,
Thanks a lot for your contribution. I started as EC member roughly when JSR
299 went into Public Draft. And among the few in the EC who also still work
on code and in EGs I helped Mike Keith (who also has other duties at Oracle
and is no longer involved in JCP work AFAIK) negotiate and coordinate how
the new JSR 330 (@Inject) and 299 could best work together instead of
reinventing the wheel.
I must say, it went rather well also thanks to Pete and other colleagues.
CDI practically became a synonym for DI since then and plays a more
important role in Java EE with every new version.
I know Antoine since we tried to start a JSR for Social Media on top of
CDI. Which wasn't approved, but we learned a lot in the process and
defining an Open Source project for it instead. So I know, Antoine will
carry the CDI torch well and help ensure, it continues to burn bright in
the Java ecosystem.
All the best for your future role,
Werner
On Fri, Aug 7, 2015 at 10:29 AM, <cdi-dev-request at lists.jboss.org> wrote:
> Send cdi-dev mailing list submissions to
> cdi-dev at lists.jboss.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.jboss.org/mailman/listinfo/cdi-dev
> or, via email, send a message with subject or body 'help' to
> cdi-dev-request at lists.jboss.org
>
> You can reach the person managing the list at
> cdi-dev-owner at lists.jboss.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of cdi-dev digest..."
>
>
> Today's Topics:
>
> 1. Re: O Captain! My Captain! (John D. Ament)
> 2. Tomorrow's agenda (Antoine Sabot-Durand)
> 3. [JBoss JIRA] (CDI-554) Additional built-in beans do not have
> a scope defined (Martin Kouba (JIRA))
> 4. Clarification on the difference on Vetoed and exclude filters
> regarding Java EE component classes (Emily Jiang)
> 5. Bean<T> that only qualifies super types? (arjan tijms)
> 6. Re: Clarification on the difference on Vetoed and exclude
> filters regarding Java EE component classes (Martin Kouba)
> 7. Re: Clarification on the difference on Vetoed and exclude
> filters regarding Java EE component classes (Emily Jiang)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sat, 01 Aug 2015 16:19:37 +0000
> From: "John D. Ament" <john.d.ament at gmail.com>
> Subject: Re: [cdi-dev] O Captain! My Captain!
> To: Pete Muir <pmuir at redhat.com>, Antoine Sabot-Durand
> <antoine at sabot-durand.net>
> Cc: cdi-dev <cdi-dev at lists.jboss.org>
> Message-ID:
> <CAOqetn98z6VcX+0zSqe8N=
> ytacXMy0EfRQRTN1uN2dCxFofJhQ at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Pete,
>
> Thank you for these last few years. Its been a pleasure seeing the CDI
> ecosystem grow from where it started. All the best!
>
> John
>
> On Thu, Jul 30, 2015 at 10:00 AM Pete Muir <pmuir at redhat.com> wrote:
>
> > Thank you everyone for all your help over the last few years, I?ve really
> > enjoyed CDI, and tried to hang on as long as I could. You?ll probably
> have
> > noticed I?ve barely been around for the last 6 months, and so it?s
> > definitely for the best that I leave it in the very capable hands of
> > Antoine :-)
> >
> > Pete
> >
> > > On 30 Jul 2015, at 14:11, Antoine Sabot-Durand <
> antoine at sabot-durand.net>
> > wrote:
> > >
> > > Hi Guys,
> > >
> > > Just to inform you that Pete is stepping down his spec lead role on CDI
> > as he's going to take new responsibilities at Red Hat.
> > >
> > > I think that we can thank him for the awesome work he did on CDI from
> > the beginning and wish him good luck for his new adventure in IT.
> > >
> > > Goodbye Pete, and thanks for all the Beans ;)
> > >
> > > Antoine
> > > _______________________________________________
> > > 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.
> >
> >
> > _______________________________________________
> > 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.
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20150801/e1843ea5/attachment-0001.html
>
> ------------------------------
>
> Message: 2
> Date: Mon, 03 Aug 2015 14:12:10 +0000
> From: Antoine Sabot-Durand <antoine at sabot-durand.net>
> Subject: [cdi-dev] Tomorrow's agenda
> To: cdi-dev <cdi-dev at lists.jboss.org>
> Message-ID:
> <CABu-YBS2c3zfuu=ewFoV6vrXsPPVT-b_f=
> jrMDEFmg6m5O6CCw at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi guys,
>
> for tomorrow's meeting I propose we start discussing face to face meeting
> content.
>
> If we have time we'll deal with remaining features in Java SE support.
>
> Regards,
>
> Antoine
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20150803/a35afa24/attachment-0001.html
>
> ------------------------------
>
> Message: 3
> Date: Thu, 6 Aug 2015 04:20:03 -0400 (EDT)
> From: "Martin Kouba (JIRA)" <issues at jboss.org>
> Subject: [cdi-dev] [JBoss JIRA] (CDI-554) Additional built-in beans do
> not have a scope defined
> To: cdi-dev at lists.jboss.org
> Message-ID:
> <JIRA.12580458.1438849173000.176286.1438849203512 at Atlassian.JIRA>
> Content-Type: text/plain; charset=UTF-8
>
> Martin Kouba created CDI-554:
> --------------------------------
>
> Summary: Additional built-in beans do not have a scope defined
> Key: CDI-554
> URL: https://issues.jboss.org/browse/CDI-554
> Project: CDI Specification Issues
> Issue Type: Clarification
> Affects Versions: 2.0-EDR1
> Reporter: Martin Kouba
>
>
> See section 17.8. Additional built-in beans - a scope is not defined for
> UserTransaction, Principal, HttpServletRequest, etc. Maybe it's defined
> somewhere else but I cannot find anything.
>
> In Weld, Java EE beans are {{@Dependent}}, HttpServletRequest and
> ServletContext are {{@RequestScoped}} and HttpSession is {{@SessionScoped}}.
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.3.15#6346)
>
>
> ------------------------------
>
> Message: 4
> Date: Thu, 6 Aug 2015 14:55:58 +0100
> From: Emily Jiang <EMIJIANG at uk.ibm.com>
> Subject: [cdi-dev] Clarification on the difference on Vetoed and
> exclude filters regarding Java EE component classes
> To: cdi-dev at lists.jboss.org
> Message-ID:
> <
> OFCB816FBA.16D9AE24-ON80257E99.004AC515-80257E99.004C8B38 at uk.ibm.com>
> Content-Type: text/plain; charset="us-ascii"
>
> 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)?
>
> 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
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20150806/94829138/attachment-0001.html
>
> ------------------------------
>
> Message: 5
> Date: Thu, 6 Aug 2015 18:07:54 +0200
> From: arjan tijms <arjan.tijms at gmail.com>
> Subject: [cdi-dev] Bean<T> that only qualifies super types?
> To: "cdi-dev at lists.jboss.org" <cdi-dev at lists.jboss.org>
> Message-ID:
> <CAE=-AhDnoaL=
> 0kF+yZSEMHXzzQ_G6cx0D0FzAyc2-tm0LLcNGQ at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> Hi,
>
> I'm wondering if it's possible in CDI to only require a qualifier for
> one of the Types in the getTypes collection of a Bean<T>
> implementation.
>
> The use case is that I have an abstract class, say Foo, that
> implements some interface, say Map:
>
> public abstract class Foo implements Map<String, Object> {
> public abstract void someMethod();
> }
>
> Then a Bean<T> implementation creates an instance of Foo:
>
> public class MyBean implements Bean<Foo> {
>
> @Override
> public Class<?> getBeanClass() {
> return Foo.class;
> }
>
> @Override
> public Set<Type> getTypes() {
> return new HashSet<Type>(asList(Foo.class, Map.class));
> }
>
> @Override
> public Integer create(CreationalContext<Integer> creationalContext) {
> return new FooImpl();
> }
>
> @Override
> public Class<? extends Annotation> getScope() {
> return RequestScoped.class;
> }
>
> // ...
> }
>
> Now the problem is that I don't want to produce Map really, as this
> may cause an ambiguity with possibly other Map producers. I only want
> to produce Foo.
>
> However, when I limit the getTypes set to contain only Foo:
>
> @Override
> public Set<Type> getTypes() {
> return new HashSet<Type>(asList(Foo.class));
> }
>
> And I subsequently inject Foo:
>
> @Inject
> private Foo foo;
>
> And then call a method from Map on foo:
>
> foo.clear();
>
> CDI (Weld 2.2.2.Final in this case) will throw an exception:
>
> "java.lang.AbstractMethodError: Method
> org/jboss/weldx/test/Foo$Proxy$_$$_WeldClientProxy.clear()V is
> abstract"
>
> So it looks like CDI (Weld) needs Map.class listed in the getTypes
> collection to fully create the proxy. Without it, the proxy only
> implements methods that are directly defined by Foo (only
> someMethod(); in this example).
>
> I therefor would like to add a qualifier such that the Map portion of
> the type needs the qualifier:
>
> @Inject @SomeQualifier
> private Map map;
>
> But Foo can still be injected without qualifier:
>
> @Inject
> private Foo foo;
>
> Is this possible already? Does something in the spec needs to be
> changed for this? (the concrete use case btw is the CDI alignment of
> JSF 2.3, where I'm trying to create a Bean<T> for
> javax.faces.context.Flash)
>
> Kind regards,
> Arjan Tijms
>
>
> ------------------------------
>
> Message: 6
> Date: Thu, 06 Aug 2015 16:24:41 +0200
> From: Martin Kouba <mkouba at redhat.com>
> Subject: Re: [cdi-dev] Clarification on the difference on Vetoed and
> exclude filters regarding Java EE component classes
> To: Emily Jiang <EMIJIANG at uk.ibm.com>, cdi-dev at lists.jboss.org
> Message-ID: <55C36E29.2040809 at redhat.com>
> Content-Type: text/plain; charset=windows-1252; format=flowed
>
> 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
>
>
> ------------------------------
>
> Message: 7
> Date: Fri, 7 Aug 2015 09:29:09 +0100
> From: Emily Jiang <EMIJIANG at uk.ibm.com>
> Subject: Re: [cdi-dev] Clarification on the difference on Vetoed and
> exclude filters regarding Java EE component classes
> To: Martin Kouba <mkouba at redhat.com>
> Cc: cdi-dev-bounces at lists.jboss.org, cdi-dev at lists.jboss.org
> Message-ID:
> <
> OF6AD439B7.C81121A5-ON80257E9A.002E1FCA-80257E9A.002E9F79 at uk.ibm.com>
> Content-Type: text/plain; charset="us-ascii"
>
> 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?
>
> "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.
>
> 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
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20150807/ddd1f56e/attachment.html
>
> ------------------------------
>
> _______________________________________________
> 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.
>
> End of cdi-dev Digest, Vol 57, Issue 2
> **************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150807/40945451/attachment-0001.html
More information about the cdi-dev
mailing list