Send cdi-dev mailing list submissions to
        cdi-dev@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@lists.jboss.org

You can reach the person managing the list at
        cdi-dev-owner@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@gmail.com>
Subject: Re: [cdi-dev] O Captain! My Captain!
To: Pete Muir <pmuir@redhat.com>,       Antoine Sabot-Durand
        <antoine@sabot-durand.net>
Cc: cdi-dev <cdi-dev@lists.jboss.org>
Message-ID:
        <CAOqetn98z6VcX+0zSqe8N=ytacXMy0EfRQRTN1uN2dCxFofJhQ@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@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@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@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@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@sabot-durand.net>
Subject: [cdi-dev] Tomorrow's agenda
To: cdi-dev <cdi-dev@lists.jboss.org>
Message-ID:
        <CABu-YBS2c3zfuu=ewFoV6vrXsPPVT-b_f=jrMDEFmg6m5O6CCw@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@jboss.org>
Subject: [cdi-dev] [JBoss JIRA] (CDI-554) Additional built-in beans do
        not have a scope defined
To: cdi-dev@lists.jboss.org
Message-ID:
        <JIRA.12580458.1438849173000.176286.1438849203512@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@uk.ibm.com>
Subject: [cdi-dev] Clarification on the difference on Vetoed and
        exclude filters regarding Java EE component classes
To: cdi-dev@lists.jboss.org
Message-ID:
        <OFCB816FBA.16D9AE24-ON80257E99.004AC515-80257E99.004C8B38@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@uk.ibm.com
Lotus Notes: Emily Jiang/UK/IBM@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@gmail.com>
Subject: [cdi-dev] Bean<T> that only qualifies super types?
To: "cdi-dev@lists.jboss.org" <cdi-dev@lists.jboss.org>
Message-ID:
        <CAE=-AhDnoaL=0kF+yZSEMHXzzQ_G6cx0D0FzAyc2-tm0LLcNGQ@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@redhat.com>
Subject: Re: [cdi-dev] Clarification on the difference on Vetoed and
        exclude filters regarding Java EE component classes
To: Emily Jiang <EMIJIANG@uk.ibm.com>, cdi-dev@lists.jboss.org
Message-ID: <55C36E29.2040809@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@uk.ibm.com
> Lotus Notes: Emily Jiang/UK/IBM@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@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@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@redhat.com>
Cc: cdi-dev-bounces@lists.jboss.org, cdi-dev@lists.jboss.org
Message-ID:
        <OF6AD439B7.C81121A5-ON80257E9A.002E1FCA-80257E9A.002E9F79@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@uk.ibm.com
Lotus Notes: Emily Jiang/UK/IBM@IBMGB




From:   Martin Kouba <mkouba@redhat.com>
To:     Emily Jiang/UK/IBM@IBMGB, cdi-dev@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@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@uk.ibm.com
> Lotus Notes: Emily Jiang/UK/IBM@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@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@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@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
**************************************