From struberg at yahoo.de  Sat Aug  1 10:25:26 2015
From: struberg at yahoo.de (Mark Struberg)
Date: Sat, 1 Aug 2015 14:25:26 +0000 (UTC)
Subject: [cdi-dev] O Captain! My Captain!
In-Reply-To: <CABu-YBRV=5Y9iUjhPLy_cnsqGKMqb74YCJeXrL1D_rENM-6dEQ@mail.gmail.com>
References: <CABu-YBRV=5Y9iUjhPLy_cnsqGKMqb74YCJeXrL1D_rENM-6dEQ@mail.gmail.com>
Message-ID: <457794653.121069.1438439126537.JavaMail.yahoo@mail.yahoo.com>

+1
Pete, it was always a pleasure to work with you!The world is so small, I bet our ways will cross again one day :)

LieGrue,strub
 


     On Thursday, 30 July 2015, 15:12, 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.

 
   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150801/06cb8b4c/attachment-0001.html 

From john.d.ament at gmail.com  Sat Aug  1 12:19:37 2015
From: john.d.ament at gmail.com (John D. Ament)
Date: Sat, 01 Aug 2015 16:19:37 +0000
Subject: [cdi-dev] O Captain! My Captain!
In-Reply-To: <DB3E71F6-749D-439C-874E-089A5A826813@redhat.com>
References: <CABu-YBRV=5Y9iUjhPLy_cnsqGKMqb74YCJeXrL1D_rENM-6dEQ@mail.gmail.com>
	<DB3E71F6-749D-439C-874E-089A5A826813@redhat.com>
Message-ID: <CAOqetn98z6VcX+0zSqe8N=ytacXMy0EfRQRTN1uN2dCxFofJhQ@mail.gmail.com>

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.html 

From antoine at sabot-durand.net  Mon Aug  3 10:12:10 2015
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Mon, 03 Aug 2015 14:12:10 +0000
Subject: [cdi-dev] Tomorrow's agenda
Message-ID: <CABu-YBS2c3zfuu=ewFoV6vrXsPPVT-b_f=jrMDEFmg6m5O6CCw@mail.gmail.com>

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.html 

From issues at jboss.org  Thu Aug  6 04:20:03 2015
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Thu, 6 Aug 2015 04:20:03 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-554) Additional built-in beans do not
 have a scope defined
In-Reply-To: <JIRA.12580458.1438849173000@Atlassian.JIRA>
References: <JIRA.12580458.1438849173000@Atlassian.JIRA>
	<JIRA.12580458.1438849173886@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12580458.1438849173000.176286.1438849203512@Atlassian.JIRA>

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)

From EMIJIANG at uk.ibm.com  Thu Aug  6 09:55:58 2015
From: EMIJIANG at uk.ibm.com (Emily Jiang)
Date: Thu, 6 Aug 2015 14:55:58 +0100
Subject: [cdi-dev] Clarification on the difference on Vetoed and exclude
 filters regarding Java EE component classes
Message-ID: <OFCB816FBA.16D9AE24-ON80257E99.004AC515-80257E99.004C8B38@uk.ibm.com>

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.html 

From arjan.tijms at gmail.com  Thu Aug  6 12:07:54 2015
From: arjan.tijms at gmail.com (arjan tijms)
Date: Thu, 6 Aug 2015 18:07:54 +0200
Subject: [cdi-dev] Bean<T> that only qualifies super types?
Message-ID: <CAE=-AhDnoaL=0kF+yZSEMHXzzQ_G6cx0D0FzAyc2-tm0LLcNGQ@mail.gmail.com>

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

From mkouba at redhat.com  Thu Aug  6 10:24:41 2015
From: mkouba at redhat.com (Martin Kouba)
Date: Thu, 06 Aug 2015 16:24:41 +0200
Subject: [cdi-dev] Clarification on the difference on Vetoed and exclude
 filters regarding Java EE component classes
In-Reply-To: <OFCB816FBA.16D9AE24-ON80257E99.004AC515-80257E99.004C8B38@uk.ibm.com>
References: <OFCB816FBA.16D9AE24-ON80257E99.004AC515-80257E99.004C8B38@uk.ibm.com>
Message-ID: <55C36E29.2040809@redhat.com>

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

From EMIJIANG at uk.ibm.com  Fri Aug  7 04:29:09 2015
From: EMIJIANG at uk.ibm.com (Emily Jiang)
Date: Fri, 7 Aug 2015 09:29:09 +0100
Subject: [cdi-dev] Clarification on the difference on Vetoed and exclude
 filters regarding Java EE component classes
In-Reply-To: <55C36E29.2040809@redhat.com>
References: <OFCB816FBA.16D9AE24-ON80257E99.004AC515-80257E99.004C8B38@uk.ibm.com>
	<55C36E29.2040809@redhat.com>
Message-ID: <OF6AD439B7.C81121A5-ON80257E9A.002E1FCA-80257E9A.002E9F79@uk.ibm.com>

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-0001.html 

From werner.keil at gmail.com  Fri Aug  7 04:52:56 2015
From: werner.keil at gmail.com (Werner Keil)
Date: Fri, 7 Aug 2015 10:52:56 +0200
Subject: [cdi-dev] O Captain! My Captain!
Message-ID: <CAAGawe3nXJtxaPc8L1DsRxFcejr2CK=ZT+XvvKXUUfsbZji1RQ@mail.gmail.com>

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 

From mkouba at redhat.com  Fri Aug  7 05:27:40 2015
From: mkouba at redhat.com (Martin Kouba)
Date: Fri, 07 Aug 2015 11:27:40 +0200
Subject: [cdi-dev] Bean<T> that only qualifies super types?
In-Reply-To: <CAE=-AhDnoaL=0kF+yZSEMHXzzQ_G6cx0D0FzAyc2-tm0LLcNGQ@mail.gmail.com>
References: <CAE=-AhDnoaL=0kF+yZSEMHXzzQ_G6cx0D0FzAyc2-tm0LLcNGQ@mail.gmail.com>
Message-ID: <55C47A0C.9060500@redhat.com>

Dne 6.8.2015 v 18:07 arjan tijms napsal(a):
> 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;
>      }

I believe the bean class should not be abstract. It's not clearly 
defined but there are some indirect suggestions: abstract class is not a 
managed bean -> Bean.getBeanClass() returns the bean class of the 
managed bean... etc.

>
>      @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).

The problem here is with the abstract Foo. Let me check the proxy 
bytecode and find out more details.

>
> 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)

No, this is not possible. Qualifiers are tied to a bean definition, not 
to a bean type.


>
> Kind regards,
> Arjan Tijms
> _______________________________________________
> 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

From arjan.tijms at gmail.com  Fri Aug  7 05:43:09 2015
From: arjan.tijms at gmail.com (arjan tijms)
Date: Fri, 7 Aug 2015 11:43:09 +0200
Subject: [cdi-dev] Bean<T> that only qualifies super types?
In-Reply-To: <55C47A0C.9060500@redhat.com>
References: <CAE=-AhDnoaL=0kF+yZSEMHXzzQ_G6cx0D0FzAyc2-tm0LLcNGQ@mail.gmail.com>
	<55C47A0C.9060500@redhat.com>
Message-ID: <CAE=-AhBgFsYQT_hBitRpvYyb2D5yU5UYi=qXV1zGJ5JNs_k5zw@mail.gmail.com>

Hi,

On Fri, Aug 7, 2015 at 11:27 AM, Martin Kouba <mkouba at redhat.com> wrote:
> I believe the bean class should not be abstract. It's not clearly defined
> but there are some indirect suggestions: abstract class is not a managed
> bean -> Bean.getBeanClass() returns the bean class of the managed bean...
> etc.

Hmmm, but it can be an interface right? And the difference between an
interface and a "pure" abstract class (abstract class with only
abstract methods) is rather minimal.

The instance that is returned is not abstract (of course), but both a
producer and a Bean<T> can have interfaces as their "declared"  bean
Type if I understood correctly.

E.g.

@Produces
public Interface produce() {
   return new InterfaceImpl();
}

There's nothing wrong with that, is it?

So by extension, is this wrong then?

@Produces
public Foo produce() {
   return new FooImpl();
}



> No, this is not possible. Qualifiers are tied to a bean definition, not to a
> bean type.

So this would possibly be an enhancement or new feature request then.


I did found a workaround though, which seems to work because the Type
I'd like to hide happens to have generic parameters:

private static class Dummy {}

@Override
public Set<Type> getTypes() {
    return new HashSet<Type>(asList(Foo.class,
ParameterizedTypeImpl(Map.class, new Type[]{Dummy.class,
Dummy.class})));
}

With those types the proxy that's generated contains methods for both
Foo and Map, but because the generic parameters are the private class,
the client application can never declare an injection point for this
(certain not accidentally).

Another possible workaround I thought of is using a second Bean<T>
that only has Foo as its type and is @Dependent scoped, which then
asks the bean manager for an instance of a qualified Foo (qualifier is
of a private type). If I'm not mistaken the first Bean<T> would then
be called and an @RequestScoped proxy would be returned, which the
second Bean<T> can then return from its create() method.

What do you think, any of these methods have potential unforeseen
side-effects or are they safe to use?

Kind regards,
Arjan







>
>
>>
>> Kind regards,
>> Arjan Tijms
>> _______________________________________________
>> 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

From mkouba at redhat.com  Fri Aug  7 07:48:40 2015
From: mkouba at redhat.com (Martin Kouba)
Date: Fri, 07 Aug 2015 13:48:40 +0200
Subject: [cdi-dev] Bean<T> that only qualifies super types?
In-Reply-To: <CAE=-AhBgFsYQT_hBitRpvYyb2D5yU5UYi=qXV1zGJ5JNs_k5zw@mail.gmail.com>
References: <CAE=-AhDnoaL=0kF+yZSEMHXzzQ_G6cx0D0FzAyc2-tm0LLcNGQ@mail.gmail.com>	<55C47A0C.9060500@redhat.com>
	<CAE=-AhBgFsYQT_hBitRpvYyb2D5yU5UYi=qXV1zGJ5JNs_k5zw@mail.gmail.com>
Message-ID: <55C49B18.2030404@redhat.com>

Dne 7.8.2015 v 11:43 arjan tijms napsal(a):
> Hi,
>
> On Fri, Aug 7, 2015 at 11:27 AM, Martin Kouba <mkouba at redhat.com> wrote:
>> I believe the bean class should not be abstract. It's not clearly defined
>> but there are some indirect suggestions: abstract class is not a managed
>> bean -> Bean.getBeanClass() returns the bean class of the managed bean...
>> etc.
>
> Hmmm, but it can be an interface right? And the difference between an
> interface and a "pure" abstract class (abstract class with only
> abstract methods) is rather minimal.
>
> The instance that is returned is not abstract (of course), but both a
> producer and a Bean<T> can have interfaces as their "declared"  bean
> Type if I understood correctly.
>
> E.g.
>
> @Produces
> public Interface produce() {
>     return new InterfaceImpl();
> }

No, an interface may be a bean type but not a bean class of a managed 
bean. For producer methods, the getBeanClass() returns the bean class of 
the bean that declares the producer method.

The bean class is defacto an implementation class.

>
> There's nothing wrong with that, is it?
>
> So by extension, is this wrong then?
>
> @Produces
> public Foo produce() {
>     return new FooImpl();
> }

This is OK. But the bean class of this producer is not Foo as mentioned 
above.

>
>
>
>> No, this is not possible. Qualifiers are tied to a bean definition, not to a
>> bean type.
>
> So this would possibly be an enhancement or new feature request then.
>
>
> I did found a workaround though, which seems to work because the Type
> I'd like to hide happens to have generic parameters:
>
> private static class Dummy {}
>
> @Override
> public Set<Type> getTypes() {
>      return new HashSet<Type>(asList(Foo.class,
> ParameterizedTypeImpl(Map.class, new Type[]{Dummy.class,
> Dummy.class})));
> }
>
> With those types the proxy that's generated contains methods for both
> Foo and Map, but because the generic parameters are the private class,
> the client application can never declare an injection point for this
> (certain not accidentally).
>
> Another possible workaround I thought of is using a second Bean<T>
> that only has Foo as its type and is @Dependent scoped, which then
> asks the bean manager for an instance of a qualified Foo (qualifier is
> of a private type). If I'm not mistaken the first Bean<T> would then
> be called and an @RequestScoped proxy would be returned, which the
> second Bean<T> can then return from its create() method.
>
> What do you think, any of these methods have potential unforeseen
> side-effects or are they safe to use?
>
> Kind regards,
> Arjan
>
>
>
>
>
>
>
>>
>>
>>>
>>> Kind regards,
>>> Arjan Tijms
>>> _______________________________________________
>>> 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

-- 
Martin Kouba
Software Engineer
Red Hat, Czech Republic

From arjan.tijms at gmail.com  Fri Aug  7 08:18:14 2015
From: arjan.tijms at gmail.com (arjan tijms)
Date: Fri, 7 Aug 2015 14:18:14 +0200
Subject: [cdi-dev] Bean<T> that only qualifies super types?
In-Reply-To: <55C49B18.2030404@redhat.com>
References: <CAE=-AhDnoaL=0kF+yZSEMHXzzQ_G6cx0D0FzAyc2-tm0LLcNGQ@mail.gmail.com>
	<55C47A0C.9060500@redhat.com>
	<CAE=-AhBgFsYQT_hBitRpvYyb2D5yU5UYi=qXV1zGJ5JNs_k5zw@mail.gmail.com>
	<55C49B18.2030404@redhat.com>
Message-ID: <CAE=-AhBxeWT688h+Ne01PtMrwH6BUtsm=X-b+YiuFwgWEDRdww@mail.gmail.com>

Hi,

On Fri, Aug 7, 2015 at 1:48 PM, Martin Kouba <mkouba at redhat.com> wrote:
> No, an interface may be a bean type but not a bean class of a managed bean.
> For producer methods, the getBeanClass() returns the bean class of the bean
> that declares the producer method.
>
> The bean class is defacto an implementation class.

Seems fair enough, but if I look at the build-in Bean<T>
implementations of Weld, then org.jboss.weld.Bean.RIBean returns the
type as the bean class. See:

http://grepcode.com/file/repo1.maven.org/maven2/org.jboss.weld/weld-core-impl/2.2.12.Final/org/jboss/weld/bean/RIBean.java#56

If we look at a concrete implementation, say HttpServletRequestBean

(see http://grepcode.com/file/repo1.maven.org/maven2/org.jboss.weld.se/weld-se/2.2.12.Final/org/jboss/weld/bean/builtin/ee/HttpServletRequestBean.java#HttpServletRequestBean)

Then HttpServletRequest.class is passed to the super ctor as the Type,
and therefor also becomes the bean class, as per RIBean.java#56.

Same thing for UserTransaction, Principal, ServletRequest, etc.

Kind regards,
Arjan Tijms





>
>>
>> There's nothing wrong with that, is it?
>>
>> So by extension, is this wrong then?
>>
>> @Produces
>> public Foo produce() {
>>     return new FooImpl();
>> }
>
>
> This is OK. But the bean class of this producer is not Foo as mentioned
> above.
>
>
>>
>>
>>
>>> No, this is not possible. Qualifiers are tied to a bean definition, not
>>> to a
>>> bean type.
>>
>>
>> So this would possibly be an enhancement or new feature request then.
>>
>>
>> I did found a workaround though, which seems to work because the Type
>> I'd like to hide happens to have generic parameters:
>>
>> private static class Dummy {}
>>
>> @Override
>> public Set<Type> getTypes() {
>>      return new HashSet<Type>(asList(Foo.class,
>> ParameterizedTypeImpl(Map.class, new Type[]{Dummy.class,
>> Dummy.class})));
>> }
>>
>> With those types the proxy that's generated contains methods for both
>> Foo and Map, but because the generic parameters are the private class,
>> the client application can never declare an injection point for this
>> (certain not accidentally).
>>
>> Another possible workaround I thought of is using a second Bean<T>
>> that only has Foo as its type and is @Dependent scoped, which then
>> asks the bean manager for an instance of a qualified Foo (qualifier is
>> of a private type). If I'm not mistaken the first Bean<T> would then
>> be called and an @RequestScoped proxy would be returned, which the
>> second Bean<T> can then return from its create() method.
>>
>> What do you think, any of these methods have potential unforeseen
>> side-effects or are they safe to use?
>>
>> Kind regards,
>> Arjan
>>
>>
>>
>>
>>
>>
>>
>>>
>>>
>>>>
>>>> Kind regards,
>>>> Arjan Tijms
>>>> _______________________________________________
>>>> 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
>
>
> --
> Martin Kouba
> Software Engineer
> Red Hat, Czech Republic

From mkouba at redhat.com  Mon Aug 10 02:41:56 2015
From: mkouba at redhat.com (Martin Kouba)
Date: Mon, 10 Aug 2015 08:41:56 +0200
Subject: [cdi-dev] Bean<T> that only qualifies super types?
In-Reply-To: <CAE=-AhBxeWT688h+Ne01PtMrwH6BUtsm=X-b+YiuFwgWEDRdww@mail.gmail.com>
References: <CAE=-AhDnoaL=0kF+yZSEMHXzzQ_G6cx0D0FzAyc2-tm0LLcNGQ@mail.gmail.com>	<55C47A0C.9060500@redhat.com>	<CAE=-AhBgFsYQT_hBitRpvYyb2D5yU5UYi=qXV1zGJ5JNs_k5zw@mail.gmail.com>	<55C49B18.2030404@redhat.com>
	<CAE=-AhBxeWT688h+Ne01PtMrwH6BUtsm=X-b+YiuFwgWEDRdww@mail.gmail.com>
Message-ID: <55C847B4.5020906@redhat.com>

Dne 7.8.2015 v 14:18 arjan tijms napsal(a):
> Hi,
>
> On Fri, Aug 7, 2015 at 1:48 PM, Martin Kouba <mkouba at redhat.com> wrote:
>> No, an interface may be a bean type but not a bean class of a managed bean.
>> For producer methods, the getBeanClass() returns the bean class of the bean
>> that declares the producer method.
>>
>> The bean class is defacto an implementation class.
>
> Seems fair enough, but if I look at the build-in Bean<T>
> implementations of Weld, then org.jboss.weld.Bean.RIBean returns the
> type as the bean class. See:

Built-in beans are handled specially in Weld.

>
> http://grepcode.com/file/repo1.maven.org/maven2/org.jboss.weld/weld-core-impl/2.2.12.Final/org/jboss/weld/bean/RIBean.java#56
>
> If we look at a concrete implementation, say HttpServletRequestBean
>
> (see http://grepcode.com/file/repo1.maven.org/maven2/org.jboss.weld.se/weld-se/2.2.12.Final/org/jboss/weld/bean/builtin/ee/HttpServletRequestBean.java#HttpServletRequestBean)
>
> Then HttpServletRequest.class is passed to the super ctor as the Type,
> and therefor also becomes the bean class, as per RIBean.java#56.

Not really. HttpServletRequestBean also extends AbstractBuiltInBean and 
so the getBeanClass() method returns the HttpServletRequestBean.class. 
See also:
http://probe-weld.itos.redhat.com/weld-numberguess/weld-probe#/bean/f24c5153-d823-366c-bdc9-c3e1a6eb0812

>
> Same thing for UserTransaction, Principal, ServletRequest, etc.
>
> Kind regards,
> Arjan Tijms
>
>
>
>
>
>>
>>>
>>> There's nothing wrong with that, is it?
>>>
>>> So by extension, is this wrong then?
>>>
>>> @Produces
>>> public Foo produce() {
>>>      return new FooImpl();
>>> }
>>
>>
>> This is OK. But the bean class of this producer is not Foo as mentioned
>> above.
>>
>>
>>>
>>>
>>>
>>>> No, this is not possible. Qualifiers are tied to a bean definition, not
>>>> to a
>>>> bean type.
>>>
>>>
>>> So this would possibly be an enhancement or new feature request then.
>>>
>>>
>>> I did found a workaround though, which seems to work because the Type
>>> I'd like to hide happens to have generic parameters:
>>>
>>> private static class Dummy {}
>>>
>>> @Override
>>> public Set<Type> getTypes() {
>>>       return new HashSet<Type>(asList(Foo.class,
>>> ParameterizedTypeImpl(Map.class, new Type[]{Dummy.class,
>>> Dummy.class})));
>>> }
>>>
>>> With those types the proxy that's generated contains methods for both
>>> Foo and Map, but because the generic parameters are the private class,
>>> the client application can never declare an injection point for this
>>> (certain not accidentally).
>>>
>>> Another possible workaround I thought of is using a second Bean<T>
>>> that only has Foo as its type and is @Dependent scoped, which then
>>> asks the bean manager for an instance of a qualified Foo (qualifier is
>>> of a private type). If I'm not mistaken the first Bean<T> would then
>>> be called and an @RequestScoped proxy would be returned, which the
>>> second Bean<T> can then return from its create() method.
>>>
>>> What do you think, any of these methods have potential unforeseen
>>> side-effects or are they safe to use?
>>>
>>> Kind regards,
>>> Arjan
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>>
>>>>
>>>>>
>>>>> Kind regards,
>>>>> Arjan Tijms
>>>>> _______________________________________________
>>>>> 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
>>
>>
>> --
>> Martin Kouba
>> Software Engineer
>> Red Hat, Czech Republic

-- 
Martin Kouba
Software Engineer
Red Hat, Czech Republic

From antoine at sabot-durand.net  Mon Aug 10 02:46:51 2015
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Mon, 10 Aug 2015 06:46:51 +0000
Subject: [cdi-dev] Next meeting on Aug 25th
Message-ID: <CABu-YBQ=2K97ftxF0DKmOzAn_X9QcTP0PQ=BHPNmJ2gyZBvrsA@mail.gmail.com>

Hi Guys,


I'm on PTO for the 2 coming weeks.
So we'll have our next CDI meeting on august 25th.

Regards,

Antoine
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150810/de1227e2/attachment.html 

From mkouba at redhat.com  Mon Aug 10 02:51:51 2015
From: mkouba at redhat.com (Martin Kouba)
Date: Mon, 10 Aug 2015 08:51:51 +0200
Subject: [cdi-dev] Clarification on the difference on Vetoed and exclude
 filters regarding Java EE component classes
In-Reply-To: <OF6AD439B7.C81121A5-ON80257E9A.002E1FCA-80257E9A.002E9F79@uk.ibm.com>
References: <OFCB816FBA.16D9AE24-ON80257E99.004AC515-80257E99.004C8B38@uk.ibm.com>
	<55C36E29.2040809@redhat.com>
	<OF6AD439B7.C81121A5-ON80257E9A.002E1FCA-80257E9A.002E9F79@uk.ibm.com>
Message-ID: <55C84A07.50102@redhat.com>

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.

>
> "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.

>
> 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

From arjan.tijms at gmail.com  Mon Aug 10 03:01:52 2015
From: arjan.tijms at gmail.com (arjan tijms)
Date: Mon, 10 Aug 2015 09:01:52 +0200
Subject: [cdi-dev] Bean<T> that only qualifies super types?
In-Reply-To: <55C847B4.5020906@redhat.com>
References: <CAE=-AhDnoaL=0kF+yZSEMHXzzQ_G6cx0D0FzAyc2-tm0LLcNGQ@mail.gmail.com>
	<55C47A0C.9060500@redhat.com>
	<CAE=-AhBgFsYQT_hBitRpvYyb2D5yU5UYi=qXV1zGJ5JNs_k5zw@mail.gmail.com>
	<55C49B18.2030404@redhat.com>
	<CAE=-AhBxeWT688h+Ne01PtMrwH6BUtsm=X-b+YiuFwgWEDRdww@mail.gmail.com>
	<55C847B4.5020906@redhat.com>
Message-ID: <CAE=-AhAgToPfy73ftjrqtx0+NFAFp6rBQ_aB8mAaMGSHvX41fg@mail.gmail.com>

Hi,

On Mon, Aug 10, 2015 at 8:41 AM, Martin Kouba <mkouba at redhat.com> wrote:
> Built-in beans are handled specially in Weld.

Okay, but if another spec wants to provide build-in beans (in this
case it concerns JSF 2.3), should it also do special things?

> Not really. HttpServletRequestBean also extends AbstractBuiltInBean and so
> the getBeanClass() method returns the HttpServletRequestBean.class.

I see, thanks for the pointer. After taking a closer look it appeared
that AbstractDecorableBuiltInBean is the one containing an overloaded
getBeanClass method. See
http://grepcode.com/file/repo1.maven.org/maven2/org.jboss.weld.se/weld-se/2.2.12.Final/org/jboss/weld/bean/builtin/AbstractDecorableBuiltInBean.java#71

@Override
public Class<?> getBeanClass() {
    return getClass();
}

Is this the recommended thing to do for build-in (spec provided)
beans? Should getBeanClass simply always return getClass()?  The spec
and JavaDoc aren't overly clear about this point.

Thanks for your help!

Kind regards,
Arjan Tijms







 See
> also:
> http://probe-weld.itos.redhat.com/weld-numberguess/weld-probe#/bean/f24c5153-d823-366c-bdc9-c3e1a6eb0812
>
>
>>
>> Same thing for UserTransaction, Principal, ServletRequest, etc.
>>
>> Kind regards,
>> Arjan Tijms
>>
>>
>>
>>
>>
>>>
>>>>
>>>> There's nothing wrong with that, is it?
>>>>
>>>> So by extension, is this wrong then?
>>>>
>>>> @Produces
>>>> public Foo produce() {
>>>>      return new FooImpl();
>>>> }
>>>
>>>
>>>
>>> This is OK. But the bean class of this producer is not Foo as mentioned
>>> above.
>>>
>>>
>>>>
>>>>
>>>>
>>>>> No, this is not possible. Qualifiers are tied to a bean definition, not
>>>>> to a
>>>>> bean type.
>>>>
>>>>
>>>>
>>>> So this would possibly be an enhancement or new feature request then.
>>>>
>>>>
>>>> I did found a workaround though, which seems to work because the Type
>>>> I'd like to hide happens to have generic parameters:
>>>>
>>>> private static class Dummy {}
>>>>
>>>> @Override
>>>> public Set<Type> getTypes() {
>>>>       return new HashSet<Type>(asList(Foo.class,
>>>> ParameterizedTypeImpl(Map.class, new Type[]{Dummy.class,
>>>> Dummy.class})));
>>>> }
>>>>
>>>> With those types the proxy that's generated contains methods for both
>>>> Foo and Map, but because the generic parameters are the private class,
>>>> the client application can never declare an injection point for this
>>>> (certain not accidentally).
>>>>
>>>> Another possible workaround I thought of is using a second Bean<T>
>>>> that only has Foo as its type and is @Dependent scoped, which then
>>>> asks the bean manager for an instance of a qualified Foo (qualifier is
>>>> of a private type). If I'm not mistaken the first Bean<T> would then
>>>> be called and an @RequestScoped proxy would be returned, which the
>>>> second Bean<T> can then return from its create() method.
>>>>
>>>> What do you think, any of these methods have potential unforeseen
>>>> side-effects or are they safe to use?
>>>>
>>>> Kind regards,
>>>> Arjan
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> Kind regards,
>>>>>> Arjan Tijms
>>>>>> _______________________________________________
>>>>>> 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
>>>
>>>
>>>
>>> --
>>> Martin Kouba
>>> Software Engineer
>>> Red Hat, Czech Republic
>
>
> --
> Martin Kouba
> Software Engineer
> Red Hat, Czech Republic

From EMIJIANG at uk.ibm.com  Tue Aug 11 05:16:20 2015
From: EMIJIANG at uk.ibm.com (Emily Jiang)
Date: Tue, 11 Aug 2015 10:16:20 +0100
Subject: [cdi-dev] Clarification on the difference on Vetoed and exclude
 filters regarding Java EE component classes
In-Reply-To: <55C84A07.50102@redhat.com>
References: <OFCB816FBA.16D9AE24-ON80257E99.004AC515-80257E99.004C8B38@uk.ibm.com>	<55C36E29.2040809@redhat.com>
	<OF6AD439B7.C81121A5-ON80257E9A.002E1FCA-80257E9A.002E9F79@uk.ibm.com>
	<55C84A07.50102@redhat.com>
Message-ID: <OFBD1806E5.B6C6CD7E-ON80257E9E.0030B88C-80257E9E.0032F148@uk.ibm.com>

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 

From arjan.tijms at gmail.com  Tue Aug 11 06:26:48 2015
From: arjan.tijms at gmail.com (arjan tijms)
Date: Tue, 11 Aug 2015 12:26:48 +0200
Subject: [cdi-dev] getBeanClass return value for build-in beans?
Message-ID: <CAE=-AhC_8+Mu9oSO_Ob-LZMrgx=P=coTWscCw5RCotGV+4RN_g@mail.gmail.com>

Hi,

This is split-off from the thread "Bean<T> that only qualifies super
types?", where the question came up what a Bean<T> should return from
the getBeanClass() method for the case of build-in beans.

The JavaDoc for getBeanClass() currently says the following:

"The bean class of the managed bean or session bean or of the bean
that declares the producer method or field."

See: https://javaee-spec.java.net/nonav/javadocs/javax/enterprise/inject/spi/Bean.html#getBeanClass()

The case where a Bean<T> instance is directly created and added as
bean to AfterBeanDiscovery in an extension does not seem to be covered
by this documentation.

Weld returns "this.class" here.

See http://grepcode.com/file/repo1.maven.org/maven2/org.jboss.weld.se/weld-se/2.2.12.Final/org/jboss/weld/bean/builtin/AbstractDecorableBuiltInBean.java#71

Is that what build-in beans should always do, and if so, should the
JavaDoc/spec be clarified for this?

Kind regards,
Arjan Tijms

From nigel.deakin at oracle.com  Tue Aug 11 11:33:18 2015
From: nigel.deakin at oracle.com (Nigel Deakin)
Date: Tue, 11 Aug 2015 16:33:18 +0100
Subject: [cdi-dev] CDI 2.0 EDR: Questions on asynchronous observers
Message-ID: <55CA15BE.8020404@oracle.com>

I've read section 10 "Events" of the CDI 2.0 early draft, and have a couple of quick questions about asynchronous 
observers.

I'd like to understand how these work with transactions. (I'm referring to normal observer methods here, not the rather 
specialised "transactional observer methods")

10.5 states "...An observer method may not directly initiate, commit or rollback JTA transactions."

This wording is unchanged from CDI 1.1. What is the reason for this restriction? I think it might be useful if an 
observer method was able to use the JTA API to start and end a transaction, especially when the observer method is being 
called asynchronously.

10.5.3 "If the observer method is asynchronous, it is called in... a new transaction context...".

What does "a new transaction context" mean? Does this mean that the container will start a transaction before calling 
the observer method? If so, it would be useful if the application could disable this. If not, it would be useful if the 
application could itself use the JTA API to start and end a transaction.

Nigel





From jharting at redhat.com  Wed Aug 12 04:10:18 2015
From: jharting at redhat.com (Jozef Hartinger)
Date: Wed, 12 Aug 2015 10:10:18 +0200
Subject: [cdi-dev] getBeanClass return value for build-in beans?
In-Reply-To: <CAE=-AhC_8+Mu9oSO_Ob-LZMrgx=P=coTWscCw5RCotGV+4RN_g@mail.gmail.com>
References: <CAE=-AhC_8+Mu9oSO_Ob-LZMrgx=P=coTWscCw5RCotGV+4RN_g@mail.gmail.com>
Message-ID: <55CAFF6A.5040900@redhat.com>

Hi Arjan,

the bean class in CDI is used for two purposes:

1) to identify the bean archive the bean belongs to (this is crucial for 
inter-module injection)
2) if the bean is an alternative, interceptor or decorator the bean 
class is used for matching with beans.xml enablement entries

Other than these, there are no restrictions imposed by the spec. Note 
that there is absolutely no requirement that the bean class is part of 
the bean types (as demonstrated by producer method/fields for example).

Therefore, you are free to use any class as a bean class that:
1) properly identifies the bean archive (i.e. is located in the bean 
archive where you want the custom bean to belong)
2) if the bean is an alternative, interceptor or decorator then choose 
the class whose name you want people to put to beans.xml when enabling it

What you indicated in the previous e-mails - that Weld does not work 
properly if the bean class is an abstract class looks like a bug in Weld 
that I will be investigating.

HTH,

Jozef



On 11.8.2015 12:26, arjan tijms wrote:
> Hi,
>
> This is split-off from the thread "Bean<T> that only qualifies super
> types?", where the question came up what a Bean<T> should return from
> the getBeanClass() method for the case of build-in beans.
>
> The JavaDoc for getBeanClass() currently says the following:
>
> "The bean class of the managed bean or session bean or of the bean
> that declares the producer method or field."
>
> See: https://javaee-spec.java.net/nonav/javadocs/javax/enterprise/inject/spi/Bean.html#getBeanClass()
>
> The case where a Bean<T> instance is directly created and added as
> bean to AfterBeanDiscovery in an extension does not seem to be covered
> by this documentation.
>
> Weld returns "this.class" here.
>
> See http://grepcode.com/file/repo1.maven.org/maven2/org.jboss.weld.se/weld-se/2.2.12.Final/org/jboss/weld/bean/builtin/AbstractDecorableBuiltInBean.java#71
>
> Is that what build-in beans should always do, and if so, should the
> JavaDoc/spec be clarified for this?
>
> Kind regards,
> Arjan Tijms
> _______________________________________________
> 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.
>

From mkouba at redhat.com  Wed Aug 12 04:22:00 2015
From: mkouba at redhat.com (Martin Kouba)
Date: Wed, 12 Aug 2015 10:22:00 +0200
Subject: [cdi-dev] getBeanClass return value for build-in beans?
In-Reply-To: <55CAFF6A.5040900@redhat.com>
References: <CAE=-AhC_8+Mu9oSO_Ob-LZMrgx=P=coTWscCw5RCotGV+4RN_g@mail.gmail.com>
	<55CAFF6A.5040900@redhat.com>
Message-ID: <55CB0228.7070507@redhat.com>

Hi Arjan,

please create a new spec issue. This should be definitely clarified.

Thanks,
Martin

Dne 12.8.2015 v 10:10 Jozef Hartinger napsal(a):
> Hi Arjan,
>
> the bean class in CDI is used for two purposes:
>
> 1) to identify the bean archive the bean belongs to (this is crucial for
> inter-module injection)
> 2) if the bean is an alternative, interceptor or decorator the bean
> class is used for matching with beans.xml enablement entries
>
> Other than these, there are no restrictions imposed by the spec. Note
> that there is absolutely no requirement that the bean class is part of
> the bean types (as demonstrated by producer method/fields for example).
>
> Therefore, you are free to use any class as a bean class that:
> 1) properly identifies the bean archive (i.e. is located in the bean
> archive where you want the custom bean to belong)
> 2) if the bean is an alternative, interceptor or decorator then choose
> the class whose name you want people to put to beans.xml when enabling it
>
> What you indicated in the previous e-mails - that Weld does not work
> properly if the bean class is an abstract class looks like a bug in Weld
> that I will be investigating.
>
> HTH,
>
> Jozef
>
>
>
> On 11.8.2015 12:26, arjan tijms wrote:
>> Hi,
>>
>> This is split-off from the thread "Bean<T> that only qualifies super
>> types?", where the question came up what a Bean<T> should return from
>> the getBeanClass() method for the case of build-in beans.
>>
>> The JavaDoc for getBeanClass() currently says the following:
>>
>> "The bean class of the managed bean or session bean or of the bean
>> that declares the producer method or field."
>>
>> See: https://javaee-spec.java.net/nonav/javadocs/javax/enterprise/inject/spi/Bean.html#getBeanClass()
>>
>> The case where a Bean<T> instance is directly created and added as
>> bean to AfterBeanDiscovery in an extension does not seem to be covered
>> by this documentation.
>>
>> Weld returns "this.class" here.
>>
>> See http://grepcode.com/file/repo1.maven.org/maven2/org.jboss.weld.se/weld-se/2.2.12.Final/org/jboss/weld/bean/builtin/AbstractDecorableBuiltInBean.java#71
>>
>> Is that what build-in beans should always do, and if so, should the
>> JavaDoc/spec be clarified for this?
>>
>> Kind regards,
>> Arjan Tijms
>> _______________________________________________
>> 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.
>

-- 
Martin Kouba
Software Engineer
Red Hat, Czech Republic

From jharting at redhat.com  Wed Aug 12 04:32:35 2015
From: jharting at redhat.com (Jozef Hartinger)
Date: Wed, 12 Aug 2015 10:32:35 +0200
Subject: [cdi-dev] CDI 2.0 EDR: Questions on asynchronous observers
In-Reply-To: <55CA15BE.8020404@oracle.com>
References: <55CA15BE.8020404@oracle.com>
Message-ID: <55CB04A3.4020406@redhat.com>



On 11.8.2015 17:33, Nigel Deakin wrote:
> I've read section 10 "Events" of the CDI 2.0 early draft, and have a couple of quick questions about asynchronous
> observers.
>
> I'd like to understand how these work with transactions. (I'm referring to normal observer methods here, not the rather
> specialised "transactional observer methods")
>
> 10.5 states "...An observer method may not directly initiate, commit or rollback JTA transactions."
>
> This wording is unchanged from CDI 1.1. What is the reason for this restriction? I think it might be useful if an
> observer method was able to use the JTA API to start and end a transaction, especially when the observer method is being
> called asynchronously.

I think this is just an oversight and this statement was not updated in 
the light of CDI 2.0 (although it should have).

>
> 10.5.3 "If the observer method is asynchronous, it is called in... a new transaction context...".
>
> What does "a new transaction context" mean? Does this mean that the container will start a transaction before calling
> the observer method? If so, it would be useful if the application could disable this. If not, it would be useful if the
> application could itself use the JTA API to start and end a transaction.

I think that what this statement is trying to say is simply that the 
transactional context of the event sender is not propagated to the async 
observer.

The observer should IMO be able to work with the transactional context 
using EJB managed transactions, @Transactional or manually with 
UserTransaction.

>
> Nigel
>
>
>
>
> _______________________________________________
> 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.
>

From arjan.tijms at gmail.com  Wed Aug 12 05:07:04 2015
From: arjan.tijms at gmail.com (arjan tijms)
Date: Wed, 12 Aug 2015 11:07:04 +0200
Subject: [cdi-dev] getBeanClass return value for build-in beans?
In-Reply-To: <55CAFF6A.5040900@redhat.com>
References: <CAE=-AhC_8+Mu9oSO_Ob-LZMrgx=P=coTWscCw5RCotGV+4RN_g@mail.gmail.com>
	<55CAFF6A.5040900@redhat.com>
Message-ID: <CAE=-AhAkfzsxZ1pAC6t8bB_4sQ95wWierz_=hGavs7-C0B+2=g@mail.gmail.com>

Hi,

On Wed, Aug 12, 2015 at 10:10 AM, Jozef Hartinger <jharting at redhat.com> wrote:
> Therefore, you are free to use any class as a bean class that:
> 1) properly identifies the bean archive (i.e. is located in the bean archive
> where you want the custom bean to belong)

In this particular case it concerns the javax.faces.jar for JSF 2.3.
Some vendors split up this archive in two, an API jar and an impl, jar
(although for JSF 2.3 we don't really encourage this). Therefor it
looks like it does make a difference if the Bean<T> implementation
will return this.class (an implementation type, like Weld does) or say
Flash.class (an API class).

> What you indicated in the previous e-mails - that Weld does not work
> properly if the bean class is an abstract class looks like a bug in Weld
> that I will be investigating.

I'm not 100% sure what the intend is. Is the proxy supposed to only
implement methods of the Types that are returned by the Bean<T>
implementation, or should it be smart enough to look at the super
types of whatever Type is returned?

So given:

public abstract class AbstractClass implements Interface { ... }

If getTypes returns only Abstract.class, then only the methods defined
by AbstractClass itself are implemented by the proxy. Those from
Interface throw exceptions when called.

If getTypes returns both Abstract.class and Interface.class, then all
methods defined by AbstractClass and Interface are implemented by the
proxy.

Is this how things should be, or should the proxy generator see for
itself that AbstractClass implements Interface?

Kind regards,
Arjan Tijms


>
> HTH,
>
> Jozef
>
>
>
>
> On 11.8.2015 12:26, arjan tijms wrote:
>>
>> Hi,
>>
>> This is split-off from the thread "Bean<T> that only qualifies super
>> types?", where the question came up what a Bean<T> should return from
>> the getBeanClass() method for the case of build-in beans.
>>
>> The JavaDoc for getBeanClass() currently says the following:
>>
>> "The bean class of the managed bean or session bean or of the bean
>> that declares the producer method or field."
>>
>> See:
>> https://javaee-spec.java.net/nonav/javadocs/javax/enterprise/inject/spi/Bean.html#getBeanClass()
>>
>> The case where a Bean<T> instance is directly created and added as
>> bean to AfterBeanDiscovery in an extension does not seem to be covered
>> by this documentation.
>>
>> Weld returns "this.class" here.
>>
>> See
>> http://grepcode.com/file/repo1.maven.org/maven2/org.jboss.weld.se/weld-se/2.2.12.Final/org/jboss/weld/bean/builtin/AbstractDecorableBuiltInBean.java#71
>>
>> Is that what build-in beans should always do, and if so, should the
>> JavaDoc/spec be clarified for this?
>>
>> Kind regards,
>> Arjan Tijms
>> _______________________________________________
>> 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.
>>
>

From arjan.tijms at gmail.com  Wed Aug 12 05:07:51 2015
From: arjan.tijms at gmail.com (arjan tijms)
Date: Wed, 12 Aug 2015 11:07:51 +0200
Subject: [cdi-dev] getBeanClass return value for build-in beans?
In-Reply-To: <55CB0228.7070507@redhat.com>
References: <CAE=-AhC_8+Mu9oSO_Ob-LZMrgx=P=coTWscCw5RCotGV+4RN_g@mail.gmail.com>
	<55CAFF6A.5040900@redhat.com> <55CB0228.7070507@redhat.com>
Message-ID: <CAE=-AhDy_B+mt4kPJqVtP+FAyFEJdzMGC7AS2Qga7=q3iVwmcA@mail.gmail.com>

Hi Martin,

On Wed, Aug 12, 2015 at 10:22 AM, Martin Kouba <mkouba at redhat.com> wrote:
> please create a new spec issue. This should be definitely clarified.

I'll do that, thanks!

Kind regards,
Arjan Tijms



>
> Thanks,
> Martin
>
> Dne 12.8.2015 v 10:10 Jozef Hartinger napsal(a):
>
>> Hi Arjan,
>>
>> the bean class in CDI is used for two purposes:
>>
>> 1) to identify the bean archive the bean belongs to (this is crucial for
>> inter-module injection)
>> 2) if the bean is an alternative, interceptor or decorator the bean
>> class is used for matching with beans.xml enablement entries
>>
>> Other than these, there are no restrictions imposed by the spec. Note
>> that there is absolutely no requirement that the bean class is part of
>> the bean types (as demonstrated by producer method/fields for example).
>>
>> Therefore, you are free to use any class as a bean class that:
>> 1) properly identifies the bean archive (i.e. is located in the bean
>> archive where you want the custom bean to belong)
>> 2) if the bean is an alternative, interceptor or decorator then choose
>> the class whose name you want people to put to beans.xml when enabling it
>>
>> What you indicated in the previous e-mails - that Weld does not work
>> properly if the bean class is an abstract class looks like a bug in Weld
>> that I will be investigating.
>>
>> HTH,
>>
>> Jozef
>>
>>
>>
>> On 11.8.2015 12:26, arjan tijms wrote:
>>>
>>> Hi,
>>>
>>> This is split-off from the thread "Bean<T> that only qualifies super
>>> types?", where the question came up what a Bean<T> should return from
>>> the getBeanClass() method for the case of build-in beans.
>>>
>>> The JavaDoc for getBeanClass() currently says the following:
>>>
>>> "The bean class of the managed bean or session bean or of the bean
>>> that declares the producer method or field."
>>>
>>> See:
>>> https://javaee-spec.java.net/nonav/javadocs/javax/enterprise/inject/spi/Bean.html#getBeanClass()
>>>
>>> The case where a Bean<T> instance is directly created and added as
>>> bean to AfterBeanDiscovery in an extension does not seem to be covered
>>> by this documentation.
>>>
>>> Weld returns "this.class" here.
>>>
>>> See
>>> http://grepcode.com/file/repo1.maven.org/maven2/org.jboss.weld.se/weld-se/2.2.12.Final/org/jboss/weld/bean/builtin/AbstractDecorableBuiltInBean.java#71
>>>
>>> Is that what build-in beans should always do, and if so, should the
>>> JavaDoc/spec be clarified for this?
>>>
>>> Kind regards,
>>> Arjan Tijms
>>> _______________________________________________
>>> 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.
>>
>
> --
> Martin Kouba
> Software Engineer
> Red Hat, Czech Republic

From jharting at redhat.com  Thu Aug 13 07:05:14 2015
From: jharting at redhat.com (Jozef Hartinger)
Date: Thu, 13 Aug 2015 13:05:14 +0200
Subject: [cdi-dev] getBeanClass return value for build-in beans?
In-Reply-To: <CAE=-AhAkfzsxZ1pAC6t8bB_4sQ95wWierz_=hGavs7-C0B+2=g@mail.gmail.com>
References: <CAE=-AhC_8+Mu9oSO_Ob-LZMrgx=P=coTWscCw5RCotGV+4RN_g@mail.gmail.com>
	<55CAFF6A.5040900@redhat.com>
	<CAE=-AhAkfzsxZ1pAC6t8bB_4sQ95wWierz_=hGavs7-C0B+2=g@mail.gmail.com>
Message-ID: <55CC79EA.8040205@redhat.com>

On 12.8.2015 11:07, arjan tijms wrote:
> So given:
>
> public abstract class AbstractClass implements Interface { ... }
>
> If getTypes returns only Abstract.class, then only the methods defined
> by AbstractClass itself are implemented by the proxy. Those from
> Interface throw exceptions when called.
>
> If getTypes returns both Abstract.class and Interface.class, then all
> methods defined by AbstractClass and Interface are implemented by the
> proxy.
>
> Is this how things should be, or should the proxy generator see for
> itself that AbstractClass implements Interface?

I think this is a bug. Even if getTypes() returns AbstractClass only, 
you should still be able to call all the methods of AbstractClass 
(including those that come from Interface) and therefore, the proxy 
class generator should be generating these.

I filed https://issues.jboss.org/browse/WELD-2010 for Weld.

From arjan.tijms at gmail.com  Thu Aug 13 07:10:03 2015
From: arjan.tijms at gmail.com (arjan tijms)
Date: Thu, 13 Aug 2015 13:10:03 +0200
Subject: [cdi-dev] getBeanClass return value for build-in beans?
In-Reply-To: <55CC79EA.8040205@redhat.com>
References: <CAE=-AhC_8+Mu9oSO_Ob-LZMrgx=P=coTWscCw5RCotGV+4RN_g@mail.gmail.com>
	<55CAFF6A.5040900@redhat.com>
	<CAE=-AhAkfzsxZ1pAC6t8bB_4sQ95wWierz_=hGavs7-C0B+2=g@mail.gmail.com>
	<55CC79EA.8040205@redhat.com>
Message-ID: <CAE=-AhDktXk1jjAj_F6u7TKDN+5rr2WR9L3GtmRCtTFR2v+7Lw@mail.gmail.com>

Hi,

On Thu, Aug 13, 2015 at 1:05 PM, Jozef Hartinger <jharting at redhat.com> wrote:
> On 12.8.2015 11:07, arjan tijms wrote:

> I think this is a bug. Even if getTypes() returns AbstractClass only, you
> should still be able to call all the methods of AbstractClass (including
> those that come from Interface) and therefore, the proxy class generator
> should be generating these.
>
> I filed https://issues.jboss.org/browse/WELD-2010 for Weld.


Okay, thanks for the update!

Kind regards,
Arjan Tijms

From werner.keil at gmail.com  Thu Aug 13 09:24:00 2015
From: werner.keil at gmail.com (Werner Keil)
Date: Thu, 13 Aug 2015 15:24:00 +0200
Subject: [cdi-dev] getBeanClass return value for build-in beans?
Message-ID: <CAAGawe2pmSrdybmSoNCmFJB8EAhKPyrcB8a4kBPe1gaYCFhJFw@mail.gmail.com>

>In this particular case it concerns the javax.faces.jar for JSF 2.3.
>Some vendors split up this archive in two, an API jar and an impl, jar
>(although for JSF 2.3 we don't really encourage this).

Could you explain, why the JSF 2.3 API and RI are molded together?
If the API JAR is no longer separate from the RI (as it was till
javax.faces-api-2.2.jar
<http://search.maven.org/remotecontent?filepath=javax/faces/javax.faces-api/2.2/javax.faces-api-2.2.jar>)
it seems, every vendor has to build that API JAR from scratch, or carry a
3-4 MB JAR where the API in 2.2 was just a little under 700kB ?;-|

Not to mention often bizarre side-effects if you (accidentially in that
case) mix multiple JSF implementations in some web-apps. I had to resolve
many of those myself between e.g. the JBoss implementation and Apache
RichFaces.

Werner

On Wed, Aug 12, 2015 at 11:07 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. getBeanClass return value for build-in beans? (arjan tijms)
>    2. CDI 2.0 EDR: Questions on asynchronous observers (Nigel Deakin)
>    3. Re: getBeanClass return value for build-in beans?
>       (Jozef Hartinger)
>    4. Re: getBeanClass return value for build-in beans? (Martin Kouba)
>    5. Re: CDI 2.0 EDR: Questions on asynchronous observers
>       (Jozef Hartinger)
>    6. Re: getBeanClass return value for build-in beans? (arjan tijms)
>    7. Re: getBeanClass return value for build-in beans? (arjan tijms)
>
>
> ----------------------------------------------------------------------
>
> Message: 6
> Date: Wed, 12 Aug 2015 11:07:04 +0200
> From: arjan tijms <arjan.tijms at gmail.com>
> Subject: Re: [cdi-dev] getBeanClass return value for build-in beans?
> To: Jozef Hartinger <jharting at redhat.com>
> Cc: "cdi-dev at lists.jboss.org" <cdi-dev at lists.jboss.org>
> Message-ID:
>         <CAE=-AhAkfzsxZ1pAC6t8bB_4sQ95wWierz_=hGavs7-C0B+2=
> g at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> Hi,
>
> On Wed, Aug 12, 2015 at 10:10 AM, Jozef Hartinger <jharting at redhat.com>
> wrote:
> > Therefore, you are free to use any class as a bean class that:
> > 1) properly identifies the bean archive (i.e. is located in the bean
> archive
> > where you want the custom bean to belong)
>
> In this particular case it concerns the javax.faces.jar for JSF 2.3.
> Some vendors split up this archive in two, an API jar and an impl, jar
> (although for JSF 2.3 we don't really encourage this). Therefor it
> looks like it does make a difference if the Bean<T> implementation
> will return this.class (an implementation type, like Weld does) or say
> Flash.class (an API class).
>
> > What you indicated in the previous e-mails - that Weld does not work
> > properly if the bean class is an abstract class looks like a bug in Weld
> > that I will be investigating.
>
> I'm not 100% sure what the intend is. Is the proxy supposed to only
> implement methods of the Types that are returned by the Bean<T>
> implementation, or should it be smart enough to look at the super
> types of whatever Type is returned?
>
> So given:
>
> public abstract class AbstractClass implements Interface { ... }
>
> If getTypes returns only Abstract.class, then only the methods defined
> by AbstractClass itself are implemented by the proxy. Those from
> Interface throw exceptions when called.
>
> If getTypes returns both Abstract.class and Interface.class, then all
> methods defined by AbstractClass and Interface are implemented by the
> proxy.
>
> Is this how things should be, or should the proxy generator see for
> itself that AbstractClass implements Interface?
>
> Kind regards,
> Arjan Tijms
>
>
> >
> > HTH,
> >
> > Jozef
> >
> >
> >
> >
> > On 11.8.2015 12:26, arjan tijms wrote:
> >>
> >> Hi,
> >>
> >> This is split-off from the thread "Bean<T> that only qualifies super
> >> types?", where the question came up what a Bean<T> should return from
> >> the getBeanClass() method for the case of build-in beans.
> >>
> >> The JavaDoc for getBeanClass() currently says the following:
> >>
> >> "The bean class of the managed bean or session bean or of the bean
> >> that declares the producer method or field."
> >>
> >> See:
> >>
> https://javaee-spec.java.net/nonav/javadocs/javax/enterprise/inject/spi/Bean.html#getBeanClass()
> >>
> >> The case where a Bean<T> instance is directly created and added as
> >> bean to AfterBeanDiscovery in an extension does not seem to be covered
> >> by this documentation.
> >>
> >> Weld returns "this.class" here.
> >>
> >> See
> >>
> http://grepcode.com/file/repo1.maven.org/maven2/org.jboss.weld.se/weld-se/2.2.12.Final/org/jboss/weld/bean/builtin/AbstractDecorableBuiltInBean.java#71
> >>
> >> Is that what build-in beans should always do, and if so, should the
> >> JavaDoc/spec be clarified for this?
> >>
> >> Kind regards,
> >> Arjan Tijms
> >> _______________________________________________
> >> 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.
> >>
> >
>
>
> ------------------------------
>
> Message: 7
> Date: Wed, 12 Aug 2015 11:07:51 +0200
> From: arjan tijms <arjan.tijms at gmail.com>
> Subject: Re: [cdi-dev] getBeanClass return value for build-in beans?
> To: Martin Kouba <mkouba at redhat.com>
> Cc: "cdi-dev at lists.jboss.org" <cdi-dev at lists.jboss.org>
> Message-ID:
>         <CAE=-AhDy_B+mt4kPJqVtP+FAyFEJdzMGC7AS2Qga7=
> q3iVwmcA at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> Hi Martin,
>
> On Wed, Aug 12, 2015 at 10:22 AM, Martin Kouba <mkouba at redhat.com> wrote:
> > please create a new spec issue. This should be definitely clarified.
>
> I'll do that, thanks!
>
> Kind regards,
> Arjan Tijms
>
>
>
> >
> > Thanks,
> > Martin
> >
> > Dne 12.8.2015 v 10:10 Jozef Hartinger napsal(a):
> >
> >> Hi Arjan,
> >>
> >> the bean class in CDI is used for two purposes:
> >>
> >> 1) to identify the bean archive the bean belongs to (this is crucial for
> >> inter-module injection)
> >> 2) if the bean is an alternative, interceptor or decorator the bean
> >> class is used for matching with beans.xml enablement entries
> >>
> >> Other than these, there are no restrictions imposed by the spec. Note
> >> that there is absolutely no requirement that the bean class is part of
> >> the bean types (as demonstrated by producer method/fields for example).
> >>
> >> Therefore, you are free to use any class as a bean class that:
> >> 1) properly identifies the bean archive (i.e. is located in the bean
> >> archive where you want the custom bean to belong)
> >> 2) if the bean is an alternative, interceptor or decorator then choose
> >> the class whose name you want people to put to beans.xml when enabling
> it
> >>
> >> What you indicated in the previous e-mails - that Weld does not work
> >> properly if the bean class is an abstract class looks like a bug in Weld
> >> that I will be investigating.
> >>
> >> HTH,
> >>
> >> Jozef
> >>
> >>
> >>
> >> On 11.8.2015 12:26, arjan tijms wrote:
> >>>
> >>> Hi,
> >>>
> >>> This is split-off from the thread "Bean<T> that only qualifies super
> >>> types?", where the question came up what a Bean<T> should return from
> >>> the getBeanClass() method for the case of build-in beans.
> >>>
> >>> The JavaDoc for getBeanClass() currently says the following:
> >>>
> >>> "The bean class of the managed bean or session bean or of the bean
> >>> that declares the producer method or field."
> >>>
> >>> See:
> >>>
> https://javaee-spec.java.net/nonav/javadocs/javax/enterprise/inject/spi/Bean.html#getBeanClass()
> >>>
> >>> The case where a Bean<T> instance is directly created and added as
> >>> bean to AfterBeanDiscovery in an extension does not seem to be covered
> >>> by this documentation.
> >>>
> >>> Weld returns "this.class" here.
> >>>
> >>> See
> >>>
> http://grepcode.com/file/repo1.maven.org/maven2/org.jboss.weld.se/weld-se/2.2.12.Final/org/jboss/weld/bean/builtin/AbstractDecorableBuiltInBean.java#71
> >>>
> >>> Is that what build-in beans should always do, and if so, should the
> >>> JavaDoc/spec be clarified for this?
> >>>
> >>> Kind regards,
> >>> Arjan Tijms
> >>> _______________________________________________
> >>> 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.
> >>
> >
> > --
> > 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.
>
> End of cdi-dev Digest, Vol 57, Issue 6
> **************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150813/1e7244f7/attachment-0001.html 

From edward.burns at oracle.com  Thu Aug 13 09:44:24 2015
From: edward.burns at oracle.com (Edward Burns)
Date: Thu, 13 Aug 2015 06:44:24 -0700
Subject: [cdi-dev] getBeanClass return value for build-in beans?
In-Reply-To: <CAAGawe2pmSrdybmSoNCmFJB8EAhKPyrcB8a4kBPe1gaYCFhJFw@mail.gmail.com>
References: <CAAGawe2pmSrdybmSoNCmFJB8EAhKPyrcB8a4kBPe1gaYCFhJFw@mail.gmail.com>
Message-ID: <21964.40760.775241.930217@gargle.gargle.HOWL>

>>>>> On Thu, 13 Aug 2015 15:24:00 +0200, Werner Keil <werner.keil at gmail.com> said:

>> In this particular case it concerns the javax.faces.jar for JSF 2.3.
>> Some vendors split up this archive in two, an API jar and an impl, jar
>> (although for JSF 2.3 we don't really encourage this).

WK> Could you explain, why the JSF 2.3 API and RI are molded together?
WK> If the API JAR is no longer separate from the RI (as it was till
WK> javax.faces-api-2.2.jar
WK> <http://search.maven.org/remotecontent?filepath=javax/faces/javax.faces-api/2.2/javax.faces-api-2.2.jar>)
WK> it seems, every vendor has to build that API JAR from scratch, or carry a
WK> 3-4 MB JAR where the API in 2.2 was just a little under 700kB ?;-|

We will be producing a separate API artifact for all the JCP
milestones.  

It is very important to note that the for all Java EE API jars,
including JSF, the only supported use is to satisfy compile time
dependencies.  Including a Java EE API jar in a runtime classpath is not
supported and may cause unexpected behavior.

If there is demand we can investigate producing a JSF API jar for
-SNAPSHOT releases as well.

Ed

-- 
| edward.burns at oracle.com | office: +1 407 458 0017
| 58 Business days til JavaOne 2015
| 73 Business days til DOAG 2015

From werner.keil at gmail.com  Thu Aug 13 09:55:49 2015
From: werner.keil at gmail.com (Werner Keil)
Date: Thu, 13 Aug 2015 15:55:49 +0200
Subject: [cdi-dev] getBeanClass return value for build-in beans?
In-Reply-To: <21964.40760.775241.930217@gargle.gargle.HOWL>
References: <CAAGawe2pmSrdybmSoNCmFJB8EAhKPyrcB8a4kBPe1gaYCFhJFw@mail.gmail.com>
	<21964.40760.775241.930217@gargle.gargle.HOWL>
Message-ID: <CAAGawe0eCfjhTNR5kJSRwYEm9NE45XP6Tf13xUSJQqpxYKvFLA@mail.gmail.com>

OK, thanks for the clarification.
The way Arjan phrased it sounded like 2.3 would generally keep them in one
place.

Hence, if separate JARs are something CDI 2 has to consider, getBeanClass()
and other methods must work for separate API and impl JARs ;-)

Werner

On Thu, Aug 13, 2015 at 3:44 PM, Edward Burns <edward.burns at oracle.com>
wrote:

> >>>>> On Thu, 13 Aug 2015 15:24:00 +0200, Werner Keil <
> werner.keil at gmail.com> said:
>
> >> In this particular case it concerns the javax.faces.jar for JSF 2.3.
> >> Some vendors split up this archive in two, an API jar and an impl, jar
> >> (although for JSF 2.3 we don't really encourage this).
>
> WK> Could you explain, why the JSF 2.3 API and RI are molded together?
> WK> If the API JAR is no longer separate from the RI (as it was till
> WK> javax.faces-api-2.2.jar
> WK> <
> http://search.maven.org/remotecontent?filepath=javax/faces/javax.faces-api/2.2/javax.faces-api-2.2.jar
> >)
> WK> it seems, every vendor has to build that API JAR from scratch, or
> carry a
> WK> 3-4 MB JAR where the API in 2.2 was just a little under 700kB ?;-|
>
> We will be producing a separate API artifact for all the JCP
> milestones.
>
> It is very important to note that the for all Java EE API jars,
> including JSF, the only supported use is to satisfy compile time
> dependencies.  Including a Java EE API jar in a runtime classpath is not
> supported and may cause unexpected behavior.
>
> If there is demand we can investigate producing a JSF API jar for
> -SNAPSHOT releases as well.
>
> Ed
>
> --
> | edward.burns at oracle.com | office: +1 407 458 0017
> | 58 Business days til JavaOne 2015
> | 73 Business days til DOAG 2015
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150813/c0e82e18/attachment.html 

From werner.keil at gmail.com  Thu Aug 13 10:13:40 2015
From: werner.keil at gmail.com (Werner Keil)
Date: Thu, 13 Aug 2015 16:13:40 +0200
Subject: [cdi-dev] getBeanClass return value for build-in beans?
In-Reply-To: <55CCA318.3040108@oracle.com>
References: <CAAGawe2pmSrdybmSoNCmFJB8EAhKPyrcB8a4kBPe1gaYCFhJFw@mail.gmail.com>
	<21964.40760.775241.930217@gargle.gargle.HOWL>
	<CAAGawe0eCfjhTNR5kJSRwYEm9NE45XP6Tf13xUSJQqpxYKvFLA@mail.gmail.com>
	<55CCA318.3040108@oracle.com>
Message-ID: <CAAGawe00BozP+doe487V-0XOfAh0TFRrC7P_mdzN=XrQayYfYw@mail.gmail.com>

Well as of  EAP 6.x (Java EE 6) JBoss seems to have them separately also at
runtime;-)

I don't have a more recent version here, so maybe they'll change it with
Wildfly...?

Kind Regards,
Werner

On Thu, Aug 13, 2015 at 4:00 PM, manfred riem <manfred.riem at oracle.com>
wrote:

> Hi Werner,
>
> Arjan is correct.
>
> The runtime classpath will have the impl JSF 2.3 JAR and it will contain
> the javax.faces and com.sun.faces packages.
>
> The API jar we are referring to will not be part of the runtime classpath
> and as such should never be on the server runtime classpath, but could be
> used to compile against (and it will contain only the javax.faces packages)
>
> Thanks!
>
> Kind regards,
> Manfred Riem
>
>
> On 8/13/15, 8:55 AM, Werner Keil wrote:
>
> OK, thanks for the clarification.
> The way Arjan phrased it sounded like 2.3 would generally keep them in one
> place.
>
> Hence, if separate JARs are something CDI 2 has to consider,
> getBeanClass() and other methods must work for separate API and impl JARs
> ;-)
>
> Werner
>
> On Thu, Aug 13, 2015 at 3:44 PM, Edward Burns <edward.burns at oracle.com>
> wrote:
>
>> >>>>> On Thu, 13 Aug 2015 15:24:00 +0200, Werner Keil <
>> werner.keil at gmail.com> said:
>>
>> >> In this particular case it concerns the javax.faces.jar for JSF 2.3.
>> >> Some vendors split up this archive in two, an API jar and an impl, jar
>> >> (although for JSF 2.3 we don't really encourage this).
>>
>> WK> Could you explain, why the JSF 2.3 API and RI are molded together?
>> WK> If the API JAR is no longer separate from the RI (as it was till
>> WK> javax.faces-api-2.2.jar
>> WK> <
>> http://search.maven.org/remotecontent?filepath=javax/faces/javax.faces-api/2.2/javax.faces-api-2.2.jar
>> >)
>> WK> it seems, every vendor has to build that API JAR from scratch, or
>> carry a
>> WK> 3-4 MB JAR where the API in 2.2 was just a little under 700kB ?;-|
>>
>> We will be producing a separate API artifact for all the JCP
>> milestones.
>>
>> It is very important to note that the for all Java EE API jars,
>> including JSF, the only supported use is to satisfy compile time
>> dependencies.  Including a Java EE API jar in a runtime classpath is not
>> supported and may cause unexpected behavior.
>>
>> If there is demand we can investigate producing a JSF API jar for
>> -SNAPSHOT releases as well.
>>
>> Ed
>>
>> --
>> | edward.burns at oracle.com | office: +1 407 458 0017
>> | 58 Business days til JavaOne 2015
>> | 73 Business days til DOAG 2015
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150813/e9209dd9/attachment.html 

From manfred.riem at oracle.com  Thu Aug 13 10:00:56 2015
From: manfred.riem at oracle.com (manfred riem)
Date: Thu, 13 Aug 2015 09:00:56 -0500
Subject: [cdi-dev] getBeanClass return value for build-in beans?
In-Reply-To: <CAAGawe0eCfjhTNR5kJSRwYEm9NE45XP6Tf13xUSJQqpxYKvFLA@mail.gmail.com>
References: <CAAGawe2pmSrdybmSoNCmFJB8EAhKPyrcB8a4kBPe1gaYCFhJFw@mail.gmail.com>
	<21964.40760.775241.930217@gargle.gargle.HOWL>
	<CAAGawe0eCfjhTNR5kJSRwYEm9NE45XP6Tf13xUSJQqpxYKvFLA@mail.gmail.com>
Message-ID: <55CCA318.3040108@oracle.com>

Hi Werner,

Arjan is correct.

The runtime classpath will have the impl JSF 2.3 JAR and it will contain 
the javax.faces and com.sun.faces packages.

The API jar we are referring to will not be part of the runtime 
classpath and as such should never be on the server runtime classpath, 
but could be used to compile against (and it will contain only the 
javax.faces packages)

Thanks!

Kind regards,
Manfred Riem

On 8/13/15, 8:55 AM, Werner Keil wrote:
> OK, thanks for the clarification.
> The way Arjan phrased it sounded like 2.3 would generally keep them in 
> one place.
>
> Hence, if separate JARs are something CDI 2 has to consider, 
> getBeanClass() and other methods must work for separate API and impl 
> JARs ;-)
>
> Werner
>
> On Thu, Aug 13, 2015 at 3:44 PM, Edward Burns <edward.burns at oracle.com 
> <mailto:edward.burns at oracle.com>> wrote:
>
>     >>>>> On Thu, 13 Aug 2015 15:24:00 +0200, Werner Keil
>     <werner.keil at gmail.com <mailto:werner.keil at gmail.com>> said:
>
>     >> In this particular case it concerns the javax.faces.jar for JSF 2.3.
>     >> Some vendors split up this archive in two, an API jar and an
>     impl, jar
>     >> (although for JSF 2.3 we don't really encourage this).
>
>     WK> Could you explain, why the JSF 2.3 API and RI are molded together?
>     WK> If the API JAR is no longer separate from the RI (as it was till
>     WK> javax.faces-api-2.2.jar
>     WK>
>     <http://search.maven.org/remotecontent?filepath=javax/faces/javax.faces-api/2.2/javax.faces-api-2.2.jar>)
>     WK> it seems, every vendor has to build that API JAR from scratch,
>     or carry a
>     WK> 3-4 MB JAR where the API in 2.2 was just a little under 700kB ?;-|
>
>     We will be producing a separate API artifact for all the JCP
>     milestones.
>
>     It is very important to note that the for all Java EE API jars,
>     including JSF, the only supported use is to satisfy compile time
>     dependencies.  Including a Java EE API jar in a runtime classpath
>     is not
>     supported and may cause unexpected behavior.
>
>     If there is demand we can investigate producing a JSF API jar for
>     -SNAPSHOT releases as well.
>
>     Ed
>
>     --
>     | edward.burns at oracle.com <mailto:edward.burns at oracle.com> |
>     office: +1 407 458 0017 <tel:%2B1%20407%20458%200017>
>     | 58 Business days til JavaOne 2015
>     | 73 Business days til DOAG 2015
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150813/914a6fab/attachment-0001.html 

From werner.keil at gmail.com  Thu Aug 13 14:24:57 2015
From: werner.keil at gmail.com (Werner Keil)
Date: Thu, 13 Aug 2015 20:24:57 +0200
Subject: [cdi-dev] getBeanClass return value for build-in beans?
Message-ID: <CAAGawe0hb3dRK0L_Q_zcgMUA86MwSc6BHWvsoHBQs_DA_jz-GQ@mail.gmail.com>

Manfred,

For Glassfish probably, but at least the version of JBoss we use here (EAP
6) has these JARs separate at runtime, too.

Werner

On Thu, Aug 13, 2015 at 7:02 PM, <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: getBeanClass return value for build-in beans? (Edward Burns)
>    2. Re: getBeanClass return value for build-in beans? (Werner Keil)
>    3. Re: getBeanClass return value for build-in beans? (Werner Keil)
>    4. Re: getBeanClass return value for build-in beans? (manfred riem)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 13 Aug 2015 06:44:24 -0700
> From: Edward Burns <edward.burns at oracle.com>
> Subject: Re: [cdi-dev] getBeanClass return value for build-in beans?
> To: Werner Keil <werner.keil at gmail.com>
> Cc: Manfred Riem <manfred.riem at oracle.com>, cdi-dev
>         <cdi-dev at lists.jboss.org>
> Message-ID: <21964.40760.775241.930217 at gargle.gargle.HOWL>
> Content-Type: text/plain; charset=us-ascii
>
> >>>>> On Thu, 13 Aug 2015 15:24:00 +0200, Werner Keil <
> werner.keil at gmail.com> said:
>
> >> In this particular case it concerns the javax.faces.jar for JSF 2.3.
> >> Some vendors split up this archive in two, an API jar and an impl, jar
> >> (although for JSF 2.3 we don't really encourage this).
>
> WK> Could you explain, why the JSF 2.3 API and RI are molded together?
> WK> If the API JAR is no longer separate from the RI (as it was till
> WK> javax.faces-api-2.2.jar
> WK> <
> http://search.maven.org/remotecontent?filepath=javax/faces/javax.faces-api/2.2/javax.faces-api-2.2.jar
> >)
> WK> it seems, every vendor has to build that API JAR from scratch, or
> carry a
> WK> 3-4 MB JAR where the API in 2.2 was just a little under 700kB ?;-|
>
> We will be producing a separate API artifact for all the JCP
> milestones.
>
> It is very important to note that the for all Java EE API jars,
> including JSF, the only supported use is to satisfy compile time
> dependencies.  Including a Java EE API jar in a runtime classpath is not
> supported and may cause unexpected behavior.
>
> If there is demand we can investigate producing a JSF API jar for
> -SNAPSHOT releases as well.
>
> Ed
>
> --
> | edward.burns at oracle.com | office: +1 407 458 0017
> | 58 Business days til JavaOne 2015
> | 73 Business days til DOAG 2015
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 13 Aug 2015 15:55:49 +0200
> From: Werner Keil <werner.keil at gmail.com>
> Subject: Re: [cdi-dev] getBeanClass return value for build-in beans?
> To: Edward Burns <edward.burns at oracle.com>
> Cc: Manfred Riem <manfred.riem at oracle.com>, cdi-dev
>         <cdi-dev at lists.jboss.org>
> Message-ID:
>         <
> CAAGawe0eCfjhTNR5kJSRwYEm9NE45XP6Tf13xUSJQqpxYKvFLA at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> OK, thanks for the clarification.
> The way Arjan phrased it sounded like 2.3 would generally keep them in one
> place.
>
> Hence, if separate JARs are something CDI 2 has to consider, getBeanClass()
> and other methods must work for separate API and impl JARs ;-)
>
> Werner
>
> On Thu, Aug 13, 2015 at 3:44 PM, Edward Burns <edward.burns at oracle.com>
> wrote:
>
> > >>>>> On Thu, 13 Aug 2015 15:24:00 +0200, Werner Keil <
> > werner.keil at gmail.com> said:
> >
> > >> In this particular case it concerns the javax.faces.jar for JSF 2.3.
> > >> Some vendors split up this archive in two, an API jar and an impl, jar
> > >> (although for JSF 2.3 we don't really encourage this).
> >
> > WK> Could you explain, why the JSF 2.3 API and RI are molded together?
> > WK> If the API JAR is no longer separate from the RI (as it was till
> > WK> javax.faces-api-2.2.jar
> > WK> <
> >
> http://search.maven.org/remotecontent?filepath=javax/faces/javax.faces-api/2.2/javax.faces-api-2.2.jar
> > >)
> > WK> it seems, every vendor has to build that API JAR from scratch, or
> > carry a
> > WK> 3-4 MB JAR where the API in 2.2 was just a little under 700kB ?;-|
> >
> > We will be producing a separate API artifact for all the JCP
> > milestones.
> >
> > It is very important to note that the for all Java EE API jars,
> > including JSF, the only supported use is to satisfy compile time
> > dependencies.  Including a Java EE API jar in a runtime classpath is not
> > supported and may cause unexpected behavior.
> >
> > If there is demand we can investigate producing a JSF API jar for
> > -SNAPSHOT releases as well.
> >
> > Ed
> >
> > --
> > | edward.burns at oracle.com | office: +1 407 458 0017
> > | 58 Business days til JavaOne 2015
> > | 73 Business days til DOAG 2015
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20150813/c0e82e18/attachment-0001.html
>
> ------------------------------
>
> Message: 3
> Date: Thu, 13 Aug 2015 16:13:40 +0200
> From: Werner Keil <werner.keil at gmail.com>
> Subject: Re: [cdi-dev] getBeanClass return value for build-in beans?
> To: manfred riem <manfred.riem at oracle.com>
> Cc: Edward Burns <edward.burns at oracle.com>, cdi-dev
>         <cdi-dev at lists.jboss.org>
> Message-ID:
>         <CAAGawe00BozP+doe487V-0XOfAh0TFRrC7P_mdzN=
> XrQayYfYw at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Well as of  EAP 6.x (Java EE 6) JBoss seems to have them separately also at
> runtime;-)
>
> I don't have a more recent version here, so maybe they'll change it with
> Wildfly...?
>
> Kind Regards,
> Werner
>
> On Thu, Aug 13, 2015 at 4:00 PM, manfred riem <manfred.riem at oracle.com>
> wrote:
>
> > Hi Werner,
> >
> > Arjan is correct.
> >
> > The runtime classpath will have the impl JSF 2.3 JAR and it will contain
> > the javax.faces and com.sun.faces packages.
> >
> > The API jar we are referring to will not be part of the runtime classpath
> > and as such should never be on the server runtime classpath, but could be
> > used to compile against (and it will contain only the javax.faces
> packages)
> >
> > Thanks!
> >
> > Kind regards,
> > Manfred Riem
> >
> >
> > On 8/13/15, 8:55 AM, Werner Keil wrote:
> >
> > OK, thanks for the clarification.
> > The way Arjan phrased it sounded like 2.3 would generally keep them in
> one
> > place.
> >
> > Hence, if separate JARs are something CDI 2 has to consider,
> > getBeanClass() and other methods must work for separate API and impl JARs
> > ;-)
> >
> > Werner
> >
> > On Thu, Aug 13, 2015 at 3:44 PM, Edward Burns <edward.burns at oracle.com>
> > wrote:
> >
> >> >>>>> On Thu, 13 Aug 2015 15:24:00 +0200, Werner Keil <
> >> werner.keil at gmail.com> said:
> >>
> >> >> In this particular case it concerns the javax.faces.jar for JSF 2.3.
> >> >> Some vendors split up this archive in two, an API jar and an impl,
> jar
> >> >> (although for JSF 2.3 we don't really encourage this).
> >>
> >> WK> Could you explain, why the JSF 2.3 API and RI are molded together?
> >> WK> If the API JAR is no longer separate from the RI (as it was till
> >> WK> javax.faces-api-2.2.jar
> >> WK> <
> >>
> http://search.maven.org/remotecontent?filepath=javax/faces/javax.faces-api/2.2/javax.faces-api-2.2.jar
> >> >)
> >> WK> it seems, every vendor has to build that API JAR from scratch, or
> >> carry a
> >> WK> 3-4 MB JAR where the API in 2.2 was just a little under 700kB ?;-|
> >>
> >> We will be producing a separate API artifact for all the JCP
> >> milestones.
> >>
> >> It is very important to note that the for all Java EE API jars,
> >> including JSF, the only supported use is to satisfy compile time
> >> dependencies.  Including a Java EE API jar in a runtime classpath is not
> >> supported and may cause unexpected behavior.
> >>
> >> If there is demand we can investigate producing a JSF API jar for
> >> -SNAPSHOT releases as well.
> >>
> >> Ed
> >>
> >> --
> >> | edward.burns at oracle.com | office: +1 407 458 0017
> >> | 58 Business days til JavaOne 2015
> >> | 73 Business days til DOAG 2015
> >>
> >
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20150813/e9209dd9/attachment-0001.html
>
> ------------------------------
>
> Message: 4
> Date: Thu, 13 Aug 2015 09:00:56 -0500
> From: manfred riem <manfred.riem at oracle.com>
> Subject: Re: [cdi-dev] getBeanClass return value for build-in beans?
> To: Werner Keil <werner.keil at gmail.com>
> Cc: Edward Burns <edward.burns at oracle.com>, cdi-dev
>         <cdi-dev at lists.jboss.org>
> Message-ID: <55CCA318.3040108 at oracle.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi Werner,
>
> Arjan is correct.
>
> The runtime classpath will have the impl JSF 2.3 JAR and it will contain
> the javax.faces and com.sun.faces packages.
>
> The API jar we are referring to will not be part of the runtime
> classpath and as such should never be on the server runtime classpath,
> but could be used to compile against (and it will contain only the
> javax.faces packages)
>
> Thanks!
>
> Kind regards,
> Manfred Riem
>
> On 8/13/15, 8:55 AM, Werner Keil wrote:
> > OK, thanks for the clarification.
> > The way Arjan phrased it sounded like 2.3 would generally keep them in
> > one place.
> >
> > Hence, if separate JARs are something CDI 2 has to consider,
> > getBeanClass() and other methods must work for separate API and impl
> > JARs ;-)
> >
> > Werner
> >
> > On Thu, Aug 13, 2015 at 3:44 PM, Edward Burns <edward.burns at oracle.com
> > <mailto:edward.burns at oracle.com>> wrote:
> >
> >     >>>>> On Thu, 13 Aug 2015 15:24:00 +0200, Werner Keil
> >     <werner.keil at gmail.com <mailto:werner.keil at gmail.com>> said:
> >
> >     >> In this particular case it concerns the javax.faces.jar for JSF
> 2.3.
> >     >> Some vendors split up this archive in two, an API jar and an
> >     impl, jar
> >     >> (although for JSF 2.3 we don't really encourage this).
> >
> >     WK> Could you explain, why the JSF 2.3 API and RI are molded
> together?
> >     WK> If the API JAR is no longer separate from the RI (as it was till
> >     WK> javax.faces-api-2.2.jar
> >     WK>
> >     <
> http://search.maven.org/remotecontent?filepath=javax/faces/javax.faces-api/2.2/javax.faces-api-2.2.jar
> >)
> >     WK> it seems, every vendor has to build that API JAR from scratch,
> >     or carry a
> >     WK> 3-4 MB JAR where the API in 2.2 was just a little under 700kB
> ?;-|
> >
> >     We will be producing a separate API artifact for all the JCP
> >     milestones.
> >
> >     It is very important to note that the for all Java EE API jars,
> >     including JSF, the only supported use is to satisfy compile time
> >     dependencies.  Including a Java EE API jar in a runtime classpath
> >     is not
> >     supported and may cause unexpected behavior.
> >
> >     If there is demand we can investigate producing a JSF API jar for
> >     -SNAPSHOT releases as well.
> >
> >     Ed
> >
> >     --
> >     | edward.burns at oracle.com <mailto:edward.burns at oracle.com> |
> >     office: +1 407 458 0017 <tel:%2B1%20407%20458%200017>
> >     | 58 Business days til JavaOne 2015
> >     | 73 Business days til DOAG 2015
> >
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20150813/914a6fab/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 8
> **************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150813/f547fa92/attachment-0001.html 

From nigel.deakin at oracle.com  Fri Aug 14 08:02:17 2015
From: nigel.deakin at oracle.com (Nigel Deakin)
Date: Fri, 14 Aug 2015 13:02:17 +0100
Subject: [cdi-dev] WithAnnotations with ProcessInjectionTarget events
Message-ID: <55CDD8C9.7090908@oracle.com>

I'm writing a portable extension, and my Extension class includes the following observer method

   public <X> void processInjectionTarget(
       @Observes ProcessInjectionTarget<X> event) {

When I start the server (Glassfish) I see this warning in the log:

   WELD-000411: Observer method [BackedAnnotatedMethod] public com.foo.MyExtension.processAnnotatedType(@Observes 
ProcessAnnotatedType<Object>) receives events for all annotated types. Consider restricting events using 
@WithAnnotations or a generic type with bounds.]]

I thought "OK, fair enough. I only want to receive ProcessInjectionTarget events for classes that have a specific 
annotation. So I'll do what it suggests and @WithAnnotations to restrict the events received."

However if I look up the javadocs for WithAnnotations it says "WithAnnotations may be applied to any portable extension 
observer method with an event parameter type of ProcessAnnotatedType to filter the events delivered."

And if I try using WithAnnotations on the above method, I indeed get an error at runtime.

So the warning message WELD-000411 is incorrect, since it suggests doing something that is not allowed.

@WithAnnotations would have been perfect for my needs. Why is it not allowed when observing ProcessInjectionTarget events?

So it looks as if I will simply have to receive every such event and check whether it has the required annotation:

   public <X> void processInjectionTarget(
       @Observes ProcessInjectionTarget<X> event) {

      if (!event.getAnnotatedType().isAnnotationPresent(MyAnnotation.class)) {
         return;
     }

This doesn't look very efficient to me, since there will be a lot of irrelevant events. Is there a better way?

Nigel



From ggastald at redhat.com  Fri Aug 14 08:52:27 2015
From: ggastald at redhat.com (George Gastaldi)
Date: Fri, 14 Aug 2015 09:52:27 -0300
Subject: [cdi-dev] WithAnnotations with ProcessInjectionTarget events
In-Reply-To: <55CDD8C9.7090908@oracle.com>
References: <55CDD8C9.7090908@oracle.com>
Message-ID: <CAMmsnJgYgrdKo2mOo2DABVOKhoi6gEyZDW_hpgwp0HDK-rsraQ@mail.gmail.com>

Hi Nigel,

Check the error message, I think it's not the same method you referenced
it. However I would like to see @WithAnnotations or a similar solution for
other Process* types.

Best Regards,

George Gastaldi
Em 14/08/2015 09:04, "Nigel Deakin" <nigel.deakin at oracle.com> escreveu:

> I'm writing a portable extension, and my Extension class includes the
> following observer method
>
>    public <X> void processInjectionTarget(
>        @Observes ProcessInjectionTarget<X> event) {
>
> When I start the server (Glassfish) I see this warning in the log:
>
>    WELD-000411: Observer method [BackedAnnotatedMethod] public
> com.foo.MyExtension.processAnnotatedType(@Observes
> ProcessAnnotatedType<Object>) receives events for all annotated types.
> Consider restricting events using
> @WithAnnotations or a generic type with bounds.]]
>
> I thought "OK, fair enough. I only want to receive ProcessInjectionTarget
> events for classes that have a specific
> annotation. So I'll do what it suggests and @WithAnnotations to restrict
> the events received."
>
> However if I look up the javadocs for WithAnnotations it says
> "WithAnnotations may be applied to any portable extension
> observer method with an event parameter type of ProcessAnnotatedType to
> filter the events delivered."
>
> And if I try using WithAnnotations on the above method, I indeed get an
> error at runtime.
>
> So the warning message WELD-000411 is incorrect, since it suggests doing
> something that is not allowed.
>
> @WithAnnotations would have been perfect for my needs. Why is it not
> allowed when observing ProcessInjectionTarget events?
>
> So it looks as if I will simply have to receive every such event and check
> whether it has the required annotation:
>
>    public <X> void processInjectionTarget(
>        @Observes ProcessInjectionTarget<X> event) {
>
>       if
> (!event.getAnnotatedType().isAnnotationPresent(MyAnnotation.class)) {
>          return;
>      }
>
> This doesn't look very efficient to me, since there will be a lot of
> irrelevant events. Is there a better way?
>
> Nigel
>
>
> _______________________________________________
> 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/20150814/e9d6d1dd/attachment.html 

From john.d.ament at gmail.com  Fri Aug 14 09:17:16 2015
From: john.d.ament at gmail.com (John D. Ament)
Date: Fri, 14 Aug 2015 13:17:16 +0000
Subject: [cdi-dev] WithAnnotations with ProcessInjectionTarget events
In-Reply-To: <55CDD8C9.7090908@oracle.com>
References: <55CDD8C9.7090908@oracle.com>
Message-ID: <CAOqetn9EQBB+waTCggs6Jy8HCovPfPifv4W5mDux3bdVj=1gsg@mail.gmail.com>

Hi Nigel,

Maybe you meant to send this to weld-dev, since its a problem with one of
the CDI impls, not cdi-dev?

Sure, there's some spec enhancement listed here, but realistically
WithAnnotations doesn't apply to an injection target the same way (I
wouldn't think).

John

On Fri, Aug 14, 2015 at 8:02 AM Nigel Deakin <nigel.deakin at oracle.com>
wrote:

> I'm writing a portable extension, and my Extension class includes the
> following observer method
>
>    public <X> void processInjectionTarget(
>        @Observes ProcessInjectionTarget<X> event) {
>
> When I start the server (Glassfish) I see this warning in the log:
>
>    WELD-000411: Observer method [BackedAnnotatedMethod] public
> com.foo.MyExtension.processAnnotatedType(@Observes
> ProcessAnnotatedType<Object>) receives events for all annotated types.
> Consider restricting events using
> @WithAnnotations or a generic type with bounds.]]
>
> I thought "OK, fair enough. I only want to receive ProcessInjectionTarget
> events for classes that have a specific
> annotation. So I'll do what it suggests and @WithAnnotations to restrict
> the events received."
>
> However if I look up the javadocs for WithAnnotations it says
> "WithAnnotations may be applied to any portable extension
> observer method with an event parameter type of ProcessAnnotatedType to
> filter the events delivered."
>
> And if I try using WithAnnotations on the above method, I indeed get an
> error at runtime.
>
> So the warning message WELD-000411 is incorrect, since it suggests doing
> something that is not allowed.
>
> @WithAnnotations would have been perfect for my needs. Why is it not
> allowed when observing ProcessInjectionTarget events?
>
> So it looks as if I will simply have to receive every such event and check
> whether it has the required annotation:
>
>    public <X> void processInjectionTarget(
>        @Observes ProcessInjectionTarget<X> event) {
>
>       if
> (!event.getAnnotatedType().isAnnotationPresent(MyAnnotation.class)) {
>          return;
>      }
>
> This doesn't look very efficient to me, since there will be a lot of
> irrelevant events. Is there a better way?
>
> Nigel
>
>
> _______________________________________________
> 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/20150814/30b72405/attachment.html 

From nigel.deakin at oracle.com  Fri Aug 14 09:20:33 2015
From: nigel.deakin at oracle.com (Nigel Deakin)
Date: Fri, 14 Aug 2015 14:20:33 +0100
Subject: [cdi-dev] WithAnnotations with ProcessInjectionTarget events
In-Reply-To: <CAMmsnJgYgrdKo2mOo2DABVOKhoi6gEyZDW_hpgwp0HDK-rsraQ@mail.gmail.com>
References: <55CDD8C9.7090908@oracle.com>
	<CAMmsnJgYgrdKo2mOo2DABVOKhoi6gEyZDW_hpgwp0HDK-rsraQ@mail.gmail.com>
Message-ID: <55CDEB21.5010606@oracle.com>

George,

Yes, you're right. That warning refers to a different method of the same extension (which is obvious now). Thanks for 
pointing that out. So the WELD message is correct.

So that just leaves me asking whether it would be desirable to support @WithAnnotations with ProcessInjectionTarget 
events, to avoid the need to call isAnnotationPresent() on every injection target.

Nigel

On 14/08/2015 13:52, George Gastaldi wrote:
>
> Hi Nigel,
>
> Check the error message, I think it's not the same method you referenced it. However I would like to see 
> @WithAnnotations or a similar solution for other Process* types.
>
> Best Regards,
>
> George Gastaldi
>
> Em 14/08/2015 09:04, "Nigel Deakin" <nigel.deakin at oracle.com <mailto:nigel.deakin at oracle.com>> escreveu:
>
>     I'm writing a portable extension, and my Extension class includes the following observer method
>
>        public <X> void processInjectionTarget(
>            @Observes ProcessInjectionTarget<X> event) {
>
>     When I start the server (Glassfish) I see this warning in the log:
>
>        WELD-000411: Observer method [BackedAnnotatedMethod] public com.foo.MyExtension.processAnnotatedType(@Observes
>     ProcessAnnotatedType<Object>) receives events for all annotated types. Consider restricting events using
>     @WithAnnotations or a generic type with bounds.]]
>
>     I thought "OK, fair enough. I only want to receive ProcessInjectionTarget events for classes that have a specific
>     annotation. So I'll do what it suggests and @WithAnnotations to restrict the events received."
>
>     However if I look up the javadocs for WithAnnotations it says "WithAnnotations may be applied to any portable
>     extension
>     observer method with an event parameter type of ProcessAnnotatedType to filter the events delivered."
>
>     And if I try using WithAnnotations on the above method, I indeed get an error at runtime.
>
>     So the warning message WELD-000411 is incorrect, since it suggests doing something that is not allowed.
>
>     @WithAnnotations would have been perfect for my needs. Why is it not allowed when observing ProcessInjectionTarget
>     events?
>
>     So it looks as if I will simply have to receive every such event and check whether it has the required annotation:
>
>        public <X> void processInjectionTarget(
>            @Observes ProcessInjectionTarget<X> event) {
>
>           if (!event.getAnnotatedType().isAnnotationPresent(MyAnnotation.class)) {
>              return;
>          }
>
>     This doesn't look very efficient to me, since there will be a lot of irrelevant events. Is there a better way?
>
>     Nigel
>
>
>     _______________________________________________
>     cdi-dev mailing list
>     cdi-dev at lists.jboss.org <mailto: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/20150814/6e8e704a/attachment-0001.html 

From jharting at redhat.com  Mon Aug 17 02:25:25 2015
From: jharting at redhat.com (Jozef Hartinger)
Date: Mon, 17 Aug 2015 08:25:25 +0200
Subject: [cdi-dev] WithAnnotations with ProcessInjectionTarget events
In-Reply-To: <55CDEB21.5010606@oracle.com>
References: <55CDD8C9.7090908@oracle.com>
	<CAMmsnJgYgrdKo2mOo2DABVOKhoi6gEyZDW_hpgwp0HDK-rsraQ@mail.gmail.com>
	<55CDEB21.5010606@oracle.com>
Message-ID: <55D17E55.7010501@redhat.com>

Hi Nigel,

this feature is being considered for CDI 2.0: The relevant issue is: 
https://issues.jboss.org/browse/CDI-270

Jozef

On 14.8.2015 15:20, Nigel Deakin wrote:
> George,
>
> Yes, you're right. That warning refers to a different method of the same
> extension (which is obvious now). Thanks for pointing that out. So the
> WELD message is correct.
>
> So that just leaves me asking whether it would be desirable to support
> @WithAnnotations with ProcessInjectionTarget events, to avoid the need
> to call isAnnotationPresent() on every injection target.
>
> Nigel
>
> On 14/08/2015 13:52, George Gastaldi wrote:
>>
>> Hi Nigel,
>>
>> Check the error message, I think it's not the same method you
>> referenced it. However I would like to see @WithAnnotations or a
>> similar solution for other Process* types.
>>
>> Best Regards,
>>
>> George Gastaldi
>>
>> Em 14/08/2015 09:04, "Nigel Deakin" <nigel.deakin at oracle.com
>> <mailto:nigel.deakin at oracle.com>> escreveu:
>>
>>     I'm writing a portable extension, and my Extension class includes
>>     the following observer method
>>
>>        public <X> void processInjectionTarget(
>>            @Observes ProcessInjectionTarget<X> event) {
>>
>>     When I start the server (Glassfish) I see this warning in the log:
>>
>>        WELD-000411: Observer method [BackedAnnotatedMethod] public
>>     com.foo.MyExtension.processAnnotatedType(@Observes
>>     ProcessAnnotatedType<Object>) receives events for all annotated
>>     types. Consider restricting events using
>>     @WithAnnotations or a generic type with bounds.]]
>>
>>     I thought "OK, fair enough. I only want to receive
>>     ProcessInjectionTarget events for classes that have a specific
>>     annotation. So I'll do what it suggests and @WithAnnotations to
>>     restrict the events received."
>>
>>     However if I look up the javadocs for WithAnnotations it says
>>     "WithAnnotations may be applied to any portable extension
>>     observer method with an event parameter type of
>>     ProcessAnnotatedType to filter the events delivered."
>>
>>     And if I try using WithAnnotations on the above method, I indeed
>>     get an error at runtime.
>>
>>     So the warning message WELD-000411 is incorrect, since it suggests
>>     doing something that is not allowed.
>>
>>     @WithAnnotations would have been perfect for my needs. Why is it
>>     not allowed when observing ProcessInjectionTarget events?
>>
>>     So it looks as if I will simply have to receive every such event
>>     and check whether it has the required annotation:
>>
>>        public <X> void processInjectionTarget(
>>            @Observes ProcessInjectionTarget<X> event) {
>>
>>           if
>>     (!event.getAnnotatedType().isAnnotationPresent(MyAnnotation.class)) {
>>              return;
>>          }
>>
>>     This doesn't look very efficient to me, since there will be a lot
>>     of irrelevant events. Is there a better way?
>>
>>     Nigel
>>
>>
>>     _______________________________________________
>>     cdi-dev mailing list
>>     cdi-dev at lists.jboss.org <mailto: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.
>
>
>
> _______________________________________________
> 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.
>

From struberg at yahoo.de  Fri Aug 21 02:47:17 2015
From: struberg at yahoo.de (Mark Struberg)
Date: Fri, 21 Aug 2015 08:47:17 +0200
Subject: [cdi-dev] master branch in cdi-spec GIT repo
Message-ID: <256D97C7-64A8-4C18-B06E-C1FEE930E9A2@yahoo.de>

Hi folks!

Seems the 2.0-EDR1 branch didn?t yet got merged back to master.

Who is doing so? Or shall we wait until Antoine is back from vacation?

LieGrue,
strub

From jharting at redhat.com  Fri Aug 21 02:51:37 2015
From: jharting at redhat.com (Jozef Hartinger)
Date: Fri, 21 Aug 2015 08:51:37 +0200
Subject: [cdi-dev] master branch in cdi-spec GIT repo
In-Reply-To: <256D97C7-64A8-4C18-B06E-C1FEE930E9A2@yahoo.de>
References: <256D97C7-64A8-4C18-B06E-C1FEE930E9A2@yahoo.de>
Message-ID: <55D6CA79.30606@redhat.com>

Yes. I am not entirely sure what his plan is here so let's rather wait 
until next week when he's back.


On 21.08.2015 08:47, Mark Struberg wrote:
> shall we wait until Antoine is back from vacation?

From noreply+4026257531 at badoo.com  Sun Aug 23 15:07:53 2015
From: noreply+4026257531 at badoo.com (Anatole)
Date: Sun, 23 Aug 2015 19:07:53 +0000
Subject: [cdi-dev] =?utf-8?q?=E2=98=85_cdi-dev=2C_Neue_Nachricht_von_Anato?=
	=?utf-8?b?bGUuLi4=?=
Message-ID: <20150823190753.DA22C8E0037B@cluster1058.monopost.com>

Neue Nachricht von Anatole...

Du kannst ?ber unseren Chat ganz einfach antworten.
Lies Deine Nachricht...
http://eu1.badoo.com/anatole.tresch.1/in/nRSrNUroxzM/?lang_id=5&g=57-0-4&m=29&mid=55da1a08000000000005004d05ea8708006ef21e015c


Diese Leute sind ebenfalls in Deiner Umgebung:


Funktionieren die angegebenen Links nicht? Kopiere sie bitte einfach in Deine Browser-Leiste.


Viel Spa?!
Das Badoo Team


Du hast diese Email von Badoo Trading Limited (Postanschrift siehe unten) erhalten.
Wenn Du keine weiteren Emails von Badoo erhalten m?chtest, klick bitte hier, um Dich aus unserem Verteiler entfernen zu lassen: https://eu1.badoo.com/impersonation.phtml?lang_id=5&email=cdi-dev%40lists.jboss.org&block_code=9765ba&m=29&mid=55da1a08000000000005004d05ea8708006ef21e015c&g=0-0-4.
Badoo Trading Limited ist ein Unternehmen mit beschr?nkter Haftung, registriert in England und Wales unter CRN 7540255, mit dem eingetragenen Firmensitz Media Village, 131 - 151 Great Titchfield Street, London, W1W 5BB.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150823/b68e34eb/attachment-0001.html 

From atsticks at gmail.com  Sun Aug 23 19:10:45 2015
From: atsticks at gmail.com (Anatole Tresch)
Date: Mon, 24 Aug 2015 01:10:45 +0200
Subject: [cdi-dev] Spam
Message-ID: <CAFJiDbf3gBeHzqE88XDd6nPyiYUyYbSmO+URKaH-1DotkXMNKg@mail.gmail.com>

Sorry, guys. There was some spam sent out from my facebook account last
night. Simply ignore the message thanks!

Anatole

-- 
*Anatole Tresch*
Java Engineer & Architect, JSR Spec Lead
Gl?rnischweg 10
CH - 8620 Wetzikon

*Switzerland, Europe Zurich, GMT+1*
*Twitter:  @atsticks*
*Blogs: **http://javaremarkables.blogspot.ch/
<http://javaremarkables.blogspot.ch/>*

*Google: atsticksMobile  +41-76 344 62 79*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150824/ea2cb896/attachment.html 

From antoine at sabot-durand.net  Mon Aug 24 04:52:56 2015
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Mon, 24 Aug 2015 08:52:56 +0000
Subject: [cdi-dev] preparing the face to face meeting
Message-ID: <CABu-YBQhR18BkaCFVj2QkpVXN5FjN0geqv7y3JQHa5Q1fYpcJQ@mail.gmail.com>

Hi guys,

Back from PTO, I'm starting the preparation of our F2F meeting in on month.

For those who missed the information, this meeting will take place in Red
Hat office near Paris (Puteaux) the 25th and 26th of September.

Regarding the content, I propose that we prioritize tasks to deal with to
build our agenda.
The objective is to finish this session with at least advanced draft of new
or revised spec parts and a clear roadmap for 2.0 release and perhaps
beyond. I'll send another mail in the coming days on the subject.

But right now, I need to know which of you will attend this meeting for
room reservation and other logistic points.

So please, send me an email to confirm your presence at this F2F meeting
ASAP.

Thanks,

Antoine
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150824/5c0613ff/attachment.html 

From antoine at sabot-durand.net  Mon Aug 24 04:55:53 2015
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Mon, 24 Aug 2015 08:55:53 +0000
Subject: [cdi-dev] master branch in cdi-spec GIT repo
In-Reply-To: <55D6CA79.30606@redhat.com>
References: <256D97C7-64A8-4C18-B06E-C1FEE930E9A2@yahoo.de>
	<55D6CA79.30606@redhat.com>
Message-ID: <CABu-YBR08Ygap-omyuUBEVJ2rA_u1j245ovzsz9Y58mAZaO=_w@mail.gmail.com>

Well, as we are still in review I thought better to keep all these new
features in a dedicated branch. Is it a problem for you Mark?

Antoine

Le ven. 21 ao?t 2015 ? 08:51, Jozef Hartinger <jharting at redhat.com> a
?crit :

> Yes. I am not entirely sure what his plan is here so let's rather wait
> until next week when he's back.
>
>
> On 21.08.2015 08:47, Mark Struberg wrote:
> > shall we wait until Antoine is back from vacation?
> _______________________________________________
> 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/20150824/a1c19e3d/attachment.html 

From antonio.goncalves at gmail.com  Mon Aug 24 05:06:54 2015
From: antonio.goncalves at gmail.com (Antonio Goncalves)
Date: Mon, 24 Aug 2015 11:06:54 +0200
Subject: [cdi-dev] preparing the face to face meeting
In-Reply-To: <CABu-YBQhR18BkaCFVj2QkpVXN5FjN0geqv7y3JQHa5Q1fYpcJQ@mail.gmail.com>
References: <CABu-YBQhR18BkaCFVj2QkpVXN5FjN0geqv7y3JQHa5Q1fYpcJQ@mail.gmail.com>
Message-ID: <CA+ZZq9_ARtkEVDrbz3=+drD+cbfS+F2e2p0EUynBDUBBc=QwZg@mail.gmail.com>

+1

As I live in Paris, no need to have logistic for me ;o)

Antoine, have you shared a Google Doc on the F2F so we can contribute in
preparing the agenda (I couldn't find anything) ?

Antonio

On Mon, Aug 24, 2015 at 10:52 AM, Antoine Sabot-Durand <
antoine at sabot-durand.net> wrote:

> Hi guys,
>
> Back from PTO, I'm starting the preparation of our F2F meeting in on month.
>
> For those who missed the information, this meeting will take place in Red
> Hat office near Paris (Puteaux) the 25th and 26th of September.
>
> Regarding the content, I propose that we prioritize tasks to deal with to
> build our agenda.
> The objective is to finish this session with at least advanced draft of
> new or revised spec parts and a clear roadmap for 2.0 release and perhaps
> beyond. I'll send another mail in the coming days on the subject.
>
> But right now, I need to know which of you will attend this meeting for
> room reservation and other logistic points.
>
> So please, send me an email to confirm your presence at this F2F meeting
> ASAP.
>
> Thanks,
>
> 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.
>



-- 
Antonio Goncalves
Software architect, Java Champion and Pluralsight author

Web site <http://www.antoniogoncalves.org> | Twitter
<http://twitter.com/agoncal> | LinkedIn <http://www.linkedin.com/in/agoncal> |
Pluralsight
<http://pluralsight.com/training/Authors/Details/antonio-goncalves> | Paris
JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150824/d23e8b00/attachment.html 

From antoine at sabot-durand.net  Mon Aug 24 05:08:48 2015
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Mon, 24 Aug 2015 09:08:48 +0000
Subject: [cdi-dev] preparing the face to face meeting
In-Reply-To: <CA+ZZq9_ARtkEVDrbz3=+drD+cbfS+F2e2p0EUynBDUBBc=QwZg@mail.gmail.com>
References: <CABu-YBQhR18BkaCFVj2QkpVXN5FjN0geqv7y3JQHa5Q1fYpcJQ@mail.gmail.com>
	<CA+ZZq9_ARtkEVDrbz3=+drD+cbfS+F2e2p0EUynBDUBBc=QwZg@mail.gmail.com>
Message-ID: <CABu-YBQzv+OCwxWLRJw8jbPDZe=AnYqDf7G5xiJvZO7uAoDSxw@mail.gmail.com>

Thanks Antonio,
No doc shared yet. I'm on it. Should be available today or tomorrow

Antoine

Le lun. 24 ao?t 2015 ? 11:07, Antonio Goncalves <antonio.goncalves at gmail.com>
a ?crit :

> +1
>
> As I live in Paris, no need to have logistic for me ;o)
>
> Antoine, have you shared a Google Doc on the F2F so we can contribute in
> preparing the agenda (I couldn't find anything) ?
>
> Antonio
>
> On Mon, Aug 24, 2015 at 10:52 AM, Antoine Sabot-Durand <
> antoine at sabot-durand.net> wrote:
>
>> Hi guys,
>>
>> Back from PTO, I'm starting the preparation of our F2F meeting in on
>> month.
>>
>> For those who missed the information, this meeting will take place in Red
>> Hat office near Paris (Puteaux) the 25th and 26th of September.
>>
>> Regarding the content, I propose that we prioritize tasks to deal with to
>> build our agenda.
>> The objective is to finish this session with at least advanced draft of
>> new or revised spec parts and a clear roadmap for 2.0 release and perhaps
>> beyond. I'll send another mail in the coming days on the subject.
>>
>> But right now, I need to know which of you will attend this meeting for
>> room reservation and other logistic points.
>>
>> So please, send me an email to confirm your presence at this F2F meeting
>> ASAP.
>>
>> Thanks,
>>
>> 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.
>>
>
>
>
> --
> Antonio Goncalves
> Software architect, Java Champion and Pluralsight author
>
> Web site <http://www.antoniogoncalves.org> | Twitter
> <http://twitter.com/agoncal> | LinkedIn
> <http://www.linkedin.com/in/agoncal> | Pluralsight
> <http://pluralsight.com/training/Authors/Details/antonio-goncalves> | Paris
> JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150824/117eda08/attachment.html 

From nigel.deakin at oracle.com  Mon Aug 24 12:30:10 2015
From: nigel.deakin at oracle.com (Nigel Deakin)
Date: Mon, 24 Aug 2015 17:30:10 +0100
Subject: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean in a Java
 EE application to listen for JMS messages
Message-ID: <55DB4692.7040304@oracle.com>

Over in the JMS 2.1 expert group I've just published some proposals to allow any CDI managed bean in a Java EE 
application to listen for JMS messages. This would be implemented as a standard CDI portable extension and would become 
a mandatory part of a full Java EE 8 application server.

I would welcome any comments from the CDI spec experts here. If you're interested in helping, please take a look at
https://java.net/projects/jms-spec/pages/CDIBeansAsJMSListeners
and send comments or questions to me or to the public users at jms-spec.java.net alias.

Thanks,

Nigel
JMS 2.1 specification lead

From antoine at sabot-durand.net  Mon Aug 24 13:24:27 2015
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Mon, 24 Aug 2015 17:24:27 +0000
Subject: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean in a
 Java EE application to listen for JMS messages
In-Reply-To: <55DB4692.7040304@oracle.com>
References: <55DB4692.7040304@oracle.com>
Message-ID: <CABu-YBTqjtdMxbLO=TcFikN9XM-zgjfDP8Chhj5bqFSy6ueKOQ@mail.gmail.com>

Great Nigel,

I'll have a look and try to give you feedback by the end of the week.

Antoine
Le lun. 24 ao?t 2015 ? 18:30, Nigel Deakin <nigel.deakin at oracle.com> a
?crit :

> Over in the JMS 2.1 expert group I've just published some proposals to
> allow any CDI managed bean in a Java EE
> application to listen for JMS messages. This would be implemented as a
> standard CDI portable extension and would become
> a mandatory part of a full Java EE 8 application server.
>
> I would welcome any comments from the CDI spec experts here. If you're
> interested in helping, please take a look at
> https://java.net/projects/jms-spec/pages/CDIBeansAsJMSListeners
> and send comments or questions to me or to the public
> users at jms-spec.java.net alias.
>
> Thanks,
>
> Nigel
> JMS 2.1 specification lead
> _______________________________________________
> 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/20150824/1da85d2e/attachment.html 

From antonio.goncalves at gmail.com  Mon Aug 24 13:42:41 2015
From: antonio.goncalves at gmail.com (Antonio Goncalves)
Date: Mon, 24 Aug 2015 19:42:41 +0200
Subject: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean in a
 Java EE application to listen for JMS messages
In-Reply-To: <55DB4692.7040304@oracle.com>
References: <55DB4692.7040304@oracle.com>
Message-ID: <CA+ZZq9_Brvtks=jxQ1TbtXMNm+ab3w3GZfG-2sGQYeMK2mu2jA@mail.gmail.com>

Nigel, what do you mean by :

"The application must obtain an instance of the JMS listener bean using
dependency injection"

In your examples, it looks like a CDI bean cannot start listening if not
injected :

@WebServlet("/myjmsservlet1")
 public class MyJMSServlet1 extends HttpServlet {

   *@Inject MyDepScopeListenerBean* myDepScopeListenerBean;

   public void service(ServletRequest req, ServletResponse res) throws
IOException, ServletException {
      ...
   }
 }


Did I understand well ? Is this the case ? Just like a MDB, I would like a
CDI bean to start listening to a message without being injected, as soon as
the application starts. Something like :

*@ApplicationScoped*
public class MyListenerBean{


 @JMSListener(lookup="java:global/java:global/Trades",type=JMSListener.Type.TOPIC
)
   public void deliver(Message message) {
     ...
   }
}

Or if we manage to get the @Startup annotation to Commons Annotation :

*@Startup*
public class MyListenerBean{


 @JMSListener(lookup="java:global/java:global/Trades",type=JMSListener.Type.TOPIC
)
   public void deliver(Message message) {
     ...
   }
}


Just thinking here

Antonio

On Mon, Aug 24, 2015 at 6:30 PM, Nigel Deakin <nigel.deakin at oracle.com>
wrote:

> Over in the JMS 2.1 expert group I've just published some proposals to
> allow any CDI managed bean in a Java EE
> application to listen for JMS messages. This would be implemented as a
> standard CDI portable extension and would become
> a mandatory part of a full Java EE 8 application server.
>
> I would welcome any comments from the CDI spec experts here. If you're
> interested in helping, please take a look at
> https://java.net/projects/jms-spec/pages/CDIBeansAsJMSListeners
> and send comments or questions to me or to the public
> users at jms-spec.java.net alias.
>
> Thanks,
>
> Nigel
> JMS 2.1 specification lead
> _______________________________________________
> 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.
>



-- 
Antonio Goncalves
Software architect, Java Champion and Pluralsight author

Web site <http://www.antoniogoncalves.org> | Twitter
<http://twitter.com/agoncal> | LinkedIn <http://www.linkedin.com/in/agoncal> |
Pluralsight
<http://pluralsight.com/training/Authors/Details/antonio-goncalves> | Paris
JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150824/55f410a4/attachment.html 

From nigel.deakin at oracle.com  Mon Aug 24 15:47:51 2015
From: nigel.deakin at oracle.com (Nigel Deakin)
Date: Mon, 24 Aug 2015 20:47:51 +0100
Subject: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean in a
 Java EE application to listen for JMS messages
In-Reply-To: <CA+ZZq9_Brvtks=jxQ1TbtXMNm+ab3w3GZfG-2sGQYeMK2mu2jA@mail.gmail.com>
References: <55DB4692.7040304@oracle.com>
	<CA+ZZq9_Brvtks=jxQ1TbtXMNm+ab3w3GZfG-2sGQYeMK2mu2jA@mail.gmail.com>
Message-ID: <55DB74E7.4080609@oracle.com>

On 24/08/2015 18:42, Antonio Goncalves wrote:
> Nigel, what do you mean by :
>
> "The application must obtain an instance of the JMS listener bean using dependency injection"
>
> In your examples, it looks like a CDI bean cannot start listening if not injected :
>
> @WebServlet("/myjmsservlet1")
>  public class MyJMSServlet1 extends HttpServlet {
> *@Inject MyDepScopeListenerBean* myDepScopeListenerBean;
>    public void service(ServletRequest req, ServletResponse res) throws IOException, ServletException {
>       ...
>    }
>  }
>
>
> Did I understand well ? Is this the case ? Just like a MDB, I would like a CDI bean to start listening to a message 
> without being injected, as soon as the application starts.

My starting point is that these are normal CDI beans which are created just like any other CDI bean. The bean's 
postCreate behaviour (inserted by the extension) would connect to the JMS provider and start listening for messages. The 
bean's preDestroy behaviour would stop listening for messages and disconnect from the JMS provider.

As I understand it, if you want to create a CDI managed bean (so that it is managed by CDI) then you have to inject it 
into some code somewhere.

Additionally, if the bean is normal scoped, you have to trigger lazy instantiation by calling a method on the injected 
bean proxy (e.g. toString()).

> Something like :
>
> *@ApplicationScoped*
> public class MyListenerBean{
>  @JMSListener(lookup="java:global/java:global/Trades",type=JMSListener.Type.TOPIC )
>    public void deliver(Message message) {
>      ...
>    }
> }
>

If I understand things correctly, if this is a normal CDI bean then this alone is not sufficient to cause an instance of 
the bean to be created.

You also need to
(1) inject it into some other bean
(2) create that other bean and
(3) call a method on the MyListenerBean to trigger lazy initialisation.

I'm trying to avoid getting ahead of myself here. My current proposals simply apply to normal CDI managed beans created 
in the normal way (via injection and lazy initialisation). But I could certainly see a benefit in extending this to 
allow JMS listener beans to be created in other ways. In particular:

(a) Creating the bean instance as soon as the bean into which it is injected enters a new scope rather than waiting for 
the application to call a method on it (so-called eager initialisation). That sounds relatively straightforward to me; 
this could either be a new standard CDI feature available to all normal-scoped beans, or something specific to beans 
annotated with @JMSListener.

(b) Creating the bean instance without the need to inject it anywhere.  As you suggest, in the case of ApplicationScoped 
beans this would make JMS listener beans more like MDBs. But it might be equally useful to support this for other normal 
scopes. For example, could we annotate a @RequestScoped bean so that every time a new request scope started, an instance 
of the bean for that scope was automatically created?

> Or if we manage to get the @Startup annotation to Commons Annotation :
>
> *@Startup*
> public class MyListenerBean{
>  @JMSListener(lookup="java:global/java:global/Trades",type=JMSListener.Type.TOPIC )
>    public void deliver(Message message) {
>      ...
>    }
> }
>

That looks as if it's tied to ApplicationScoped. I'd rather look for something more general.

Thanks for your comments so far. You're raising issues I have been thinking about for some time.

Nigel



>
> Just thinking here
>
> Antonio
>
> On Mon, Aug 24, 2015 at 6:30 PM, Nigel Deakin <nigel.deakin at oracle.com <mailto:nigel.deakin at oracle.com>> wrote:
>
>     Over in the JMS 2.1 expert group I've just published some proposals to allow any CDI managed bean in a Java EE
>     application to listen for JMS messages. This would be implemented as a standard CDI portable extension and would
>     become
>     a mandatory part of a full Java EE 8 application server.
>
>     I would welcome any comments from the CDI spec experts here. If you're interested in helping, please take a look at
>     https://java.net/projects/jms-spec/pages/CDIBeansAsJMSListeners
>     and send comments or questions to me or to the public users at jms-spec.java.net <mailto:users at jms-spec.java.net> alias.
>
>     Thanks,
>
>     Nigel
>     JMS 2.1 specification lead
>     _______________________________________________
>     cdi-dev mailing list
>     cdi-dev at lists.jboss.org <mailto: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.
>
>
>
>
> -- 
> Antonio Goncalves
> Software architect, Java Champion and Pluralsight author
>
> Web site <http://www.antoniogoncalves.org> | Twitter <http://twitter.com/agoncal> | LinkedIn 
> <http://www.linkedin.com/in/agoncal> | Pluralsight 
> <http://pluralsight.com/training/Authors/Details/antonio-goncalves> | Paris JUG <http://www.parisjug.org> | Devoxx 
> France <http://www.devoxx.fr>

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

From werner.keil at gmail.com  Mon Aug 24 16:22:32 2015
From: werner.keil at gmail.com (Werner Keil)
Date: Mon, 24 Aug 2015 22:22:32 +0200
Subject: [cdi-dev] Proposal to allow any CDI managed bean in a Java EE
 application to listen for JMS messages
Message-ID: <CAAGawe286HGbeozBKNBOrJRYr1P0tVOYdso+=ZOpfm+skuXYBQ@mail.gmail.com>

Antoine/Nigel/all,

Sounds very interesting (especially being in both EGs)
Although the project situation ended up with a more synchronous
requirement, I did something very similar as a prototype relaying an MDB's
onMessage() to a CDI event;-)

Would be great to get something like that standardized.

Werner


On Mon, Aug 24, 2015 at 9:48 PM, <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: JMS 2.1: Proposal to allow any CDI managed bean in a Java
>       EE application to listen for JMS messages (Antoine Sabot-Durand)
>    2. Re: JMS 2.1: Proposal to allow any CDI managed bean in a Java
>       EE application to listen for JMS messages (Antonio Goncalves)
>    3. Re: JMS 2.1: Proposal to allow any CDI managed bean in a Java
>       EE application to listen for JMS messages (Nigel Deakin)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 24 Aug 2015 17:24:27 +0000
> From: Antoine Sabot-Durand <antoine at sabot-durand.net>
> Subject: Re: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean
>         in a Java EE application to listen for JMS messages
> To: Nigel Deakin <nigel.deakin at oracle.com>, cdi-dev at lists.jboss.org
> Message-ID:
>         <CABu-YBTqjtdMxbLO=
> TcFikN9XM-zgjfDP8Chhj5bqFSy6ueKOQ at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Great Nigel,
>
> I'll have a look and try to give you feedback by the end of the week.
>
> Antoine
> Le lun. 24 ao?t 2015 ? 18:30, Nigel Deakin <nigel.deakin at oracle.com> a
> ?crit :
>
> > Over in the JMS 2.1 expert group I've just published some proposals to
> > allow any CDI managed bean in a Java EE
> > application to listen for JMS messages. This would be implemented as a
> > standard CDI portable extension and would become
> > a mandatory part of a full Java EE 8 application server.
> >
> > I would welcome any comments from the CDI spec experts here. If you're
> > interested in helping, please take a look at
> > https://java.net/projects/jms-spec/pages/CDIBeansAsJMSListeners
> > and send comments or questions to me or to the public
> > users at jms-spec.java.net alias.
> >
> > Thanks,
> >
> > Nigel
> > JMS 2.1 specification lead
> > _______________________________________________
> > 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/20150824/1da85d2e/attachment-0001.html
>
> ------------------------------
>
> Message: 2
> Date: Mon, 24 Aug 2015 19:42:41 +0200
> From: Antonio Goncalves <antonio.goncalves at gmail.com>
> Subject: Re: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean
>         in a Java EE application to listen for JMS messages
> To: Nigel Deakin <nigel.deakin at oracle.com>
> Cc: cdi-dev <cdi-dev at lists.jboss.org>
> Message-ID:
>         <CA+ZZq9_Brvtks=
> jxQ1TbtXMNm+ab3w3GZfG-2sGQYeMK2mu2jA at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Nigel, what do you mean by :
>
> "The application must obtain an instance of the JMS listener bean using
> dependency injection"
>
> In your examples, it looks like a CDI bean cannot start listening if not
> injected :
>
> @WebServlet("/myjmsservlet1")
>  public class MyJMSServlet1 extends HttpServlet {
>
>    *@Inject MyDepScopeListenerBean* myDepScopeListenerBean;
>
>    public void service(ServletRequest req, ServletResponse res) throws
> IOException, ServletException {
>       ...
>    }
>  }
>
>
> Did I understand well ? Is this the case ? Just like a MDB, I would like a
> CDI bean to start listening to a message without being injected, as soon as
> the application starts. Something like :
>
> *@ApplicationScoped*
> public class MyListenerBean{
>
>
>
>  @JMSListener(lookup="java:global/java:global/Trades",type=JMSListener.Type.TOPIC
> )
>    public void deliver(Message message) {
>      ...
>    }
> }
>
> Or if we manage to get the @Startup annotation to Commons Annotation :
>
> *@Startup*
> public class MyListenerBean{
>
>
>
>  @JMSListener(lookup="java:global/java:global/Trades",type=JMSListener.Type.TOPIC
> )
>    public void deliver(Message message) {
>      ...
>    }
> }
>
>
> Just thinking here
>
> Antonio
>
> On Mon, Aug 24, 2015 at 6:30 PM, Nigel Deakin <nigel.deakin at oracle.com>
> wrote:
>
> > Over in the JMS 2.1 expert group I've just published some proposals to
> > allow any CDI managed bean in a Java EE
> > application to listen for JMS messages. This would be implemented as a
> > standard CDI portable extension and would become
> > a mandatory part of a full Java EE 8 application server.
> >
> > I would welcome any comments from the CDI spec experts here. If you're
> > interested in helping, please take a look at
> > https://java.net/projects/jms-spec/pages/CDIBeansAsJMSListeners
> > and send comments or questions to me or to the public
> > users at jms-spec.java.net alias.
> >
> > Thanks,
> >
> > Nigel
> > JMS 2.1 specification lead
> > _______________________________________________
> > 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.
> >
>
>
>
> --
> Antonio Goncalves
> Software architect, Java Champion and Pluralsight author
>
> Web site <http://www.antoniogoncalves.org> | Twitter
> <http://twitter.com/agoncal> | LinkedIn <
> http://www.linkedin.com/in/agoncal> |
> Pluralsight
> <http://pluralsight.com/training/Authors/Details/antonio-goncalves> |
> Paris
> JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20150824/55f410a4/attachment-0001.html
>
> ------------------------------
>
> Message: 3
> Date: Mon, 24 Aug 2015 20:47:51 +0100
> From: Nigel Deakin <nigel.deakin at oracle.com>
> Subject: Re: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean
>         in a Java EE application to listen for JMS messages
> To: Antonio Goncalves <antonio.goncalves at gmail.com>
> Cc: cdi-dev <cdi-dev at lists.jboss.org>
> Message-ID: <55DB74E7.4080609 at oracle.com>
> Content-Type: text/plain; charset="utf-8"
>
> On 24/08/2015 18:42, Antonio Goncalves wrote:
> > Nigel, what do you mean by :
> >
> > "The application must obtain an instance of the JMS listener bean using
> dependency injection"
> >
> > In your examples, it looks like a CDI bean cannot start listening if not
> injected :
> >
> > @WebServlet("/myjmsservlet1")
> >  public class MyJMSServlet1 extends HttpServlet {
> > *@Inject MyDepScopeListenerBean* myDepScopeListenerBean;
> >    public void service(ServletRequest req, ServletResponse res) throws
> IOException, ServletException {
> >       ...
> >    }
> >  }
> >
> >
> > Did I understand well ? Is this the case ? Just like a MDB, I would like
> a CDI bean to start listening to a message
> > without being injected, as soon as the application starts.
>
> My starting point is that these are normal CDI beans which are created
> just like any other CDI bean. The bean's
> postCreate behaviour (inserted by the extension) would connect to the JMS
> provider and start listening for messages. The
> bean's preDestroy behaviour would stop listening for messages and
> disconnect from the JMS provider.
>
> As I understand it, if you want to create a CDI managed bean (so that it
> is managed by CDI) then you have to inject it
> into some code somewhere.
>
> Additionally, if the bean is normal scoped, you have to trigger lazy
> instantiation by calling a method on the injected
> bean proxy (e.g. toString()).
>
> > Something like :
> >
> > *@ApplicationScoped*
> > public class MyListenerBean{
> >
> @JMSListener(lookup="java:global/java:global/Trades",type=JMSListener.Type.TOPIC
> )
> >    public void deliver(Message message) {
> >      ...
> >    }
> > }
> >
>
> If I understand things correctly, if this is a normal CDI bean then this
> alone is not sufficient to cause an instance of
> the bean to be created.
>
> You also need to
> (1) inject it into some other bean
> (2) create that other bean and
> (3) call a method on the MyListenerBean to trigger lazy initialisation.
>
> I'm trying to avoid getting ahead of myself here. My current proposals
> simply apply to normal CDI managed beans created
> in the normal way (via injection and lazy initialisation). But I could
> certainly see a benefit in extending this to
> allow JMS listener beans to be created in other ways. In particular:
>
> (a) Creating the bean instance as soon as the bean into which it is
> injected enters a new scope rather than waiting for
> the application to call a method on it (so-called eager initialisation).
> That sounds relatively straightforward to me;
> this could either be a new standard CDI feature available to all
> normal-scoped beans, or something specific to beans
> annotated with @JMSListener.
>
> (b) Creating the bean instance without the need to inject it anywhere.  As
> you suggest, in the case of ApplicationScoped
> beans this would make JMS listener beans more like MDBs. But it might be
> equally useful to support this for other normal
> scopes. For example, could we annotate a @RequestScoped bean so that every
> time a new request scope started, an instance
> of the bean for that scope was automatically created?
>
> > Or if we manage to get the @Startup annotation to Commons Annotation :
> >
> > *@Startup*
> > public class MyListenerBean{
> >
> @JMSListener(lookup="java:global/java:global/Trades",type=JMSListener.Type.TOPIC
> )
> >    public void deliver(Message message) {
> >      ...
> >    }
> > }
> >
>
> That looks as if it's tied to ApplicationScoped. I'd rather look for
> something more general.
>
> Thanks for your comments so far. You're raising issues I have been
> thinking about for some time.
>
> Nigel
>
>
>
> >
> > Just thinking here
> >
> > Antonio
> >
> > On Mon, Aug 24, 2015 at 6:30 PM, Nigel Deakin <nigel.deakin at oracle.com
> <mailto:nigel.deakin at oracle.com>> wrote:
> >
> >     Over in the JMS 2.1 expert group I've just published some proposals
> to allow any CDI managed bean in a Java EE
> >     application to listen for JMS messages. This would be implemented as
> a standard CDI portable extension and would
> >     become
> >     a mandatory part of a full Java EE 8 application server.
> >
> >     I would welcome any comments from the CDI spec experts here. If
> you're interested in helping, please take a look at
> >     https://java.net/projects/jms-spec/pages/CDIBeansAsJMSListeners
> >     and send comments or questions to me or to the public
> users at jms-spec.java.net <mailto:users at jms-spec.java.net> alias.
> >
> >     Thanks,
> >
> >     Nigel
> >     JMS 2.1 specification lead
> >     _______________________________________________
> >     cdi-dev mailing list
> >     cdi-dev at lists.jboss.org <mailto: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.
> >
> >
> >
> >
> > --
> > Antonio Goncalves
> > Software architect, Java Champion and Pluralsight author
> >
> > Web site <http://www.antoniogoncalves.org> | Twitter <
> http://twitter.com/agoncal> | LinkedIn
> > <http://www.linkedin.com/in/agoncal> | Pluralsight
> > <http://pluralsight.com/training/Authors/Details/antonio-goncalves> |
> Paris JUG <http://www.parisjug.org> | Devoxx
> > France <http://www.devoxx.fr>
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20150824/86151522/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 13
> ***************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150824/5ac19b62/attachment-0001.html 

From john.d.ament at gmail.com  Mon Aug 24 16:24:28 2015
From: john.d.ament at gmail.com (John D. Ament)
Date: Mon, 24 Aug 2015 20:24:28 +0000
Subject: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean in a
 Java EE application to listen for JMS messages
In-Reply-To: <55DB74E7.4080609@oracle.com>
References: <55DB4692.7040304@oracle.com>
	<CA+ZZq9_Brvtks=jxQ1TbtXMNm+ab3w3GZfG-2sGQYeMK2mu2jA@mail.gmail.com>
	<55DB74E7.4080609@oracle.com>
Message-ID: <CAOqetn9XTi0zSHMs9y_c3-XT1ghwTxog03BKwb+4=Jw3aPbPWg@mail.gmail.com>

Hi Nigel!

Glad to hear from you.  Was wondering, is there a way to manually register
listeners?  It would be great if this could be leveraged in a CDI SE
environment as well as EE environment.

John

On Mon, Aug 24, 2015 at 3:48 PM Nigel Deakin <nigel.deakin at oracle.com>
wrote:

> On 24/08/2015 18:42, Antonio Goncalves wrote:
>
> Nigel, what do you mean by :
>
> "The application must obtain an instance of the JMS listener bean using
> dependency injection"
>
> In your examples, it looks like a CDI bean cannot start listening if not
> injected :
>
> @WebServlet("/myjmsservlet1")
>  public class MyJMSServlet1 extends HttpServlet {
>
>    *@Inject MyDepScopeListenerBean* myDepScopeListenerBean;
>
>    public void service(ServletRequest req, ServletResponse res) throws
> IOException, ServletException {
>       ...
>    }
>  }
>
>
> Did I understand well ? Is this the case ? Just like a MDB, I would like a
> CDI bean to start listening to a message without being injected, as soon as
> the application starts.
>
>
> My starting point is that these are normal CDI beans which are created
> just like any other CDI bean. The bean's postCreate behaviour (inserted by
> the extension) would connect to the JMS provider and start listening for
> messages. The bean's preDestroy behaviour would stop listening for messages
> and disconnect from the JMS provider.
>
> As I understand it, if you want to create a CDI managed bean (so that it
> is managed by CDI) then you have to inject it into some code somewhere.
>
> Additionally, if the bean is normal scoped, you have to trigger lazy
> instantiation by calling a method on the injected bean proxy (e.g.
> toString()).
>
> Something like :
>
> *@ApplicationScoped*
> public class MyListenerBean{
>
>
>  @JMSListener(lookup="java:global/java:global/Trades",type=JMSListener.Type.TOPIC
> )
>    public void deliver(Message message) {
>      ...
>    }
> }
>
>
> If I understand things correctly, if this is a normal CDI bean then this
> alone is not sufficient to cause an instance of the bean to be created.
>
> You also need to
> (1) inject it into some other bean
> (2) create that other bean and
> (3) call a method on the MyListenerBean to trigger lazy initialisation.
>
> I'm trying to avoid getting ahead of myself here. My current proposals
> simply apply to normal CDI managed beans created in the normal way (via
> injection and lazy initialisation). But I could certainly see a benefit in
> extending this to allow JMS listener beans to be created in other ways. In
> particular:
>
> (a) Creating the bean instance as soon as the bean into which it is
> injected enters a new scope rather than waiting for the application to call
> a method on it (so-called eager initialisation). That sounds relatively
> straightforward to me; this could either be a new standard CDI feature
> available to all normal-scoped beans, or something specific to beans
> annotated with @JMSListener.
>
> (b) Creating the bean instance without the need to inject it anywhere.  As
> you suggest, in the case of ApplicationScoped beans this would make JMS
> listener beans more like MDBs. But it might be equally useful to support
> this for other normal scopes. For example, could we annotate a
> @RequestScoped bean so that every time a new request scope started, an
> instance of the bean for that scope was automatically created?
>
> Or if we manage to get the @Startup annotation to Commons Annotation :
>
> *@Startup*
> public class MyListenerBean{
>
>
>  @JMSListener(lookup="java:global/java:global/Trades",type=JMSListener.Type.TOPIC
> )
>    public void deliver(Message message) {
>      ...
>    }
> }
>
>
> That looks as if it's tied to ApplicationScoped. I'd rather look for
> something more general.
>
> Thanks for your comments so far. You're raising issues I have been
> thinking about for some time.
>
>
> Nigel
>
>
>
>
>
> Just thinking here
>
> Antonio
>
> On Mon, Aug 24, 2015 at 6:30 PM, Nigel Deakin <nigel.deakin at oracle.com>
> wrote:
>
>> Over in the JMS 2.1 expert group I've just published some proposals to
>> allow any CDI managed bean in a Java EE
>> application to listen for JMS messages. This would be implemented as a
>> standard CDI portable extension and would become
>> a mandatory part of a full Java EE 8 application server.
>>
>> I would welcome any comments from the CDI spec experts here. If you're
>> interested in helping, please take a look at
>> https://java.net/projects/jms-spec/pages/CDIBeansAsJMSListeners
>> and send comments or questions to me or to the public
>> <users at jms-spec.java.net>users at jms-spec.java.net alias.
>>
>> Thanks,
>>
>> Nigel
>> JMS 2.1 specification lead
>> _______________________________________________
>> 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>
>> 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.
>>
>
>
>
> --
> Antonio Goncalves
> Software architect, Java Champion and Pluralsight author
>
> Web site <http://www.antoniogoncalves.org> | Twitter
> <http://twitter.com/agoncal> | LinkedIn
> <http://www.linkedin.com/in/agoncal> | Pluralsight
> <http://pluralsight.com/training/Authors/Details/antonio-goncalves> | Paris
> JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr>
>
>
> _______________________________________________
> 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/20150824/171fd898/attachment.html 

From arjan.tijms at gmail.com  Mon Aug 24 19:18:36 2015
From: arjan.tijms at gmail.com (arjan tijms)
Date: Tue, 25 Aug 2015 01:18:36 +0200
Subject: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean in a
 Java EE application to listen for JMS messages
In-Reply-To: <55DB74E7.4080609@oracle.com>
References: <55DB4692.7040304@oracle.com>
	<CA+ZZq9_Brvtks=jxQ1TbtXMNm+ab3w3GZfG-2sGQYeMK2mu2jA@mail.gmail.com>
	<55DB74E7.4080609@oracle.com>
Message-ID: <CAE=-AhAd-dPbr1sAANiHQ4eD0BF2YA601Emk6+jk9fb_YOCgLQ@mail.gmail.com>

Hi,

On Mon, Aug 24, 2015 at 9:47 PM, Nigel Deakin <nigel.deakin at oracle.com> wrote:
> As I understand it, if you want to create a CDI managed bean (so that it is
> managed by CDI) then you have to inject it into some code somewhere.

This is not exclusively the case really;

There are generally 3 options:

1. Bean is injected
2. Bean is named (using @Named annotation or getName() of a Bean<T>
returns non null) and referenced by EL
3. Bean is programmatically created via BeanManager

In saw that the proposal essentially has an example of 3. already;
using the Instance injection. There are 2 variants on this where code
either uses the BeanManager directly or uses the "shortcut"
CDI.current().select(...);

Option 3. is often used when something needs a bean of a specific type
to do something. E.g. in JSF 2.3 a user would define a bean like this:

@FacesDataModel(forClass = MyCollection.class)
public class MyCollectionModel<E> extends DataModel<E> { ... }

And it just sits there (the user doesn't have to create it).

When a component needs this, it tries to obtain it programmatically,
via something like:

cdi.select(
    DataModel.class,
    new FacesDataModelAnnotationLiteral(MyCollection.class)
).get();

So the *expectation* may be that a user just defines a CDI based JMS
listener bean, and that the container will then find those beans when
it needs to deliver a message.

Of course this is not entirely trivial in the JMS listener case. The
JMS runtime can not easily ask CDI for all active instances of say the
request scope, and then ask for beans to be created in all those
scopes and then deliver the message to all of them.


> If I understand things correctly, if this is a normal CDI bean then this
> alone is not sufficient to cause an instance of the bean to be created.
>
> You also need to
> (1) inject it into some other bean
> (2) create that other bean and
> (3) call a method on the MyListenerBean to trigger lazy initialisation.

This is one way for sure, but one alternative worth mentioning is to
eagerly instantiatie the scoped bean whenever its scope starts. For
OmniFaces we have implemented a separate annotation for this for CDI
1.0, see http://showcase.omnifaces.org/cdi/Eager

For CDI 1.1, there's the @Initialized and @Destroyed annotations that
can be used to observe any scope where the implementing Context throws
events for these (which are all Java EE provided scopes as far as I
know). See https://rmannibucau.wordpress.com/2015/03/10/cdi-and-startup
and https://issues.jboss.org/browse/CDI-86

One CDI technicality is that if the listener method is called via the
proxy, I think it will resolve to the current scope that thread is in.
So this may mean the JMS endpoint that calls the JMS listener bean can
only call the actual bean's method, not the proxied one. I'm sure the
CDI experts here will have more knowledge about this.

Hope this helps.

Kind regards,
Arjan Tijms










>
> I'm trying to avoid getting ahead of myself here. My current proposals
> simply apply to normal CDI managed beans created in the normal way (via
> injection and lazy initialisation). But I could certainly see a benefit in
> extending this to allow JMS listener beans to be created in other ways. In
> particular:
>
> (a) Creating the bean instance as soon as the bean into which it is injected
> enters a new scope rather than waiting for the application to call a method
> on it (so-called eager initialisation). That sounds relatively
> straightforward to me; this could either be a new standard CDI feature
> available to all normal-scoped beans, or something specific to beans
> annotated with @JMSListener.
>
> (b) Creating the bean instance without the need to inject it anywhere.  As
> you suggest, in the case of ApplicationScoped beans this would make JMS
> listener beans more like MDBs. But it might be equally useful to support
> this for other normal scopes. For example, could we annotate a
> @RequestScoped bean so that every time a new request scope started, an
> instance of the bean for that scope was automatically created?
>
> Or if we manage to get the @Startup annotation to Commons Annotation :
>
> @Startup
> public class MyListenerBean{
>
>
> @JMSListener(lookup="java:global/java:global/Trades",type=JMSListener.Type.TOPIC
> )
>    public void deliver(Message message) {
>      ...
>    }
> }
>
>
> That looks as if it's tied to ApplicationScoped. I'd rather look for
> something more general.
>
> Thanks for your comments so far. You're raising issues I have been thinking
> about for some time.
>
> Nigel
>
>
>
>
> Just thinking here
>
> Antonio
>
> On Mon, Aug 24, 2015 at 6:30 PM, Nigel Deakin <nigel.deakin at oracle.com>
> wrote:
>>
>> Over in the JMS 2.1 expert group I've just published some proposals to
>> allow any CDI managed bean in a Java EE
>> application to listen for JMS messages. This would be implemented as a
>> standard CDI portable extension and would become
>> a mandatory part of a full Java EE 8 application server.
>>
>> I would welcome any comments from the CDI spec experts here. If you're
>> interested in helping, please take a look at
>> https://java.net/projects/jms-spec/pages/CDIBeansAsJMSListeners
>> and send comments or questions to me or to the public
>> users at jms-spec.java.net alias.
>>
>> Thanks,
>>
>> Nigel
>> JMS 2.1 specification lead
>> _______________________________________________
>> 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.
>
>
>
>
> --
> Antonio Goncalves
> Software architect, Java Champion and Pluralsight author
>
> Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France
>
>
>
> _______________________________________________
> 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.

From struberg at yahoo.de  Tue Aug 25 01:36:09 2015
From: struberg at yahoo.de (Mark Struberg)
Date: Mon, 24 Aug 2015 22:36:09 -0700
Subject: [cdi-dev] master branch in cdi-spec GIT repo
In-Reply-To: <CABu-YBR08Ygap-omyuUBEVJ2rA_u1j245ovzsz9Y58mAZaO=_w@mail.gmail.com>
Message-ID: <1440480969.74018.YahooMailIosMobile@web121604.mail.ne1.yahoo.com>

An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150824/dd3066a4/attachment.html 

From issues at jboss.org  Tue Aug 25 03:26:28 2015
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Tue, 25 Aug 2015 03:26:28 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-552) Add support for injection,
 decorators and interceptors on "new-ed" objects
In-Reply-To: <JIRA.12579311.1437747419000@Atlassian.JIRA>
References: <JIRA.12579311.1437747419000@Atlassian.JIRA>
	<JIRA.12579311.1437747419000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12579311.1437747419000.25496.1440487588980@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Antoine Sabot-Durand updated CDI-552:
-------------------------------------
    Issue Type: Feature Request  (was: Epic)


> Add support for injection, decorators and interceptors on "new-ed" objects
> --------------------------------------------------------------------------
>
>                 Key: CDI-552
>                 URL: https://issues.jboss.org/browse/CDI-552
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Beans, Decorators, Interceptors, Resolution
>    Affects Versions: 2.0-EDR1
>            Reporter: Rogerio Liesenfeld
>
> The current CDI programming model is not friendly to object-oriented code or proper class design, and does not support true POJOs.
> With this I mean:
> 1) For object-oriented code, I need to be able to instantiate and use *stateful*, short-lived, objects, while still having @Inject fields in it. I shouldn't be forced to have a stateless (non-OO) class (ie, a [Transaction Script|http://martinfowler.com/eaaCatalog/transactionScript.html]).
> 2) Most classes in a business app are not meant to be used as subclasses, ie, they are not designed for extension; therefore, I should be able to make them {{final}} (see http://lcsd05.cs.tamu.edu/slides/keynote.pdf, page 26, or item 17 in the [book|http://www.amazon.com/Effective-Java-2nd-Joshua-Bloch/dp/0321356683]).
> 3) For a class to truly be a POJO, I must be able to make *full use* of the Java language when designing and implementing it; arbitrary constraints like "can't be final", "can't have final instance fields", "cannot be instantiated directly", etc. prevent it from being a "plain-old" Java object.
> Specifically, what I want is to be able to write the following in a JSF/CDI backing bean for a web UI:
> {code}
> MyBusinessService businessOp = new MyBusinessService(fieldFromUI1, fieldFromUI2, listWithMoreDataFromUI);
> businessOp.performSomeBusinessOperation(otherArgs);
> String result1 = businessOp.getResultXyz();
> List<result> moreResultData = businessOp.getFinalData();
> {code}
> ... while having MyBusinessService be a CDI bean containing one or more @Inject/@PersistenceContext fields (typically, an EntityManager and perhaps other service beans).
> Without this ability, application developers are forced to create procedural Transation Scripts (stateless service class, which tend to have low cohesion).
> For a CDI implementation to do this, it will need to use the java.lang.instrument API, like others tools (AspectJ, JBoss AOP, JBoss Byteman, JaCoCo, JMockit) already do.
> Also, for reference, the Spring framework already supports it for some time: http://docs.spring.io/spring/docs/3.0.0.M3/spring-framework-reference/html/ch08s08.html



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From antoine at sabot-durand.net  Tue Aug 25 04:08:36 2015
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Tue, 25 Aug 2015 08:08:36 +0000
Subject: [cdi-dev] F2F meeting Prioritization
Message-ID: <CABu-YBSgPkzMaTYh5U3+Z+SSqAceG_6iDOAOfYCGqdGGZZoy6Q@mail.gmail.com>

Hi guys,


Just shared the following google spreadsheet for topics during the F2F
meeting.
https://docs.google.com/a/sabot-durand.net/spreadsheets/d/1Frlfv39Nixalt783dx6Yv7rvYWuFcoumlzZa4W5F8dw/edit?usp=sharing

Please add your own topic. When done, I propose we prioritize them by
voting for each topic and have someone in charge to start working on each
of them to arrive to meeting with preliminary work.

Antoine
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150825/0b95cf96/attachment.html 

From antoine at sabot-durand.net  Tue Aug 25 04:23:58 2015
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Tue, 25 Aug 2015 08:23:58 +0000
Subject: [cdi-dev] F2F participants
Message-ID: <CABu-YBRHvvUYMRk5tQbOT8TKuZwys_HijSakfA_nWGgLx1mEOg@mail.gmail.com>

Hi,

I added a sheet for participants to the shared spreadsheet:

https://docs.google.com/a/sabot-durand.net/spreadsheets/d/1Frlfv39Nixalt783dx6Yv7rvYWuFcoumlzZa4W5F8dw/edit?usp=sharing

You can add your name and other informations there.

Antoine
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150825/6a12fe52/attachment.html 

From antonio.goncalves at gmail.com  Tue Aug 25 05:51:23 2015
From: antonio.goncalves at gmail.com (Antonio Goncalves)
Date: Tue, 25 Aug 2015 11:51:23 +0200
Subject: [cdi-dev] F2F participants
In-Reply-To: <CABu-YBRHvvUYMRk5tQbOT8TKuZwys_HijSakfA_nWGgLx1mEOg@mail.gmail.com>
References: <CABu-YBRHvvUYMRk5tQbOT8TKuZwys_HijSakfA_nWGgLx1mEOg@mail.gmail.com>
Message-ID: <CA+ZZq99Ph8U2wSKWabMO2i=n9DR-xwv9GmdRggE13qPdZepuyA@mail.gmail.com>

I've also added a "Location Tab" (for Antoine to give us all the details of
the location + Hotels if needed) and an "Agenda Tab" so we can set up our
agenda (I've added "Evening" in case we want to have diner somewhere ;o)

Antonio

On Tue, Aug 25, 2015 at 10:23 AM, Antoine Sabot-Durand <
antoine at sabot-durand.net> wrote:

> Hi,
>
> I added a sheet for participants to the shared spreadsheet:
>
>
> https://docs.google.com/a/sabot-durand.net/spreadsheets/d/1Frlfv39Nixalt783dx6Yv7rvYWuFcoumlzZa4W5F8dw/edit?usp=sharing
>
> You can add your name and other informations there.
>
> 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.
>



-- 
Antonio Goncalves
Software architect, Java Champion and Pluralsight author

Web site <http://www.antoniogoncalves.org> | Twitter
<http://twitter.com/agoncal> | LinkedIn <http://www.linkedin.com/in/agoncal> |
Pluralsight
<http://pluralsight.com/training/Authors/Details/antonio-goncalves> | Paris
JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150825/1c303413/attachment.html 

From john.d.ament at gmail.com  Tue Aug 25 07:19:16 2015
From: john.d.ament at gmail.com (John D. Ament)
Date: Tue, 25 Aug 2015 11:19:16 +0000
Subject: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean in a
 Java EE application to listen for JMS messages
In-Reply-To: <CAE=-AhAd-dPbr1sAANiHQ4eD0BF2YA601Emk6+jk9fb_YOCgLQ@mail.gmail.com>
References: <55DB4692.7040304@oracle.com>
	<CA+ZZq9_Brvtks=jxQ1TbtXMNm+ab3w3GZfG-2sGQYeMK2mu2jA@mail.gmail.com>
	<55DB74E7.4080609@oracle.com>
	<CAE=-AhAd-dPbr1sAANiHQ4eD0BF2YA601Emk6+jk9fb_YOCgLQ@mail.gmail.com>
Message-ID: <CAOqetn8mn0eWGWVo3AiwJZu_A4nDngsgzj3cjiSqVGUPx09UEA@mail.gmail.com>

Technically speaking, I can have a bean like this:

@ApplicationScoped
public class Foo {
    public void onStart(@Observes @initialized(ApplicationScoped.class)
Object obj) {
       // do some work here
    }
}

That bean will get instantiated by the container, even if it doesn't have
any injection targets.

John

On Mon, Aug 24, 2015 at 7:18 PM arjan tijms <arjan.tijms at gmail.com> wrote:

> Hi,
>
> On Mon, Aug 24, 2015 at 9:47 PM, Nigel Deakin <nigel.deakin at oracle.com>
> wrote:
> > As I understand it, if you want to create a CDI managed bean (so that it
> is
> > managed by CDI) then you have to inject it into some code somewhere.
>
> This is not exclusively the case really;
>
> There are generally 3 options:
>
> 1. Bean is injected
> 2. Bean is named (using @Named annotation or getName() of a Bean<T>
> returns non null) and referenced by EL
> 3. Bean is programmatically created via BeanManager
>
> In saw that the proposal essentially has an example of 3. already;
> using the Instance injection. There are 2 variants on this where code
> either uses the BeanManager directly or uses the "shortcut"
> CDI.current().select(...);
>
> Option 3. is often used when something needs a bean of a specific type
> to do something. E.g. in JSF 2.3 a user would define a bean like this:
>
> @FacesDataModel(forClass = MyCollection.class)
> public class MyCollectionModel<E> extends DataModel<E> { ... }
>
> And it just sits there (the user doesn't have to create it).
>
> When a component needs this, it tries to obtain it programmatically,
> via something like:
>
> cdi.select(
>     DataModel.class,
>     new FacesDataModelAnnotationLiteral(MyCollection.class)
> ).get();
>
> So the *expectation* may be that a user just defines a CDI based JMS
> listener bean, and that the container will then find those beans when
> it needs to deliver a message.
>
> Of course this is not entirely trivial in the JMS listener case. The
> JMS runtime can not easily ask CDI for all active instances of say the
> request scope, and then ask for beans to be created in all those
> scopes and then deliver the message to all of them.
>
>
> > If I understand things correctly, if this is a normal CDI bean then this
> > alone is not sufficient to cause an instance of the bean to be created.
> >
> > You also need to
> > (1) inject it into some other bean
> > (2) create that other bean and
> > (3) call a method on the MyListenerBean to trigger lazy initialisation.
>
> This is one way for sure, but one alternative worth mentioning is to
> eagerly instantiatie the scoped bean whenever its scope starts. For
> OmniFaces we have implemented a separate annotation for this for CDI
> 1.0, see http://showcase.omnifaces.org/cdi/Eager
>
> For CDI 1.1, there's the @Initialized and @Destroyed annotations that
> can be used to observe any scope where the implementing Context throws
> events for these (which are all Java EE provided scopes as far as I
> know). See https://rmannibucau.wordpress.com/2015/03/10/cdi-and-startup
> and https://issues.jboss.org/browse/CDI-86
>
> One CDI technicality is that if the listener method is called via the
> proxy, I think it will resolve to the current scope that thread is in.
> So this may mean the JMS endpoint that calls the JMS listener bean can
> only call the actual bean's method, not the proxied one. I'm sure the
> CDI experts here will have more knowledge about this.
>
> Hope this helps.
>
> Kind regards,
> Arjan Tijms
>
>
>
>
>
>
>
>
>
>
> >
> > I'm trying to avoid getting ahead of myself here. My current proposals
> > simply apply to normal CDI managed beans created in the normal way (via
> > injection and lazy initialisation). But I could certainly see a benefit
> in
> > extending this to allow JMS listener beans to be created in other ways.
> In
> > particular:
> >
> > (a) Creating the bean instance as soon as the bean into which it is
> injected
> > enters a new scope rather than waiting for the application to call a
> method
> > on it (so-called eager initialisation). That sounds relatively
> > straightforward to me; this could either be a new standard CDI feature
> > available to all normal-scoped beans, or something specific to beans
> > annotated with @JMSListener.
> >
> > (b) Creating the bean instance without the need to inject it anywhere.
> As
> > you suggest, in the case of ApplicationScoped beans this would make JMS
> > listener beans more like MDBs. But it might be equally useful to support
> > this for other normal scopes. For example, could we annotate a
> > @RequestScoped bean so that every time a new request scope started, an
> > instance of the bean for that scope was automatically created?
> >
> > Or if we manage to get the @Startup annotation to Commons Annotation :
> >
> > @Startup
> > public class MyListenerBean{
> >
> >
> >
> @JMSListener(lookup="java:global/java:global/Trades",type=JMSListener.Type.TOPIC
> > )
> >    public void deliver(Message message) {
> >      ...
> >    }
> > }
> >
> >
> > That looks as if it's tied to ApplicationScoped. I'd rather look for
> > something more general.
> >
> > Thanks for your comments so far. You're raising issues I have been
> thinking
> > about for some time.
> >
> > Nigel
> >
> >
> >
> >
> > Just thinking here
> >
> > Antonio
> >
> > On Mon, Aug 24, 2015 at 6:30 PM, Nigel Deakin <nigel.deakin at oracle.com>
> > wrote:
> >>
> >> Over in the JMS 2.1 expert group I've just published some proposals to
> >> allow any CDI managed bean in a Java EE
> >> application to listen for JMS messages. This would be implemented as a
> >> standard CDI portable extension and would become
> >> a mandatory part of a full Java EE 8 application server.
> >>
> >> I would welcome any comments from the CDI spec experts here. If you're
> >> interested in helping, please take a look at
> >> https://java.net/projects/jms-spec/pages/CDIBeansAsJMSListeners
> >> and send comments or questions to me or to the public
> >> users at jms-spec.java.net alias.
> >>
> >> Thanks,
> >>
> >> Nigel
> >> JMS 2.1 specification lead
> >> _______________________________________________
> >> 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.
> >
> >
> >
> >
> > --
> > Antonio Goncalves
> > Software architect, Java Champion and Pluralsight author
> >
> > Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France
> >
> >
> >
> > _______________________________________________
> > 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/20150825/9ed0c209/attachment-0001.html 

From werner.keil at gmail.com  Tue Aug 25 07:32:15 2015
From: werner.keil at gmail.com (Werner Keil)
Date: Tue, 25 Aug 2015 13:32:15 +0200
Subject: [cdi-dev] F2F participants
Message-ID: <CAAGawe1=4eq10gB3Z1VHR1c+gZwQHAgg7SZtLMsmF3f5iMovqg@mail.gmail.com>

I just realized, it'w 3 days total.
Given, I have a total of 15 working days with 3 Java/IT related conferences
confirmed as speaker between Sep and Nov (ApacheCon EU, JavaOne EC duties
and DevoXX Morocco) I'm afraid, despite being very active CDI (1.0) users
my client and project will not grant me any paid leave to attend the F2F,
so at most it looks like I'll arrive in the course of Fri and be there all
of Sat.

Will see how the agenda shapes up. Especially on the JMS topic I'd love to
participate in discussions since I not only did something with JMS and CDI
events but also am in the JMS 2.1 EG. Sorry to be only available for part
of it but I'm not paid to speak or attend these kinds of meetings like some
of you might by your companies;-)

Werner

On Tue, Aug 25, 2015 at 1:19 PM, <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: master branch in cdi-spec GIT repo (Mark Struberg)
>    2. [JBoss JIRA] (CDI-552) Add support for injection, decorators
>       and interceptors on "new-ed" objects (Antoine Sabot-Durand (JIRA))
>    3. F2F meeting Prioritization (Antoine Sabot-Durand)
>    4. F2F participants (Antoine Sabot-Durand)
>    5. Re: F2F participants (Antonio Goncalves)
>    6. Re: JMS 2.1: Proposal to allow any CDI managed bean in a Java
>       EE application to listen for JMS messages (John D. Ament)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 24 Aug 2015 22:36:09 -0700
> From: Mark Struberg <struberg at yahoo.de>
> Subject: Re: [cdi-dev] master branch in cdi-spec GIT repo
> To: "antoine at sabot-durand.net" <antoine at sabot-durand.net>,
>         "jharting at redhat.com" <jharting at redhat.com>,    "
> cdi-dev at lists.jboss.org"
>         <cdi-dev at lists.jboss.org>
> Message-ID:
>         <1440480969.74018.YahooMailIosMobile at web121604.mail.ne1.yahoo.com>
> Content-Type: text/plain; charset="us-ascii"
>
> An HTML attachment was scrubbed...
> URL:
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20150824/dd3066a4/attachment-0001.html
>
> ------------------------------
>
> Message: 2
> Date: Tue, 25 Aug 2015 03:26:28 -0400 (EDT)
> From: "Antoine Sabot-Durand (JIRA)" <issues at jboss.org>
> Subject: [cdi-dev] [JBoss JIRA] (CDI-552) Add support for injection,
>         decorators and interceptors on "new-ed" objects
> To: cdi-dev at lists.jboss.org
> Message-ID:
>         <JIRA.12579311.1437747419000.25496.1440487588980 at Atlassian.JIRA>
> Content-Type: text/plain; charset=UTF-8
>
>
>      [
> https://issues.jboss.org/browse/CDI-552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
> ]
>
> Antoine Sabot-Durand updated CDI-552:
> -------------------------------------
>     Issue Type: Feature Request  (was: Epic)
>
>
> > Add support for injection, decorators and interceptors on "new-ed"
> objects
> >
> --------------------------------------------------------------------------
> >
> >                 Key: CDI-552
> >                 URL: https://issues.jboss.org/browse/CDI-552
> >             Project: CDI Specification Issues
> >          Issue Type: Feature Request
> >          Components: Beans, Decorators, Interceptors, Resolution
> >    Affects Versions: 2.0-EDR1
> >            Reporter: Rogerio Liesenfeld
> >
> > The current CDI programming model is not friendly to object-oriented
> code or proper class design, and does not support true POJOs.
> > With this I mean:
> > 1) For object-oriented code, I need to be able to instantiate and use
> *stateful*, short-lived, objects, while still having @Inject fields in it.
> I shouldn't be forced to have a stateless (non-OO) class (ie, a
> [Transaction Script|
> http://martinfowler.com/eaaCatalog/transactionScript.html]).
> > 2) Most classes in a business app are not meant to be used as
> subclasses, ie, they are not designed for extension; therefore, I should be
> able to make them {{final}} (see
> http://lcsd05.cs.tamu.edu/slides/keynote.pdf, page 26, or item 17 in the
> [book|http://www.amazon.com/Effective-Java-2nd-Joshua-Bloch/dp/0321356683]
> ).
> > 3) For a class to truly be a POJO, I must be able to make *full use* of
> the Java language when designing and implementing it; arbitrary constraints
> like "can't be final", "can't have final instance fields", "cannot be
> instantiated directly", etc. prevent it from being a "plain-old" Java
> object.
> > Specifically, what I want is to be able to write the following in a
> JSF/CDI backing bean for a web UI:
> > {code}
> > MyBusinessService businessOp = new MyBusinessService(fieldFromUI1,
> fieldFromUI2, listWithMoreDataFromUI);
> > businessOp.performSomeBusinessOperation(otherArgs);
> > String result1 = businessOp.getResultXyz();
> > List<result> moreResultData = businessOp.getFinalData();
> > {code}
> > ... while having MyBusinessService be a CDI bean containing one or more
> @Inject/@PersistenceContext fields (typically, an EntityManager and perhaps
> other service beans).
> > Without this ability, application developers are forced to create
> procedural Transation Scripts (stateless service class, which tend to have
> low cohesion).
> > For a CDI implementation to do this, it will need to use the
> java.lang.instrument API, like others tools (AspectJ, JBoss AOP, JBoss
> Byteman, JaCoCo, JMockit) already do.
> > Also, for reference, the Spring framework already supports it for some
> time:
> http://docs.spring.io/spring/docs/3.0.0.M3/spring-framework-reference/html/ch08s08.html
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.3.15#6346)
>
>
> ------------------------------
>
> Message: 3
> Date: Tue, 25 Aug 2015 08:08:36 +0000
> From: Antoine Sabot-Durand <antoine at sabot-durand.net>
> Subject: [cdi-dev] F2F meeting Prioritization
> To: CDI Java EE Specification <cdi-dev at lists.jboss.org>
> Message-ID:
>         <
> CABu-YBSgPkzMaTYh5U3+Z+SSqAceG_6iDOAOfYCGqdGGZZoy6Q at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi guys,
>
>
> Just shared the following google spreadsheet for topics during the F2F
> meeting.
>
> https://docs.google.com/a/sabot-durand.net/spreadsheets/d/1Frlfv39Nixalt783dx6Yv7rvYWuFcoumlzZa4W5F8dw/edit?usp=sharing
>
> Please add your own topic. When done, I propose we prioritize them by
> voting for each topic and have someone in charge to start working on each
> of them to arrive to meeting with preliminary work.
>
> Antoine
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20150825/0b95cf96/attachment-0001.html
>
> ------------------------------
>
> Message: 4
> Date: Tue, 25 Aug 2015 08:23:58 +0000
> From: Antoine Sabot-Durand <antoine at sabot-durand.net>
> Subject: [cdi-dev] F2F participants
> To: cdi-dev <cdi-dev at lists.jboss.org>
> Message-ID:
>         <
> CABu-YBRHvvUYMRk5tQbOT8TKuZwys_HijSakfA_nWGgLx1mEOg at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi,
>
> I added a sheet for participants to the shared spreadsheet:
>
>
> https://docs.google.com/a/sabot-durand.net/spreadsheets/d/1Frlfv39Nixalt783dx6Yv7rvYWuFcoumlzZa4W5F8dw/edit?usp=sharing
>
> You can add your name and other informations there.
>
> Antoine
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20150825/6a12fe52/attachment-0001.html
>
> ------------------------------
>
> Message: 5
> Date: Tue, 25 Aug 2015 11:51:23 +0200
> From: Antonio Goncalves <antonio.goncalves at gmail.com>
> Subject: Re: [cdi-dev] F2F participants
> To: Antoine Sabot-Durand <antoine at sabot-durand.net>
> Cc: cdi-dev <cdi-dev at lists.jboss.org>
> Message-ID:
>         <CA+ZZq99Ph8U2wSKWabMO2i=
> n9DR-xwv9GmdRggE13qPdZepuyA at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> I've also added a "Location Tab" (for Antoine to give us all the details of
> the location + Hotels if needed) and an "Agenda Tab" so we can set up our
> agenda (I've added "Evening" in case we want to have diner somewhere ;o)
>
> Antonio
>
> On Tue, Aug 25, 2015 at 10:23 AM, Antoine Sabot-Durand <
> antoine at sabot-durand.net> wrote:
>
> > Hi,
> >
> > I added a sheet for participants to the shared spreadsheet:
> >
> >
> >
> https://docs.google.com/a/sabot-durand.net/spreadsheets/d/1Frlfv39Nixalt783dx6Yv7rvYWuFcoumlzZa4W5F8dw/edit?usp=sharing
> >
> > You can add your name and other informations there.
> >
> > 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.
> >
>
>
>
> --
> Antonio Goncalves
> Software architect, Java Champion and Pluralsight author
>
> Web site <http://www.antoniogoncalves.org> | Twitter
> <http://twitter.com/agoncal> | LinkedIn <
> http://www.linkedin.com/in/agoncal> |
> Pluralsight
> <http://pluralsight.com/training/Authors/Details/antonio-goncalves> |
> Paris
> JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20150825/1c303413/attachment-0001.html
>
> ------------------------------
>
> Message: 6
> Date: Tue, 25 Aug 2015 11:19:16 +0000
> From: "John D. Ament" <john.d.ament at gmail.com>
> Subject: Re: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean
>         in a Java EE application to listen for JMS messages
> To: arjan tijms <arjan.tijms at gmail.com>, Nigel Deakin
>         <nigel.deakin at oracle.com>
> Cc: cdi-dev <cdi-dev at lists.jboss.org>
> Message-ID:
>         <
> CAOqetn8mn0eWGWVo3AiwJZu_A4nDngsgzj3cjiSqVGUPx09UEA at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Technically speaking, I can have a bean like this:
>
> @ApplicationScoped
> public class Foo {
>     public void onStart(@Observes @initialized(ApplicationScoped.class)
> Object obj) {
>        // do some work here
>     }
> }
>
> That bean will get instantiated by the container, even if it doesn't have
> any injection targets.
>
> John
>
> On Mon, Aug 24, 2015 at 7:18 PM arjan tijms <arjan.tijms at gmail.com> wrote:
>
> > Hi,
> >
> > On Mon, Aug 24, 2015 at 9:47 PM, Nigel Deakin <nigel.deakin at oracle.com>
> > wrote:
> > > As I understand it, if you want to create a CDI managed bean (so that
> it
> > is
> > > managed by CDI) then you have to inject it into some code somewhere.
> >
> > This is not exclusively the case really;
> >
> > There are generally 3 options:
> >
> > 1. Bean is injected
> > 2. Bean is named (using @Named annotation or getName() of a Bean<T>
> > returns non null) and referenced by EL
> > 3. Bean is programmatically created via BeanManager
> >
> > In saw that the proposal essentially has an example of 3. already;
> > using the Instance injection. There are 2 variants on this where code
> > either uses the BeanManager directly or uses the "shortcut"
> > CDI.current().select(...);
> >
> > Option 3. is often used when something needs a bean of a specific type
> > to do something. E.g. in JSF 2.3 a user would define a bean like this:
> >
> > @FacesDataModel(forClass = MyCollection.class)
> > public class MyCollectionModel<E> extends DataModel<E> { ... }
> >
> > And it just sits there (the user doesn't have to create it).
> >
> > When a component needs this, it tries to obtain it programmatically,
> > via something like:
> >
> > cdi.select(
> >     DataModel.class,
> >     new FacesDataModelAnnotationLiteral(MyCollection.class)
> > ).get();
> >
> > So the *expectation* may be that a user just defines a CDI based JMS
> > listener bean, and that the container will then find those beans when
> > it needs to deliver a message.
> >
> > Of course this is not entirely trivial in the JMS listener case. The
> > JMS runtime can not easily ask CDI for all active instances of say the
> > request scope, and then ask for beans to be created in all those
> > scopes and then deliver the message to all of them.
> >
> >
> > > If I understand things correctly, if this is a normal CDI bean then
> this
> > > alone is not sufficient to cause an instance of the bean to be created.
> > >
> > > You also need to
> > > (1) inject it into some other bean
> > > (2) create that other bean and
> > > (3) call a method on the MyListenerBean to trigger lazy initialisation.
> >
> > This is one way for sure, but one alternative worth mentioning is to
> > eagerly instantiatie the scoped bean whenever its scope starts. For
> > OmniFaces we have implemented a separate annotation for this for CDI
> > 1.0, see http://showcase.omnifaces.org/cdi/Eager
> >
> > For CDI 1.1, there's the @Initialized and @Destroyed annotations that
> > can be used to observe any scope where the implementing Context throws
> > events for these (which are all Java EE provided scopes as far as I
> > know). See https://rmannibucau.wordpress.com/2015/03/10/cdi-and-startup
> > and https://issues.jboss.org/browse/CDI-86
> >
> > One CDI technicality is that if the listener method is called via the
> > proxy, I think it will resolve to the current scope that thread is in.
> > So this may mean the JMS endpoint that calls the JMS listener bean can
> > only call the actual bean's method, not the proxied one. I'm sure the
> > CDI experts here will have more knowledge about this.
> >
> > Hope this helps.
> >
> > Kind regards,
> > Arjan Tijms
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > >
> > > I'm trying to avoid getting ahead of myself here. My current proposals
> > > simply apply to normal CDI managed beans created in the normal way (via
> > > injection and lazy initialisation). But I could certainly see a benefit
> > in
> > > extending this to allow JMS listener beans to be created in other ways.
> > In
> > > particular:
> > >
> > > (a) Creating the bean instance as soon as the bean into which it is
> > injected
> > > enters a new scope rather than waiting for the application to call a
> > method
> > > on it (so-called eager initialisation). That sounds relatively
> > > straightforward to me; this could either be a new standard CDI feature
> > > available to all normal-scoped beans, or something specific to beans
> > > annotated with @JMSListener.
> > >
> > > (b) Creating the bean instance without the need to inject it anywhere.
> > As
> > > you suggest, in the case of ApplicationScoped beans this would make JMS
> > > listener beans more like MDBs. But it might be equally useful to
> support
> > > this for other normal scopes. For example, could we annotate a
> > > @RequestScoped bean so that every time a new request scope started, an
> > > instance of the bean for that scope was automatically created?
> > >
> > > Or if we manage to get the @Startup annotation to Commons Annotation :
> > >
> > > @Startup
> > > public class MyListenerBean{
> > >
> > >
> > >
> >
> @JMSListener(lookup="java:global/java:global/Trades",type=JMSListener.Type.TOPIC
> > > )
> > >    public void deliver(Message message) {
> > >      ...
> > >    }
> > > }
> > >
> > >
> > > That looks as if it's tied to ApplicationScoped. I'd rather look for
> > > something more general.
> > >
> > > Thanks for your comments so far. You're raising issues I have been
> > thinking
> > > about for some time.
> > >
> > > Nigel
> > >
> > >
> > >
> > >
> > > Just thinking here
> > >
> > > Antonio
> > >
> > > On Mon, Aug 24, 2015 at 6:30 PM, Nigel Deakin <nigel.deakin at oracle.com
> >
> > > wrote:
> > >>
> > >> Over in the JMS 2.1 expert group I've just published some proposals to
> > >> allow any CDI managed bean in a Java EE
> > >> application to listen for JMS messages. This would be implemented as a
> > >> standard CDI portable extension and would become
> > >> a mandatory part of a full Java EE 8 application server.
> > >>
> > >> I would welcome any comments from the CDI spec experts here. If you're
> > >> interested in helping, please take a look at
> > >> https://java.net/projects/jms-spec/pages/CDIBeansAsJMSListeners
> > >> and send comments or questions to me or to the public
> > >> users at jms-spec.java.net alias.
> > >>
> > >> Thanks,
> > >>
> > >> Nigel
> > >> JMS 2.1 specification lead
> > >> _______________________________________________
> > >> 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.
> > >
> > >
> > >
> > >
> > > --
> > > Antonio Goncalves
> > > Software architect, Java Champion and Pluralsight author
> > >
> > > Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France
> > >
> > >
> > >
> > > _______________________________________________
> > > 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/20150825/9ed0c209/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 16
> ***************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150825/679738ce/attachment-0001.html 

From arjan.tijms at gmail.com  Tue Aug 25 07:38:28 2015
From: arjan.tijms at gmail.com (arjan tijms)
Date: Tue, 25 Aug 2015 13:38:28 +0200
Subject: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean in a
 Java EE application to listen for JMS messages
In-Reply-To: <CAOqetn8mn0eWGWVo3AiwJZu_A4nDngsgzj3cjiSqVGUPx09UEA@mail.gmail.com>
References: <55DB4692.7040304@oracle.com>
	<CA+ZZq9_Brvtks=jxQ1TbtXMNm+ab3w3GZfG-2sGQYeMK2mu2jA@mail.gmail.com>
	<55DB74E7.4080609@oracle.com>
	<CAE=-AhAd-dPbr1sAANiHQ4eD0BF2YA601Emk6+jk9fb_YOCgLQ@mail.gmail.com>
	<CAOqetn8mn0eWGWVo3AiwJZu_A4nDngsgzj3cjiSqVGUPx09UEA@mail.gmail.com>
Message-ID: <CAE=-AhBBSPw1ZRdzSQOJm1aRKiTxKo0tBHagv8_bn9D=g2B+HQ@mail.gmail.com>

On Tue, Aug 25, 2015 at 1:19 PM, John D. Ament <john.d.ament at gmail.com> wrote:
> Technically speaking, I can have a bean like this:
>
> @ApplicationScoped
> public class Foo {
>     public void onStart(@Observes @initialized(ApplicationScoped.class)
> Object obj) {
>        // do some work here
>     }
> }
>
> That bean will get instantiated by the container, even if it doesn't have
> any injection targets.

Indeed, that's what I meant above with the reference to the
@Initialized and @Destroyed annotations. With that construct a JMS
Listener bean can be "started" without it having to be referenced from
other code.

From issues at jboss.org  Tue Aug 25 09:08:43 2015
From: issues at jboss.org (Tomas Remes (JIRA))
Date: Tue, 25 Aug 2015 09:08:43 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-555) Inaccurate wording in "24.3.1.
 Obtaining a reference to the CDI container in Java EE"
In-Reply-To: <JIRA.12582539.1440508088000@Atlassian.JIRA>
References: <JIRA.12582539.1440508088000@Atlassian.JIRA>
	<JIRA.12582539.1440508088059@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582539.1440508088000.716.1440508123196@Atlassian.JIRA>

Tomas Remes created CDI-555:
-------------------------------

             Summary: Inaccurate wording in "24.3.1. Obtaining a reference to the CDI container in Java EE"
                 Key: CDI-555
                 URL: https://issues.jboss.org/browse/CDI-555
             Project: CDI Specification Issues
          Issue Type: Bug
    Affects Versions: 2.0-EDR1
            Reporter: Tomas Remes


Chapter {{24.3.1. Obtaining a reference to the CDI container in Java EE}} states:
{quote}
When running in Java EE, when initialize, stop or shutdown methods of CDIProvider are called an UnsupportedOperationException is thrown.
{quote}

However there are no shutdown and stop methods in {{javax.enterprise.inject.spi.CDIProvider}} interface



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From nigel.deakin at oracle.com  Tue Aug 25 09:51:12 2015
From: nigel.deakin at oracle.com (Nigel Deakin)
Date: Tue, 25 Aug 2015 14:51:12 +0100
Subject: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean in a
 Java EE application to listen for JMS messages
In-Reply-To: <CAOqetn9XTi0zSHMs9y_c3-XT1ghwTxog03BKwb+4=Jw3aPbPWg@mail.gmail.com>
References: <55DB4692.7040304@oracle.com>
	<CA+ZZq9_Brvtks=jxQ1TbtXMNm+ab3w3GZfG-2sGQYeMK2mu2jA@mail.gmail.com>
	<55DB74E7.4080609@oracle.com>
	<CAOqetn9XTi0zSHMs9y_c3-XT1ghwTxog03BKwb+4=Jw3aPbPWg@mail.gmail.com>
Message-ID: <55DC72D0.5090608@oracle.com>

On 24/08/2015 21:24, John D. Ament wrote:
>
> Hi Nigel!
>
> Glad to hear from you.  Was wondering, is there a way to manually register listeners?

The current proposal is is for the bean to start listening just as soon as it is created (by CDI), and for it to stop 
listening just before it is destroyed (by CDI).

As you suggesting that CDI would create the listener, but the application would call some method to tell it to start 
listening? or did you have something else in mind?

 > It would be great if this could
> be leveraged in a CDI SE environment as well as EE environment.

I see that work is underway for CDI 2.0 to define how CDI might work in a Java SE environment. I don't see why a similar 
portable extension could not be created for use in Java SE. Since there would be no need to support Java EE behaviour 
such as transactions this could be built directly on top of the JMS provider's Java SE client. No need to use a resource 
adapter. However since the @JMSListener and @JMSConnectionFactory annotations use JNDI there would be a need to be a way 
to specify which JNDI InitialContext to use. I'm not proposing any of this at the moment, but it might perhaps be 
something that we (the JMS expert group) could consider later on as a optional part of JMS 2.1.

There's also the Java EE application client to consider.

Nigel


From rmannibucau at gmail.com  Tue Aug 25 10:05:09 2015
From: rmannibucau at gmail.com (Romain Manni-Bucau)
Date: Tue, 25 Aug 2015 16:05:09 +0200
Subject: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean in a
 Java EE application to listen for JMS messages
In-Reply-To: <55DC72D0.5090608@oracle.com>
References: <55DB4692.7040304@oracle.com>
	<CA+ZZq9_Brvtks=jxQ1TbtXMNm+ab3w3GZfG-2sGQYeMK2mu2jA@mail.gmail.com>
	<55DB74E7.4080609@oracle.com>
	<CAOqetn9XTi0zSHMs9y_c3-XT1ghwTxog03BKwb+4=Jw3aPbPWg@mail.gmail.com>
	<55DC72D0.5090608@oracle.com>
Message-ID: <CACLE=7Ne_okSRKHa74WGAnZCzGy8ds=m=L_ArWWVzyxc1-LA0g@mail.gmail.com>

So if I get it right the issue is for now in CDI you don't really know if
the backing instance - if exists - is created or not (ie toString() is not
enough). I think on this point CDI can be enhanced to have a
isInstantiated() method in its SPI and potentially a forceInstantiation()
one to solve it - would also allow to fix the @Startup issue.

Now for JMS having an event based SPI would be a good addition allowing
some programmatic registration - naming is to completely to rework but the
idea would be:


public void startJms(@Observes final JmsAfterStart jmsStart) {
    jmsStart.registerListener(message -> System.out.println(message))
                 .registerListener(new MyTypedMessageListener()); // or
even an injected instance
}

// JmsBeforeShutdown would be needed as well with a unregister for symmetry
but auto deregistration is possible as well

with MyTypedMessageListener:

public class MyTypedMessageListener {
      public void onMessage(MyTypedMessageICreatedInMyApp msg() {}
}

For this last case a really elegant solution would be to just reuse
@Observes to fire the message from the jms "container" listener and
propagate it to the "user" listener. This would then allow to decouple the
application listener from JMS.

For client side having a custom qualifier supporting placeholding - a bit
like jbatch for system properties - would be nice and would allow to skip
JNDI which means enabling SE usage as well.


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com>

2015-08-25 15:51 GMT+02:00 Nigel Deakin <nigel.deakin at oracle.com>:

> On 24/08/2015 21:24, John D. Ament wrote:
> >
> > Hi Nigel!
> >
> > Glad to hear from you.  Was wondering, is there a way to manually
> register listeners?
>
> The current proposal is is for the bean to start listening just as soon as
> it is created (by CDI), and for it to stop
> listening just before it is destroyed (by CDI).
>
> As you suggesting that CDI would create the listener, but the application
> would call some method to tell it to start
> listening? or did you have something else in mind?
>
>  > It would be great if this could
> > be leveraged in a CDI SE environment as well as EE environment.
>
> I see that work is underway for CDI 2.0 to define how CDI might work in a
> Java SE environment. I don't see why a similar
> portable extension could not be created for use in Java SE. Since there
> would be no need to support Java EE behaviour
> such as transactions this could be built directly on top of the JMS
> provider's Java SE client. No need to use a resource
> adapter. However since the @JMSListener and @JMSConnectionFactory
> annotations use JNDI there would be a need to be a way
> to specify which JNDI InitialContext to use. I'm not proposing any of this
> at the moment, but it might perhaps be
> something that we (the JMS expert group) could consider later on as a
> optional part of JMS 2.1.
>
> There's also the Java EE application client to consider.
>
> Nigel
>
> _______________________________________________
> 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/20150825/b18a7022/attachment.html 

From jharting at redhat.com  Tue Aug 25 10:26:21 2015
From: jharting at redhat.com (Jozef Hartinger)
Date: Tue, 25 Aug 2015 16:26:21 +0200
Subject: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean in a
 Java EE application to listen for JMS messages
In-Reply-To: <CACLE=7Ne_okSRKHa74WGAnZCzGy8ds=m=L_ArWWVzyxc1-LA0g@mail.gmail.com>
References: <55DB4692.7040304@oracle.com>
	<CA+ZZq9_Brvtks=jxQ1TbtXMNm+ab3w3GZfG-2sGQYeMK2mu2jA@mail.gmail.com>
	<55DB74E7.4080609@oracle.com>
	<CAOqetn9XTi0zSHMs9y_c3-XT1ghwTxog03BKwb+4=Jw3aPbPWg@mail.gmail.com>
	<55DC72D0.5090608@oracle.com>
	<CACLE=7Ne_okSRKHa74WGAnZCzGy8ds=m=L_ArWWVzyxc1-LA0g@mail.gmail.com>
Message-ID: <55DC7B0D.8080200@redhat.com>

Agreed. I think we should leverage the existing CDI event/observer 
functionality instead of introducing a completely new delivery mechanism.


On 25.08.2015 16:05, Romain Manni-Bucau wrote:
>
> For this last case a really elegant solution would be to just reuse
> @Observes to fire the message from the jms "container" listener and
> propagate it to the "user" listener. This would then allow to decouple
> the application listener from JMS.

From arjan.tijms at gmail.com  Tue Aug 25 10:40:09 2015
From: arjan.tijms at gmail.com (arjan tijms)
Date: Tue, 25 Aug 2015 16:40:09 +0200
Subject: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean in a
 Java EE application to listen for JMS messages
In-Reply-To: <CACLE=7Ne_okSRKHa74WGAnZCzGy8ds=m=L_ArWWVzyxc1-LA0g@mail.gmail.com>
References: <55DB4692.7040304@oracle.com>
	<CA+ZZq9_Brvtks=jxQ1TbtXMNm+ab3w3GZfG-2sGQYeMK2mu2jA@mail.gmail.com>
	<55DB74E7.4080609@oracle.com>
	<CAOqetn9XTi0zSHMs9y_c3-XT1ghwTxog03BKwb+4=Jw3aPbPWg@mail.gmail.com>
	<55DC72D0.5090608@oracle.com>
	<CACLE=7Ne_okSRKHa74WGAnZCzGy8ds=m=L_ArWWVzyxc1-LA0g@mail.gmail.com>
Message-ID: <CAE=-AhBOCz=iUBg9u7XQqWLR4vrw8e7aTw89P5_gqzUVA8thoQ@mail.gmail.com>

Hi,

On Tue, Aug 25, 2015 at 4:05 PM, Romain Manni-Bucau
<rmannibucau at gmail.com> wrote:
> For this last case a really elegant solution would be to just reuse
> @Observes to fire the message from the jms "container" listener and
> propagate it to the "user" listener. This would then allow to decouple the
> application listener from JMS.

That sounds great indeed.

I'm very likely missing something though, but I wonder using that
preferred approach how a message is exactly delivered to all instances
of a bean in a given scope?

E.g.

Suppose the JMS listener bean is @SessionScoped, and there are
currently 3 active sessions. The event is then fired from a system
thread (I assume, but is this correct?). Can CDI find all of the 3
active sessions and then call the observer method for separate
instances of the bean in those 3 sessions?

Or is this not how the feature is intended?

Kind regards,
Arjan Tijms




>
> For client side having a custom qualifier supporting placeholding - a bit
> like jbatch for system properties - would be nice and would allow to skip
> JNDI which means enabling SE usage as well.
>
>
> Romain Manni-Bucau
> @rmannibucau |  Blog | Github | LinkedIn | Tomitriber
>
> 2015-08-25 15:51 GMT+02:00 Nigel Deakin <nigel.deakin at oracle.com>:
>>
>> On 24/08/2015 21:24, John D. Ament wrote:
>> >
>> > Hi Nigel!
>> >
>> > Glad to hear from you.  Was wondering, is there a way to manually
>> > register listeners?
>>
>> The current proposal is is for the bean to start listening just as soon as
>> it is created (by CDI), and for it to stop
>> listening just before it is destroyed (by CDI).
>>
>> As you suggesting that CDI would create the listener, but the application
>> would call some method to tell it to start
>> listening? or did you have something else in mind?
>>
>>  > It would be great if this could
>> > be leveraged in a CDI SE environment as well as EE environment.
>>
>> I see that work is underway for CDI 2.0 to define how CDI might work in a
>> Java SE environment. I don't see why a similar
>> portable extension could not be created for use in Java SE. Since there
>> would be no need to support Java EE behaviour
>> such as transactions this could be built directly on top of the JMS
>> provider's Java SE client. No need to use a resource
>> adapter. However since the @JMSListener and @JMSConnectionFactory
>> annotations use JNDI there would be a need to be a way
>> to specify which JNDI InitialContext to use. I'm not proposing any of this
>> at the moment, but it might perhaps be
>> something that we (the JMS expert group) could consider later on as a
>> optional part of JMS 2.1.
>>
>> There's also the Java EE application client to consider.
>>
>> Nigel
>>
>> _______________________________________________
>> 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.

From rmannibucau at gmail.com  Tue Aug 25 10:43:42 2015
From: rmannibucau at gmail.com (Romain Manni-Bucau)
Date: Tue, 25 Aug 2015 16:43:42 +0200
Subject: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean in a
 Java EE application to listen for JMS messages
In-Reply-To: <CAE=-AhBOCz=iUBg9u7XQqWLR4vrw8e7aTw89P5_gqzUVA8thoQ@mail.gmail.com>
References: <55DB4692.7040304@oracle.com>
	<CA+ZZq9_Brvtks=jxQ1TbtXMNm+ab3w3GZfG-2sGQYeMK2mu2jA@mail.gmail.com>
	<55DB74E7.4080609@oracle.com>
	<CAOqetn9XTi0zSHMs9y_c3-XT1ghwTxog03BKwb+4=Jw3aPbPWg@mail.gmail.com>
	<55DC72D0.5090608@oracle.com>
	<CACLE=7Ne_okSRKHa74WGAnZCzGy8ds=m=L_ArWWVzyxc1-LA0g@mail.gmail.com>
	<CAE=-AhBOCz=iUBg9u7XQqWLR4vrw8e7aTw89P5_gqzUVA8thoQ@mail.gmail.com>
Message-ID: <CACLE=7PN+Xg+E5bBcwK5ZrWMwdO7vYNXKyDAB62A5huejTow2g@mail.gmail.com>

2015-08-25 16:40 GMT+02:00 arjan tijms <arjan.tijms at gmail.com>:

> Hi,
>
> On Tue, Aug 25, 2015 at 4:05 PM, Romain Manni-Bucau
> <rmannibucau at gmail.com> wrote:
> > For this last case a really elegant solution would be to just reuse
> > @Observes to fire the message from the jms "container" listener and
> > propagate it to the "user" listener. This would then allow to decouple
> the
> > application listener from JMS.
>
> That sounds great indeed.
>
> I'm very likely missing something though, but I wonder using that
> preferred approach how a message is exactly delivered to all instances
> of a bean in a given scope?
>
> E.g.
>
> Suppose the JMS listener bean is @SessionScoped, and there are
> currently 3 active sessions. The event is then fired from a system
> thread (I assume, but is this correct?). Can CDI find all of the 3
> active sessions and then call the observer method for separate
> instances of the bean in those 3 sessions?
>
>
CDI not sure but CDI implementations can for sure find the instances, that
said I hope it will be forbidden and that only scopes linked the a message
context (ie app scoped, maybe singleton, dependent and jms scopes would be
allowed. I am not yet clear is request scoped should be supported or if we
need a wider scope because of JMS protocol)


> Or is this not how the feature is intended?
>
> Kind regards,
> Arjan Tijms
>
>
>
>
> >
> > For client side having a custom qualifier supporting placeholding - a bit
> > like jbatch for system properties - would be nice and would allow to skip
> > JNDI which means enabling SE usage as well.
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau |  Blog | Github | LinkedIn | Tomitriber
> >
> > 2015-08-25 15:51 GMT+02:00 Nigel Deakin <nigel.deakin at oracle.com>:
> >>
> >> On 24/08/2015 21:24, John D. Ament wrote:
> >> >
> >> > Hi Nigel!
> >> >
> >> > Glad to hear from you.  Was wondering, is there a way to manually
> >> > register listeners?
> >>
> >> The current proposal is is for the bean to start listening just as soon
> as
> >> it is created (by CDI), and for it to stop
> >> listening just before it is destroyed (by CDI).
> >>
> >> As you suggesting that CDI would create the listener, but the
> application
> >> would call some method to tell it to start
> >> listening? or did you have something else in mind?
> >>
> >>  > It would be great if this could
> >> > be leveraged in a CDI SE environment as well as EE environment.
> >>
> >> I see that work is underway for CDI 2.0 to define how CDI might work in
> a
> >> Java SE environment. I don't see why a similar
> >> portable extension could not be created for use in Java SE. Since there
> >> would be no need to support Java EE behaviour
> >> such as transactions this could be built directly on top of the JMS
> >> provider's Java SE client. No need to use a resource
> >> adapter. However since the @JMSListener and @JMSConnectionFactory
> >> annotations use JNDI there would be a need to be a way
> >> to specify which JNDI InitialContext to use. I'm not proposing any of
> this
> >> at the moment, but it might perhaps be
> >> something that we (the JMS expert group) could consider later on as a
> >> optional part of JMS 2.1.
> >>
> >> There's also the Java EE application client to consider.
> >>
> >> Nigel
> >>
> >> _______________________________________________
> >> 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/20150825/3bffc2ec/attachment-0001.html 

From arjan.tijms at gmail.com  Tue Aug 25 11:22:22 2015
From: arjan.tijms at gmail.com (arjan tijms)
Date: Tue, 25 Aug 2015 17:22:22 +0200
Subject: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean in a
 Java EE application to listen for JMS messages
In-Reply-To: <CACLE=7PN+Xg+E5bBcwK5ZrWMwdO7vYNXKyDAB62A5huejTow2g@mail.gmail.com>
References: <55DB4692.7040304@oracle.com>
	<CA+ZZq9_Brvtks=jxQ1TbtXMNm+ab3w3GZfG-2sGQYeMK2mu2jA@mail.gmail.com>
	<55DB74E7.4080609@oracle.com>
	<CAOqetn9XTi0zSHMs9y_c3-XT1ghwTxog03BKwb+4=Jw3aPbPWg@mail.gmail.com>
	<55DC72D0.5090608@oracle.com>
	<CACLE=7Ne_okSRKHa74WGAnZCzGy8ds=m=L_ArWWVzyxc1-LA0g@mail.gmail.com>
	<CAE=-AhBOCz=iUBg9u7XQqWLR4vrw8e7aTw89P5_gqzUVA8thoQ@mail.gmail.com>
	<CACLE=7PN+Xg+E5bBcwK5ZrWMwdO7vYNXKyDAB62A5huejTow2g@mail.gmail.com>
Message-ID: <CAE=-AhDYhWYgv3DLo7ROmguG9o3DcprgMZ0P1RqwnvyiWWby1g@mail.gmail.com>

Hi,

On Tue, Aug 25, 2015 at 4:43 PM, Romain Manni-Bucau
<rmannibucau at gmail.com> wrote:
> CDI not sure but CDI implementations can for sure find the instances, that
> said I hope it will be forbidden and that only scopes linked the a message
> context (ie app scoped, maybe singleton, dependent and jms scopes would be
> allowed.

This was one of my biggest questions when reading the proposal. It now
explicitly mentions @RequestScoped beans
(https://java.net/projects/jms-spec/pages/CDIBeansAsJMSListeners#CDI_managed_listener_bean_with_request_scope).

With the proposed mechanism where a bean instance itself (invisibly)
connects to the location from where the JMS messages originate, this
would be somewhat doable, but it's not exactly how CDI events normally
work.

> I am not yet clear is request scoped should be supported or if we
> need a wider scope because of JMS protocol)

That's a good question.

Kind regards,
Arjan Tijms



>
>>
>> Or is this not how the feature is intended?
>>
>> Kind regards,
>> Arjan Tijms
>>
>>
>>
>>
>> >
>> > For client side having a custom qualifier supporting placeholding - a
>> > bit
>> > like jbatch for system properties - would be nice and would allow to
>> > skip
>> > JNDI which means enabling SE usage as well.
>> >
>> >
>> > Romain Manni-Bucau
>> > @rmannibucau |  Blog | Github | LinkedIn | Tomitriber
>> >
>> > 2015-08-25 15:51 GMT+02:00 Nigel Deakin <nigel.deakin at oracle.com>:
>> >>
>> >> On 24/08/2015 21:24, John D. Ament wrote:
>> >> >
>> >> > Hi Nigel!
>> >> >
>> >> > Glad to hear from you.  Was wondering, is there a way to manually
>> >> > register listeners?
>> >>
>> >> The current proposal is is for the bean to start listening just as soon
>> >> as
>> >> it is created (by CDI), and for it to stop
>> >> listening just before it is destroyed (by CDI).
>> >>
>> >> As you suggesting that CDI would create the listener, but the
>> >> application
>> >> would call some method to tell it to start
>> >> listening? or did you have something else in mind?
>> >>
>> >>  > It would be great if this could
>> >> > be leveraged in a CDI SE environment as well as EE environment.
>> >>
>> >> I see that work is underway for CDI 2.0 to define how CDI might work in
>> >> a
>> >> Java SE environment. I don't see why a similar
>> >> portable extension could not be created for use in Java SE. Since there
>> >> would be no need to support Java EE behaviour
>> >> such as transactions this could be built directly on top of the JMS
>> >> provider's Java SE client. No need to use a resource
>> >> adapter. However since the @JMSListener and @JMSConnectionFactory
>> >> annotations use JNDI there would be a need to be a way
>> >> to specify which JNDI InitialContext to use. I'm not proposing any of
>> >> this
>> >> at the moment, but it might perhaps be
>> >> something that we (the JMS expert group) could consider later on as a
>> >> optional part of JMS 2.1.
>> >>
>> >> There's also the Java EE application client to consider.
>> >>
>> >> Nigel
>> >>
>> >> _______________________________________________
>> >> 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.
>
>

From john.d.ament at gmail.com  Tue Aug 25 11:31:12 2015
From: john.d.ament at gmail.com (John D. Ament)
Date: Tue, 25 Aug 2015 15:31:12 +0000
Subject: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean in a
 Java EE application to listen for JMS messages
In-Reply-To: <55DC72D0.5090608@oracle.com>
References: <55DB4692.7040304@oracle.com>
	<CA+ZZq9_Brvtks=jxQ1TbtXMNm+ab3w3GZfG-2sGQYeMK2mu2jA@mail.gmail.com>
	<55DB74E7.4080609@oracle.com>
	<CAOqetn9XTi0zSHMs9y_c3-XT1ghwTxog03BKwb+4=Jw3aPbPWg@mail.gmail.com>
	<55DC72D0.5090608@oracle.com>
Message-ID: <CAOqetn-rUz=7F+oeymXrxH=OHMRzXC+9-n3LcsHnDQ4_Kq8Lyg@mail.gmail.com>

On Tue, Aug 25, 2015 at 9:51 AM Nigel Deakin <nigel.deakin at oracle.com>
wrote:

> On 24/08/2015 21:24, John D. Ament wrote:
> >
> > Hi Nigel!
> >
> > Glad to hear from you.  Was wondering, is there a way to manually
> register listeners?
>
> The current proposal is is for the bean to start listening just as soon as
> it is created (by CDI), and for it to stop
> listening just before it is destroyed (by CDI).
>
> As you suggesting that CDI would create the listener, but the application
> would call some method to tell it to start
> listening? or did you have something else in mind?
>


Hmm, this would mean that only app scoped beans would apply?
It might be better to scan for the annotations and use that to start up the
listener?


>
>  > It would be great if this could
> > be leveraged in a CDI SE environment as well as EE environment.
>
> I see that work is underway for CDI 2.0 to define how CDI might work in a
> Java SE environment. I don't see why a similar
> portable extension could not be created for use in Java SE. Since there
> would be no need to support Java EE behaviour
> such as transactions this could be built directly on top of the JMS
> provider's Java SE client. No need to use a resource
> adapter. However since the @JMSListener and @JMSConnectionFactory
> annotations use JNDI there would be a need to be a way
> to specify which JNDI InitialContext to use. I'm not proposing any of this
> at the moment, but it might perhaps be
> something that we (the JMS expert group) could consider later on as a
> optional part of JMS 2.1.
>
> There's also the Java EE application client to consider.
>
> Nigel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150825/39c57995/attachment.html 

From rmannibucau at gmail.com  Tue Aug 25 11:35:12 2015
From: rmannibucau at gmail.com (Romain Manni-Bucau)
Date: Tue, 25 Aug 2015 17:35:12 +0200
Subject: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean in a
 Java EE application to listen for JMS messages
In-Reply-To: <CAOqetn-rUz=7F+oeymXrxH=OHMRzXC+9-n3LcsHnDQ4_Kq8Lyg@mail.gmail.com>
References: <55DB4692.7040304@oracle.com>
	<CA+ZZq9_Brvtks=jxQ1TbtXMNm+ab3w3GZfG-2sGQYeMK2mu2jA@mail.gmail.com>
	<55DB74E7.4080609@oracle.com>
	<CAOqetn9XTi0zSHMs9y_c3-XT1ghwTxog03BKwb+4=Jw3aPbPWg@mail.gmail.com>
	<55DC72D0.5090608@oracle.com>
	<CAOqetn-rUz=7F+oeymXrxH=OHMRzXC+9-n3LcsHnDQ4_Kq8Lyg@mail.gmail.com>
Message-ID: <CACLE=7NZ=kubwHTh5m7JWtipzmRNbQQBQNeT3LxvXqpDs3Y0RA@mail.gmail.com>

2015-08-25 17:31 GMT+02:00 John D. Ament <john.d.ament at gmail.com>:

>
>
> On Tue, Aug 25, 2015 at 9:51 AM Nigel Deakin <nigel.deakin at oracle.com>
> wrote:
>
>> On 24/08/2015 21:24, John D. Ament wrote:
>> >
>> > Hi Nigel!
>> >
>> > Glad to hear from you.  Was wondering, is there a way to manually
>> register listeners?
>>
>> The current proposal is is for the bean to start listening just as soon
>> as it is created (by CDI), and for it to stop
>> listening just before it is destroyed (by CDI).
>>
>> As you suggesting that CDI would create the listener, but the application
>> would call some method to tell it to start
>> listening? or did you have something else in mind?
>>
>
>
> Hmm, this would mean that only app scoped beans would apply?
> It might be better to scan for the annotations and use that to start up
> the listener?
>
>

Does it mean anything to have a request scope or session scope listener? I
see technically how it can be done but I dont see any case needing it but I
feel it can hurt a lot to support it for anything else than PoC - ie in
prod, no?


>
>>  > It would be great if this could
>> > be leveraged in a CDI SE environment as well as EE environment.
>>
>> I see that work is underway for CDI 2.0 to define how CDI might work in a
>> Java SE environment. I don't see why a similar
>> portable extension could not be created for use in Java SE. Since there
>> would be no need to support Java EE behaviour
>> such as transactions this could be built directly on top of the JMS
>> provider's Java SE client. No need to use a resource
>> adapter. However since the @JMSListener and @JMSConnectionFactory
>> annotations use JNDI there would be a need to be a way
>> to specify which JNDI InitialContext to use. I'm not proposing any of
>> this at the moment, but it might perhaps be
>> something that we (the JMS expert group) could consider later on as a
>> optional part of JMS 2.1.
>>
>> There's also the Java EE application client to consider.
>>
>> Nigel
>>
>>
> _______________________________________________
> 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/20150825/91e1ca8a/attachment.html 

From nigel.deakin at oracle.com  Tue Aug 25 12:25:46 2015
From: nigel.deakin at oracle.com (Nigel Deakin)
Date: Tue, 25 Aug 2015 17:25:46 +0100
Subject: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean in a
 Java EE application to listen for JMS messages
In-Reply-To: <CAOqetn-rUz=7F+oeymXrxH=OHMRzXC+9-n3LcsHnDQ4_Kq8Lyg@mail.gmail.com>
References: <55DB4692.7040304@oracle.com>
	<CA+ZZq9_Brvtks=jxQ1TbtXMNm+ab3w3GZfG-2sGQYeMK2mu2jA@mail.gmail.com>
	<55DB74E7.4080609@oracle.com>
	<CAOqetn9XTi0zSHMs9y_c3-XT1ghwTxog03BKwb+4=Jw3aPbPWg@mail.gmail.com>
	<55DC72D0.5090608@oracle.com>
	<CAOqetn-rUz=7F+oeymXrxH=OHMRzXC+9-n3LcsHnDQ4_Kq8Lyg@mail.gmail.com>
Message-ID: <55DC970A.4050607@oracle.com>

John,

On 25/08/2015 16:31, John D. Ament wrote:
>
>
> On Tue, Aug 25, 2015 at 9:51 AM Nigel Deakin <nigel.deakin at oracle.com <mailto:nigel.deakin at oracle.com>> wrote:
>
>     On 24/08/2015 21:24, John D. Ament wrote:
>      >
>      > Hi Nigel!
>      >
>      > Glad to hear from you.  Was wondering, is there a way to manually register listeners?
>
>     The current proposal is is for the bean to start listening just as soon as it is created (by CDI), and for it to stop
>     listening just before it is destroyed (by CDI).
>
>     As you suggesting that CDI would create the listener, but the application would call some method to tell it to start
>     listening? or did you have something else in mind?
>
>
>
> Hmm, this would mean that only app scoped beans would apply?
> It might be better to scan for the annotations and use that to start up the listener?

I was just making a guess at what you might had in mind by "manually register listeners".

Nigel


>
>       > It would be great if this could
>      > be leveraged in a CDI SE environment as well as EE environment.
>
>     I see that work is underway for CDI 2.0 to define how CDI might work in a Java SE environment. I don't see why a similar
>     portable extension could not be created for use in Java SE. Since there would be no need to support Java EE behaviour
>     such as transactions this could be built directly on top of the JMS provider's Java SE client. No need to use a resource
>     adapter. However since the @JMSListener and @JMSConnectionFactory annotations use JNDI there would be a need to be a way
>     to specify which JNDI InitialContext to use. I'm not proposing any of this at the moment, but it might perhaps be
>     something that we (the JMS expert group) could consider later on as a optional part of JMS 2.1.
>
>     There's also the Java EE application client to consider.
>
>     Nigel
>

From rmannibucau at gmail.com  Tue Aug 25 12:35:18 2015
From: rmannibucau at gmail.com (Romain Manni-Bucau)
Date: Tue, 25 Aug 2015 18:35:18 +0200
Subject: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean in a
 Java EE application to listen for JMS messages
In-Reply-To: <55DC970A.4050607@oracle.com>
References: <55DB4692.7040304@oracle.com>
	<CA+ZZq9_Brvtks=jxQ1TbtXMNm+ab3w3GZfG-2sGQYeMK2mu2jA@mail.gmail.com>
	<55DB74E7.4080609@oracle.com>
	<CAOqetn9XTi0zSHMs9y_c3-XT1ghwTxog03BKwb+4=Jw3aPbPWg@mail.gmail.com>
	<55DC72D0.5090608@oracle.com>
	<CAOqetn-rUz=7F+oeymXrxH=OHMRzXC+9-n3LcsHnDQ4_Kq8Lyg@mail.gmail.com>
	<55DC970A.4050607@oracle.com>
Message-ID: <CACLE=7PEBZomd7tuJby7F1zcrdr_sEFif=z1xgVMPPCZMXY=0g@mail.gmail.com>

well was thinking to both but I see it really nice to not rely only on
annotation - and aligned with most specs - since sometimes you just want to
either be able to rely on a loop or a custom config to register your
listeners. Annotations are too rigid for such cases.


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com>

2015-08-25 18:25 GMT+02:00 Nigel Deakin <nigel.deakin at oracle.com>:

> John,
>
> On 25/08/2015 16:31, John D. Ament wrote:
> >
> >
> > On Tue, Aug 25, 2015 at 9:51 AM Nigel Deakin <nigel.deakin at oracle.com
> <mailto:nigel.deakin at oracle.com>> wrote:
> >
> >     On 24/08/2015 21:24, John D. Ament wrote:
> >      >
> >      > Hi Nigel!
> >      >
> >      > Glad to hear from you.  Was wondering, is there a way to manually
> register listeners?
> >
> >     The current proposal is is for the bean to start listening just as
> soon as it is created (by CDI), and for it to stop
> >     listening just before it is destroyed (by CDI).
> >
> >     As you suggesting that CDI would create the listener, but the
> application would call some method to tell it to start
> >     listening? or did you have something else in mind?
> >
> >
> >
> > Hmm, this would mean that only app scoped beans would apply?
> > It might be better to scan for the annotations and use that to start up
> the listener?
>
> I was just making a guess at what you might had in mind by "manually
> register listeners".
>
> Nigel
>
>
> >
> >       > It would be great if this could
> >      > be leveraged in a CDI SE environment as well as EE environment.
> >
> >     I see that work is underway for CDI 2.0 to define how CDI might work
> in a Java SE environment. I don't see why a similar
> >     portable extension could not be created for use in Java SE. Since
> there would be no need to support Java EE behaviour
> >     such as transactions this could be built directly on top of the JMS
> provider's Java SE client. No need to use a resource
> >     adapter. However since the @JMSListener and @JMSConnectionFactory
> annotations use JNDI there would be a need to be a way
> >     to specify which JNDI InitialContext to use. I'm not proposing any
> of this at the moment, but it might perhaps be
> >     something that we (the JMS expert group) could consider later on as
> a optional part of JMS 2.1.
> >
> >     There's also the Java EE application client to consider.
> >
> >     Nigel
> >
> _______________________________________________
> 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/20150825/931c644c/attachment-0001.html 

From nigel.deakin at oracle.com  Tue Aug 25 12:58:09 2015
From: nigel.deakin at oracle.com (Nigel Deakin)
Date: Tue, 25 Aug 2015 17:58:09 +0100
Subject: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean in a
 Java EE application to listen for JMS messages
In-Reply-To: <CACLE=7PEBZomd7tuJby7F1zcrdr_sEFif=z1xgVMPPCZMXY=0g@mail.gmail.com>
References: <55DB4692.7040304@oracle.com>
	<CA+ZZq9_Brvtks=jxQ1TbtXMNm+ab3w3GZfG-2sGQYeMK2mu2jA@mail.gmail.com>
	<55DB74E7.4080609@oracle.com>
	<CAOqetn9XTi0zSHMs9y_c3-XT1ghwTxog03BKwb+4=Jw3aPbPWg@mail.gmail.com>
	<55DC72D0.5090608@oracle.com>
	<CAOqetn-rUz=7F+oeymXrxH=OHMRzXC+9-n3LcsHnDQ4_Kq8Lyg@mail.gmail.com>
	<55DC970A.4050607@oracle.com>
	<CACLE=7PEBZomd7tuJby7F1zcrdr_sEFif=z1xgVMPPCZMXY=0g@mail.gmail.com>
Message-ID: <55DC9EA1.408@oracle.com>

On 25/08/2015 17:35, Romain Manni-Bucau wrote:
> well was thinking to both but I see it really nice to not rely only on annotation - and aligned with most specs - since
> sometimes you just want to either be able to rely on a loop or a custom config to register your listeners. Annotations
> are too rigid for such cases.

Obviously, if users don't want to use CDI (or MDBs, which are also declarative), then they would use the normal JMS API. 
The existing API to register an async message listener isn't good enough, and we may improve it in JMS 2.1, but that's 
not something that I'd want to bother the people on cdi-dev with.

Nigel

From rmannibucau at gmail.com  Tue Aug 25 13:03:58 2015
From: rmannibucau at gmail.com (Romain Manni-Bucau)
Date: Tue, 25 Aug 2015 19:03:58 +0200
Subject: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean in a
 Java EE application to listen for JMS messages
In-Reply-To: <55DC9EA1.408@oracle.com>
References: <55DB4692.7040304@oracle.com>
	<CA+ZZq9_Brvtks=jxQ1TbtXMNm+ab3w3GZfG-2sGQYeMK2mu2jA@mail.gmail.com>
	<55DB74E7.4080609@oracle.com>
	<CAOqetn9XTi0zSHMs9y_c3-XT1ghwTxog03BKwb+4=Jw3aPbPWg@mail.gmail.com>
	<55DC72D0.5090608@oracle.com>
	<CAOqetn-rUz=7F+oeymXrxH=OHMRzXC+9-n3LcsHnDQ4_Kq8Lyg@mail.gmail.com>
	<55DC970A.4050607@oracle.com>
	<CACLE=7PEBZomd7tuJby7F1zcrdr_sEFif=z1xgVMPPCZMXY=0g@mail.gmail.com>
	<55DC9EA1.408@oracle.com>
Message-ID: <CACLE=7ML=yNsn2vRW6MX_2cNjAMedGnd2bjAPjg=7KLRn6etvQ@mail.gmail.com>

Integrating it in CDI lifecycle through an event allow CDI users to still
use it in the right phase of the container boot so it is still important
IMO and avoid all users to have their own custom listener for it -
@Initialized(AppScoped.class). Also allow to enrich the API through the
event itself making things smoother IMO.


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com>

2015-08-25 18:58 GMT+02:00 Nigel Deakin <nigel.deakin at oracle.com>:

> On 25/08/2015 17:35, Romain Manni-Bucau wrote:
>
>> well was thinking to both but I see it really nice to not rely only on
>> annotation - and aligned with most specs - since
>> sometimes you just want to either be able to rely on a loop or a custom
>> config to register your listeners. Annotations
>> are too rigid for such cases.
>>
>
> Obviously, if users don't want to use CDI (or MDBs, which are also
> declarative), then they would use the normal JMS API. The existing API to
> register an async message listener isn't good enough, and we may improve it
> in JMS 2.1, but that's not something that I'd want to bother the people on
> cdi-dev with.
>
> Nigel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150825/27993d63/attachment.html 

From nigel.deakin at oracle.com  Tue Aug 25 13:07:12 2015
From: nigel.deakin at oracle.com (Nigel Deakin)
Date: Tue, 25 Aug 2015 18:07:12 +0100
Subject: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean in a
 Java EE application to listen for JMS messages
In-Reply-To: <CAE=-AhBBSPw1ZRdzSQOJm1aRKiTxKo0tBHagv8_bn9D=g2B+HQ@mail.gmail.com>
References: <55DB4692.7040304@oracle.com>
	<CA+ZZq9_Brvtks=jxQ1TbtXMNm+ab3w3GZfG-2sGQYeMK2mu2jA@mail.gmail.com>
	<55DB74E7.4080609@oracle.com>
	<CAE=-AhAd-dPbr1sAANiHQ4eD0BF2YA601Emk6+jk9fb_YOCgLQ@mail.gmail.com>
	<CAOqetn8mn0eWGWVo3AiwJZu_A4nDngsgzj3cjiSqVGUPx09UEA@mail.gmail.com>
	<CAE=-AhBBSPw1ZRdzSQOJm1aRKiTxKo0tBHagv8_bn9D=g2B+HQ@mail.gmail.com>
Message-ID: <55DCA0C0.9080900@oracle.com>

On 25/08/2015 12:38, arjan tijms wrote:
> On Tue, Aug 25, 2015 at 1:19 PM, John D. Ament <john.d.ament at gmail.com> wrote:
>> Technically speaking, I can have a bean like this:
>>
>> @ApplicationScoped
>> public class Foo {
>>      public void onStart(@Observes @initialized(ApplicationScoped.class)
>> Object obj) {
>>         // do some work here
>>      }
>> }
>>
>> That bean will get instantiated by the container, even if it doesn't have
>> any injection targets.
>
> Indeed, that's what I meant above with the reference to the
> @Initialized and @Destroyed annotations. With that construct a JMS
> Listener bean can be "started" without it having to be referenced from
> other code.

Arjan, John,

This looks very interesting. Does this work with any normal scope?

I was thinking of a hypothetical feature in which a application defines a @RequestScoped bean...

@RequestScoped
public class MyCDIBean21 {

    @JMSListener(lookup="java:global/java:global/Trades",type=JMSListener.Type.TOPIC )
    @JMSConnectionFactory("java:global/MyCF")
    @MessageSelector("ticker='ORCL'")
    public void processNewsItem(String newsItem) {
      ...
    }
  }

...but we want to avoid the need for the application to inject and lazily create an instance of the bean in each request.

Are you suggesting that if the user added:

    public void onStart(@Observes @initialized(RequestScoped.class) Object obj) {
       // do nothing here
    }

then every time a new request starts, this event is fired which causes an instance of the bean to be created for that 
request?

Nigel


From nigel.deakin at oracle.com  Tue Aug 25 13:10:21 2015
From: nigel.deakin at oracle.com (Nigel Deakin)
Date: Tue, 25 Aug 2015 18:10:21 +0100
Subject: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean in a
 Java EE application to listen for JMS messages
In-Reply-To: <CACLE=7ML=yNsn2vRW6MX_2cNjAMedGnd2bjAPjg=7KLRn6etvQ@mail.gmail.com>
References: <55DB4692.7040304@oracle.com>
	<CA+ZZq9_Brvtks=jxQ1TbtXMNm+ab3w3GZfG-2sGQYeMK2mu2jA@mail.gmail.com>
	<55DB74E7.4080609@oracle.com>
	<CAOqetn9XTi0zSHMs9y_c3-XT1ghwTxog03BKwb+4=Jw3aPbPWg@mail.gmail.com>
	<55DC72D0.5090608@oracle.com>
	<CAOqetn-rUz=7F+oeymXrxH=OHMRzXC+9-n3LcsHnDQ4_Kq8Lyg@mail.gmail.com>
	<55DC970A.4050607@oracle.com>
	<CACLE=7PEBZomd7tuJby7F1zcrdr_sEFif=z1xgVMPPCZMXY=0g@mail.gmail.com>
	<55DC9EA1.408@oracle.com>
	<CACLE=7ML=yNsn2vRW6MX_2cNjAMedGnd2bjAPjg=7KLRn6etvQ@mail.gmail.com>
Message-ID: <55DCA17D.9050602@oracle.com>

I'm sorry I don't understand you. I thought you were asking about an API which does not use annotation.

Nigel

On 25/08/2015 18:03, Romain Manni-Bucau wrote:
> Integrating it in CDI lifecycle through an event allow CDI users to still use it in the right phase of the container
> boot so it is still important IMO and avoid all users to have their own custom listener for it -
> @Initialized(AppScoped.class). Also allow to enrich the API through the event itself making things smoother IMO.
>
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> | Blog <http://rmannibucau.wordpress.com> | Github
> <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> <http://www.tomitribe.com>
>
> 2015-08-25 18:58 GMT+02:00 Nigel Deakin <nigel.deakin at oracle.com <mailto:nigel.deakin at oracle.com>>:
>
>     On 25/08/2015 17:35, Romain Manni-Bucau wrote:
>
>         well was thinking to both but I see it really nice to not rely only on annotation - and aligned with most specs
>         - since
>         sometimes you just want to either be able to rely on a loop or a custom config to register your listeners.
>         Annotations
>         are too rigid for such cases.
>
>
>     Obviously, if users don't want to use CDI (or MDBs, which are also declarative), then they would use the normal JMS
>     API. The existing API to register an async message listener isn't good enough, and we may improve it in JMS 2.1, but
>     that's not something that I'd want to bother the people on cdi-dev with.
>
>     Nigel
>
>

From nigel.deakin at oracle.com  Tue Aug 25 13:20:18 2015
From: nigel.deakin at oracle.com (Nigel Deakin)
Date: Tue, 25 Aug 2015 18:20:18 +0100
Subject: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean in a
 Java EE application to listen for JMS messages
In-Reply-To: <CAE=-AhAd-dPbr1sAANiHQ4eD0BF2YA601Emk6+jk9fb_YOCgLQ@mail.gmail.com>
References: <55DB4692.7040304@oracle.com>
	<CA+ZZq9_Brvtks=jxQ1TbtXMNm+ab3w3GZfG-2sGQYeMK2mu2jA@mail.gmail.com>
	<55DB74E7.4080609@oracle.com>
	<CAE=-AhAd-dPbr1sAANiHQ4eD0BF2YA601Emk6+jk9fb_YOCgLQ@mail.gmail.com>
Message-ID: <55DCA3D2.2040600@oracle.com>

On 25/08/2015 00:18, arjan tijms wrote:
> Hi,

Hi Arjan,

> On Mon, Aug 24, 2015 at 9:47 PM, Nigel Deakin <nigel.deakin at oracle.com> wrote:
>
>> If I understand things correctly, if this is a normal CDI bean then this
>> alone is not sufficient to cause an instance of the bean to be created.
>>
>> You also need to
>> (1) inject it into some other bean
>> (2) create that other bean and
>> (3) call a method on the MyListenerBean to trigger lazy initialisation.
>
> This is one way for sure, but one alternative worth mentioning is to
> eagerly instantiatie the scoped bean whenever its scope starts. For
> OmniFaces we have implemented a separate annotation for this for CDI
> 1.0, see http://showcase.omnifaces.org/cdi/Eager

Someone over on the JMS user alias told me about this yesterday. So that would avoid the need to call a method to 
trigger lazy initialisation on normal-scoped bean proxies. I presume the application still has to inject the bean.

If so then it sounds useful. Is it going to be included as a standard feature of CDI 2.0? I see someone has proposed 
https://issues.jboss.org/browse/CDI-473 .

Nigel



From rmannibucau at gmail.com  Tue Aug 25 13:33:42 2015
From: rmannibucau at gmail.com (Romain Manni-Bucau)
Date: Tue, 25 Aug 2015 19:33:42 +0200
Subject: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean in a
 Java EE application to listen for JMS messages
In-Reply-To: <55DCA17D.9050602@oracle.com>
References: <55DB4692.7040304@oracle.com>
	<CA+ZZq9_Brvtks=jxQ1TbtXMNm+ab3w3GZfG-2sGQYeMK2mu2jA@mail.gmail.com>
	<55DB74E7.4080609@oracle.com>
	<CAOqetn9XTi0zSHMs9y_c3-XT1ghwTxog03BKwb+4=Jw3aPbPWg@mail.gmail.com>
	<55DC72D0.5090608@oracle.com>
	<CAOqetn-rUz=7F+oeymXrxH=OHMRzXC+9-n3LcsHnDQ4_Kq8Lyg@mail.gmail.com>
	<55DC970A.4050607@oracle.com>
	<CACLE=7PEBZomd7tuJby7F1zcrdr_sEFif=z1xgVMPPCZMXY=0g@mail.gmail.com>
	<55DC9EA1.408@oracle.com>
	<CACLE=7ML=yNsn2vRW6MX_2cNjAMedGnd2bjAPjg=7KLRn6etvQ@mail.gmail.com>
	<55DCA17D.9050602@oracle.com>
Message-ID: <CACLE=7N8mNhvYh_g2W+D97zH4f5pKpH3a0sz1wDfJgdWu_scOg@mail.gmail.com>

2015-08-25 19:10 GMT+02:00 Nigel Deakin <nigel.deakin at oracle.com>:

> I'm sorry I don't understand you. I thought you were asking about an API
> which does not use annotation.
>
>
Both are needed (like websocket spec). Annotation one is nice for fully
business code and/or simple libs but relying on CDI allows to simplify the
wiring since you can reuse CDI beans under the hood ie have an implicit
connection factory if there is a single one etc which is not possible in
fully SE context.


> Nigel
>
> On 25/08/2015 18:03, Romain Manni-Bucau wrote:
>
>> Integrating it in CDI lifecycle through an event allow CDI users to still
>> use it in the right phase of the container
>> boot so it is still important IMO and avoid all users to have their own
>> custom listener for it -
>> @Initialized(AppScoped.class). Also allow to enrich the API through the
>> event itself making things smoother IMO.
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau <https://twitter.com/rmannibucau> | Blog <
>> http://rmannibucau.wordpress.com> | Github
>> <https://github.com/rmannibucau> | LinkedIn <
>> https://www.linkedin.com/in/rmannibucau> | Tomitriber
>> <http://www.tomitribe.com>
>>
>> 2015-08-25 18:58 GMT+02:00 Nigel Deakin <nigel.deakin at oracle.com <mailto:
>> nigel.deakin at oracle.com>>:
>>
>>     On 25/08/2015 17:35, Romain Manni-Bucau wrote:
>>
>>         well was thinking to both but I see it really nice to not rely
>> only on annotation - and aligned with most specs
>>         - since
>>         sometimes you just want to either be able to rely on a loop or a
>> custom config to register your listeners.
>>         Annotations
>>         are too rigid for such cases.
>>
>>
>>     Obviously, if users don't want to use CDI (or MDBs, which are also
>> declarative), then they would use the normal JMS
>>     API. The existing API to register an async message listener isn't
>> good enough, and we may improve it in JMS 2.1, but
>>     that's not something that I'd want to bother the people on cdi-dev
>> with.
>>
>>     Nigel
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150825/c96e90bf/attachment-0001.html 

From arjan.tijms at gmail.com  Tue Aug 25 16:53:21 2015
From: arjan.tijms at gmail.com (arjan tijms)
Date: Tue, 25 Aug 2015 22:53:21 +0200
Subject: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean in a
 Java EE application to listen for JMS messages
In-Reply-To: <55DCA0C0.9080900@oracle.com>
References: <55DB4692.7040304@oracle.com>
	<CA+ZZq9_Brvtks=jxQ1TbtXMNm+ab3w3GZfG-2sGQYeMK2mu2jA@mail.gmail.com>
	<55DB74E7.4080609@oracle.com>
	<CAE=-AhAd-dPbr1sAANiHQ4eD0BF2YA601Emk6+jk9fb_YOCgLQ@mail.gmail.com>
	<CAOqetn8mn0eWGWVo3AiwJZu_A4nDngsgzj3cjiSqVGUPx09UEA@mail.gmail.com>
	<CAE=-AhBBSPw1ZRdzSQOJm1aRKiTxKo0tBHagv8_bn9D=g2B+HQ@mail.gmail.com>
	<55DCA0C0.9080900@oracle.com>
Message-ID: <CAE=-AhCnTyS-ZVAfT9k2jDK=k6QHW4ShUab_Vt+e6WmBN76gWg@mail.gmail.com>

Hi,

On Tue, Aug 25, 2015 at 7:07 PM, Nigel Deakin <nigel.deakin at oracle.com> wrote:
> On 25/08/2015 12:38, arjan tijms wrote:
> This looks very interesting. Does this work with any normal scope?

Yes, all normal scopes that are available in standard Java EE support
this as far as I know.

There's the small caveat that CDI itself doesn't know about this
automatically for any custom normal scope. That implementation of such
scope (via a Context) must explicitly throw these events.

For example, this is what Mojarra does for the @FlowScoped implementation:

https://github.com/omnifaces/mojarra/blob/master/jsf-ri/src/main/java/com/sun/faces/flow/FlowCDIEventFireHelperImpl.java

Which is fired when the scope starts here:
https://github.com/omnifaces/mojarra/blob/master/jsf-ri/src/main/java/com/sun/faces/flow/FlowCDIContext.java#L431

(the exact same code is used for @ViewScoped in Mojarra as well)


> then every time a new request starts, this event is fired which causes an
> instance of the bean to be created for that request?

Yes, that is what this does ;)

Kind regards,
Arjan Tijms

From arjan.tijms at gmail.com  Tue Aug 25 17:16:27 2015
From: arjan.tijms at gmail.com (arjan tijms)
Date: Tue, 25 Aug 2015 23:16:27 +0200
Subject: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean in a
 Java EE application to listen for JMS messages
In-Reply-To: <55DCA3D2.2040600@oracle.com>
References: <55DB4692.7040304@oracle.com>
	<CA+ZZq9_Brvtks=jxQ1TbtXMNm+ab3w3GZfG-2sGQYeMK2mu2jA@mail.gmail.com>
	<55DB74E7.4080609@oracle.com>
	<CAE=-AhAd-dPbr1sAANiHQ4eD0BF2YA601Emk6+jk9fb_YOCgLQ@mail.gmail.com>
	<55DCA3D2.2040600@oracle.com>
Message-ID: <CAE=-AhCugW3jWD1FnghFzAkiuBL6-Kg2ROKa2FCJHfcd2E2+DQ@mail.gmail.com>

Hi,

On Tue, Aug 25, 2015 at 7:20 PM, Nigel Deakin <nigel.deakin at oracle.com> wrote:
> Someone over on the JMS user alias told me about this yesterday. So that
> would avoid the need to call a method to trigger lazy initialisation on
> normal-scoped bean proxies. I presume the application still has to inject
> the bean.

The bean does not necessarily have to be injected at any point.

With @Eager it will be activated and its @PostConstruct method will be
invoked in case it hadn't been referenced before (which in case of
@Eager is unlikely, as it instantiates very early, but still
theoretically possible).

The bean can of course still be injected or otherwise referenced later
within the same scope, but as mentioned this is not required.

So for example if you have OmniFaces on your classpath and then only
the following bean in an application:

@Eager
@ApplicationScoped
public class MyEagerApplicationScopedBean {

     @PostConstruct
     public void init() {
         System.out.println("Application scoped init!");
     }
 }

Then you'll see "Application scoped init!" being printed in your
server log when you deploy that application. No other code is needed.


> If so then it sounds useful. Is it going to be included as a standard
> feature of CDI 2.0? I see someone has proposed
> https://issues.jboss.org/browse/CDI-473 .

As the issue already mentions, this is possible with current day CDI
already. The proposal may arguably make it a little more concise and a
little less verbose. An eager attribute on the scope looks like a
quite minimal and elegant solution. Additionally it may make sense for
some scopes to restrict for which "IDs' it's eagerly instantiated
(e.g. paths for @RequestScoped, view IDs for @ViewScoped, flow IDs for
@FlowScoped, etc).

A new @Startup seems more like a very specific usage of the eager
attribute, namely for @ApplicationScoped (or Singleton?) beans.

Kind regards,
Arjan





>
> Nigel
>
>

From rmannibucau at gmail.com  Wed Aug 26 04:11:21 2015
From: rmannibucau at gmail.com (Romain Manni-Bucau)
Date: Wed, 26 Aug 2015 10:11:21 +0200
Subject: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean in a
 Java EE application to listen for JMS messages
In-Reply-To: <CAE=-AhCnTyS-ZVAfT9k2jDK=k6QHW4ShUab_Vt+e6WmBN76gWg@mail.gmail.com>
References: <55DB4692.7040304@oracle.com>
	<CA+ZZq9_Brvtks=jxQ1TbtXMNm+ab3w3GZfG-2sGQYeMK2mu2jA@mail.gmail.com>
	<55DB74E7.4080609@oracle.com>
	<CAE=-AhAd-dPbr1sAANiHQ4eD0BF2YA601Emk6+jk9fb_YOCgLQ@mail.gmail.com>
	<CAOqetn8mn0eWGWVo3AiwJZu_A4nDngsgzj3cjiSqVGUPx09UEA@mail.gmail.com>
	<CAE=-AhBBSPw1ZRdzSQOJm1aRKiTxKo0tBHagv8_bn9D=g2B+HQ@mail.gmail.com>
	<55DCA0C0.9080900@oracle.com>
	<CAE=-AhCnTyS-ZVAfT9k2jDK=k6QHW4ShUab_Vt+e6WmBN76gWg@mail.gmail.com>
Message-ID: <CACLE=7PQaDz4fmXW2f39PN_+zdXioDfAu987OSuaxodBZx=SyQ@mail.gmail.com>

2015-08-25 22:53 GMT+02:00 arjan tijms <arjan.tijms at gmail.com>:

> Hi,
>
> On Tue, Aug 25, 2015 at 7:07 PM, Nigel Deakin <nigel.deakin at oracle.com>
> wrote:
> > On 25/08/2015 12:38, arjan tijms wrote:
> > This looks very interesting. Does this work with any normal scope?
>
> Yes, all normal scopes that are available in standard Java EE support
> this as far as I know.
>
>
Events are not mandatory for a normal scope - at least was the case in 1.2
- so JMS can't rely on it for custom normal scopes.


> There's the small caveat that CDI itself doesn't know about this
> automatically for any custom normal scope. That implementation of such
> scope (via a Context) must explicitly throw these events.
>
> For example, this is what Mojarra does for the @FlowScoped implementation:
>
>
> https://github.com/omnifaces/mojarra/blob/master/jsf-ri/src/main/java/com/sun/faces/flow/FlowCDIEventFireHelperImpl.java
>
> Which is fired when the scope starts here:
>
> https://github.com/omnifaces/mojarra/blob/master/jsf-ri/src/main/java/com/sun/faces/flow/FlowCDIContext.java#L431
>
> (the exact same code is used for @ViewScoped in Mojarra as well)
>
>
> > then every time a new request starts, this event is fired which causes an
> > instance of the bean to be created for that request?
>
> Yes, that is what this does ;)
>
> Kind regards,
> Arjan Tijms
> _______________________________________________
> 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/20150826/c1f05f1c/attachment.html 

From nigel.deakin at oracle.com  Wed Aug 26 05:07:01 2015
From: nigel.deakin at oracle.com (Nigel Deakin)
Date: Wed, 26 Aug 2015 10:07:01 +0100
Subject: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean in a
 Java EE application to listen for JMS messages
In-Reply-To: <CACLE=7N8mNhvYh_g2W+D97zH4f5pKpH3a0sz1wDfJgdWu_scOg@mail.gmail.com>
References: <55DB4692.7040304@oracle.com>
	<CA+ZZq9_Brvtks=jxQ1TbtXMNm+ab3w3GZfG-2sGQYeMK2mu2jA@mail.gmail.com>
	<55DB74E7.4080609@oracle.com>
	<CAOqetn9XTi0zSHMs9y_c3-XT1ghwTxog03BKwb+4=Jw3aPbPWg@mail.gmail.com>
	<55DC72D0.5090608@oracle.com>
	<CAOqetn-rUz=7F+oeymXrxH=OHMRzXC+9-n3LcsHnDQ4_Kq8Lyg@mail.gmail.com>
	<55DC970A.4050607@oracle.com>
	<CACLE=7PEBZomd7tuJby7F1zcrdr_sEFif=z1xgVMPPCZMXY=0g@mail.gmail.com>
	<55DC9EA1.408@oracle.com>
	<CACLE=7ML=yNsn2vRW6MX_2cNjAMedGnd2bjAPjg=7KLRn6etvQ@mail.gmail.com>
	<55DCA17D.9050602@oracle.com>
	<CACLE=7N8mNhvYh_g2W+D97zH4f5pKpH3a0sz1wDfJgdWu_scOg@mail.gmail.com>
Message-ID: <55DD81B5.9040407@oracle.com>

(Tidying up the top-posting...)

Romain Manni-Bucau:
 > ...I see it really nice to not rely only on annotation - and aligned with
 > most specs - since sometimes you just want to either be able to rely on a
 > loop or a custom config to register your listeners. Annotations are too
 > rigid for such cases.

Nigel:
 > Obviously, if users don't want to use CDI (or MDBs, which are also
 > declarative), then they would use the  normal JMS API. The existing
 > API to register an async message listener isn't good enough,
 > and we may improve it in JMS 2.1, but that's not something that
 > I'd want to bother the people on cdi-dev with.

Romain Manni-Bucau:
 > Integrating it in CDI lifecycle through an event allow CDI users to still
 > use it in the right phase of the container boot so it is still important
 > IMO and avoid all users to have their own custom listener for it -
 > @Initialized(AppScoped.class). Also allow to enrich the API through the event
 > itself making things smoother IMO.

Nigel:
 > I'm sorry I don't understand you.
 > I thought you were asking about an API which does not use annotation.

Romain Manni-Bucau:
 > Both are needed (like websocket spec). Annotation one is nice for fully business
 > code and/or simple libs but relying on CDI allows to simplify the wiring since you
 > can reuse CDI beans under the hood ie have an implicit connection factory if
 > there is a single one etc which is not possible in fully SE context.

Can you explain the distinction you're making here? You seem to be suggesting two alternatives, using "annotation" and 
"relying on CDI". What would an application which uses CDI but which doesn't use annotation look like?

Nigel

From arjan.tijms at gmail.com  Wed Aug 26 05:07:46 2015
From: arjan.tijms at gmail.com (arjan tijms)
Date: Wed, 26 Aug 2015 11:07:46 +0200
Subject: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean in a
 Java EE application to listen for JMS messages
In-Reply-To: <CACLE=7PQaDz4fmXW2f39PN_+zdXioDfAu987OSuaxodBZx=SyQ@mail.gmail.com>
References: <55DB4692.7040304@oracle.com>
	<CA+ZZq9_Brvtks=jxQ1TbtXMNm+ab3w3GZfG-2sGQYeMK2mu2jA@mail.gmail.com>
	<55DB74E7.4080609@oracle.com>
	<CAE=-AhAd-dPbr1sAANiHQ4eD0BF2YA601Emk6+jk9fb_YOCgLQ@mail.gmail.com>
	<CAOqetn8mn0eWGWVo3AiwJZu_A4nDngsgzj3cjiSqVGUPx09UEA@mail.gmail.com>
	<CAE=-AhBBSPw1ZRdzSQOJm1aRKiTxKo0tBHagv8_bn9D=g2B+HQ@mail.gmail.com>
	<55DCA0C0.9080900@oracle.com>
	<CAE=-AhCnTyS-ZVAfT9k2jDK=k6QHW4ShUab_Vt+e6WmBN76gWg@mail.gmail.com>
	<CACLE=7PQaDz4fmXW2f39PN_+zdXioDfAu987OSuaxodBZx=SyQ@mail.gmail.com>
Message-ID: <CAE=-AhBcnrC6xOdRSXtBdg-7JgfcKcGQMgtow4V0PPVspKxr_Q@mail.gmail.com>

Hi,

On Wed, Aug 26, 2015 at 10:11 AM, Romain Manni-Bucau
<rmannibucau at gmail.com> wrote:
>> Yes, all normal scopes that are available in standard Java EE support
>> this as far as I know.
>>
>
> Events are not mandatory for a normal scope - at least was the case in 1.2 -
> so JMS can't rely on it for custom normal scopes.

Absolutely true, but that was exactly what I said ;)

All Java EE provided scopes throw the events. For CDI, this is
mandated by the spec (6.7) for @RequestScoped, @SessionScoped,
@ApplicationScoped and @ConversationScoped.

For JSF, at least Mojarra, @FlowScoped and @ViewScope do so too. I
have to double check whether this is actually in the spec for those
last two and if not see if we can update it for 2.3.

Kind regards,
Arjan Tijms

From rmannibucau at gmail.com  Wed Aug 26 05:09:30 2015
From: rmannibucau at gmail.com (Romain Manni-Bucau)
Date: Wed, 26 Aug 2015 11:09:30 +0200
Subject: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean in a
 Java EE application to listen for JMS messages
In-Reply-To: <CAE=-AhBcnrC6xOdRSXtBdg-7JgfcKcGQMgtow4V0PPVspKxr_Q@mail.gmail.com>
References: <55DB4692.7040304@oracle.com>
	<CA+ZZq9_Brvtks=jxQ1TbtXMNm+ab3w3GZfG-2sGQYeMK2mu2jA@mail.gmail.com>
	<55DB74E7.4080609@oracle.com>
	<CAE=-AhAd-dPbr1sAANiHQ4eD0BF2YA601Emk6+jk9fb_YOCgLQ@mail.gmail.com>
	<CAOqetn8mn0eWGWVo3AiwJZu_A4nDngsgzj3cjiSqVGUPx09UEA@mail.gmail.com>
	<CAE=-AhBBSPw1ZRdzSQOJm1aRKiTxKo0tBHagv8_bn9D=g2B+HQ@mail.gmail.com>
	<55DCA0C0.9080900@oracle.com>
	<CAE=-AhCnTyS-ZVAfT9k2jDK=k6QHW4ShUab_Vt+e6WmBN76gWg@mail.gmail.com>
	<CACLE=7PQaDz4fmXW2f39PN_+zdXioDfAu987OSuaxodBZx=SyQ@mail.gmail.com>
	<CAE=-AhBcnrC6xOdRSXtBdg-7JgfcKcGQMgtow4V0PPVspKxr_Q@mail.gmail.com>
Message-ID: <CACLE=7NfLo0ZXvSG2Ae1mLRd2kGWWjmr6E0=kL6gyb5jHb7fdA@mail.gmail.com>

2015-08-26 11:07 GMT+02:00 arjan tijms <arjan.tijms at gmail.com>:

> Hi,
>
> On Wed, Aug 26, 2015 at 10:11 AM, Romain Manni-Bucau
> <rmannibucau at gmail.com> wrote:
> >> Yes, all normal scopes that are available in standard Java EE support
> >> this as far as I know.
> >>
> >
> > Events are not mandatory for a normal scope - at least was the case in
> 1.2 -
> > so JMS can't rely on it for custom normal scopes.
>
> Absolutely true, but that was exactly what I said ;)
>
> All Java EE provided scopes throw the events. For CDI, this is
> mandated by the spec (6.7) for @RequestScoped, @SessionScoped,
> @ApplicationScoped and @ConversationScoped.
>
> For JSF, at least Mojarra, @FlowScoped and @ViewScope do so too. I
> have to double check whether this is actually in the spec for those
> last two and if not see if we can update it for 2.3.
>
>
Agree for provided scope but JMS + short time scopes will not match well in
practise so i would worry more about not "default" scopes which can miss
these events.


> Kind regards,
> Arjan Tijms
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150826/a7884300/attachment.html 

From rmannibucau at gmail.com  Wed Aug 26 05:16:04 2015
From: rmannibucau at gmail.com (Romain Manni-Bucau)
Date: Wed, 26 Aug 2015 11:16:04 +0200
Subject: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean in a
 Java EE application to listen for JMS messages
In-Reply-To: <55DD81B5.9040407@oracle.com>
References: <55DB4692.7040304@oracle.com>
	<CA+ZZq9_Brvtks=jxQ1TbtXMNm+ab3w3GZfG-2sGQYeMK2mu2jA@mail.gmail.com>
	<55DB74E7.4080609@oracle.com>
	<CAOqetn9XTi0zSHMs9y_c3-XT1ghwTxog03BKwb+4=Jw3aPbPWg@mail.gmail.com>
	<55DC72D0.5090608@oracle.com>
	<CAOqetn-rUz=7F+oeymXrxH=OHMRzXC+9-n3LcsHnDQ4_Kq8Lyg@mail.gmail.com>
	<55DC970A.4050607@oracle.com>
	<CACLE=7PEBZomd7tuJby7F1zcrdr_sEFif=z1xgVMPPCZMXY=0g@mail.gmail.com>
	<55DC9EA1.408@oracle.com>
	<CACLE=7ML=yNsn2vRW6MX_2cNjAMedGnd2bjAPjg=7KLRn6etvQ@mail.gmail.com>
	<55DCA17D.9050602@oracle.com>
	<CACLE=7N8mNhvYh_g2W+D97zH4f5pKpH3a0sz1wDfJgdWu_scOg@mail.gmail.com>
	<55DD81B5.9040407@oracle.com>
Message-ID: <CACLE=7O3b8WM79ueUcmuDq5Vi_UC5o2gObU8MnK8tqGJMcGfOQ@mail.gmail.com>

2015-08-26 11:07 GMT+02:00 Nigel Deakin <nigel.deakin at oracle.com>:

> (Tidying up the top-posting...)
>
> Romain Manni-Bucau:
> > ...I see it really nice to not rely only on annotation - and aligned with
> > most specs - since sometimes you just want to either be able to rely on a
> > loop or a custom config to register your listeners. Annotations are too
> > rigid for such cases.
>
> Nigel:
> > Obviously, if users don't want to use CDI (or MDBs, which are also
> > declarative), then they would use the  normal JMS API. The existing
> > API to register an async message listener isn't good enough,
> > and we may improve it in JMS 2.1, but that's not something that
> > I'd want to bother the people on cdi-dev with.
>
> Romain Manni-Bucau:
> > Integrating it in CDI lifecycle through an event allow CDI users to still
> > use it in the right phase of the container boot so it is still important
> > IMO and avoid all users to have their own custom listener for it -
> > @Initialized(AppScoped.class). Also allow to enrich the API through the
> event
> > itself making things smoother IMO.
>
> Nigel:
> > I'm sorry I don't understand you.
> > I thought you were asking about an API which does not use annotation.
>
> Romain Manni-Bucau:
> > Both are needed (like websocket spec). Annotation one is nice for fully
> business
> > code and/or simple libs but relying on CDI allows to simplify the wiring
> since you
> > can reuse CDI beans under the hood ie have an implicit connection
> factory if
> > there is a single one etc which is not possible in fully SE context.
>
> Can you explain the distinction you're making here? You seem to be
> suggesting two alternatives, using "annotation" and "relying on CDI". What
> would an application which uses CDI but which doesn't use annotation look
> like?
>
>
The sample I gave before with the JmsStart event basically:


public class JmsRegistrar {
    @Inject
    @JmsConnectionFactory(...)
    private ConnectionFactory factory;

    @Inject
    @JmsQueue(...)
    private Queue queue;

    public void startJms(@Observes JmsStart start) {
        start.withFactory(factory) // withFactory should be optional if
only 1 bean matches it
               .register(MyCdiTypedListener.class) // with defaults for all
potential config
                   .listenOn(queue)
               .register(MyCdiTypedListener2.class, new MyLiteral())
                    .withMaxSessions(10)
                    .listenOn(Queue.class, new QueueLiteral(...))
                    ......;
    }
}


The power of it appears when you have a config injection in JmsRegistrar
you can iterate over to get the list of listener for instance.

Also JMS resources can be decorated and referenced from qualifiers instead
of instances thanks to CDI.

It doesnt prevent the app to use @JmxListener somewhere else if the
listener doesnt need any input/config to be registered.


> Nigel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150826/cb5c6600/attachment-0001.html 

From nigel.deakin at oracle.com  Wed Aug 26 05:43:40 2015
From: nigel.deakin at oracle.com (Nigel Deakin)
Date: Wed, 26 Aug 2015 10:43:40 +0100
Subject: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean in a
 Java EE application to listen for JMS messages
In-Reply-To: <55DC7B0D.8080200@redhat.com>
References: <55DB4692.7040304@oracle.com>
	<CA+ZZq9_Brvtks=jxQ1TbtXMNm+ab3w3GZfG-2sGQYeMK2mu2jA@mail.gmail.com>
	<55DB74E7.4080609@oracle.com>
	<CAOqetn9XTi0zSHMs9y_c3-XT1ghwTxog03BKwb+4=Jw3aPbPWg@mail.gmail.com>
	<55DC72D0.5090608@oracle.com>
	<CACLE=7Ne_okSRKHa74WGAnZCzGy8ds=m=L_ArWWVzyxc1-LA0g@mail.gmail.com>
	<55DC7B0D.8080200@redhat.com>
Message-ID: <55DD8A4C.7050107@oracle.com>

 > On 25.08.2015 16:05, Romain Manni-Bucau wrote:
 >>
 >> For this last case a really elegant solution would be to just reuse
 >> @Observes to fire the message from the jms "container" listener and
 >> propagate it to the "user" listener. This would then allow to decouple
 >> the application listener from JMS.

On 25/08/2015 15:26, Jozef Hartinger wrote:
> Agreed. I think we should leverage the existing CDI event/observer functionality instead of introducing a completely new
> delivery mechanism.

Can you please say a bit more about what you have in mind?

Romain suggests using events to invoke the "user" listener from the "JMS container listener".
That's a useful distinction. Just to clarify the terminology:

"user" listener = listener bean provided by the application
"JMS container listener" = JMS consumer provided by the application server or resource adapter

There needs to be one consumer for every listener bean since the two need to have the same lifecycle, and also so we can 
implement JMS queue sematics which require that a message from a queue is delivered to one and only one listener.

The transaction needs to be started by the consumer before invoking the listener and ended after the listener returns. 
This allows the acknowledgement of the message (which is performed by the consumer) to take place in the same 
transaction as is used by the listener's method.

Currently I'm proposing that the "consumer" invokes the "listener" by a simple method call. I suppose instead of simply 
invoking the method it could fire a synchronous event, which only the associated listener instance would receive, but 
I'm not sure what the benefit of this would be. Since JMS semantics are very different from CDI event semantics I think 
there's a danger that this will be confusing, since the user might think they were getting CDI event semantics, but they 
were actually getting JMS semantics.

Since this is a bit of a FAQ, it might be useful to explore the differences between the two semantics, but currently 
they seem profoundly different to me. That's why my proposals are built on the CDI bean lifecycle model but not the CDI 
event observer model.

Nigel


From rmannibucau at gmail.com  Wed Aug 26 05:46:57 2015
From: rmannibucau at gmail.com (Romain Manni-Bucau)
Date: Wed, 26 Aug 2015 11:46:57 +0200
Subject: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean in a
 Java EE application to listen for JMS messages
In-Reply-To: <55DD8A4C.7050107@oracle.com>
References: <55DB4692.7040304@oracle.com>
	<CA+ZZq9_Brvtks=jxQ1TbtXMNm+ab3w3GZfG-2sGQYeMK2mu2jA@mail.gmail.com>
	<55DB74E7.4080609@oracle.com>
	<CAOqetn9XTi0zSHMs9y_c3-XT1ghwTxog03BKwb+4=Jw3aPbPWg@mail.gmail.com>
	<55DC72D0.5090608@oracle.com>
	<CACLE=7Ne_okSRKHa74WGAnZCzGy8ds=m=L_ArWWVzyxc1-LA0g@mail.gmail.com>
	<55DC7B0D.8080200@redhat.com> <55DD8A4C.7050107@oracle.com>
Message-ID: <CACLE=7MYErwNimYDz=5C5+xD5MFV-T8M6wjyw9Ax8p59T6Z2ww@mail.gmail.com>

Something I didnt think before but if you can register a method reference
then CDI event system starts to be useless:

xxx.register(myCdiBean::listenOn);

can be something to investigate API wise maybe


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com>

2015-08-26 11:43 GMT+02:00 Nigel Deakin <nigel.deakin at oracle.com>:

> > On 25.08.2015 16:05, Romain Manni-Bucau wrote:
> >>
> >> For this last case a really elegant solution would be to just reuse
> >> @Observes to fire the message from the jms "container" listener and
> >> propagate it to the "user" listener. This would then allow to decouple
> >> the application listener from JMS.
>
> On 25/08/2015 15:26, Jozef Hartinger wrote:
>
>> Agreed. I think we should leverage the existing CDI event/observer
>> functionality instead of introducing a completely new
>> delivery mechanism.
>>
>
> Can you please say a bit more about what you have in mind?
>
> Romain suggests using events to invoke the "user" listener from the "JMS
> container listener".
> That's a useful distinction. Just to clarify the terminology:
>
> "user" listener = listener bean provided by the application
> "JMS container listener" = JMS consumer provided by the application server
> or resource adapter
>
> There needs to be one consumer for every listener bean since the two need
> to have the same lifecycle, and also so we can implement JMS queue sematics
> which require that a message from a queue is delivered to one and only one
> listener.
>
> The transaction needs to be started by the consumer before invoking the
> listener and ended after the listener returns. This allows the
> acknowledgement of the message (which is performed by the consumer) to take
> place in the same transaction as is used by the listener's method.
>
> Currently I'm proposing that the "consumer" invokes the "listener" by a
> simple method call. I suppose instead of simply invoking the method it
> could fire a synchronous event, which only the associated listener instance
> would receive, but I'm not sure what the benefit of this would be. Since
> JMS semantics are very different from CDI event semantics I think there's a
> danger that this will be confusing, since the user might think they were
> getting CDI event semantics, but they were actually getting JMS semantics.
>
> Since this is a bit of a FAQ, it might be useful to explore the
> differences between the two semantics, but currently they seem profoundly
> different to me. That's why my proposals are built on the CDI bean
> lifecycle model but not the CDI event observer model.
>
> Nigel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150826/a1a16971/attachment.html 

From arjan.tijms at gmail.com  Wed Aug 26 05:51:30 2015
From: arjan.tijms at gmail.com (arjan tijms)
Date: Wed, 26 Aug 2015 11:51:30 +0200
Subject: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean in a
 Java EE application to listen for JMS messages
In-Reply-To: <CACLE=7NfLo0ZXvSG2Ae1mLRd2kGWWjmr6E0=kL6gyb5jHb7fdA@mail.gmail.com>
References: <55DB4692.7040304@oracle.com>
	<CA+ZZq9_Brvtks=jxQ1TbtXMNm+ab3w3GZfG-2sGQYeMK2mu2jA@mail.gmail.com>
	<55DB74E7.4080609@oracle.com>
	<CAE=-AhAd-dPbr1sAANiHQ4eD0BF2YA601Emk6+jk9fb_YOCgLQ@mail.gmail.com>
	<CAOqetn8mn0eWGWVo3AiwJZu_A4nDngsgzj3cjiSqVGUPx09UEA@mail.gmail.com>
	<CAE=-AhBBSPw1ZRdzSQOJm1aRKiTxKo0tBHagv8_bn9D=g2B+HQ@mail.gmail.com>
	<55DCA0C0.9080900@oracle.com>
	<CAE=-AhCnTyS-ZVAfT9k2jDK=k6QHW4ShUab_Vt+e6WmBN76gWg@mail.gmail.com>
	<CACLE=7PQaDz4fmXW2f39PN_+zdXioDfAu987OSuaxodBZx=SyQ@mail.gmail.com>
	<CAE=-AhBcnrC6xOdRSXtBdg-7JgfcKcGQMgtow4V0PPVspKxr_Q@mail.gmail.com>
	<CACLE=7NfLo0ZXvSG2Ae1mLRd2kGWWjmr6E0=kL6gyb5jHb7fdA@mail.gmail.com>
Message-ID: <CAE=-AhBb6e_LM4OV3zyH_k-g7PpBN=3=DAyVa3C54+2EtBK7-g@mail.gmail.com>

On Wed, Aug 26, 2015 at 11:09 AM, Romain Manni-Bucau
<rmannibucau at gmail.com> wrote:
> Agree for provided scope but JMS + short time scopes will not match well in
> practise so i would worry more about not "default" scopes which can miss
> these events.

Short lived scopes like @RequestScoped may not be the best match indeed.

Additionally, @RequestScoped is kinda assumed to be an "@ThreadScoped"
thing, e.g. there's the expectation that only the current thread will
access it. If the JMS provider will asynchronously call a method on
the bean instance from another thread, then this breaks this
assumption.

From werner.keil at gmail.com  Wed Aug 26 06:10:37 2015
From: werner.keil at gmail.com (Werner Keil)
Date: Wed, 26 Aug 2015 12:10:37 +0200
Subject: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean in a
 Java EE application to listen for JMS messages
Message-ID: <CAAGawe1bxW1oA_s4t0RNPJCf2hQYgRMsPJatB-M8BCy7xuwRoA@mail.gmail.com>

Hi,

public class JmsRegistrar {
    @Inject
    @JmsConnectionFactory(...)
    private ConnectionFactory factory;

    @Inject
    @JmsQueue(...)
    private Queue queue;

    public void startJms(@Observes JmsStart start) {
        start.withFactory(factory) // withFactory should be optional if
only 1 bean matches it
               .register(BookingListener.class) // with defaults for all
potential config
                   .listenOn(queue)
               .register(BookingListener2.class, new BookingLiteral2())
                    .withMaxSessions(10)
                    .listenOn(Queue.class, new QueueLiteral(...))
                    ......;
    }
}


it could allow to accomplish what I did (loosely based on
http://www.jboss.org/quickstarts/eap/payment-cdi-event/) forwarding MDB
events to custom CDI ones like that.

Class BookingMDB:

  @Inject
  private BookingBean booker;

   public void onMessage(Message rcvMessage) {
        BytesMessage msg = null;
        try {
            if (rcvMessage instanceof BytesMessage) {
                msg = (BytesMessage) rcvMessage;
                byte[] output = new byte[5];
                msg.readBytes(output);
                booker.book(output);
            } else {
                LOGGER.warning("Message of wrong type: " +
rcvMessage.getClass().getName());
            }
        } catch (JMSException e) {
            throw new RuntimeException(e);
        }
}
Class BookingBean:
    public void book(byte[] msg) {
       BookingEvent bookingEvent = new BookingEvent();
       if (msg[256] = 42}
          bookingEvent.setType(BookingType.OK);
        } else {
           <some other message data triggering a different booking event>
        }
        bookingEvent.setMessage(msg);
        bookingEvent.setDatetime(LocalDateTime.now());

        switch (bookingEvent.getType()) {
            case OK:
                BookingEventProducer.fire(bookingEvent);
                break;
case [...]
            default:
                LOGGER.severe("invalid booking option");
                break;
        }
    }

You'll get the idea about other types involved from the standard CDI
example.
We're dealing with BytesMessage because part of that booking process
happens on host servers;-)

Werner

On Wed, Aug 26, 2015 at 11:16 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: JMS 2.1: Proposal to allow any CDI managed bean in a Java
>       EE application to listen for JMS messages (arjan tijms)
>    2. Re: JMS 2.1: Proposal to allow any CDI managed bean in a Java
>       EE application to listen for JMS messages (arjan tijms)
>    3. Re: JMS 2.1: Proposal to allow any CDI managed bean in a Java
>       EE application to listen for JMS messages (Romain Manni-Bucau)
>    4. Re: JMS 2.1: Proposal to allow any CDI managed bean in a Java
>       EE application to listen for JMS messages (Nigel Deakin)
>    5. Re: JMS 2.1: Proposal to allow any CDI managed bean in a Java
>       EE application to listen for JMS messages (arjan tijms)
>    6. Re: JMS 2.1: Proposal to allow any CDI managed bean in a Java
>       EE application to listen for JMS messages (Romain Manni-Bucau)
>    7. Re: JMS 2.1: Proposal to allow any CDI managed bean in a Java
>       EE application to listen for JMS messages (Romain Manni-Bucau)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 25 Aug 2015 22:53:21 +0200
> From: arjan tijms <arjan.tijms at gmail.com>
> Subject: Re: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean
>         in a Java EE application to listen for JMS messages
> To: Nigel Deakin <nigel.deakin at oracle.com>
> Cc: cdi-dev <cdi-dev at lists.jboss.org>
> Message-ID:
>         <CAE=-AhCnTyS-ZVAfT9k2jDK=
> k6QHW4ShUab_Vt+e6WmBN76gWg at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> Hi,
>
> On Tue, Aug 25, 2015 at 7:07 PM, Nigel Deakin <nigel.deakin at oracle.com>
> wrote:
> > On 25/08/2015 12:38, arjan tijms wrote:
> > This looks very interesting. Does this work with any normal scope?
>
> Yes, all normal scopes that are available in standard Java EE support
> this as far as I know.
>
> There's the small caveat that CDI itself doesn't know about this
> automatically for any custom normal scope. That implementation of such
> scope (via a Context) must explicitly throw these events.
>
> For example, this is what Mojarra does for the @FlowScoped implementation:
>
>
> https://github.com/omnifaces/mojarra/blob/master/jsf-ri/src/main/java/com/sun/faces/flow/FlowCDIEventFireHelperImpl.java
>
> Which is fired when the scope starts here:
>
> https://github.com/omnifaces/mojarra/blob/master/jsf-ri/src/main/java/com/sun/faces/flow/FlowCDIContext.java#L431
>
> (the exact same code is used for @ViewScoped in Mojarra as well)
>
>
> > then every time a new request starts, this event is fired which causes an
> > instance of the bean to be created for that request?
>
> Yes, that is what this does ;)
>
> Kind regards,
> Arjan Tijms
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 25 Aug 2015 23:16:27 +0200
> From: arjan tijms <arjan.tijms at gmail.com>
> Subject: Re: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean
>         in a Java EE application to listen for JMS messages
> To: Nigel Deakin <nigel.deakin at oracle.com>
> Cc: cdi-dev <cdi-dev at lists.jboss.org>
> Message-ID:
>         <CAE=-
> AhCugW3jWD1FnghFzAkiuBL6-Kg2ROKa2FCJHfcd2E2+DQ at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> Hi,
>
> On Tue, Aug 25, 2015 at 7:20 PM, Nigel Deakin <nigel.deakin at oracle.com>
> wrote:
> > Someone over on the JMS user alias told me about this yesterday. So that
> > would avoid the need to call a method to trigger lazy initialisation on
> > normal-scoped bean proxies. I presume the application still has to inject
> > the bean.
>
> The bean does not necessarily have to be injected at any point.
>
> With @Eager it will be activated and its @PostConstruct method will be
> invoked in case it hadn't been referenced before (which in case of
> @Eager is unlikely, as it instantiates very early, but still
> theoretically possible).
>
> The bean can of course still be injected or otherwise referenced later
> within the same scope, but as mentioned this is not required.
>
> So for example if you have OmniFaces on your classpath and then only
> the following bean in an application:
>
> @Eager
> @ApplicationScoped
> public class MyEagerApplicationScopedBean {
>
>      @PostConstruct
>      public void init() {
>          System.out.println("Application scoped init!");
>      }
>  }
>
> Then you'll see "Application scoped init!" being printed in your
> server log when you deploy that application. No other code is needed.
>
>
> > If so then it sounds useful. Is it going to be included as a standard
> > feature of CDI 2.0? I see someone has proposed
> > https://issues.jboss.org/browse/CDI-473 .
>
> As the issue already mentions, this is possible with current day CDI
> already. The proposal may arguably make it a little more concise and a
> little less verbose. An eager attribute on the scope looks like a
> quite minimal and elegant solution. Additionally it may make sense for
> some scopes to restrict for which "IDs' it's eagerly instantiated
> (e.g. paths for @RequestScoped, view IDs for @ViewScoped, flow IDs for
> @FlowScoped, etc).
>
> A new @Startup seems more like a very specific usage of the eager
> attribute, namely for @ApplicationScoped (or Singleton?) beans.
>
> Kind regards,
> Arjan
>
>
>
>
>
> >
> > Nigel
> >
> >
>
>
> ------------------------------
>
> Message: 3
> Date: Wed, 26 Aug 2015 10:11:21 +0200
> From: Romain Manni-Bucau <rmannibucau at gmail.com>
> Subject: Re: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean
>         in a Java EE application to listen for JMS messages
> To: arjan tijms <arjan.tijms at gmail.com>
> Cc: cdi-dev <cdi-dev at lists.jboss.org>
> Message-ID:
>         <CACLE=7PQaDz4fmXW2f39PN_+zdXioDfAu987OSuaxodBZx=
> SyQ at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> 2015-08-25 22:53 GMT+02:00 arjan tijms <arjan.tijms at gmail.com>:
>
> > Hi,
> >
> > On Tue, Aug 25, 2015 at 7:07 PM, Nigel Deakin <nigel.deakin at oracle.com>
> > wrote:
> > > On 25/08/2015 12:38, arjan tijms wrote:
> > > This looks very interesting. Does this work with any normal scope?
> >
> > Yes, all normal scopes that are available in standard Java EE support
> > this as far as I know.
> >
> >
> Events are not mandatory for a normal scope - at least was the case in 1.2
> - so JMS can't rely on it for custom normal scopes.
>
>
> > There's the small caveat that CDI itself doesn't know about this
> > automatically for any custom normal scope. That implementation of such
> > scope (via a Context) must explicitly throw these events.
> >
> > For example, this is what Mojarra does for the @FlowScoped
> implementation:
> >
> >
> >
> https://github.com/omnifaces/mojarra/blob/master/jsf-ri/src/main/java/com/sun/faces/flow/FlowCDIEventFireHelperImpl.java
> >
> > Which is fired when the scope starts here:
> >
> >
> https://github.com/omnifaces/mojarra/blob/master/jsf-ri/src/main/java/com/sun/faces/flow/FlowCDIContext.java#L431
> >
> > (the exact same code is used for @ViewScoped in Mojarra as well)
> >
> >
> > > then every time a new request starts, this event is fired which causes
> an
> > > instance of the bean to be created for that request?
> >
> > Yes, that is what this does ;)
> >
> > Kind regards,
> > Arjan Tijms
> > _______________________________________________
> > 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/20150826/c1f05f1c/attachment-0001.html
>
> ------------------------------
>
> Message: 4
> Date: Wed, 26 Aug 2015 10:07:01 +0100
> From: Nigel Deakin <nigel.deakin at oracle.com>
> Subject: Re: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean
>         in a Java EE application to listen for JMS messages
> To: Romain Manni-Bucau <rmannibucau at gmail.com>
> Cc: cdi-dev <cdi-dev at lists.jboss.org>
> Message-ID: <55DD81B5.9040407 at oracle.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> (Tidying up the top-posting...)
>
> Romain Manni-Bucau:
>  > ...I see it really nice to not rely only on annotation - and aligned
> with
>  > most specs - since sometimes you just want to either be able to rely on
> a
>  > loop or a custom config to register your listeners. Annotations are too
>  > rigid for such cases.
>
> Nigel:
>  > Obviously, if users don't want to use CDI (or MDBs, which are also
>  > declarative), then they would use the  normal JMS API. The existing
>  > API to register an async message listener isn't good enough,
>  > and we may improve it in JMS 2.1, but that's not something that
>  > I'd want to bother the people on cdi-dev with.
>
> Romain Manni-Bucau:
>  > Integrating it in CDI lifecycle through an event allow CDI users to
> still
>  > use it in the right phase of the container boot so it is still important
>  > IMO and avoid all users to have their own custom listener for it -
>  > @Initialized(AppScoped.class). Also allow to enrich the API through the
> event
>  > itself making things smoother IMO.
>
> Nigel:
>  > I'm sorry I don't understand you.
>  > I thought you were asking about an API which does not use annotation.
>
> Romain Manni-Bucau:
>  > Both are needed (like websocket spec). Annotation one is nice for fully
> business
>  > code and/or simple libs but relying on CDI allows to simplify the
> wiring since you
>  > can reuse CDI beans under the hood ie have an implicit connection
> factory if
>  > there is a single one etc which is not possible in fully SE context.
>
> Can you explain the distinction you're making here? You seem to be
> suggesting two alternatives, using "annotation" and
> "relying on CDI". What would an application which uses CDI but which
> doesn't use annotation look like?
>
> Nigel
>
>
> ------------------------------
>
> Message: 5
> Date: Wed, 26 Aug 2015 11:07:46 +0200
> From: arjan tijms <arjan.tijms at gmail.com>
> Subject: Re: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean
>         in a Java EE application to listen for JMS messages
> To: Romain Manni-Bucau <rmannibucau at gmail.com>
> Cc: cdi-dev <cdi-dev at lists.jboss.org>
> Message-ID:
>         <CAE=-
> AhBcnrC6xOdRSXtBdg-7JgfcKcGQMgtow4V0PPVspKxr_Q at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> Hi,
>
> On Wed, Aug 26, 2015 at 10:11 AM, Romain Manni-Bucau
> <rmannibucau at gmail.com> wrote:
> >> Yes, all normal scopes that are available in standard Java EE support
> >> this as far as I know.
> >>
> >
> > Events are not mandatory for a normal scope - at least was the case in
> 1.2 -
> > so JMS can't rely on it for custom normal scopes.
>
> Absolutely true, but that was exactly what I said ;)
>
> All Java EE provided scopes throw the events. For CDI, this is
> mandated by the spec (6.7) for @RequestScoped, @SessionScoped,
> @ApplicationScoped and @ConversationScoped.
>
> For JSF, at least Mojarra, @FlowScoped and @ViewScope do so too. I
> have to double check whether this is actually in the spec for those
> last two and if not see if we can update it for 2.3.
>
> Kind regards,
> Arjan Tijms
>
>
> ------------------------------
>
> Message: 6
> Date: Wed, 26 Aug 2015 11:09:30 +0200
> From: Romain Manni-Bucau <rmannibucau at gmail.com>
> Subject: Re: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean
>         in a Java EE application to listen for JMS messages
> To: arjan tijms <arjan.tijms at gmail.com>
> Cc: cdi-dev <cdi-dev at lists.jboss.org>
> Message-ID:
>         <CACLE=7NfLo0ZXvSG2Ae1mLRd2kGWWjmr6E0=
> kL6gyb5jHb7fdA at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> 2015-08-26 11:07 GMT+02:00 arjan tijms <arjan.tijms at gmail.com>:
>
> > Hi,
> >
> > On Wed, Aug 26, 2015 at 10:11 AM, Romain Manni-Bucau
> > <rmannibucau at gmail.com> wrote:
> > >> Yes, all normal scopes that are available in standard Java EE support
> > >> this as far as I know.
> > >>
> > >
> > > Events are not mandatory for a normal scope - at least was the case in
> > 1.2 -
> > > so JMS can't rely on it for custom normal scopes.
> >
> > Absolutely true, but that was exactly what I said ;)
> >
> > All Java EE provided scopes throw the events. For CDI, this is
> > mandated by the spec (6.7) for @RequestScoped, @SessionScoped,
> > @ApplicationScoped and @ConversationScoped.
> >
> > For JSF, at least Mojarra, @FlowScoped and @ViewScope do so too. I
> > have to double check whether this is actually in the spec for those
> > last two and if not see if we can update it for 2.3.
> >
> >
> Agree for provided scope but JMS + short time scopes will not match well in
> practise so i would worry more about not "default" scopes which can miss
> these events.
>
>
> > Kind regards,
> > Arjan Tijms
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20150826/a7884300/attachment-0001.html
>
> ------------------------------
>
> Message: 7
> Date: Wed, 26 Aug 2015 11:16:04 +0200
> From: Romain Manni-Bucau <rmannibucau at gmail.com>
> Subject: Re: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean
>         in a Java EE application to listen for JMS messages
> To: Nigel Deakin <nigel.deakin at oracle.com>
> Cc: cdi-dev <cdi-dev at lists.jboss.org>
> Message-ID:
>         <CACLE=
> 7O3b8WM79ueUcmuDq5Vi_UC5o2gObU8MnK8tqGJMcGfOQ at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> 2015-08-26 11:07 GMT+02:00 Nigel Deakin <nigel.deakin at oracle.com>:
>
> > (Tidying up the top-posting...)
> >
> > Romain Manni-Bucau:
> > > ...I see it really nice to not rely only on annotation - and aligned
> with
> > > most specs - since sometimes you just want to either be able to rely
> on a
> > > loop or a custom config to register your listeners. Annotations are too
> > > rigid for such cases.
> >
> > Nigel:
> > > Obviously, if users don't want to use CDI (or MDBs, which are also
> > > declarative), then they would use the  normal JMS API. The existing
> > > API to register an async message listener isn't good enough,
> > > and we may improve it in JMS 2.1, but that's not something that
> > > I'd want to bother the people on cdi-dev with.
> >
> > Romain Manni-Bucau:
> > > Integrating it in CDI lifecycle through an event allow CDI users to
> still
> > > use it in the right phase of the container boot so it is still
> important
> > > IMO and avoid all users to have their own custom listener for it -
> > > @Initialized(AppScoped.class). Also allow to enrich the API through the
> > event
> > > itself making things smoother IMO.
> >
> > Nigel:
> > > I'm sorry I don't understand you.
> > > I thought you were asking about an API which does not use annotation.
> >
> > Romain Manni-Bucau:
> > > Both are needed (like websocket spec). Annotation one is nice for fully
> > business
> > > code and/or simple libs but relying on CDI allows to simplify the
> wiring
> > since you
> > > can reuse CDI beans under the hood ie have an implicit connection
> > factory if
> > > there is a single one etc which is not possible in fully SE context.
> >
> > Can you explain the distinction you're making here? You seem to be
> > suggesting two alternatives, using "annotation" and "relying on CDI".
> What
> > would an application which uses CDI but which doesn't use annotation look
> > like?
> >
> >
> The sample I gave before with the JmsStart event basically:
>
>
> public class JmsRegistrar {
>     @Inject
>     @JmsConnectionFactory(...)
>     private ConnectionFactory factory;
>
>     @Inject
>     @JmsQueue(...)
>     private Queue queue;
>
>     public void startJms(@Observes JmsStart start) {
>         start.withFactory(factory) // withFactory should be optional if
> only 1 bean matches it
>                .register(MyCdiTypedListener.class) // with defaults for all
> potential config
>                    .listenOn(queue)
>                .register(MyCdiTypedListener2.class, new MyLiteral())
>                     .withMaxSessions(10)
>                     .listenOn(Queue.class, new QueueLiteral(...))
>                     ......;
>     }
> }
>
>
> The power of it appears when you have a config injection in JmsRegistrar
> you can iterate over to get the list of listener for instance.
>
> Also JMS resources can be decorated and referenced from qualifiers instead
> of instances thanks to CDI.
>
> It doesnt prevent the app to use @JmxListener somewhere else if the
> listener doesnt need any input/config to be registered.
>
>
> > Nigel
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20150826/cb5c6600/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 21
> ***************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150826/c56ea2e7/attachment-0001.html 

From werner.keil at gmail.com  Wed Aug 26 06:12:57 2015
From: werner.keil at gmail.com (Werner Keil)
Date: Wed, 26 Aug 2015 12:12:57 +0200
Subject: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean in a
 Java EE application to listen for JMS messages
Message-ID: <CAAGawe1GhhwTPurB5x69Z=1hYX17mbxcpKoModS_m4WAkh-anA@mail.gmail.com>

... with less code, sorry forgot to mention ;-)

Werner

On Wed, Aug 26, 2015 at 12:10 PM, Werner Keil <werner.keil at gmail.com> wrote:

> Hi,
>
> public class JmsRegistrar {
>     @Inject
>     @JmsConnectionFactory(...)
>     private ConnectionFactory factory;
>
>     @Inject
>     @JmsQueue(...)
>     private Queue queue;
>
>     public void startJms(@Observes JmsStart start) {
>         start.withFactory(factory) // withFactory should be optional if
> only 1 bean matches it
>                .register(BookingListener.class) // with defaults for all
> potential config
>                    .listenOn(queue)
>                .register(BookingListener2.class, new BookingLiteral2())
>                     .withMaxSessions(10)
>                     .listenOn(Queue.class, new QueueLiteral(...))
>                     ......;
>     }
> }
>
>
> it could allow to accomplish what I did (loosely based on
> http://www.jboss.org/quickstarts/eap/payment-cdi-event/) forwarding MDB
> events to custom CDI ones like that.
>
> Class BookingMDB:
>
>   @Inject
>   private BookingBean booker;
>
>    public void onMessage(Message rcvMessage) {
>         BytesMessage msg = null;
>         try {
>             if (rcvMessage instanceof BytesMessage) {
>                 msg = (BytesMessage) rcvMessage;
>                 byte[] output = new byte[5];
>                 msg.readBytes(output);
>                 booker.book(output);
>             } else {
>                 LOGGER.warning("Message of wrong type: " +
> rcvMessage.getClass().getName());
>             }
>         } catch (JMSException e) {
>             throw new RuntimeException(e);
>         }
> }
> Class BookingBean:
>     public void book(byte[] msg) {
>        BookingEvent bookingEvent = new BookingEvent();
>        if (msg[256] = 42}
>           bookingEvent.setType(BookingType.OK);
>         } else {
>            <some other message data triggering a different booking event>
>         }
>         bookingEvent.setMessage(msg);
>         bookingEvent.setDatetime(LocalDateTime.now());
>
>         switch (bookingEvent.getType()) {
>             case OK:
>                 BookingEventProducer.fire(bookingEvent);
>                 break;
> case [...]
>             default:
>                 LOGGER.severe("invalid booking option");
>                 break;
>         }
>     }
>
> You'll get the idea about other types involved from the standard CDI
> example.
> We're dealing with BytesMessage because part of that booking process
> happens on host servers;-)
>
> Werner
>
> On Wed, Aug 26, 2015 at 11:16 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: JMS 2.1: Proposal to allow any CDI managed bean in a Java
>>       EE application to listen for JMS messages (arjan tijms)
>>    2. Re: JMS 2.1: Proposal to allow any CDI managed bean in a Java
>>       EE application to listen for JMS messages (arjan tijms)
>>    3. Re: JMS 2.1: Proposal to allow any CDI managed bean in a Java
>>       EE application to listen for JMS messages (Romain Manni-Bucau)
>>    4. Re: JMS 2.1: Proposal to allow any CDI managed bean in a Java
>>       EE application to listen for JMS messages (Nigel Deakin)
>>    5. Re: JMS 2.1: Proposal to allow any CDI managed bean in a Java
>>       EE application to listen for JMS messages (arjan tijms)
>>    6. Re: JMS 2.1: Proposal to allow any CDI managed bean in a Java
>>       EE application to listen for JMS messages (Romain Manni-Bucau)
>>    7. Re: JMS 2.1: Proposal to allow any CDI managed bean in a Java
>>       EE application to listen for JMS messages (Romain Manni-Bucau)
>>
>> ------------------------------
>>
>> Message: 7
>> Date: Wed, 26 Aug 2015 11:16:04 +0200
>> From: Romain Manni-Bucau <rmannibucau at gmail.com>
>> Subject: Re: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean
>>         in a Java EE application to listen for JMS messages
>> To: Nigel Deakin <nigel.deakin at oracle.com>
>> Cc: cdi-dev <cdi-dev at lists.jboss.org>
>> Message-ID:
>>         <CACLE=
>> 7O3b8WM79ueUcmuDq5Vi_UC5o2gObU8MnK8tqGJMcGfOQ at mail.gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> 2015-08-26 11:07 GMT+02:00 Nigel Deakin <nigel.deakin at oracle.com>:
>>
>> > (Tidying up the top-posting...)
>> >
>> > Romain Manni-Bucau:
>> > > ...I see it really nice to not rely only on annotation - and aligned
>> with
>> > > most specs - since sometimes you just want to either be able to rely
>> on a
>> > > loop or a custom config to register your listeners. Annotations are
>> too
>> > > rigid for such cases.
>> >
>> > Nigel:
>> > > Obviously, if users don't want to use CDI (or MDBs, which are also
>> > > declarative), then they would use the  normal JMS API. The existing
>> > > API to register an async message listener isn't good enough,
>> > > and we may improve it in JMS 2.1, but that's not something that
>> > > I'd want to bother the people on cdi-dev with.
>> >
>> > Romain Manni-Bucau:
>> > > Integrating it in CDI lifecycle through an event allow CDI users to
>> still
>> > > use it in the right phase of the container boot so it is still
>> important
>> > > IMO and avoid all users to have their own custom listener for it -
>> > > @Initialized(AppScoped.class). Also allow to enrich the API through
>> the
>> > event
>> > > itself making things smoother IMO.
>> >
>> > Nigel:
>> > > I'm sorry I don't understand you.
>> > > I thought you were asking about an API which does not use annotation.
>> >
>> > Romain Manni-Bucau:
>> > > Both are needed (like websocket spec). Annotation one is nice for
>> fully
>> > business
>> > > code and/or simple libs but relying on CDI allows to simplify the
>> wiring
>> > since you
>> > > can reuse CDI beans under the hood ie have an implicit connection
>> > factory if
>> > > there is a single one etc which is not possible in fully SE context.
>> >
>> > Can you explain the distinction you're making here? You seem to be
>> > suggesting two alternatives, using "annotation" and "relying on CDI".
>> What
>> > would an application which uses CDI but which doesn't use annotation
>> look
>> > like?
>> >
>> >
>> The sample I gave before with the JmsStart event basically:
>>
>>
>> public class JmsRegistrar {
>>     @Inject
>>     @JmsConnectionFactory(...)
>>     private ConnectionFactory factory;
>>
>>     @Inject
>>     @JmsQueue(...)
>>     private Queue queue;
>>
>>     public void startJms(@Observes JmsStart start) {
>>         start.withFactory(factory) // withFactory should be optional if
>> only 1 bean matches it
>>                .register(MyCdiTypedListener.class) // with defaults for
>> all
>> potential config
>>                    .listenOn(queue)
>>                .register(MyCdiTypedListener2.class, new MyLiteral())
>>                     .withMaxSessions(10)
>>                     .listenOn(Queue.class, new QueueLiteral(...))
>>                     ......;
>>     }
>> }
>>
>>
>> The power of it appears when you have a config injection in JmsRegistrar
>> you can iterate over to get the list of listener for instance.
>>
>> Also JMS resources can be decorated and referenced from qualifiers instead
>> of instances thanks to CDI.
>>
>> It doesnt prevent the app to use @JmxListener somewhere else if the
>> listener doesnt need any input/config to be registered.
>>
>>
>> > Nigel
>> >
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL:
>> http://lists.jboss.org/pipermail/cdi-dev/attachments/20150826/cb5c6600/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 21
>> ***************************************
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150826/0aaf2877/attachment.html 

From werner.keil at gmail.com  Wed Aug 26 06:21:38 2015
From: werner.keil at gmail.com (Werner Keil)
Date: Wed, 26 Aug 2015 12:21:38 +0200
Subject: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean in a
 Java EE application to listen for JMS messages
Message-ID: <CAAGawe1zEvMMU6Ca-eGOh4ac7YiZp1oxQHXNSp82bJgUPRm-VA@mail.gmail.com>

Good point. What I tried to sketch out from my example here was mapping a
"JMS container listener" (MDB) to a "business" or "user" listener making
sense for the business logic of a particular application domain.


Werner

On Wed, Aug 26, 2015 at 12:10 PM, <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: JMS 2.1: Proposal to allow any CDI managed bean in a Java
>       EE application to listen for JMS messages (Nigel Deakin)
>    2. Re: JMS 2.1: Proposal to allow any CDI managed bean in a Java
>       EE application to listen for JMS messages (Romain Manni-Bucau)
>    3. Re: JMS 2.1: Proposal to allow any CDI managed bean in a Java
>       EE application to listen for JMS messages (arjan tijms)
>    4. Re: JMS 2.1: Proposal to allow any CDI managed bean in a Java
>       EE application to listen for JMS messages (Werner Keil)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 26 Aug 2015 10:43:40 +0100
> From: Nigel Deakin <nigel.deakin at oracle.com>
> Subject: Re: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean
>         in a Java EE application to listen for JMS messages
> To: Jozef Hartinger <jharting at redhat.com>,      Romain Manni-Bucau
>         <rmannibucau at gmail.com>
> Cc: cdi-dev <cdi-dev at lists.jboss.org>
> Message-ID: <55DD8A4C.7050107 at oracle.com>
> Content-Type: text/plain; charset=windows-1252; format=flowed
>
>  > On 25.08.2015 16:05, Romain Manni-Bucau wrote:
>  >>
>  >> For this last case a really elegant solution would be to just reuse
>  >> @Observes to fire the message from the jms "container" listener and
>  >> propagate it to the "user" listener. This would then allow to decouple
>  >> the application listener from JMS.
>
> On 25/08/2015 15:26, Jozef Hartinger wrote:
> > Agreed. I think we should leverage the existing CDI event/observer
> functionality instead of introducing a completely new
> > delivery mechanism.
>
> Can you please say a bit more about what you have in mind?
>
> Romain suggests using events to invoke the "user" listener from the "JMS
> container listener".
> That's a useful distinction. Just to clarify the terminology:
>
> "user" listener = listener bean provided by the application
> "JMS container listener" = JMS consumer provided by the application server
> or resource adapter
>
> There needs to be one consumer for every listener bean since the two need
> to have the same lifecycle, and also so we can
> implement JMS queue sematics which require that a message from a queue is
> delivered to one and only one listener.
>
> The transaction needs to be started by the consumer before invoking the
> listener and ended after the listener returns.
> This allows the acknowledgement of the message (which is performed by the
> consumer) to take place in the same
> transaction as is used by the listener's method.
>
> Currently I'm proposing that the "consumer" invokes the "listener" by a
> simple method call. I suppose instead of simply
> invoking the method it could fire a synchronous event, which only the
> associated listener instance would receive, but
> I'm not sure what the benefit of this would be. Since JMS semantics are
> very different from CDI event semantics I think
> there's a danger that this will be confusing, since the user might think
> they were getting CDI event semantics, but they
> were actually getting JMS semantics.
>
> Since this is a bit of a FAQ, it might be useful to explore the
> differences between the two semantics, but currently
> they seem profoundly different to me. That's why my proposals are built on
> the CDI bean lifecycle model but not the CDI
> event observer model.
>
> Nigel
>
>
>
> ------------------------------
>
> Message: 2
> Date: Wed, 26 Aug 2015 11:46:57 +0200
> From: Romain Manni-Bucau <rmannibucau at gmail.com>
> Subject: Re: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean
>         in a Java EE application to listen for JMS messages
> To: Nigel Deakin <nigel.deakin at oracle.com>
> Cc: cdi-dev <cdi-dev at lists.jboss.org>
> Message-ID:
>         <CACLE=7MYErwNimYDz=
> 5C5+xD5MFV-T8M6wjyw9Ax8p59T6Z2ww at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Something I didnt think before but if you can register a method reference
> then CDI event system starts to be useless:
>
> xxx.register(myCdiBean::listenOn);
>
> can be something to investigate API wise maybe
>
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> <http://www.tomitribe.com>
>
> 2015-08-26 11:43 GMT+02:00 Nigel Deakin <nigel.deakin at oracle.com>:
>
> > > On 25.08.2015 16:05, Romain Manni-Bucau wrote:
> > >>
> > >> For this last case a really elegant solution would be to just reuse
> > >> @Observes to fire the message from the jms "container" listener and
> > >> propagate it to the "user" listener. This would then allow to decouple
> > >> the application listener from JMS.
> >
> > On 25/08/2015 15:26, Jozef Hartinger wrote:
> >
> >> Agreed. I think we should leverage the existing CDI event/observer
> >> functionality instead of introducing a completely new
> >> delivery mechanism.
> >>
> >
> > Can you please say a bit more about what you have in mind?
> >
> > Romain suggests using events to invoke the "user" listener from the "JMS
> > container listener".
> > That's a useful distinction. Just to clarify the terminology:
> >
> > "user" listener = listener bean provided by the application
> > "JMS container listener" = JMS consumer provided by the application
> server
> > or resource adapter
> >
> > There needs to be one consumer for every listener bean since the two need
> > to have the same lifecycle, and also so we can implement JMS queue
> sematics
> > which require that a message from a queue is delivered to one and only
> one
> > listener.
> >
> > The transaction needs to be started by the consumer before invoking the
> > listener and ended after the listener returns. This allows the
> > acknowledgement of the message (which is performed by the consumer) to
> take
> > place in the same transaction as is used by the listener's method.
> >
> > Currently I'm proposing that the "consumer" invokes the "listener" by a
> > simple method call. I suppose instead of simply invoking the method it
> > could fire a synchronous event, which only the associated listener
> instance
> > would receive, but I'm not sure what the benefit of this would be. Since
> > JMS semantics are very different from CDI event semantics I think
> there's a
> > danger that this will be confusing, since the user might think they were
> > getting CDI event semantics, but they were actually getting JMS
> semantics.
> >
> > Since this is a bit of a FAQ, it might be useful to explore the
> > differences between the two semantics, but currently they seem profoundly
> > different to me. That's why my proposals are built on the CDI bean
> > lifecycle model but not the CDI event observer model.
> >
> > Nigel
> >
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20150826/a1a16971/attachment-0001.html
>
> ------------------------------
>
> Message: 3
> Date: Wed, 26 Aug 2015 11:51:30 +0200
> From: arjan tijms <arjan.tijms at gmail.com>
> Subject: Re: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean
>         in a Java EE application to listen for JMS messages
> To: Romain Manni-Bucau <rmannibucau at gmail.com>
> Cc: cdi-dev <cdi-dev at lists.jboss.org>
> Message-ID:
>         <CAE=-AhBb6e_LM4OV3zyH_k-g7PpBN=3=
> DAyVa3C54+2EtBK7-g at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> On Wed, Aug 26, 2015 at 11:09 AM, Romain Manni-Bucau
> <rmannibucau at gmail.com> wrote:
> > Agree for provided scope but JMS + short time scopes will not match well
> in
> > practise so i would worry more about not "default" scopes which can miss
> > these events.
>
> Short lived scopes like @RequestScoped may not be the best match indeed.
>
> Additionally, @RequestScoped is kinda assumed to be an "@ThreadScoped"
> thing, e.g. there's the expectation that only the current thread will
> access it. If the JMS provider will asynchronously call a method on
> the bean instance from another thread, then this breaks this
> assumption.
>
>
> ------------------------------
>
> Message: 4
> Date: Wed, 26 Aug 2015 12:10:37 +0200
> From: Werner Keil <werner.keil at gmail.com>
> Subject: Re: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean
>         in a Java EE application to listen for JMS messages
> To: cdi-dev <cdi-dev at lists.jboss.org>
> Message-ID:
>         <
> CAAGawe1bxW1oA_s4t0RNPJCf2hQYgRMsPJatB-M8BCy7xuwRoA at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi,
>
> public class JmsRegistrar {
>     @Inject
>     @JmsConnectionFactory(...)
>     private ConnectionFactory factory;
>
>     @Inject
>     @JmsQueue(...)
>     private Queue queue;
>
>     public void startJms(@Observes JmsStart start) {
>         start.withFactory(factory) // withFactory should be optional if
> only 1 bean matches it
>                .register(BookingListener.class) // with defaults for all
> potential config
>                    .listenOn(queue)
>                .register(BookingListener2.class, new BookingLiteral2())
>                     .withMaxSessions(10)
>                     .listenOn(Queue.class, new QueueLiteral(...))
>                     ......;
>     }
> }
>
>
> it could allow to accomplish what I did (loosely based on
> http://www.jboss.org/quickstarts/eap/payment-cdi-event/) forwarding MDB
> events to custom CDI ones like that.
>
> Class BookingMDB:
>
>   @Inject
>   private BookingBean booker;
>
>    public void onMessage(Message rcvMessage) {
>         BytesMessage msg = null;
>         try {
>             if (rcvMessage instanceof BytesMessage) {
>                 msg = (BytesMessage) rcvMessage;
>                 byte[] output = new byte[5];
>                 msg.readBytes(output);
>                 booker.book(output);
>             } else {
>                 LOGGER.warning("Message of wrong type: " +
> rcvMessage.getClass().getName());
>             }
>         } catch (JMSException e) {
>             throw new RuntimeException(e);
>         }
> }
> Class BookingBean:
>     public void book(byte[] msg) {
>        BookingEvent bookingEvent = new BookingEvent();
>        if (msg[256] = 42}
>           bookingEvent.setType(BookingType.OK);
>         } else {
>            <some other message data triggering a different booking event>
>         }
>         bookingEvent.setMessage(msg);
>         bookingEvent.setDatetime(LocalDateTime.now());
>
>         switch (bookingEvent.getType()) {
>             case OK:
>                 BookingEventProducer.fire(bookingEvent);
>                 break;
> case [...]
>             default:
>                 LOGGER.severe("invalid booking option");
>                 break;
>         }
>     }
>
> You'll get the idea about other types involved from the standard CDI
> example.
> We're dealing with BytesMessage because part of that booking process
> happens on host servers;-)
>
> Werner
>
> On Wed, Aug 26, 2015 at 11:16 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: JMS 2.1: Proposal to allow any CDI managed bean in a Java
> >       EE application to listen for JMS messages (arjan tijms)
> >    2. Re: JMS 2.1: Proposal to allow any CDI managed bean in a Java
> >       EE application to listen for JMS messages (arjan tijms)
> >    3. Re: JMS 2.1: Proposal to allow any CDI managed bean in a Java
> >       EE application to listen for JMS messages (Romain Manni-Bucau)
> >    4. Re: JMS 2.1: Proposal to allow any CDI managed bean in a Java
> >       EE application to listen for JMS messages (Nigel Deakin)
> >    5. Re: JMS 2.1: Proposal to allow any CDI managed bean in a Java
> >       EE application to listen for JMS messages (arjan tijms)
> >    6. Re: JMS 2.1: Proposal to allow any CDI managed bean in a Java
> >       EE application to listen for JMS messages (Romain Manni-Bucau)
> >    7. Re: JMS 2.1: Proposal to allow any CDI managed bean in a Java
> >       EE application to listen for JMS messages (Romain Manni-Bucau)
> >
> >
> > ----------------------------------------------------------------------
> >
> > Message: 1
> > Date: Tue, 25 Aug 2015 22:53:21 +0200
> > From: arjan tijms <arjan.tijms at gmail.com>
> > Subject: Re: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean
> >         in a Java EE application to listen for JMS messages
> > To: Nigel Deakin <nigel.deakin at oracle.com>
> > Cc: cdi-dev <cdi-dev at lists.jboss.org>
> > Message-ID:
> >         <CAE=-AhCnTyS-ZVAfT9k2jDK=
> > k6QHW4ShUab_Vt+e6WmBN76gWg at mail.gmail.com>
> > Content-Type: text/plain; charset=UTF-8
> >
> > Hi,
> >
> > On Tue, Aug 25, 2015 at 7:07 PM, Nigel Deakin <nigel.deakin at oracle.com>
> > wrote:
> > > On 25/08/2015 12:38, arjan tijms wrote:
> > > This looks very interesting. Does this work with any normal scope?
> >
> > Yes, all normal scopes that are available in standard Java EE support
> > this as far as I know.
> >
> > There's the small caveat that CDI itself doesn't know about this
> > automatically for any custom normal scope. That implementation of such
> > scope (via a Context) must explicitly throw these events.
> >
> > For example, this is what Mojarra does for the @FlowScoped
> implementation:
> >
> >
> >
> https://github.com/omnifaces/mojarra/blob/master/jsf-ri/src/main/java/com/sun/faces/flow/FlowCDIEventFireHelperImpl.java
> >
> > Which is fired when the scope starts here:
> >
> >
> https://github.com/omnifaces/mojarra/blob/master/jsf-ri/src/main/java/com/sun/faces/flow/FlowCDIContext.java#L431
> >
> > (the exact same code is used for @ViewScoped in Mojarra as well)
> >
> >
> > > then every time a new request starts, this event is fired which causes
> an
> > > instance of the bean to be created for that request?
> >
> > Yes, that is what this does ;)
> >
> > Kind regards,
> > Arjan Tijms
> >
> >
> > ------------------------------
> >
> > Message: 2
> > Date: Tue, 25 Aug 2015 23:16:27 +0200
> > From: arjan tijms <arjan.tijms at gmail.com>
> > Subject: Re: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean
> >         in a Java EE application to listen for JMS messages
> > To: Nigel Deakin <nigel.deakin at oracle.com>
> > Cc: cdi-dev <cdi-dev at lists.jboss.org>
> > Message-ID:
> >         <CAE=-
> > AhCugW3jWD1FnghFzAkiuBL6-Kg2ROKa2FCJHfcd2E2+DQ at mail.gmail.com>
> > Content-Type: text/plain; charset=UTF-8
> >
> > Hi,
> >
> > On Tue, Aug 25, 2015 at 7:20 PM, Nigel Deakin <nigel.deakin at oracle.com>
> > wrote:
> > > Someone over on the JMS user alias told me about this yesterday. So
> that
> > > would avoid the need to call a method to trigger lazy initialisation on
> > > normal-scoped bean proxies. I presume the application still has to
> inject
> > > the bean.
> >
> > The bean does not necessarily have to be injected at any point.
> >
> > With @Eager it will be activated and its @PostConstruct method will be
> > invoked in case it hadn't been referenced before (which in case of
> > @Eager is unlikely, as it instantiates very early, but still
> > theoretically possible).
> >
> > The bean can of course still be injected or otherwise referenced later
> > within the same scope, but as mentioned this is not required.
> >
> > So for example if you have OmniFaces on your classpath and then only
> > the following bean in an application:
> >
> > @Eager
> > @ApplicationScoped
> > public class MyEagerApplicationScopedBean {
> >
> >      @PostConstruct
> >      public void init() {
> >          System.out.println("Application scoped init!");
> >      }
> >  }
> >
> > Then you'll see "Application scoped init!" being printed in your
> > server log when you deploy that application. No other code is needed.
> >
> >
> > > If so then it sounds useful. Is it going to be included as a standard
> > > feature of CDI 2.0? I see someone has proposed
> > > https://issues.jboss.org/browse/CDI-473 .
> >
> > As the issue already mentions, this is possible with current day CDI
> > already. The proposal may arguably make it a little more concise and a
> > little less verbose. An eager attribute on the scope looks like a
> > quite minimal and elegant solution. Additionally it may make sense for
> > some scopes to restrict for which "IDs' it's eagerly instantiated
> > (e.g. paths for @RequestScoped, view IDs for @ViewScoped, flow IDs for
> > @FlowScoped, etc).
> >
> > A new @Startup seems more like a very specific usage of the eager
> > attribute, namely for @ApplicationScoped (or Singleton?) beans.
> >
> > Kind regards,
> > Arjan
> >
> >
> >
> >
> >
> > >
> > > Nigel
> > >
> > >
> >
> >
> > ------------------------------
> >
> > Message: 3
> > Date: Wed, 26 Aug 2015 10:11:21 +0200
> > From: Romain Manni-Bucau <rmannibucau at gmail.com>
> > Subject: Re: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean
> >         in a Java EE application to listen for JMS messages
> > To: arjan tijms <arjan.tijms at gmail.com>
> > Cc: cdi-dev <cdi-dev at lists.jboss.org>
> > Message-ID:
> >         <CACLE=7PQaDz4fmXW2f39PN_+zdXioDfAu987OSuaxodBZx=
> > SyQ at mail.gmail.com>
> > Content-Type: text/plain; charset="utf-8"
> >
> > 2015-08-25 22:53 GMT+02:00 arjan tijms <arjan.tijms at gmail.com>:
> >
> > > Hi,
> > >
> > > On Tue, Aug 25, 2015 at 7:07 PM, Nigel Deakin <nigel.deakin at oracle.com
> >
> > > wrote:
> > > > On 25/08/2015 12:38, arjan tijms wrote:
> > > > This looks very interesting. Does this work with any normal scope?
> > >
> > > Yes, all normal scopes that are available in standard Java EE support
> > > this as far as I know.
> > >
> > >
> > Events are not mandatory for a normal scope - at least was the case in
> 1.2
> > - so JMS can't rely on it for custom normal scopes.
> >
> >
> > > There's the small caveat that CDI itself doesn't know about this
> > > automatically for any custom normal scope. That implementation of such
> > > scope (via a Context) must explicitly throw these events.
> > >
> > > For example, this is what Mojarra does for the @FlowScoped
> > implementation:
> > >
> > >
> > >
> >
> https://github.com/omnifaces/mojarra/blob/master/jsf-ri/src/main/java/com/sun/faces/flow/FlowCDIEventFireHelperImpl.java
> > >
> > > Which is fired when the scope starts here:
> > >
> > >
> >
> https://github.com/omnifaces/mojarra/blob/master/jsf-ri/src/main/java/com/sun/faces/flow/FlowCDIContext.java#L431
> > >
> > > (the exact same code is used for @ViewScoped in Mojarra as well)
> > >
> > >
> > > > then every time a new request starts, this event is fired which
> causes
> > an
> > > > instance of the bean to be created for that request?
> > >
> > > Yes, that is what this does ;)
> > >
> > > Kind regards,
> > > Arjan Tijms
> > > _______________________________________________
> > > 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/20150826/c1f05f1c/attachment-0001.html
> >
> > ------------------------------
> >
> > Message: 4
> > Date: Wed, 26 Aug 2015 10:07:01 +0100
> > From: Nigel Deakin <nigel.deakin at oracle.com>
> > Subject: Re: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean
> >         in a Java EE application to listen for JMS messages
> > To: Romain Manni-Bucau <rmannibucau at gmail.com>
> > Cc: cdi-dev <cdi-dev at lists.jboss.org>
> > Message-ID: <55DD81B5.9040407 at oracle.com>
> > Content-Type: text/plain; charset=utf-8; format=flowed
> >
> > (Tidying up the top-posting...)
> >
> > Romain Manni-Bucau:
> >  > ...I see it really nice to not rely only on annotation - and aligned
> > with
> >  > most specs - since sometimes you just want to either be able to rely
> on
> > a
> >  > loop or a custom config to register your listeners. Annotations are
> too
> >  > rigid for such cases.
> >
> > Nigel:
> >  > Obviously, if users don't want to use CDI (or MDBs, which are also
> >  > declarative), then they would use the  normal JMS API. The existing
> >  > API to register an async message listener isn't good enough,
> >  > and we may improve it in JMS 2.1, but that's not something that
> >  > I'd want to bother the people on cdi-dev with.
> >
> > Romain Manni-Bucau:
> >  > Integrating it in CDI lifecycle through an event allow CDI users to
> > still
> >  > use it in the right phase of the container boot so it is still
> important
> >  > IMO and avoid all users to have their own custom listener for it -
> >  > @Initialized(AppScoped.class). Also allow to enrich the API through
> the
> > event
> >  > itself making things smoother IMO.
> >
> > Nigel:
> >  > I'm sorry I don't understand you.
> >  > I thought you were asking about an API which does not use annotation.
> >
> > Romain Manni-Bucau:
> >  > Both are needed (like websocket spec). Annotation one is nice for
> fully
> > business
> >  > code and/or simple libs but relying on CDI allows to simplify the
> > wiring since you
> >  > can reuse CDI beans under the hood ie have an implicit connection
> > factory if
> >  > there is a single one etc which is not possible in fully SE context.
> >
> > Can you explain the distinction you're making here? You seem to be
> > suggesting two alternatives, using "annotation" and
> > "relying on CDI". What would an application which uses CDI but which
> > doesn't use annotation look like?
> >
> > Nigel
> >
> >
> > ------------------------------
> >
> > Message: 5
> > Date: Wed, 26 Aug 2015 11:07:46 +0200
> > From: arjan tijms <arjan.tijms at gmail.com>
> > Subject: Re: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean
> >         in a Java EE application to listen for JMS messages
> > To: Romain Manni-Bucau <rmannibucau at gmail.com>
> > Cc: cdi-dev <cdi-dev at lists.jboss.org>
> > Message-ID:
> >         <CAE=-
> > AhBcnrC6xOdRSXtBdg-7JgfcKcGQMgtow4V0PPVspKxr_Q at mail.gmail.com>
> > Content-Type: text/plain; charset=UTF-8
> >
> > Hi,
> >
> > On Wed, Aug 26, 2015 at 10:11 AM, Romain Manni-Bucau
> > <rmannibucau at gmail.com> wrote:
> > >> Yes, all normal scopes that are available in standard Java EE support
> > >> this as far as I know.
> > >>
> > >
> > > Events are not mandatory for a normal scope - at least was the case in
> > 1.2 -
> > > so JMS can't rely on it for custom normal scopes.
> >
> > Absolutely true, but that was exactly what I said ;)
> >
> > All Java EE provided scopes throw the events. For CDI, this is
> > mandated by the spec (6.7) for @RequestScoped, @SessionScoped,
> > @ApplicationScoped and @ConversationScoped.
> >
> > For JSF, at least Mojarra, @FlowScoped and @ViewScope do so too. I
> > have to double check whether this is actually in the spec for those
> > last two and if not see if we can update it for 2.3.
> >
> > Kind regards,
> > Arjan Tijms
> >
> >
> > ------------------------------
> >
> > Message: 6
> > Date: Wed, 26 Aug 2015 11:09:30 +0200
> > From: Romain Manni-Bucau <rmannibucau at gmail.com>
> > Subject: Re: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean
> >         in a Java EE application to listen for JMS messages
> > To: arjan tijms <arjan.tijms at gmail.com>
> > Cc: cdi-dev <cdi-dev at lists.jboss.org>
> > Message-ID:
> >         <CACLE=7NfLo0ZXvSG2Ae1mLRd2kGWWjmr6E0=
> > kL6gyb5jHb7fdA at mail.gmail.com>
> > Content-Type: text/plain; charset="utf-8"
> >
> > 2015-08-26 11:07 GMT+02:00 arjan tijms <arjan.tijms at gmail.com>:
> >
> > > Hi,
> > >
> > > On Wed, Aug 26, 2015 at 10:11 AM, Romain Manni-Bucau
> > > <rmannibucau at gmail.com> wrote:
> > > >> Yes, all normal scopes that are available in standard Java EE
> support
> > > >> this as far as I know.
> > > >>
> > > >
> > > > Events are not mandatory for a normal scope - at least was the case
> in
> > > 1.2 -
> > > > so JMS can't rely on it for custom normal scopes.
> > >
> > > Absolutely true, but that was exactly what I said ;)
> > >
> > > All Java EE provided scopes throw the events. For CDI, this is
> > > mandated by the spec (6.7) for @RequestScoped, @SessionScoped,
> > > @ApplicationScoped and @ConversationScoped.
> > >
> > > For JSF, at least Mojarra, @FlowScoped and @ViewScope do so too. I
> > > have to double check whether this is actually in the spec for those
> > > last two and if not see if we can update it for 2.3.
> > >
> > >
> > Agree for provided scope but JMS + short time scopes will not match well
> in
> > practise so i would worry more about not "default" scopes which can miss
> > these events.
> >
> >
> > > Kind regards,
> > > Arjan Tijms
> > >
> > -------------- next part --------------
> > An HTML attachment was scrubbed...
> > URL:
> >
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20150826/a7884300/attachment-0001.html
> >
> > ------------------------------
> >
> > Message: 7
> > Date: Wed, 26 Aug 2015 11:16:04 +0200
> > From: Romain Manni-Bucau <rmannibucau at gmail.com>
> > Subject: Re: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean
> >         in a Java EE application to listen for JMS messages
> > To: Nigel Deakin <nigel.deakin at oracle.com>
> > Cc: cdi-dev <cdi-dev at lists.jboss.org>
> > Message-ID:
> >         <CACLE=
> > 7O3b8WM79ueUcmuDq5Vi_UC5o2gObU8MnK8tqGJMcGfOQ at mail.gmail.com>
> > Content-Type: text/plain; charset="utf-8"
> >
> > 2015-08-26 11:07 GMT+02:00 Nigel Deakin <nigel.deakin at oracle.com>:
> >
> > > (Tidying up the top-posting...)
> > >
> > > Romain Manni-Bucau:
> > > > ...I see it really nice to not rely only on annotation - and aligned
> > with
> > > > most specs - since sometimes you just want to either be able to rely
> > on a
> > > > loop or a custom config to register your listeners. Annotations are
> too
> > > > rigid for such cases.
> > >
> > > Nigel:
> > > > Obviously, if users don't want to use CDI (or MDBs, which are also
> > > > declarative), then they would use the  normal JMS API. The existing
> > > > API to register an async message listener isn't good enough,
> > > > and we may improve it in JMS 2.1, but that's not something that
> > > > I'd want to bother the people on cdi-dev with.
> > >
> > > Romain Manni-Bucau:
> > > > Integrating it in CDI lifecycle through an event allow CDI users to
> > still
> > > > use it in the right phase of the container boot so it is still
> > important
> > > > IMO and avoid all users to have their own custom listener for it -
> > > > @Initialized(AppScoped.class). Also allow to enrich the API through
> the
> > > event
> > > > itself making things smoother IMO.
> > >
> > > Nigel:
> > > > I'm sorry I don't understand you.
> > > > I thought you were asking about an API which does not use annotation.
> > >
> > > Romain Manni-Bucau:
> > > > Both are needed (like websocket spec). Annotation one is nice for
> fully
> > > business
> > > > code and/or simple libs but relying on CDI allows to simplify the
> > wiring
> > > since you
> > > > can reuse CDI beans under the hood ie have an implicit connection
> > > factory if
> > > > there is a single one etc which is not possible in fully SE context.
> > >
> > > Can you explain the distinction you're making here? You seem to be
> > > suggesting two alternatives, using "annotation" and "relying on CDI".
> > What
> > > would an application which uses CDI but which doesn't use annotation
> look
> > > like?
> > >
> > >
> > The sample I gave before with the JmsStart event basically:
> >
> >
> > public class JmsRegistrar {
> >     @Inject
> >     @JmsConnectionFactory(...)
> >     private ConnectionFactory factory;
> >
> >     @Inject
> >     @JmsQueue(...)
> >     private Queue queue;
> >
> >     public void startJms(@Observes JmsStart start) {
> >         start.withFactory(factory) // withFactory should be optional if
> > only 1 bean matches it
> >                .register(MyCdiTypedListener.class) // with defaults for
> all
> > potential config
> >                    .listenOn(queue)
> >                .register(MyCdiTypedListener2.class, new MyLiteral())
> >                     .withMaxSessions(10)
> >                     .listenOn(Queue.class, new QueueLiteral(...))
> >                     ......;
> >     }
> > }
> >
> >
> > The power of it appears when you have a config injection in JmsRegistrar
> > you can iterate over to get the list of listener for instance.
> >
> > Also JMS resources can be decorated and referenced from qualifiers
> instead
> > of instances thanks to CDI.
> >
> > It doesnt prevent the app to use @JmxListener somewhere else if the
> > listener doesnt need any input/config to be registered.
> >
> >
> > > Nigel
> > >
> > -------------- next part --------------
> > An HTML attachment was scrubbed...
> > URL:
> >
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20150826/cb5c6600/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 21
> > ***************************************
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20150826/c56ea2e7/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 22
> ***************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150826/34139ad1/attachment-0001.html 

From nigel.deakin at oracle.com  Wed Aug 26 06:53:14 2015
From: nigel.deakin at oracle.com (Nigel Deakin)
Date: Wed, 26 Aug 2015 11:53:14 +0100
Subject: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean in a
 Java EE application to listen for JMS messages
In-Reply-To: <CAE=-AhBb6e_LM4OV3zyH_k-g7PpBN=3=DAyVa3C54+2EtBK7-g@mail.gmail.com>
References: <55DB4692.7040304@oracle.com>
	<CA+ZZq9_Brvtks=jxQ1TbtXMNm+ab3w3GZfG-2sGQYeMK2mu2jA@mail.gmail.com>
	<55DB74E7.4080609@oracle.com>
	<CAE=-AhAd-dPbr1sAANiHQ4eD0BF2YA601Emk6+jk9fb_YOCgLQ@mail.gmail.com>
	<CAOqetn8mn0eWGWVo3AiwJZu_A4nDngsgzj3cjiSqVGUPx09UEA@mail.gmail.com>
	<CAE=-AhBBSPw1ZRdzSQOJm1aRKiTxKo0tBHagv8_bn9D=g2B+HQ@mail.gmail.com>
	<55DCA0C0.9080900@oracle.com>
	<CAE=-AhCnTyS-ZVAfT9k2jDK=k6QHW4ShUab_Vt+e6WmBN76gWg@mail.gmail.com>
	<CACLE=7PQaDz4fmXW2f39PN_+zdXioDfAu987OSuaxodBZx=SyQ@mail.gmail.com>
	<CAE=-AhBcnrC6xOdRSXtBdg-7JgfcKcGQMgtow4V0PPVspKxr_Q@mail.gmail.com>
	<CACLE=7NfLo0ZXvSG2Ae1mLRd2kGWWjmr6E0=kL6gyb5jHb7fdA@mail.gmail.com>
	<CAE=-AhBb6e_LM4OV3zyH_k-g7PpBN=3=DAyVa3C54+2EtBK7-g@mail.gmail.com>
Message-ID: <55DD9A9A.1070503@oracle.com>

On 26/08/2015 10:51, arjan tijms wrote:
> On Wed, Aug 26, 2015 at 11:09 AM, Romain Manni-Bucau
> <rmannibucau at gmail.com> wrote:
>> Agree for provided scope but JMS + short time scopes will not match well in
>> practise so i would worry more about not "default" scopes which can miss
>> these events.
>
> Short lived scopes like @RequestScoped may not be the best match indeed.
>
> Additionally, @RequestScoped is kinda assumed to be an "@ThreadScoped"
> thing, e.g. there's the expectation that only the current thread will
> access it. If the JMS provider will asynchronously call a method on
> the bean instance from another thread, then this breaks this
> assumption.

That's an interesting point. Is there anything in the CDI spec which would forbid the use of a @RequestScoped JMS 
listener bean from another thread?

Perhaps all that is needed is to make it clear to users that this is what would happen. The same issue would arise if 
the user injected a dependent-scoped JMS listener bean into a @RequestScoped bean.

It's worth considering threading more generally. Although the JMS provider (resource adapter, actually) can make sure 
that the callback method won't be called from multiple JMS provider threads at the same time, it can't guarantee that an 
application thread won't be calling a business method on the bean at the same time. (Would it want to?)

Nigel

From john.d.ament at gmail.com  Wed Aug 26 07:10:11 2015
From: john.d.ament at gmail.com (John D. Ament)
Date: Wed, 26 Aug 2015 11:10:11 +0000
Subject: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean in a
 Java EE application to listen for JMS messages
In-Reply-To: <55DD9A9A.1070503@oracle.com>
References: <55DB4692.7040304@oracle.com>
	<CA+ZZq9_Brvtks=jxQ1TbtXMNm+ab3w3GZfG-2sGQYeMK2mu2jA@mail.gmail.com>
	<55DB74E7.4080609@oracle.com>
	<CAE=-AhAd-dPbr1sAANiHQ4eD0BF2YA601Emk6+jk9fb_YOCgLQ@mail.gmail.com>
	<CAOqetn8mn0eWGWVo3AiwJZu_A4nDngsgzj3cjiSqVGUPx09UEA@mail.gmail.com>
	<CAE=-AhBBSPw1ZRdzSQOJm1aRKiTxKo0tBHagv8_bn9D=g2B+HQ@mail.gmail.com>
	<55DCA0C0.9080900@oracle.com>
	<CAE=-AhCnTyS-ZVAfT9k2jDK=k6QHW4ShUab_Vt+e6WmBN76gWg@mail.gmail.com>
	<CACLE=7PQaDz4fmXW2f39PN_+zdXioDfAu987OSuaxodBZx=SyQ@mail.gmail.com>
	<CAE=-AhBcnrC6xOdRSXtBdg-7JgfcKcGQMgtow4V0PPVspKxr_Q@mail.gmail.com>
	<CACLE=7NfLo0ZXvSG2Ae1mLRd2kGWWjmr6E0=kL6gyb5jHb7fdA@mail.gmail.com>
	<CAE=-AhBb6e_LM4OV3zyH_k-g7PpBN=3=DAyVa3C54+2EtBK7-g@mail.gmail.com>
	<55DD9A9A.1070503@oracle.com>
Message-ID: <CAOqetn8LhNvq+4ELzuq-MLA3=6eVP3-k_AMQ8502=ag4jy4ZCg@mail.gmail.com>

On Wed, Aug 26, 2015 at 6:53 AM Nigel Deakin <nigel.deakin at oracle.com>
wrote:

> On 26/08/2015 10:51, arjan tijms wrote:
> > On Wed, Aug 26, 2015 at 11:09 AM, Romain Manni-Bucau
> > <rmannibucau at gmail.com> wrote:
> >> Agree for provided scope but JMS + short time scopes will not match
> well in
> >> practise so i would worry more about not "default" scopes which can miss
> >> these events.
> >
> > Short lived scopes like @RequestScoped may not be the best match indeed.
> >
> > Additionally, @RequestScoped is kinda assumed to be an "@ThreadScoped"
> > thing, e.g. there's the expectation that only the current thread will
> > access it. If the JMS provider will asynchronously call a method on
> > the bean instance from another thread, then this breaks this
> > assumption.
>
> That's an interesting point. Is there anything in the CDI spec which would
> forbid the use of a @RequestScoped JMS
> listener bean from another thread?
>

The CDI spec still mandates that a request scope is started for delivery to
MDBs.  See http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#request_context

The JMS provider would be responsible for retrieving a contextual reference
to the bean and then invoking the method.  The container should still be
responsible for starting the request context (If I read this correctly).

Likewise, we could say that a @TransactionScoped bean also applies here,
since a JTA transaction should have been started by the RA.


>
> Perhaps all that is needed is to make it clear to users that this is what
> would happen. The same issue would arise if
> the user injected a dependent-scoped JMS listener bean into a
> @RequestScoped bean.
>
> It's worth considering threading more generally. Although the JMS provider
> (resource adapter, actually) can make sure
> that the callback method won't be called from multiple JMS provider
> threads at the same time, it can't guarantee that an
> application thread won't be calling a business method on the bean at the
> same time. (Would it want to?)
>
> Nigel
> _______________________________________________
> 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/20150826/bb408008/attachment.html 

From arjan.tijms at gmail.com  Wed Aug 26 07:33:02 2015
From: arjan.tijms at gmail.com (arjan tijms)
Date: Wed, 26 Aug 2015 13:33:02 +0200
Subject: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean in a
 Java EE application to listen for JMS messages
In-Reply-To: <CAOqetn8LhNvq+4ELzuq-MLA3=6eVP3-k_AMQ8502=ag4jy4ZCg@mail.gmail.com>
References: <55DB4692.7040304@oracle.com>
	<CA+ZZq9_Brvtks=jxQ1TbtXMNm+ab3w3GZfG-2sGQYeMK2mu2jA@mail.gmail.com>
	<55DB74E7.4080609@oracle.com>
	<CAE=-AhAd-dPbr1sAANiHQ4eD0BF2YA601Emk6+jk9fb_YOCgLQ@mail.gmail.com>
	<CAOqetn8mn0eWGWVo3AiwJZu_A4nDngsgzj3cjiSqVGUPx09UEA@mail.gmail.com>
	<CAE=-AhBBSPw1ZRdzSQOJm1aRKiTxKo0tBHagv8_bn9D=g2B+HQ@mail.gmail.com>
	<55DCA0C0.9080900@oracle.com>
	<CAE=-AhCnTyS-ZVAfT9k2jDK=k6QHW4ShUab_Vt+e6WmBN76gWg@mail.gmail.com>
	<CACLE=7PQaDz4fmXW2f39PN_+zdXioDfAu987OSuaxodBZx=SyQ@mail.gmail.com>
	<CAE=-AhBcnrC6xOdRSXtBdg-7JgfcKcGQMgtow4V0PPVspKxr_Q@mail.gmail.com>
	<CACLE=7NfLo0ZXvSG2Ae1mLRd2kGWWjmr6E0=kL6gyb5jHb7fdA@mail.gmail.com>
	<CAE=-AhBb6e_LM4OV3zyH_k-g7PpBN=3=DAyVa3C54+2EtBK7-g@mail.gmail.com>
	<55DD9A9A.1070503@oracle.com>
	<CAOqetn8LhNvq+4ELzuq-MLA3=6eVP3-k_AMQ8502=ag4jy4ZCg@mail.gmail.com>
Message-ID: <CAE=-AhBd8R==v38Osim_hzTe_2xwBkh14nqa-EHkuaO1i6aKPw@mail.gmail.com>

On Wed, Aug 26, 2015 at 1:10 PM, John D. Ament <john.d.ament at gmail.com> wrote:
> The JMS provider would be responsible for retrieving a contextual reference
> to the bean and then invoking the method.

But in that case the contextual reference to the bean would be within
the single request scope that the resource adapter adapter sees.
Likewise, IFF the bridging would be done via an MDB, and the MDB would
retrieve a contextual reference of an @RequestScoped bean, then it
would be the single instance corresponding to the same request the MDB
sees.

What I think is wanted here is that an arbitrary *other* request
that's active, say an HTTP request to a Servlet, has an active
@RequestScoped bean and the resource adapter or MDB invokes a method
on the bean in that other request scope.

Correct me if I'm wrong, but this is not entirely how CDI normally
works, where contextual references always resolve to beans that are in
the scope of the caller.

From john.d.ament at gmail.com  Wed Aug 26 07:51:45 2015
From: john.d.ament at gmail.com (John D. Ament)
Date: Wed, 26 Aug 2015 11:51:45 +0000
Subject: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean in a
 Java EE application to listen for JMS messages
In-Reply-To: <CAE=-AhBd8R==v38Osim_hzTe_2xwBkh14nqa-EHkuaO1i6aKPw@mail.gmail.com>
References: <55DB4692.7040304@oracle.com>
	<CA+ZZq9_Brvtks=jxQ1TbtXMNm+ab3w3GZfG-2sGQYeMK2mu2jA@mail.gmail.com>
	<55DB74E7.4080609@oracle.com>
	<CAE=-AhAd-dPbr1sAANiHQ4eD0BF2YA601Emk6+jk9fb_YOCgLQ@mail.gmail.com>
	<CAOqetn8mn0eWGWVo3AiwJZu_A4nDngsgzj3cjiSqVGUPx09UEA@mail.gmail.com>
	<CAE=-AhBBSPw1ZRdzSQOJm1aRKiTxKo0tBHagv8_bn9D=g2B+HQ@mail.gmail.com>
	<55DCA0C0.9080900@oracle.com>
	<CAE=-AhCnTyS-ZVAfT9k2jDK=k6QHW4ShUab_Vt+e6WmBN76gWg@mail.gmail.com>
	<CACLE=7PQaDz4fmXW2f39PN_+zdXioDfAu987OSuaxodBZx=SyQ@mail.gmail.com>
	<CAE=-AhBcnrC6xOdRSXtBdg-7JgfcKcGQMgtow4V0PPVspKxr_Q@mail.gmail.com>
	<CACLE=7NfLo0ZXvSG2Ae1mLRd2kGWWjmr6E0=kL6gyb5jHb7fdA@mail.gmail.com>
	<CAE=-AhBb6e_LM4OV3zyH_k-g7PpBN=3=DAyVa3C54+2EtBK7-g@mail.gmail.com>
	<55DD9A9A.1070503@oracle.com>
	<CAOqetn8LhNvq+4ELzuq-MLA3=6eVP3-k_AMQ8502=ag4jy4ZCg@mail.gmail.com>
	<CAE=-AhBd8R==v38Osim_hzTe_2xwBkh14nqa-EHkuaO1i6aKPw@mail.gmail.com>
Message-ID: <CAOqetn8TrF=p-z9MKUFDX_zLd2MBaR6+2_BECoHQHHMF2JkLNA@mail.gmail.com>

On Wed, Aug 26, 2015 at 7:33 AM arjan tijms <arjan.tijms at gmail.com> wrote:

> On Wed, Aug 26, 2015 at 1:10 PM, John D. Ament <john.d.ament at gmail.com>
> wrote:
> > The JMS provider would be responsible for retrieving a contextual
> reference
> > to the bean and then invoking the method.
>
> But in that case the contextual reference to the bean would be within
> the single request scope that the resource adapter adapter sees.
> Likewise, IFF the bridging would be done via an MDB, and the MDB would
> retrieve a contextual reference of an @RequestScoped bean, then it
> would be the single instance corresponding to the same request the MDB
> sees.
>
> What I think is wanted here is that an arbitrary *other* request
> that's active, say an HTTP request to a Servlet, has an active
> @RequestScoped bean and the resource adapter or MDB invokes a method
> on the bean in that other request scope.
>
> Correct me if I'm wrong, but this is not entirely how CDI normally
> works, where contextual references always resolve to beans that are in
> the scope of the caller.
>


I think we're saying the same thing.  I feel like I had similar discussions
with Nigel in JMS 2, and cautioned him to not redefine how CDI works or how
request scoped works.  By simply saying "this is the active context when
you do this" it's covering that request context will continue to be request
context.  If the CDI E.G. ever redefined how request context works, then
those changes should just apply anywhere that request context is used,
without requiring the specs to change something.

There is currently no sharing of request contexts.  One of the open
requests from the servlet spec is to bridge request on async submissions.
They should be able to specify that themselves, but meh.  LIkewise, there
is no guarantee that the MDB that the message gets delivered to shares any
topology with the client that produced the message, so attempting to state
that the http request is shared makes very little sense.  If there are
attributes that want to be shared, that's fine, but those can be sent with
the message itself.

John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150826/b7700702/attachment.html 

From nigel.deakin at oracle.com  Wed Aug 26 08:03:10 2015
From: nigel.deakin at oracle.com (Nigel Deakin)
Date: Wed, 26 Aug 2015 13:03:10 +0100
Subject: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean in a
 Java EE application to listen for JMS messages
In-Reply-To: <CAOqetn8LhNvq+4ELzuq-MLA3=6eVP3-k_AMQ8502=ag4jy4ZCg@mail.gmail.com>
References: <55DB4692.7040304@oracle.com>
	<CA+ZZq9_Brvtks=jxQ1TbtXMNm+ab3w3GZfG-2sGQYeMK2mu2jA@mail.gmail.com>
	<55DB74E7.4080609@oracle.com>
	<CAE=-AhAd-dPbr1sAANiHQ4eD0BF2YA601Emk6+jk9fb_YOCgLQ@mail.gmail.com>
	<CAOqetn8mn0eWGWVo3AiwJZu_A4nDngsgzj3cjiSqVGUPx09UEA@mail.gmail.com>
	<CAE=-AhBBSPw1ZRdzSQOJm1aRKiTxKo0tBHagv8_bn9D=g2B+HQ@mail.gmail.com>
	<55DCA0C0.9080900@oracle.com>
	<CAE=-AhCnTyS-ZVAfT9k2jDK=k6QHW4ShUab_Vt+e6WmBN76gWg@mail.gmail.com>
	<CACLE=7PQaDz4fmXW2f39PN_+zdXioDfAu987OSuaxodBZx=SyQ@mail.gmail.com>
	<CAE=-AhBcnrC6xOdRSXtBdg-7JgfcKcGQMgtow4V0PPVspKxr_Q@mail.gmail.com>
	<CACLE=7NfLo0ZXvSG2Ae1mLRd2kGWWjmr6E0=kL6gyb5jHb7fdA@mail.gmail.com>
	<CAE=-AhBb6e_LM4OV3zyH_k-g7PpBN=3=DAyVa3C54+2EtBK7-g@mail.gmail.com>
	<55DD9A9A.1070503@oracle.com>
	<CAOqetn8LhNvq+4ELzuq-MLA3=6eVP3-k_AMQ8502=ag4jy4ZCg@mail.gmail.com>
Message-ID: <55DDAAFE.20602@oracle.com>

On 26/08/2015 12:10, John D. Ament wrote:
>
>
> On Wed, Aug 26, 2015 at 6:53 AM Nigel Deakin <nigel.deakin at oracle.com <mailto:nigel.deakin at oracle.com>> wrote:
>
>     On 26/08/2015 10:51, arjan tijms wrote:
>      > On Wed, Aug 26, 2015 at 11:09 AM, Romain Manni-Bucau
>      > <rmannibucau at gmail.com <mailto:rmannibucau at gmail.com>> wrote:
>      >> Agree for provided scope but JMS + short time scopes will not match well in
>      >> practise so i would worry more about not "default" scopes which can miss
>      >> these events.
>      >
>      > Short lived scopes like @RequestScoped may not be the best match indeed.
>      >
>      > Additionally, @RequestScoped is kinda assumed to be an "@ThreadScoped"
>      > thing, e.g. there's the expectation that only the current thread will
>      > access it. If the JMS provider will asynchronously call a method on
>      > the bean instance from another thread, then this breaks this
>      > assumption.
>
>     That's an interesting point. Is there anything in the CDI spec which would forbid the use of a @RequestScoped JMS
>     listener bean from another thread?
>
>
> The CDI spec still mandates that a request scope is started for delivery to MDBs.  See
> http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#request_context
>
> The JMS provider would be responsible for retrieving a contextual reference to the bean and then invoking the method.
> The container should still be responsible for starting the request context (If I read this correctly).

In the case of a "JMS listener bean" with @RequestScoped (or any scope, really) then the JMS consumer (the thread which 
receives a message from the JMS server and invokes the listener) is associated with the actual bean instance. We should 
think of it as an extension to that instance. The bean instance would be created when the request (e.g. the HTTP 
request) started, and will be destroyed when the request ends. Likewise the JMS consumer is created when the request 
starts and will be destroyed when the request ends. The consumer thread that is calling the listener doesn't "retrieve a 
contextual reference to the bean" since it is already associated with a specific instance.

However once you're inside the callback method then this request scope (which relates to a different thread) is not 
available. As John suggests, we should probably define that a request scope is started when the callback method is 
invoked, and ended when the callback method returns. The listener method itself could inject @RequestScoped objects 
(including JMSContexts, which are request-scoped if there were no transaction), where the request scope used is the one 
associated with this particular callback.

> Likewise, we could say that a @TransactionScoped bean also applies here, since a JTA transaction should have been
> started by the RA.

If the listener bean were @TransactionScoped then the JTA transaction would (by definition) have been started before the 
bean was created, and before the consumer was created. That would be separate from any transaction started by the 
resource adapter (which would be in a different thread).

Once again, the bean instance being used would be the one associated with the consumer, and which lives for as long as 
the first (application's) transaction.

However the callback method would be called in the context of the second transaction (since that it's in the same thread 
as that transaction). The listener method itself could inject @TransactionScoped objects (including JMSContexts), where 
the transaction used would be the one started and ended by the JMS provider/RA.

Nigel

From arjan.tijms at gmail.com  Wed Aug 26 08:26:16 2015
From: arjan.tijms at gmail.com (arjan tijms)
Date: Wed, 26 Aug 2015 14:26:16 +0200
Subject: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean in a
 Java EE application to listen for JMS messages
In-Reply-To: <55DDAAFE.20602@oracle.com>
References: <55DB4692.7040304@oracle.com>
	<CA+ZZq9_Brvtks=jxQ1TbtXMNm+ab3w3GZfG-2sGQYeMK2mu2jA@mail.gmail.com>
	<55DB74E7.4080609@oracle.com>
	<CAE=-AhAd-dPbr1sAANiHQ4eD0BF2YA601Emk6+jk9fb_YOCgLQ@mail.gmail.com>
	<CAOqetn8mn0eWGWVo3AiwJZu_A4nDngsgzj3cjiSqVGUPx09UEA@mail.gmail.com>
	<CAE=-AhBBSPw1ZRdzSQOJm1aRKiTxKo0tBHagv8_bn9D=g2B+HQ@mail.gmail.com>
	<55DCA0C0.9080900@oracle.com>
	<CAE=-AhCnTyS-ZVAfT9k2jDK=k6QHW4ShUab_Vt+e6WmBN76gWg@mail.gmail.com>
	<CACLE=7PQaDz4fmXW2f39PN_+zdXioDfAu987OSuaxodBZx=SyQ@mail.gmail.com>
	<CAE=-AhBcnrC6xOdRSXtBdg-7JgfcKcGQMgtow4V0PPVspKxr_Q@mail.gmail.com>
	<CACLE=7NfLo0ZXvSG2Ae1mLRd2kGWWjmr6E0=kL6gyb5jHb7fdA@mail.gmail.com>
	<CAE=-AhBb6e_LM4OV3zyH_k-g7PpBN=3=DAyVa3C54+2EtBK7-g@mail.gmail.com>
	<55DD9A9A.1070503@oracle.com>
	<CAOqetn8LhNvq+4ELzuq-MLA3=6eVP3-k_AMQ8502=ag4jy4ZCg@mail.gmail.com>
	<55DDAAFE.20602@oracle.com>
Message-ID: <CAE=-AhCBjLK5HWEcPoJkYW96K1Yu9VdOWiTRamLN3Ss7KYkM1A@mail.gmail.com>

Hi,

On Wed, Aug 26, 2015 at 2:03 PM, Nigel Deakin <nigel.deakin at oracle.com> wrote:
> In the case of a "JMS listener bean" with @RequestScoped (or any scope,
> really) then the JMS consumer (the thread which receives a message from the
> JMS server and invokes the listener) is associated with the actual bean
> instance.

Indeed, so the call takes place in the context of the JMS consumer
thread and happens to the "bare" bean instance and does not go through
the proxy that's normally used to access that bean.


> However once you're inside the callback method then this request scope
> (which relates to a different thread) is not available.

So this would be an important detail for the user to take into
account. The callback method is NOT allowed to access any other normal
scoped beans, be it via injection, beanmanager lookup or whatever.

E.g. given:

@RequestScoped
public class MyCDIBean21 {

  @Inject
  private MyRequestScopedBean requestBean;

   @JMSListener(lookup="java:global/java:global/Trades",type=JMSListener.Type.TOPIC
)
   @JMSConnectionFactory("java:global/MyCF")
   @MessageSelector("ticker='ORCL'")
   public void processNewsItem(String newsItem) {
     ...
   }
 }

Then the callback processNewsItem() can not use requestBean, since
it's a proxy and it will try to delegate to a scope that does not
exist for that thread.

Alternative, if there's an other @RequestScope active (as suggested
below) it will end up calling a different bean instance than the user
may expect.

While it could work, I wonder if this aspect wouldn't be a bit confusing?

From werner.keil at gmail.com  Wed Aug 26 08:26:16 2015
From: werner.keil at gmail.com (Werner Keil)
Date: Wed, 26 Aug 2015 14:26:16 +0200
Subject: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean in a
 Java EE application to listen for JMS messages
Message-ID: <CAAGawe2sJitUPvHJM7DZTW0pTrjLOKdZif1HpXU1UWwYcZ1Dzw@mail.gmail.com>

I can confirm, in my example for routing events, the BookingBean injected
into a BookingMDB and listening Observer class also had to
be @RequestScoped.

Werner

On Wed, Aug 26, 2015 at 2:03 PM, <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: JMS 2.1: Proposal to allow any CDI managed bean in a Java
>       EE application to listen for JMS messages (Nigel Deakin)
>    2. Re: JMS 2.1: Proposal to allow any CDI managed bean in a Java
>       EE application to listen for JMS messages (John D. Ament)
>
> ----------------------------------------------------------------------
>
> Message: 2
> Date: Wed, 26 Aug 2015 11:10:11 +0000
> From: "John D. Ament" <john.d.ament at gmail.com>
> Subject: Re: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean
>         in a Java EE application to listen for JMS messages
> To: Nigel Deakin <nigel.deakin at oracle.com>,     arjan tijms
>         <arjan.tijms at gmail.com>,        Romain Manni-Bucau <
> rmannibucau at gmail.com>
> Cc: cdi-dev <cdi-dev at lists.jboss.org>
> Message-ID:
>         <CAOqetn8LhNvq+4ELzuq-MLA3=6eVP3-k_AMQ8502=
> ag4jy4ZCg at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> On Wed, Aug 26, 2015 at 6:53 AM Nigel Deakin <nigel.deakin at oracle.com>
> wrote:
>
> > On 26/08/2015 10:51, arjan tijms wrote:
> > > On Wed, Aug 26, 2015 at 11:09 AM, Romain Manni-Bucau
> > > <rmannibucau at gmail.com> wrote:
> > >> Agree for provided scope but JMS + short time scopes will not match
> > well in
> > >> practise so i would worry more about not "default" scopes which can
> miss
> > >> these events.
> > >
> > > Short lived scopes like @RequestScoped may not be the best match
> indeed.
> > >
> > > Additionally, @RequestScoped is kinda assumed to be an "@ThreadScoped"
> > > thing, e.g. there's the expectation that only the current thread will
> > > access it. If the JMS provider will asynchronously call a method on
> > > the bean instance from another thread, then this breaks this
> > > assumption.
> >
> > That's an interesting point. Is there anything in the CDI spec which
> would
> > forbid the use of a @RequestScoped JMS
> > listener bean from another thread?
> >
>
> The CDI spec still mandates that a request scope is started for delivery to
> MDBs.  See
> http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#request_context
>
> The JMS provider would be responsible for retrieving a contextual reference
> to the bean and then invoking the method.  The container should still be
> responsible for starting the request context (If I read this correctly).
>
> Likewise, we could say that a @TransactionScoped bean also applies here,
> since a JTA transaction should have been started by the RA.
>
>
> >
> > Perhaps all that is needed is to make it clear to users that this is what
> > would happen. The same issue would arise if
> > the user injected a dependent-scoped JMS listener bean into a
> > @RequestScoped bean.
> >
> > It's worth considering threading more generally. Although the JMS
> provider
> > (resource adapter, actually) can make sure
> > that the callback method won't be called from multiple JMS provider
> > threads at the same time, it can't guarantee that an
> > application thread won't be calling a business method on the bean at the
> > same time. (Would it want to?)
> >
> > Nigel
> > _______________________________________________
> > 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/20150826/bb408008/attachment-0001.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 24
> ***************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150826/bf6b4cf0/attachment.html 

From jharting at redhat.com  Wed Aug 26 09:04:06 2015
From: jharting at redhat.com (Jozef Hartinger)
Date: Wed, 26 Aug 2015 15:04:06 +0200
Subject: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean in a
 Java EE application to listen for JMS messages
In-Reply-To: <55DD8A4C.7050107@oracle.com>
References: <55DB4692.7040304@oracle.com>
	<CA+ZZq9_Brvtks=jxQ1TbtXMNm+ab3w3GZfG-2sGQYeMK2mu2jA@mail.gmail.com>
	<55DB74E7.4080609@oracle.com>
	<CAOqetn9XTi0zSHMs9y_c3-XT1ghwTxog03BKwb+4=Jw3aPbPWg@mail.gmail.com>
	<55DC72D0.5090608@oracle.com>
	<CACLE=7Ne_okSRKHa74WGAnZCzGy8ds=m=L_ArWWVzyxc1-LA0g@mail.gmail.com>
	<55DC7B0D.8080200@redhat.com> <55DD8A4C.7050107@oracle.com>
Message-ID: <55DDB946.9050208@redhat.com>

To me the proposed approach seems to be very strict about JMS semantics 
and bending CDI over it (not using CDI contextual instances properly, 
calling @RequestScoped instances from multiple threads in parallel, ..).

A simpler approach would be a bridge where a JMS message would produce a 
single CDI event. The semantics of synchronous CDI events would apply 
from there. For users this should be straightforward as they would know 
that they are working with a CDI event that was raised by the container 
when it received a JMS message.

Jozef


On 26.08.2015 11:43, Nigel Deakin wrote:
>  > On 25.08.2015 16:05, Romain Manni-Bucau wrote:
>  >>
>  >> For this last case a really elegant solution would be to just reuse
>  >> @Observes to fire the message from the jms "container" listener and
>  >> propagate it to the "user" listener. This would then allow to decouple
>  >> the application listener from JMS.
>
> On 25/08/2015 15:26, Jozef Hartinger wrote:
>> Agreed. I think we should leverage the existing CDI event/observer
>> functionality instead of introducing a completely new
>> delivery mechanism.
>
> Can you please say a bit more about what you have in mind?
>
> Romain suggests using events to invoke the "user" listener from the "JMS
> container listener".
> That's a useful distinction. Just to clarify the terminology:
>
> "user" listener = listener bean provided by the application
> "JMS container listener" = JMS consumer provided by the application
> server or resource adapter
>
> There needs to be one consumer for every listener bean since the two
> need to have the same lifecycle, and also so we can implement JMS queue
> sematics which require that a message from a queue is delivered to one
> and only one listener.
>
> The transaction needs to be started by the consumer before invoking the
> listener and ended after the listener returns. This allows the
> acknowledgement of the message (which is performed by the consumer) to
> take place in the same transaction as is used by the listener's method.
>
> Currently I'm proposing that the "consumer" invokes the "listener" by a
> simple method call. I suppose instead of simply invoking the method it
> could fire a synchronous event, which only the associated listener
> instance would receive, but I'm not sure what the benefit of this would
> be. Since JMS semantics are very different from CDI event semantics I
> think there's a danger that this will be confusing, since the user might
> think they were getting CDI event semantics, but they were actually
> getting JMS semantics.
>
> Since this is a bit of a FAQ, it might be useful to explore the
> differences between the two semantics, but currently they seem
> profoundly different to me. That's why my proposals are built on the CDI
> bean lifecycle model but not the CDI event observer model.
>
> Nigel
>

From nigel.deakin at oracle.com  Wed Aug 26 09:50:26 2015
From: nigel.deakin at oracle.com (Nigel Deakin)
Date: Wed, 26 Aug 2015 14:50:26 +0100
Subject: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean in a
 Java EE application to listen for JMS messages
In-Reply-To: <CAE=-AhCBjLK5HWEcPoJkYW96K1Yu9VdOWiTRamLN3Ss7KYkM1A@mail.gmail.com>
References: <55DB4692.7040304@oracle.com>
	<CA+ZZq9_Brvtks=jxQ1TbtXMNm+ab3w3GZfG-2sGQYeMK2mu2jA@mail.gmail.com>
	<55DB74E7.4080609@oracle.com>
	<CAE=-AhAd-dPbr1sAANiHQ4eD0BF2YA601Emk6+jk9fb_YOCgLQ@mail.gmail.com>
	<CAOqetn8mn0eWGWVo3AiwJZu_A4nDngsgzj3cjiSqVGUPx09UEA@mail.gmail.com>
	<CAE=-AhBBSPw1ZRdzSQOJm1aRKiTxKo0tBHagv8_bn9D=g2B+HQ@mail.gmail.com>
	<55DCA0C0.9080900@oracle.com>
	<CAE=-AhCnTyS-ZVAfT9k2jDK=k6QHW4ShUab_Vt+e6WmBN76gWg@mail.gmail.com>
	<CACLE=7PQaDz4fmXW2f39PN_+zdXioDfAu987OSuaxodBZx=SyQ@mail.gmail.com>
	<CAE=-AhBcnrC6xOdRSXtBdg-7JgfcKcGQMgtow4V0PPVspKxr_Q@mail.gmail.com>
	<CACLE=7NfLo0ZXvSG2Ae1mLRd2kGWWjmr6E0=kL6gyb5jHb7fdA@mail.gmail.com>
	<CAE=-AhBb6e_LM4OV3zyH_k-g7PpBN=3=DAyVa3C54+2EtBK7-g@mail.gmail.com>
	<55DD9A9A.1070503@oracle.com>
	<CAOqetn8LhNvq+4ELzuq-MLA3=6eVP3-k_AMQ8502=ag4jy4ZCg@mail.gmail.com>
	<55DDAAFE.20602@oracle.com>
	<CAE=-AhCBjLK5HWEcPoJkYW96K1Yu9VdOWiTRamLN3Ss7KYkM1A@mail.gmail.com>
Message-ID: <55DDC422.7000907@oracle.com>

On 26/08/2015 13:26, arjan tijms wrote:
> Hi,
>
> On Wed, Aug 26, 2015 at 2:03 PM, Nigel Deakin <nigel.deakin at oracle.com> wrote:
>> In the case of a "JMS listener bean" with @RequestScoped (or any scope,
>> really) then the JMS consumer (the thread which receives a message from the
>> JMS server and invokes the listener) is associated with the actual bean
>> instance.
>
> Indeed, so the call takes place in the context of the JMS consumer
> thread and happens to the "bare" bean instance and does not go through
> the proxy that's normally used to access that bean.
>
>
>> However once you're inside the callback method then this request scope
>> (which relates to a different thread) is not available.
>
> So this would be an important detail for the user to take into
> account. The callback method is NOT allowed to access any other normal
> scoped beans, be it via injection, beanmanager lookup or whatever.
>
> E.g. given:
>
> @RequestScoped
> public class MyCDIBean21 {
>
>    @Inject
>    private MyRequestScopedBean requestBean;
>
>     @JMSListener(lookup="java:global/java:global/Trades",type=JMSListener.Type.TOPIC
> )
>     @JMSConnectionFactory("java:global/MyCF")
>     @MessageSelector("ticker='ORCL'")
>     public void processNewsItem(String newsItem) {
>       ...
>     }
>   }
>
> Then the callback processNewsItem() can not use requestBean, since
> it's a proxy and it will try to delegate to a scope that does not
> exist for that thread.
>
> Alternative, if there's an other @RequestScope active (as suggested
> below) it will end up calling a different bean instance than the user
> may expect.

Yes, I can see how that might be surprising.

However it looks as if this is exactly what is proposed in CDI 2.0 for asynchronous observer methods:

10.5.3 "Observer method invocation context" states "If the observer method is asynchronous, it is called in a new 
lifecycle contexts, a new transaction context but the same security context as the invocation of Event.fireAsync()."

19.3.1. "Request context lifecycle in Java EE". States that "The request scope is active...during any asynchronous 
invocation of an event observer".

Please correct me if I have misunderstood what is proposed.

> While it could work, I wonder if this aspect wouldn't be a bit confusing?

Good question!

Nigel

From werner.keil at gmail.com  Wed Aug 26 10:22:16 2015
From: werner.keil at gmail.com (Werner Keil)
Date: Wed, 26 Aug 2015 16:22:16 +0200
Subject: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean in a
 Java EE application to listen for JMS messages
Message-ID: <CAAGawe0mOjOTwu+SzSp5qLnDRAzNX_x4qaJnLePamB+F2-ze2g@mail.gmail.com>

Jozef,

Can't say to what extent this could also apply for JMS but just wanted to
point to the recent Portlet 3 draft
https://java.net/downloads/portletspec3/SpecDrafts/PortletSpec3-Draft1-20150821.pdf
(20.2 Custom Scopes) where the JSR intends to add new CDI scopes for
certain parts of the standard while using the ones Java EE/CDI defines in
other cases.

Werner

On Wed, Aug 26, 2015 at 3:50 PM, <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: JMS 2.1: Proposal to allow any CDI managed bean in a Java
>       EE application to listen for JMS messages (arjan tijms)
>    2. Re: JMS 2.1: Proposal to allow any CDI managed bean in a Java
>       EE application to listen for JMS messages (Werner Keil)
>    3. Re: JMS 2.1: Proposal to allow any CDI managed bean in a Java
>       EE application to listen for JMS messages (Jozef Hartinger)
>    4. Re: JMS 2.1: Proposal to allow any CDI managed bean in a Java
>       EE application to listen for JMS messages (Nigel Deakin)
>
>
> ----------------------------------------------------------------------
>
> Message: 3
> Date: Wed, 26 Aug 2015 15:04:06 +0200
> From: Jozef Hartinger <jharting at redhat.com>
> Subject: Re: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean
>         in a Java EE application to listen for JMS messages
> To: Nigel Deakin <nigel.deakin at oracle.com>,     Romain Manni-Bucau
>         <rmannibucau at gmail.com>
> Cc: cdi-dev <cdi-dev at lists.jboss.org>
> Message-ID: <55DDB946.9050208 at redhat.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> To me the proposed approach seems to be very strict about JMS semantics
> and bending CDI over it (not using CDI contextual instances properly,
> calling @RequestScoped instances from multiple threads in parallel, ..).
>
> A simpler approach would be a bridge where a JMS message would produce a
> single CDI event. The semantics of synchronous CDI events would apply
> from there. For users this should be straightforward as they would know
> that they are working with a CDI event that was raised by the container
> when it received a JMS message.
>
> Jozef
>
>
> On 26.08.2015 11:43, Nigel Deakin wrote:
> >  > On 25.08.2015 16:05, Romain Manni-Bucau wrote:
> >  >>
> >  >> For this last case a really elegant solution would be to just reuse
> >  >> @Observes to fire the message from the jms "container" listener and
> >  >> propagate it to the "user" listener. This would then allow to
> decouple
> >  >> the application listener from JMS.
> >
> > On 25/08/2015 15:26, Jozef Hartinger wrote:
> >> Agreed. I think we should leverage the existing CDI event/observer
> >> functionality instead of introducing a completely new
> >> delivery mechanism.
> >
> > Can you please say a bit more about what you have in mind?
> >
> > Romain suggests using events to invoke the "user" listener from the "JMS
> > container listener".
> > That's a useful distinction. Just to clarify the terminology:
> >
> > "user" listener = listener bean provided by the application
> > "JMS container listener" = JMS consumer provided by the application
> > server or resource adapter
> >
> > There needs to be one consumer for every listener bean since the two
> > need to have the same lifecycle, and also so we can implement JMS queue
> > sematics which require that a message from a queue is delivered to one
> > and only one listener.
> >
> > The transaction needs to be started by the consumer before invoking the
> > listener and ended after the listener returns. This allows the
> > acknowledgement of the message (which is performed by the consumer) to
> > take place in the same transaction as is used by the listener's method.
> >
> > Currently I'm proposing that the "consumer" invokes the "listener" by a
> > simple method call. I suppose instead of simply invoking the method it
> > could fire a synchronous event, which only the associated listener
> > instance would receive, but I'm not sure what the benefit of this would
> > be. Since JMS semantics are very different from CDI event semantics I
> > think there's a danger that this will be confusing, since the user might
> > think they were getting CDI event semantics, but they were actually
> > getting JMS semantics.
> >
> > Since this is a bit of a FAQ, it might be useful to explore the
> > differences between the two semantics, but currently they seem
> > profoundly different to me. That's why my proposals are built on the CDI
> > bean lifecycle model but not the CDI event observer model.
> >
> > Nigel
> >
>
>
> ------------------------------
>
> Message: 4
> Date: Wed, 26 Aug 2015 14:50:26 +0100
> From: Nigel Deakin <nigel.deakin at oracle.com>
> Subject: Re: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean
>         in a Java EE application to listen for JMS messages
> To: arjan tijms <arjan.tijms at gmail.com>
> Cc: cdi-dev <cdi-dev at lists.jboss.org>
> Message-ID: <55DDC422.7000907 at oracle.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> On 26/08/2015 13:26, arjan tijms wrote:
> > Hi,
> >
> > On Wed, Aug 26, 2015 at 2:03 PM, Nigel Deakin <nigel.deakin at oracle.com>
> wrote:
> >> In the case of a "JMS listener bean" with @RequestScoped (or any scope,
> >> really) then the JMS consumer (the thread which receives a message from
> the
> >> JMS server and invokes the listener) is associated with the actual bean
> >> instance.
> >
> > Indeed, so the call takes place in the context of the JMS consumer
> > thread and happens to the "bare" bean instance and does not go through
> > the proxy that's normally used to access that bean.
> >
> >
> >> However once you're inside the callback method then this request scope
> >> (which relates to a different thread) is not available.
> >
> > So this would be an important detail for the user to take into
> > account. The callback method is NOT allowed to access any other normal
> > scoped beans, be it via injection, beanmanager lookup or whatever.
> >
> > E.g. given:
> >
> > @RequestScoped
> > public class MyCDIBean21 {
> >
> >    @Inject
> >    private MyRequestScopedBean requestBean;
> >
> >
>  @JMSListener(lookup="java:global/java:global/Trades",type=JMSListener.Type.TOPIC
> > )
> >     @JMSConnectionFactory("java:global/MyCF")
> >     @MessageSelector("ticker='ORCL'")
> >     public void processNewsItem(String newsItem) {
> >       ...
> >     }
> >   }
> >
> > Then the callback processNewsItem() can not use requestBean, since
> > it's a proxy and it will try to delegate to a scope that does not
> > exist for that thread.
> >
> > Alternative, if there's an other @RequestScope active (as suggested
> > below) it will end up calling a different bean instance than the user
> > may expect.
>
> Yes, I can see how that might be surprising.
>
> However it looks as if this is exactly what is proposed in CDI 2.0 for
> asynchronous observer methods:
>
> 10.5.3 "Observer method invocation context" states "If the observer method
> is asynchronous, it is called in a new
> lifecycle contexts, a new transaction context but the same security
> context as the invocation of Event.fireAsync()."
>
> 19.3.1. "Request context lifecycle in Java EE". States that "The request
> scope is active...during any asynchronous
> invocation of an event observer".
>
> Please correct me if I have misunderstood what is proposed.
>
> > While it could work, I wonder if this aspect wouldn't be a bit confusing?
>
> Good question!
>
> Nigel
>
>
> ------------------------------
>
> _______________________________________________
> 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 25
> ***************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150826/ce8efcae/attachment.html 

From arjan.tijms at gmail.com  Wed Aug 26 10:56:15 2015
From: arjan.tijms at gmail.com (arjan tijms)
Date: Wed, 26 Aug 2015 16:56:15 +0200
Subject: [cdi-dev] Problem with JDK8 u60 and synthesized methods for lambdas
 now exposing annotations
Message-ID: <CAE=-AhC=-D8-z-5+3e-SLk5UYtAQc1=kfEjbtur=i344Gsx-BQ@mail.gmail.com>

Hi,

We just discovered an issue where using a lambda in an observer method
results in a synthesized method for that lambda that since u60 makes
the @Observes annotation visible. This will cause CDI (Weld
2.2.2.Final in this case as shipped with GlassFish 4.1) to see this
generated method as an actual observer method.

See the following mail on the OpenJDK list for details:

http://mail.openjdk.java.net/pipermail/lambda-dev/2015-August/012146.html/012146.html

The suggestion there is that it's simply a bug in the CDI implementation.

I wonder, should the CDI spec in general say that synthesized methods
should be ignored when scanning for observer (and possible other)
methods? I briefly scanned through the spec but didn't see any
references to synthesized methods.

Kind regards,
Arjan Tijms

From antoine at sabot-durand.net  Wed Aug 26 12:13:15 2015
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Wed, 26 Aug 2015 16:13:15 +0000
Subject: [cdi-dev] Problem with JDK8 u60 and synthesized methods for
 lambdas now exposing annotations
In-Reply-To: <CAE=-AhC=-D8-z-5+3e-SLk5UYtAQc1=kfEjbtur=i344Gsx-BQ@mail.gmail.com>
References: <CAE=-AhC=-D8-z-5+3e-SLk5UYtAQc1=kfEjbtur=i344Gsx-BQ@mail.gmail.com>
Message-ID: <CABu-YBQ_WmGt_LVeZ4KiFtNgnLYkCnearTM_QtP4XUfN9wU4PQ@mail.gmail.com>

Hi Arjan,

I'm not sure that we should state that in the spec. The fact that the
compiler generates a synthetic method for the lambda is a java
implementation choice. Our implementation should only consider code written
by user not the one generated by the compiler. Wdyt Jozef ?

Antoine

Le mer. 26 ao?t 2015 ? 16:56, arjan tijms <arjan.tijms at gmail.com> a ?crit :

> Hi,
>
> We just discovered an issue where using a lambda in an observer method
> results in a synthesized method for that lambda that since u60 makes
> the @Observes annotation visible. This will cause CDI (Weld
> 2.2.2.Final in this case as shipped with GlassFish 4.1) to see this
> generated method as an actual observer method.
>
> See the following mail on the OpenJDK list for details:
>
>
> http://mail.openjdk.java.net/pipermail/lambda-dev/2015-August/012146.html/012146.html
>
> The suggestion there is that it's simply a bug in the CDI implementation.
>
> I wonder, should the CDI spec in general say that synthesized methods
> should be ignored when scanning for observer (and possible other)
> methods? I briefly scanned through the spec but didn't see any
> references to synthesized methods.
>
> Kind regards,
> Arjan Tijms
> _______________________________________________
> 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/20150826/6e6dad87/attachment-0001.html 

From jharting at redhat.com  Thu Aug 27 03:17:16 2015
From: jharting at redhat.com (Jozef Hartinger)
Date: Thu, 27 Aug 2015 09:17:16 +0200
Subject: [cdi-dev] Problem with JDK8 u60 and synthesized methods for
 lambdas now exposing annotations
In-Reply-To: <CAE=-AhC=-D8-z-5+3e-SLk5UYtAQc1=kfEjbtur=i344Gsx-BQ@mail.gmail.com>
References: <CAE=-AhC=-D8-z-5+3e-SLk5UYtAQc1=kfEjbtur=i344Gsx-BQ@mail.gmail.com>
Message-ID: <55DEB97C.1050408@redhat.com>

Agreed, this looks like a bug in Weld.

On 26.08.2015 16:56, arjan tijms wrote:
> Hi,
>
> We just discovered an issue where using a lambda in an observer method
> results in a synthesized method for that lambda that since u60 makes
> the @Observes annotation visible. This will cause CDI (Weld
> 2.2.2.Final in this case as shipped with GlassFish 4.1) to see this
> generated method as an actual observer method.
>
> See the following mail on the OpenJDK list for details:
>
> http://mail.openjdk.java.net/pipermail/lambda-dev/2015-August/012146.html/012146.html
>
> The suggestion there is that it's simply a bug in the CDI implementation.
>
> I wonder, should the CDI spec in general say that synthesized methods
> should be ignored when scanning for observer (and possible other)
> methods? I briefly scanned through the spec but didn't see any
> references to synthesized methods.
>
> Kind regards,
> Arjan Tijms
> _______________________________________________
> 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.
>

From john.d.ament at gmail.com  Thu Aug 27 06:58:35 2015
From: john.d.ament at gmail.com (John D. Ament)
Date: Thu, 27 Aug 2015 10:58:35 +0000
Subject: [cdi-dev] Problem with JDK8 u60 and synthesized methods for
 lambdas now exposing annotations
In-Reply-To: <CABu-YBQ_WmGt_LVeZ4KiFtNgnLYkCnearTM_QtP4XUfN9wU4PQ@mail.gmail.com>
References: <CAE=-AhC=-D8-z-5+3e-SLk5UYtAQc1=kfEjbtur=i344Gsx-BQ@mail.gmail.com>
	<CABu-YBQ_WmGt_LVeZ4KiFtNgnLYkCnearTM_QtP4XUfN9wU4PQ@mail.gmail.com>
Message-ID: <CAOqetn-MSOsRTxMKvfkNAyjU2utZeNmad6xpmrk0uoxdnPiiCg@mail.gmail.com>

I'd be concerned if we introduced text explicitly calling out code written
by the developer instead of generated by the compiler.  What if I'm using
an annotation processor that generated implementations for CDI beans? Those
would get ignored.

Better to say something along the lines of synthesized methods are not
typically visible, therefore shouldn't be scanned.

John

On Wed, Aug 26, 2015 at 12:14 PM Antoine Sabot-Durand <
antoine at sabot-durand.net> wrote:

> Hi Arjan,
>
> I'm not sure that we should state that in the spec. The fact that the
> compiler generates a synthetic method for the lambda is a java
> implementation choice. Our implementation should only consider code written
> by user not the one generated by the compiler. Wdyt Jozef ?
>
> Antoine
>
> Le mer. 26 ao?t 2015 ? 16:56, arjan tijms <arjan.tijms at gmail.com> a
> ?crit :
>
>> Hi,
>>
>> We just discovered an issue where using a lambda in an observer method
>> results in a synthesized method for that lambda that since u60 makes
>> the @Observes annotation visible. This will cause CDI (Weld
>> 2.2.2.Final in this case as shipped with GlassFish 4.1) to see this
>> generated method as an actual observer method.
>>
>> See the following mail on the OpenJDK list for details:
>>
>>
>> http://mail.openjdk.java.net/pipermail/lambda-dev/2015-August/012146.html/012146.html
>>
>> The suggestion there is that it's simply a bug in the CDI implementation.
>>
>> I wonder, should the CDI spec in general say that synthesized methods
>> should be ignored when scanning for observer (and possible other)
>> methods? I briefly scanned through the spec but didn't see any
>> references to synthesized methods.
>>
>> Kind regards,
>> Arjan Tijms
>> _______________________________________________
>> 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/20150827/068b5b6e/attachment.html 

From arjan.tijms at gmail.com  Thu Aug 27 08:18:48 2015
From: arjan.tijms at gmail.com (arjan tijms)
Date: Thu, 27 Aug 2015 14:18:48 +0200
Subject: [cdi-dev] Problem with JDK8 u60 and synthesized methods for
 lambdas now exposing annotations
In-Reply-To: <55DEB97C.1050408@redhat.com>
References: <CAE=-AhC=-D8-z-5+3e-SLk5UYtAQc1=kfEjbtur=i344Gsx-BQ@mail.gmail.com>
	<55DEB97C.1050408@redhat.com>
Message-ID: <CAE=-AhDmio0aE8imnSry9U-V4OKiMF-3ytYV+rr8WAj9dJEvXQ@mail.gmail.com>

On Thu, Aug 27, 2015 at 9:17 AM, Jozef Hartinger <jharting at redhat.com> wrote:
> Agreed, this looks like a bug in Weld.

I checked on OWB too (using TomEE 7.0-snapshot), this time using the
reproducer as given here: https://github.com/payara/Payara/issues/407

And on OWB there did not seem to be any problems.

To double check I added another observer method to the test class that
should fail deployment, namely:

   public void foo(@Observes String someString, Integer thisshouldFail) {
        List<String> strList = Arrays.asList("s1", "s2", "s3");
        final int a = 0;
        final int b = 1;

        strList.forEach((s) -> { System.out.printf("%s - %d - %d -
%s\n", someString, a, b, s); });
    }

And that one indeed failed (as it should).

So it looks like this particular problem is localized to Weld.

From rmannibucau at gmail.com  Thu Aug 27 08:22:04 2015
From: rmannibucau at gmail.com (Romain Manni-Bucau)
Date: Thu, 27 Aug 2015 14:22:04 +0200
Subject: [cdi-dev] Problem with JDK8 u60 and synthesized methods for
 lambdas now exposing annotations
In-Reply-To: <CAE=-AhDmio0aE8imnSry9U-V4OKiMF-3ytYV+rr8WAj9dJEvXQ@mail.gmail.com>
References: <CAE=-AhC=-D8-z-5+3e-SLk5UYtAQc1=kfEjbtur=i344Gsx-BQ@mail.gmail.com>
	<55DEB97C.1050408@redhat.com>
	<CAE=-AhDmio0aE8imnSry9U-V4OKiMF-3ytYV+rr8WAj9dJEvXQ@mail.gmail.com>
Message-ID: <CACLE=7NouyO6D6Bv_TsRpC+rABP8xA7E=C7sgSesP8Dney_GAQ@mail.gmail.com>

OWB handles synthetic methods already AFAIK, surely why we see this behavior


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com>

2015-08-27 14:18 GMT+02:00 arjan tijms <arjan.tijms at gmail.com>:

> On Thu, Aug 27, 2015 at 9:17 AM, Jozef Hartinger <jharting at redhat.com>
> wrote:
> > Agreed, this looks like a bug in Weld.
>
> I checked on OWB too (using TomEE 7.0-snapshot), this time using the
> reproducer as given here: https://github.com/payara/Payara/issues/407
>
> And on OWB there did not seem to be any problems.
>
> To double check I added another observer method to the test class that
> should fail deployment, namely:
>
>    public void foo(@Observes String someString, Integer thisshouldFail) {
>         List<String> strList = Arrays.asList("s1", "s2", "s3");
>         final int a = 0;
>         final int b = 1;
>
>         strList.forEach((s) -> { System.out.printf("%s - %d - %d -
> %s\n", someString, a, b, s); });
>     }
>
> And that one indeed failed (as it should).
>
> So it looks like this particular problem is localized to Weld.
> _______________________________________________
> 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/20150827/a599e263/attachment.html 

From nigel.deakin at oracle.com  Thu Aug 27 11:31:25 2015
From: nigel.deakin at oracle.com (Nigel Deakin)
Date: Thu, 27 Aug 2015 16:31:25 +0100
Subject: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean in a
 Java EE application to listen for JMS messages
In-Reply-To: <CACLE=7O3b8WM79ueUcmuDq5Vi_UC5o2gObU8MnK8tqGJMcGfOQ@mail.gmail.com>
References: <55DB4692.7040304@oracle.com>
	<CA+ZZq9_Brvtks=jxQ1TbtXMNm+ab3w3GZfG-2sGQYeMK2mu2jA@mail.gmail.com>
	<55DB74E7.4080609@oracle.com>
	<CAOqetn9XTi0zSHMs9y_c3-XT1ghwTxog03BKwb+4=Jw3aPbPWg@mail.gmail.com>
	<55DC72D0.5090608@oracle.com>
	<CAOqetn-rUz=7F+oeymXrxH=OHMRzXC+9-n3LcsHnDQ4_Kq8Lyg@mail.gmail.com>
	<55DC970A.4050607@oracle.com>
	<CACLE=7PEBZomd7tuJby7F1zcrdr_sEFif=z1xgVMPPCZMXY=0g@mail.gmail.com>
	<55DC9EA1.408@oracle.com>
	<CACLE=7ML=yNsn2vRW6MX_2cNjAMedGnd2bjAPjg=7KLRn6etvQ@mail.gmail.com>
	<55DCA17D.9050602@oracle.com>
	<CACLE=7N8mNhvYh_g2W+D97zH4f5pKpH3a0sz1wDfJgdWu_scOg@mail.gmail.com>
	<55DD81B5.9040407@oracle.com>
	<CACLE=7O3b8WM79ueUcmuDq5Vi_UC5o2gObU8MnK8tqGJMcGfOQ@mail.gmail.com>
Message-ID: <55DF2D4D.5070301@oracle.com>

On 26/08/2015 10:16, Romain Manni-Bucau wrote:
>
>
> The sample I gave before with the JmsStart event basically:
>
>
> public class JmsRegistrar {
>      @Inject
>      @JmsConnectionFactory(...)
>      private ConnectionFactory factory;
>
>      @Inject
>      @JmsQueue(...)
>      private Queue queue;
>
>      public void startJms(@Observes JmsStart start) {
>          start.withFactory(factory) // withFactory should be optional if only 1 bean matches it
>                 .register(MyCdiTypedListener.class) // with defaults for all potential config
>                     .listenOn(queue)
>                 .register(MyCdiTypedListener2.class, new MyLiteral())
>                      .withMaxSessions(10)
>                      .listenOn(Queue.class, new QueueLiteral(...))
>                      ......;
>      }
> }
>
>
> The power of it appears when you have a config injection in JmsRegistrar you can iterate over to get the list of
> listener for instance.
>
> Also JMS resources can be decorated and referenced from qualifiers instead of instances thanks to CDI.
>
> It doesnt prevent the app to use @JmxListener somewhere else if the listener doesnt need any input/config to be registered.
>

I'm trying to understand this. Are you suggesting that

1. When the application is started an event of type JmsStart is fired. This class will be defined by JMS and implemented 
by the application server.

2. The application defines a class (in this example called JmsRegistrar). This has a method startJms which receives the 
event.

3. JmsStart (the event class) has several builder methods. The most important of these is register() which you can use 
to specify the class of a listener. The other methods withFactory, register, withMaxSession and listenOn specify things 
like which connection factory is used, which queue is used and so on.

This doesn't look very different from the normal JMS API, except that it uses a builder pattern and is triggered 
automatically at startup. Apart from triggering the initial event, what is CDI doing for you here?

Nigel

From rmannibucau at gmail.com  Thu Aug 27 11:35:02 2015
From: rmannibucau at gmail.com (Romain Manni-Bucau)
Date: Thu, 27 Aug 2015 17:35:02 +0200
Subject: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean in a
 Java EE application to listen for JMS messages
In-Reply-To: <55DF2D4D.5070301@oracle.com>
References: <55DB4692.7040304@oracle.com>
	<CA+ZZq9_Brvtks=jxQ1TbtXMNm+ab3w3GZfG-2sGQYeMK2mu2jA@mail.gmail.com>
	<55DB74E7.4080609@oracle.com>
	<CAOqetn9XTi0zSHMs9y_c3-XT1ghwTxog03BKwb+4=Jw3aPbPWg@mail.gmail.com>
	<55DC72D0.5090608@oracle.com>
	<CAOqetn-rUz=7F+oeymXrxH=OHMRzXC+9-n3LcsHnDQ4_Kq8Lyg@mail.gmail.com>
	<55DC970A.4050607@oracle.com>
	<CACLE=7PEBZomd7tuJby7F1zcrdr_sEFif=z1xgVMPPCZMXY=0g@mail.gmail.com>
	<55DC9EA1.408@oracle.com>
	<CACLE=7ML=yNsn2vRW6MX_2cNjAMedGnd2bjAPjg=7KLRn6etvQ@mail.gmail.com>
	<55DCA17D.9050602@oracle.com>
	<CACLE=7N8mNhvYh_g2W+D97zH4f5pKpH3a0sz1wDfJgdWu_scOg@mail.gmail.com>
	<55DD81B5.9040407@oracle.com>
	<CACLE=7O3b8WM79ueUcmuDq5Vi_UC5o2gObU8MnK8tqGJMcGfOQ@mail.gmail.com>
	<55DF2D4D.5070301@oracle.com>
Message-ID: <CACLE=7PHhFh82-UN-KRy34nYwe982cOnc5V4OTmVGeWO2SmdCg@mail.gmail.com>

2015-08-27 17:31 GMT+02:00 Nigel Deakin <nigel.deakin at oracle.com>:

> On 26/08/2015 10:16, Romain Manni-Bucau wrote:
>
>>
>>
>> The sample I gave before with the JmsStart event basically:
>>
>>
>> public class JmsRegistrar {
>>      @Inject
>>      @JmsConnectionFactory(...)
>>      private ConnectionFactory factory;
>>
>>      @Inject
>>      @JmsQueue(...)
>>      private Queue queue;
>>
>>      public void startJms(@Observes JmsStart start) {
>>          start.withFactory(factory) // withFactory should be optional if
>> only 1 bean matches it
>>                 .register(MyCdiTypedListener.class) // with defaults for
>> all potential config
>>                     .listenOn(queue)
>>                 .register(MyCdiTypedListener2.class, new MyLiteral())
>>                      .withMaxSessions(10)
>>                      .listenOn(Queue.class, new QueueLiteral(...))
>>                      ......;
>>      }
>> }
>>
>>
>> The power of it appears when you have a config injection in JmsRegistrar
>> you can iterate over to get the list of
>> listener for instance.
>>
>> Also JMS resources can be decorated and referenced from qualifiers
>> instead of instances thanks to CDI.
>>
>> It doesnt prevent the app to use @JmxListener somewhere else if the
>> listener doesnt need any input/config to be registered.
>>
>>
> I'm trying to understand this. Are you suggesting that
>
> 1. When the application is started an event of type JmsStart is fired.
> This class will be defined by JMS and implemented by the application server.
>
> 2. The application defines a class (in this example called JmsRegistrar).
> This has a method startJms which receives the event.
>
> 3. JmsStart (the event class) has several builder methods. The most
> important of these is register() which you can use to specify the class of
> a listener. The other methods withFactory, register, withMaxSession and
> listenOn specify things like which connection factory is used, which queue
> is used and so on.
>
> This doesn't look very different from the normal JMS API, except that it
> uses a builder pattern and is triggered automatically at startup. Apart
> from triggering the initial event, what is CDI doing for you here?
>
>
Yes this is it, few details important for CDI:

1- ensure JMS is CDI ready - ie dont use it before the start event, if JMS
uses @Initialized(ApplicationScoped) then the app cant use it for instance,
same using extension AfterValidationDeployment etc...so this event is just
to ensure we dont use "JMS CDI" too early
2- JMS can use contextual instances implicitely which is not the case in SE

otherwise you are right the API is just fluent compared to what is already
there - found it nicer to expose but this point is maybe personal.


> Nigel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150827/d36d1035/attachment-0001.html 

From antoine at sabot-durand.net  Thu Aug 27 11:56:55 2015
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Thu, 27 Aug 2015 15:56:55 +0000
Subject: [cdi-dev] Exploring the interest of mutating bean manager at runtime
Message-ID: <CABu-YBQWHU+qzyiwuWTX4qYUdNLMjZExgYv_R=wGbom0uyMZ8A@mail.gmail.com>

Hi all,

This topic (modifying bean meta data at runtime) has been coming and going
since CDI 1.0.
As we are moving to Java SE with potentially more dynamic env, I think
interesting to see if there is a real need to explore it.
It's a very disruptive feature and obviously costly to add to the spec, so
I think we should start gathering proof that it would bring more power and
new usage to CDI before discussing all the problems it could raise.

I propose to g that way:

1) Launch a public consultation to ask our user if they are interested and
more than all give use real use case where it would solve a problem

2) Analyse these use cases to see if they are real or as some people think
are only a lack of knowledge of the spec

3) From there we could either left this aside if nothing relevant comes out
or start discussing the constraint around this feature.

Wdyt?

Antoine
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150827/c63bf787/attachment.html 

From nigel.deakin at oracle.com  Thu Aug 27 12:00:00 2015
From: nigel.deakin at oracle.com (Nigel Deakin)
Date: Thu, 27 Aug 2015 17:00:00 +0100
Subject: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean in a
 Java EE application to listen for JMS messages
In-Reply-To: <CACLE=7PHhFh82-UN-KRy34nYwe982cOnc5V4OTmVGeWO2SmdCg@mail.gmail.com>
References: <55DB4692.7040304@oracle.com>
	<CA+ZZq9_Brvtks=jxQ1TbtXMNm+ab3w3GZfG-2sGQYeMK2mu2jA@mail.gmail.com>
	<55DB74E7.4080609@oracle.com>
	<CAOqetn9XTi0zSHMs9y_c3-XT1ghwTxog03BKwb+4=Jw3aPbPWg@mail.gmail.com>
	<55DC72D0.5090608@oracle.com>
	<CAOqetn-rUz=7F+oeymXrxH=OHMRzXC+9-n3LcsHnDQ4_Kq8Lyg@mail.gmail.com>
	<55DC970A.4050607@oracle.com>
	<CACLE=7PEBZomd7tuJby7F1zcrdr_sEFif=z1xgVMPPCZMXY=0g@mail.gmail.com>
	<55DC9EA1.408@oracle.com>
	<CACLE=7ML=yNsn2vRW6MX_2cNjAMedGnd2bjAPjg=7KLRn6etvQ@mail.gmail.com>
	<55DCA17D.9050602@oracle.com>
	<CACLE=7N8mNhvYh_g2W+D97zH4f5pKpH3a0sz1wDfJgdWu_scOg@mail.gmail.com>
	<55DD81B5.9040407@oracle.com>
	<CACLE=7O3b8WM79ueUcmuDq5Vi_UC5o2gObU8MnK8tqGJMcGfOQ@mail.gmail.com>
	<55DF2D4D.5070301@oracle.com>
	<CACLE=7PHhFh82-UN-KRy34nYwe982cOnc5V4OTmVGeWO2SmdCg@mail.gmail.com>
Message-ID: <55DF3400.6080600@oracle.com>

On 27/08/2015 16:35, Romain Manni-Bucau wrote:
>
> 2015-08-27 17:31 GMT+02:00 Nigel Deakin <nigel.deakin at oracle.com <mailto:nigel.deakin at oracle.com>>:
>
>     On 26/08/2015 10:16, Romain Manni-Bucau wrote:
>
>
>
>         The sample I gave before with the JmsStart event basically:
>
>
>         public class JmsRegistrar {
>               @Inject
>               @JmsConnectionFactory(...)
>               private ConnectionFactory factory;
>
>               @Inject
>               @JmsQueue(...)
>               private Queue queue;
>
>               public void startJms(@Observes JmsStart start) {
>                   start.withFactory(factory) // withFactory should be optional if only 1 bean matches it
>                          .register(MyCdiTypedListener.class) // with defaults for all potential config
>                              .listenOn(queue)
>                          .register(MyCdiTypedListener2.class, new MyLiteral())
>                               .withMaxSessions(10)
>                               .listenOn(Queue.class, new QueueLiteral(...))
>                               ......;
>               }
>         }
>
>
>         The power of it appears when you have a config injection in JmsRegistrar you can iterate over to get the list of
>         listener for instance.
>
>         Also JMS resources can be decorated and referenced from qualifiers instead of instances thanks to CDI.
>
>         It doesnt prevent the app to use @JmxListener somewhere else if the listener doesnt need any input/config to be
>         registered.
>
>
>     I'm trying to understand this. Are you suggesting that
>
>     1. When the application is started an event of type JmsStart is fired. This class will be defined by JMS and
>     implemented by the application server.
>
>     2. The application defines a class (in this example called JmsRegistrar). This has a method startJms which receives
>     the event.
>
>     3. JmsStart (the event class) has several builder methods. The most important of these is register() which you can
>     use to specify the class of a listener. The other methods withFactory, register, withMaxSession and listenOn specify
>     things like which connection factory is used, which queue is used and so on.
>
>     This doesn't look very different from the normal JMS API, except that it uses a builder pattern and is triggered
>     automatically at startup. Apart from triggering the initial event, what is CDI doing for you here?
>
>
> Yes this is it, few details important for CDI:
>
> 1- ensure JMS is CDI ready - ie dont use it before the start event, if JMS uses @Initialized(ApplicationScoped) then the
> app cant use it for instance, same using extension AfterValidationDeployment etc...so this event is just to ensure we
> dont use "JMS CDI" too early
> 2- JMS can use contextual instances implicitely which is not the case in SE
>
> otherwise you are right the API is just fluent compared to what is already there - found it nicer to expose but this
> point is maybe personal.

OK. I'm interested in your statement "JMS can use contextual instances implicitly". That suggests that the method 
register(MyCdiTypedListener.class) would use some CDI API such as Instance.get() to obtain an instance of 
MyCdiTypedListener rather than simply using new. Is that right?

What I can't see yet is how to pass in the configuration parameters for specifying things like the queue. These are not 
qualifiers which are used by Instance.select() to determine which class is instantiated. They are values which are used 
by the bean's postConstruct method (as extended by the portable extension) to initialise the bean.

Nigel



From rmannibucau at gmail.com  Thu Aug 27 12:03:55 2015
From: rmannibucau at gmail.com (Romain Manni-Bucau)
Date: Thu, 27 Aug 2015 18:03:55 +0200
Subject: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean in a
 Java EE application to listen for JMS messages
In-Reply-To: <55DF3400.6080600@oracle.com>
References: <55DB4692.7040304@oracle.com>
	<CA+ZZq9_Brvtks=jxQ1TbtXMNm+ab3w3GZfG-2sGQYeMK2mu2jA@mail.gmail.com>
	<55DB74E7.4080609@oracle.com>
	<CAOqetn9XTi0zSHMs9y_c3-XT1ghwTxog03BKwb+4=Jw3aPbPWg@mail.gmail.com>
	<55DC72D0.5090608@oracle.com>
	<CAOqetn-rUz=7F+oeymXrxH=OHMRzXC+9-n3LcsHnDQ4_Kq8Lyg@mail.gmail.com>
	<55DC970A.4050607@oracle.com>
	<CACLE=7PEBZomd7tuJby7F1zcrdr_sEFif=z1xgVMPPCZMXY=0g@mail.gmail.com>
	<55DC9EA1.408@oracle.com>
	<CACLE=7ML=yNsn2vRW6MX_2cNjAMedGnd2bjAPjg=7KLRn6etvQ@mail.gmail.com>
	<55DCA17D.9050602@oracle.com>
	<CACLE=7N8mNhvYh_g2W+D97zH4f5pKpH3a0sz1wDfJgdWu_scOg@mail.gmail.com>
	<55DD81B5.9040407@oracle.com>
	<CACLE=7O3b8WM79ueUcmuDq5Vi_UC5o2gObU8MnK8tqGJMcGfOQ@mail.gmail.com>
	<55DF2D4D.5070301@oracle.com>
	<CACLE=7PHhFh82-UN-KRy34nYwe982cOnc5V4OTmVGeWO2SmdCg@mail.gmail.com>
	<55DF3400.6080600@oracle.com>
Message-ID: <CACLE=7Mxc3y5zFXccZgzd6di81w7iuBx=h2+cJBYpM0OXgA6vw@mail.gmail.com>

2015-08-27 18:00 GMT+02:00 Nigel Deakin <nigel.deakin at oracle.com>:

> On 27/08/2015 16:35, Romain Manni-Bucau wrote:
>
>>
>> 2015-08-27 17:31 GMT+02:00 Nigel Deakin <nigel.deakin at oracle.com <mailto:
>> nigel.deakin at oracle.com>>:
>>
>>
>>     On 26/08/2015 10:16, Romain Manni-Bucau wrote:
>>
>>
>>
>>         The sample I gave before with the JmsStart event basically:
>>
>>
>>         public class JmsRegistrar {
>>               @Inject
>>               @JmsConnectionFactory(...)
>>               private ConnectionFactory factory;
>>
>>               @Inject
>>               @JmsQueue(...)
>>               private Queue queue;
>>
>>               public void startJms(@Observes JmsStart start) {
>>                   start.withFactory(factory) // withFactory should be
>> optional if only 1 bean matches it
>>                          .register(MyCdiTypedListener.class) // with
>> defaults for all potential config
>>                              .listenOn(queue)
>>                          .register(MyCdiTypedListener2.class, new
>> MyLiteral())
>>                               .withMaxSessions(10)
>>                               .listenOn(Queue.class, new
>> QueueLiteral(...))
>>                               ......;
>>               }
>>         }
>>
>>
>>         The power of it appears when you have a config injection in
>> JmsRegistrar you can iterate over to get the list of
>>         listener for instance.
>>
>>         Also JMS resources can be decorated and referenced from
>> qualifiers instead of instances thanks to CDI.
>>
>>         It doesnt prevent the app to use @JmxListener somewhere else if
>> the listener doesnt need any input/config to be
>>         registered.
>>
>>
>>     I'm trying to understand this. Are you suggesting that
>>
>>     1. When the application is started an event of type JmsStart is
>> fired. This class will be defined by JMS and
>>     implemented by the application server.
>>
>>     2. The application defines a class (in this example called
>> JmsRegistrar). This has a method startJms which receives
>>     the event.
>>
>>     3. JmsStart (the event class) has several builder methods. The most
>> important of these is register() which you can
>>     use to specify the class of a listener. The other methods
>> withFactory, register, withMaxSession and listenOn specify
>>     things like which connection factory is used, which queue is used and
>> so on.
>>
>>     This doesn't look very different from the normal JMS API, except that
>> it uses a builder pattern and is triggered
>>     automatically at startup. Apart from triggering the initial event,
>> what is CDI doing for you here?
>>
>>
>> Yes this is it, few details important for CDI:
>>
>> 1- ensure JMS is CDI ready - ie dont use it before the start event, if
>> JMS uses @Initialized(ApplicationScoped) then the
>> app cant use it for instance, same using extension
>> AfterValidationDeployment etc...so this event is just to ensure we
>> dont use "JMS CDI" too early
>> 2- JMS can use contextual instances implicitely which is not the case in
>> SE
>>
>> otherwise you are right the API is just fluent compared to what is
>> already there - found it nicer to expose but this
>> point is maybe personal.
>>
>
> OK. I'm interested in your statement "JMS can use contextual instances
> implicitly". That suggests that the method
> register(MyCdiTypedListener.class) would use some CDI API such as
> Instance.get() to obtain an instance of MyCdiTypedListener rather than
> simply using new. Is that right?
>
>
it would do a lookup in CDI context - using the bean manager most probably.
It also means to retrieve the JMS components linked (connection factory,
Destination?....) it can do a lookup as well and do the wiring if not
ambiguous. Very good point about it is it makes default resource optional -
and then makes CDI integration more SE friendly and avoids the pain to rely
on a default resource you can't suppose anything about excepted it is there.


> What I can't see yet is how to pass in the configuration parameters for
> specifying things like the queue. These are not qualifiers which are used
> by Instance.select() to determine which class is instantiated. They are
> values which are used by the bean's postConstruct method (as extended by
> the portable extension) to initialise the bean.
>
>
Options are IMO:

- get actual instance, at this point in CDI lifecycle you can get them
injected if you want or create them manually if you desire
- use a jms qualifier to find them

Having both makes sense if a jms qualifier is added.


> Nigel
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150827/58295f77/attachment.html 

From arjan.tijms at gmail.com  Thu Aug 27 14:55:15 2015
From: arjan.tijms at gmail.com (arjan tijms)
Date: Thu, 27 Aug 2015 20:55:15 +0200
Subject: [cdi-dev] Exploring the interest of mutating bean manager at
	runtime
In-Reply-To: <CABu-YBQWHU+qzyiwuWTX4qYUdNLMjZExgYv_R=wGbom0uyMZ8A@mail.gmail.com>
References: <CABu-YBQWHU+qzyiwuWTX4qYUdNLMjZExgYv_R=wGbom0uyMZ8A@mail.gmail.com>
Message-ID: <CAE=-AhByipLtvwq-pjP=GrGQwLvuPmE0JFXb5HvjATfDq2-mKg@mail.gmail.com>

Hi,

On Thu, Aug 27, 2015 at 5:56 PM, Antoine Sabot-Durand
<antoine at sabot-durand.net> wrote:
> This topic (modifying bean meta data at runtime) has been coming and going
> since CDI 1.0.

Does this also mean that Bean<T> instances can be registered at runtime?

If so, there's maybe one common use, although it's a pretty restricted
version of "runtime"; the ability to register a Bean<T> and/or do
other things extensions typically do from a ServletContainerListener.

The reason to do those things from a ServletContainerListener is that
the ServletContext is available then, which in turn allows one to read
WEB-INF/web.xml. There are a number of requests to have the
ServletContext made available in extensions, but that's clearly very
difficult to do.

So if the ServletContext can't come to extensions, maybe extensions
can be brought to the ServletContext via this way?

Kind regards,
Arjan Tijms

From antoine at sabot-durand.net  Thu Aug 27 15:19:03 2015
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Thu, 27 Aug 2015 19:19:03 +0000
Subject: [cdi-dev] Exploring the interest of mutating bean manager at
	runtime
In-Reply-To: <CAE=-AhByipLtvwq-pjP=GrGQwLvuPmE0JFXb5HvjATfDq2-mKg@mail.gmail.com>
References: <CABu-YBQWHU+qzyiwuWTX4qYUdNLMjZExgYv_R=wGbom0uyMZ8A@mail.gmail.com>
	<CAE=-AhByipLtvwq-pjP=GrGQwLvuPmE0JFXb5HvjATfDq2-mKg@mail.gmail.com>
Message-ID: <CABu-YBSsYVZjih0_rTCx0hDbzggyhtXbSZe+2Y4+VUwPL=i7+A@mail.gmail.com>

Yes, I guess it's the same limitation raised by JAX-RS regarding CDI
integration: when they are up, it's too late. Now perhaps this use case
could be addressed by adding a way to wait for servlet initialization
before triggering AfterDeploymentValidation event.
Le jeu. 27 ao?t 2015 ? 20:55, arjan tijms <arjan.tijms at gmail.com> a ?crit :

> Hi,
>
> On Thu, Aug 27, 2015 at 5:56 PM, Antoine Sabot-Durand
> <antoine at sabot-durand.net> wrote:
> > This topic (modifying bean meta data at runtime) has been coming and
> going
> > since CDI 1.0.
>
> Does this also mean that Bean<T> instances can be registered at runtime?
>
> If so, there's maybe one common use, although it's a pretty restricted
> version of "runtime"; the ability to register a Bean<T> and/or do
> other things extensions typically do from a ServletContainerListener.
>
> The reason to do those things from a ServletContainerListener is that
> the ServletContext is available then, which in turn allows one to read
> WEB-INF/web.xml. There are a number of requests to have the
> ServletContext made available in extensions, but that's clearly very
> difficult to do.
>
> So if the ServletContext can't come to extensions, maybe extensions
> can be brought to the ServletContext via this way?
>
> Kind regards,
> Arjan Tijms
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150827/f894eb18/attachment-0001.html 

From antoine at sabot-durand.net  Fri Aug 28 05:35:47 2015
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Fri, 28 Aug 2015 09:35:47 +0000
Subject: [cdi-dev] Time to start working on CDI lite
Message-ID: <CABu-YBQvgrVZcH31i+Uw9ZefsTZvLHJ4919PW=vnvRBa2RVoTQ@mail.gmail.com>

Hi guys,

CDI lite is one of the big feature we are expected to deliver for version
2.0. I think it's time to start discussing about its design.

The big picture is to provide a consistent subset of CDI that could be
implemented like Dagger is (code generated with process annotation). This
would allow using CDI in constrained environment like mobile or embedded
devices.

IMO CDI lite should be targeted to Java SE (I don't think it would make
sense for Java EE). So, from a specification perspective, we''l probably
have to split core part in 2 and se part as well (gosh).

I'm not sure regarding API. today they only weight 72 KB, so creating a
subset only for the sake of the weight doesn't make sense. the only reason
would be to have something clearer for the end user. but that could be
tricky.

Antoine
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150828/5b413b08/attachment.html 

From antoine at sabot-durand.net  Sat Aug 29 04:39:35 2015
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: 29 Aug 2015 08:39:35 +0000
Subject: [cdi-dev] Cancelled: CDI weekly meeting
Message-ID: <201508290839.t7T8dZAq032314@lists01.dmz-a.mwc.hst.phx2.redhat.com>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150829/b9887d65/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/calendar
Size: 6852 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20150829/b9887d65/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: invite.ics
Type: application/ics
Size: 6852 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20150829/b9887d65/attachment-0001.bin 

From antonio.goncalves at gmail.com  Sat Aug 29 14:45:55 2015
From: antonio.goncalves at gmail.com (Antonio Goncalves)
Date: Sat, 29 Aug 2015 20:45:55 +0200
Subject: [cdi-dev] Time to start working on CDI lite
In-Reply-To: <CABu-YBQvgrVZcH31i+Uw9ZefsTZvLHJ4919PW=vnvRBa2RVoTQ@mail.gmail.com>
References: <CABu-YBQvgrVZcH31i+Uw9ZefsTZvLHJ4919PW=vnvRBa2RVoTQ@mail.gmail.com>
Message-ID: <CA+ZZq9_C_nTH1YY1uNYnH2aW6RBBR7+xH9ZF+cduMhzOQHOO8g@mail.gmail.com>

Hi all,

With my strong Java EE background, sentences like "IMO CDI lite should be
targeted to Java SE", hurt ;o)

I remember talking with the JAX-RS guys (Java EE), years ago (back in EE6),
and their answer for not adopting CDI was "too heavy". Today, a JBoss
project called JBoss Forge (Java SE) is "dumping" CDI from its internals
because it's too slow (George, could you develop a bit more this topic?).
What do these two projects have in common ? They just need a "light"
dependency injection framework. I was talking to the Forge guys (I think it
was Lincoln) and, basically, they just need @Inject, @Qualifier and
@Produces (the missing one).

My question is : do we need a CDI Lite, or do we need a "fatter" @Inject
(for both SE and EE) ? I think that if we manage to move producers (and
disposers) to JSR 330, then CDI would do the rest, no need for a Ligther
version.

WDYT ?

Antonio

PS : With Antoine we talked to Juergen (co-spec lead od 330) and Patrick
Curran (JCP Chair man) and it looks like another lead could take over 330
(I'm imagining RedHat talking the Lead role on 330). Even a maintenance
release would be doable

On Fri, Aug 28, 2015 at 11:35 AM, Antoine Sabot-Durand <
antoine at sabot-durand.net> wrote:

> Hi guys,
>
> CDI lite is one of the big feature we are expected to deliver for version
> 2.0. I think it's time to start discussing about its design.
>
> The big picture is to provide a consistent subset of CDI that could be
> implemented like Dagger is (code generated with process annotation). This
> would allow using CDI in constrained environment like mobile or embedded
> devices.
>
> IMO CDI lite should be targeted to Java SE (I don't think it would make
> sense for Java EE). So, from a specification perspective, we''l probably
> have to split core part in 2 and se part as well (gosh).
>
> I'm not sure regarding API. today they only weight 72 KB, so creating a
> subset only for the sake of the weight doesn't make sense. the only reason
> would be to have something clearer for the end user. but that could be
> tricky.
>
> 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.
>



-- 
Antonio Goncalves
Software architect, Java Champion and Pluralsight author

Web site <http://www.antoniogoncalves.org> | Twitter
<http://twitter.com/agoncal> | LinkedIn <http://www.linkedin.com/in/agoncal> |
Pluralsight
<http://pluralsight.com/training/Authors/Details/antonio-goncalves> | Paris
JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150829/2ded33c2/attachment-0001.html 

From ggastald at redhat.com  Sat Aug 29 16:05:39 2015
From: ggastald at redhat.com (George Gastaldi)
Date: Sat, 29 Aug 2015 17:05:39 -0300
Subject: [cdi-dev] Time to start working on CDI lite
In-Reply-To: <CA+ZZq9_C_nTH1YY1uNYnH2aW6RBBR7+xH9ZF+cduMhzOQHOO8g@mail.gmail.com>
References: <CABu-YBQvgrVZcH31i+Uw9ZefsTZvLHJ4919PW=vnvRBa2RVoTQ@mail.gmail.com>
	<CA+ZZq9_C_nTH1YY1uNYnH2aW6RBBR7+xH9ZF+cduMhzOQHOO8g@mail.gmail.com>
Message-ID: <CAMmsnJi=VYPnALVrHBvTNF81tmCwpced=yeSxtPqDDNm4_YiaA@mail.gmail.com>

HI Antonio,

About JBoss Forge, our goal is to reduce the startup time. As Forge runs
under a modular runtime (Furnace), each add-on is loaded based on another
special add-on type container (eg. CDI or simple, with no support for
@Inject). We profiled our application and discovered (among several things)
that one bottleneck is the startup of several Weld instances.

The Forge team is not giving up on Weld, as we know that the Weld team is
already working hard on improving and providing options to minimize boot
time along with CDI 2.0 features.

Best Regards,

George Gastaldi

On Sat, Aug 29, 2015 at 3:45 PM, Antonio Goncalves <
antonio.goncalves at gmail.com> wrote:

> Hi all,
>
> With my strong Java EE background, sentences like "IMO CDI lite should be
> targeted to Java SE", hurt ;o)
>
> I remember talking with the JAX-RS guys (Java EE), years ago (back in
> EE6), and their answer for not adopting CDI was "too heavy". Today, a JBoss
> project called JBoss Forge (Java SE) is "dumping" CDI from its internals
> because it's too slow (George, could you develop a bit more this topic?).
> What do these two projects have in common ? They just need a "light"
> dependency injection framework. I was talking to the Forge guys (I think it
> was Lincoln) and, basically, they just need @Inject, @Qualifier and
> @Produces (the missing one).
>
> My question is : do we need a CDI Lite, or do we need a "fatter" @Inject
> (for both SE and EE) ? I think that if we manage to move producers (and
> disposers) to JSR 330, then CDI would do the rest, no need for a Ligther
> version.
>
> WDYT ?
>
> Antonio
>
> PS : With Antoine we talked to Juergen (co-spec lead od 330) and Patrick
> Curran (JCP Chair man) and it looks like another lead could take over 330
> (I'm imagining RedHat talking the Lead role on 330). Even a maintenance
> release would be doable
>
> On Fri, Aug 28, 2015 at 11:35 AM, Antoine Sabot-Durand <
> antoine at sabot-durand.net> wrote:
>
>> Hi guys,
>>
>> CDI lite is one of the big feature we are expected to deliver for version
>> 2.0. I think it's time to start discussing about its design.
>>
>> The big picture is to provide a consistent subset of CDI that could be
>> implemented like Dagger is (code generated with process annotation). This
>> would allow using CDI in constrained environment like mobile or embedded
>> devices.
>>
>> IMO CDI lite should be targeted to Java SE (I don't think it would make
>> sense for Java EE). So, from a specification perspective, we''l probably
>> have to split core part in 2 and se part as well (gosh).
>>
>> I'm not sure regarding API. today they only weight 72 KB, so creating a
>> subset only for the sake of the weight doesn't make sense. the only reason
>> would be to have something clearer for the end user. but that could be
>> tricky.
>>
>> 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.
>>
>
>
>
> --
> Antonio Goncalves
> Software architect, Java Champion and Pluralsight author
>
> Web site <http://www.antoniogoncalves.org> | Twitter
> <http://twitter.com/agoncal> | LinkedIn
> <http://www.linkedin.com/in/agoncal> | Pluralsight
> <http://pluralsight.com/training/Authors/Details/antonio-goncalves> | Paris
> JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr>
>
> _______________________________________________
> 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.
>



-- 
*George Gastaldi | Senior Software Engineer*

JBoss Forge Team
T: +55 11 3524-6169
M: +55 47 9711-1000
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150829/409eb94e/attachment.html 

From antoine at sabot-durand.net  Sat Aug 29 16:54:06 2015
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Sat, 29 Aug 2015 20:54:06 +0000
Subject: [cdi-dev] Time to start working on CDI lite
In-Reply-To: <CA+ZZq9_C_nTH1YY1uNYnH2aW6RBBR7+xH9ZF+cduMhzOQHOO8g@mail.gmail.com>
References: <CABu-YBQvgrVZcH31i+Uw9ZefsTZvLHJ4919PW=vnvRBa2RVoTQ@mail.gmail.com>
	<CA+ZZq9_C_nTH1YY1uNYnH2aW6RBBR7+xH9ZF+cduMhzOQHOO8g@mail.gmail.com>
Message-ID: <CABu-YBS87aatD1=1a0e=gxadBt_VLm5igbUQy-79_Ak9DOMHqg@mail.gmail.com>

Antonio,

The goal here is not to propose a new EE profile but a subspec that could
lead to a lighter implementation. And I don't see the benefit of pushing
this implementation to Java EE since CDI is today far less heavy that some
other spec like EJB or JPA. Perhaps you can give reason to review my
opinion here.

The benefit of CDI light would be in SE where the weight of libs really
count. That doesn't mean that someone couldn't take CDI light API to
produce a library and have it working on SE and EE since CDI lite has to be
a subset of CDI full.

Regarding JAX-RS my feedback was that the lack of SE support in CDI and
weight of impl in SE were the main reasons of the non adoption of CDI
support. As we are adding SE support and lite version of CDI these reason
will disappear.

Same for forge: CDI lite will help them to have something faster to start.
If we figure a solution to mutate bean manager at runtime that could also
help them I guess.

Roughly CDI lite is basic injection plus producer plus programmatic lookup
plus events, so it's more than a fatter jsr 330.

Antoine

Le sam. 29 ao?t 2015 ? 20:46, Antonio Goncalves <antonio.goncalves at gmail.com>
a ?crit :

> Hi all,
>
> With my strong Java EE background, sentences like "IMO CDI lite should be
> targeted to Java SE", hurt ;o)
>
> I remember talking with the JAX-RS guys (Java EE), years ago (back in
> EE6), and their answer for not adopting CDI was "too heavy". Today, a JBoss
> project called JBoss Forge (Java SE) is "dumping" CDI from its internals
> because it's too slow (George, could you develop a bit more this topic?).
> What do these two projects have in common ? They just need a "light"
> dependency injection framework. I was talking to the Forge guys (I think it
> was Lincoln) and, basically, they just need @Inject, @Qualifier and
> @Produces (the missing one).
>
> My question is : do we need a CDI Lite, or do we need a "fatter" @Inject
> (for both SE and EE) ? I think that if we manage to move producers (and
> disposers) to JSR 330, then CDI would do the rest, no need for a Ligther
> version.
>
> WDYT ?
>
> Antonio
>
> PS : With Antoine we talked to Juergen (co-spec lead od 330) and Patrick
> Curran (JCP Chair man) and it looks like another lead could take over 330
> (I'm imagining RedHat talking the Lead role on 330). Even a maintenance
> release would be doable
>
> On Fri, Aug 28, 2015 at 11:35 AM, Antoine Sabot-Durand <
> antoine at sabot-durand.net> wrote:
>
>> Hi guys,
>>
>> CDI lite is one of the big feature we are expected to deliver for version
>> 2.0. I think it's time to start discussing about its design.
>>
>> The big picture is to provide a consistent subset of CDI that could be
>> implemented like Dagger is (code generated with process annotation). This
>> would allow using CDI in constrained environment like mobile or embedded
>> devices.
>>
>> IMO CDI lite should be targeted to Java SE (I don't think it would make
>> sense for Java EE). So, from a specification perspective, we''l probably
>> have to split core part in 2 and se part as well (gosh).
>>
>> I'm not sure regarding API. today they only weight 72 KB, so creating a
>> subset only for the sake of the weight doesn't make sense. the only reason
>> would be to have something clearer for the end user. but that could be
>> tricky.
>>
>> 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.
>>
>
>
>
> --
> Antonio Goncalves
> Software architect, Java Champion and Pluralsight author
>
> Web site <http://www.antoniogoncalves.org> | Twitter
> <http://twitter.com/agoncal> | LinkedIn
> <http://www.linkedin.com/in/agoncal> | Pluralsight
> <http://pluralsight.com/training/Authors/Details/antonio-goncalves> | Paris
> JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150829/4f371604/attachment.html 

From arjan.tijms at gmail.com  Sat Aug 29 17:15:08 2015
From: arjan.tijms at gmail.com (arjan tijms)
Date: Sat, 29 Aug 2015 23:15:08 +0200
Subject: [cdi-dev] Time to start working on CDI lite
In-Reply-To: <CA+ZZq9_C_nTH1YY1uNYnH2aW6RBBR7+xH9ZF+cduMhzOQHOO8g@mail.gmail.com>
References: <CABu-YBQvgrVZcH31i+Uw9ZefsTZvLHJ4919PW=vnvRBa2RVoTQ@mail.gmail.com>
	<CA+ZZq9_C_nTH1YY1uNYnH2aW6RBBR7+xH9ZF+cduMhzOQHOO8g@mail.gmail.com>
Message-ID: <CAE=-AhDa84QjHqwNLJD3+a1f2mD2d+Y_2kwqRVqzBRkuvf4Qfw@mail.gmail.com>

On Sat, Aug 29, 2015 at 8:45 PM, Antonio Goncalves
<antonio.goncalves at gmail.com> wrote:
> I remember talking with the JAX-RS guys (Java EE), years ago (back in EE6),
> and their answer for not adopting CDI was "too heavy".

I can't find an exact reference anymore, but I somewhat remember that
one of the reasons was also simply that CDI as a general solution
finished late in Java EE 6, while JAX-RS finished earlier and had all
the work for their own DI solution already done.

From antonio.goncalves at gmail.com  Sun Aug 30 02:47:13 2015
From: antonio.goncalves at gmail.com (Antonio Goncalves)
Date: Sun, 30 Aug 2015 08:47:13 +0200
Subject: [cdi-dev] Time to start working on CDI lite
In-Reply-To: <CAE=-AhDa84QjHqwNLJD3+a1f2mD2d+Y_2kwqRVqzBRkuvf4Qfw@mail.gmail.com>
References: <CABu-YBQvgrVZcH31i+Uw9ZefsTZvLHJ4919PW=vnvRBa2RVoTQ@mail.gmail.com>
	<CA+ZZq9_C_nTH1YY1uNYnH2aW6RBBR7+xH9ZF+cduMhzOQHOO8g@mail.gmail.com>
	<CAE=-AhDa84QjHqwNLJD3+a1f2mD2d+Y_2kwqRVqzBRkuvf4Qfw@mail.gmail.com>
Message-ID: <CA+ZZq9_X-yguFTj72c3zZbLy88FGmCESjL=3r4VLrHMYeTudVg@mail.gmail.com>

@George, in your use case, would having basic dependency injection help ?

@Antoine If the future of Java EE is modularity, then having basic
dependency injection *makes* sense. Even if Java EE 8 will not make any
movement towards modularity, we hope that EE9 will. In these times of micro
services, you could bundle basic DI instead of the all thing. So, in my
opinion, it makes sense to think of it in EE too.

*"CDI lite is basic injection plus producer plus programmatic lookup plus
events, so it's more than a fatter jsr 330"*

So you are thinking of having events in CDI Lite ?

Antonio




On Sat, Aug 29, 2015 at 11:15 PM, arjan tijms <arjan.tijms at gmail.com> wrote:

> On Sat, Aug 29, 2015 at 8:45 PM, Antonio Goncalves
> <antonio.goncalves at gmail.com> wrote:
> > I remember talking with the JAX-RS guys (Java EE), years ago (back in
> EE6),
> > and their answer for not adopting CDI was "too heavy".
>
> I can't find an exact reference anymore, but I somewhat remember that
> one of the reasons was also simply that CDI as a general solution
> finished late in Java EE 6, while JAX-RS finished earlier and had all
> the work for their own DI solution already done.
>



-- 
Antonio Goncalves
Software architect, Java Champion and Pluralsight author

Web site <http://www.antoniogoncalves.org> | Twitter
<http://twitter.com/agoncal> | LinkedIn <http://www.linkedin.com/in/agoncal> |
Pluralsight
<http://pluralsight.com/training/Authors/Details/antonio-goncalves> | Paris
JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150830/75ea49fa/attachment-0001.html 

From antoine at sabot-durand.net  Sun Aug 30 03:06:25 2015
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Sun, 30 Aug 2015 07:06:25 +0000
Subject: [cdi-dev] Time to start working on CDI lite
In-Reply-To: <CA+ZZq9_X-yguFTj72c3zZbLy88FGmCESjL=3r4VLrHMYeTudVg@mail.gmail.com>
References: <CABu-YBQvgrVZcH31i+Uw9ZefsTZvLHJ4919PW=vnvRBa2RVoTQ@mail.gmail.com>
	<CA+ZZq9_C_nTH1YY1uNYnH2aW6RBBR7+xH9ZF+cduMhzOQHOO8g@mail.gmail.com>
	<CAE=-AhDa84QjHqwNLJD3+a1f2mD2d+Y_2kwqRVqzBRkuvf4Qfw@mail.gmail.com>
	<CA+ZZq9_X-yguFTj72c3zZbLy88FGmCESjL=3r4VLrHMYeTudVg@mail.gmail.com>
Message-ID: <CABu-YBS7kE+jVesFDqwmj9gJ0yt3uY=xU4hXB9rC62nywbCuiA@mail.gmail.com>

Antonio,

It's not my intention to prevent future usage of CDI lite in EE, if it
makes sense some day. I was only saying that the only benefit of lite for
EE 8 would be to work for a new EE profile and I don't want to go in that
direction. That's why the target here is primary SE IMO.

Antoine
Le dim. 30 ao?t 2015 ? 08:47, Antonio Goncalves <antonio.goncalves at gmail.com>
a ?crit :

> @George, in your use case, would having basic dependency injection help ?
>
> @Antoine If the future of Java EE is modularity, then having basic
> dependency injection *makes* sense. Even if Java EE 8 will not make any
> movement towards modularity, we hope that EE9 will. In these times of micro
> services, you could bundle basic DI instead of the all thing. So, in my
> opinion, it makes sense to think of it in EE too.
>
> *"CDI lite is basic injection plus producer plus programmatic lookup plus
> events, so it's more than a fatter jsr 330"*
>
> So you are thinking of having events in CDI Lite ?
>
> Antonio
>
>
>
>
> On Sat, Aug 29, 2015 at 11:15 PM, arjan tijms <arjan.tijms at gmail.com>
> wrote:
>
>> On Sat, Aug 29, 2015 at 8:45 PM, Antonio Goncalves
>> <antonio.goncalves at gmail.com> wrote:
>> > I remember talking with the JAX-RS guys (Java EE), years ago (back in
>> EE6),
>> > and their answer for not adopting CDI was "too heavy".
>>
>> I can't find an exact reference anymore, but I somewhat remember that
>> one of the reasons was also simply that CDI as a general solution
>> finished late in Java EE 6, while JAX-RS finished earlier and had all
>> the work for their own DI solution already done.
>>
>
>
>
> --
> Antonio Goncalves
> Software architect, Java Champion and Pluralsight author
>
> Web site <http://www.antoniogoncalves.org> | Twitter
> <http://twitter.com/agoncal> | LinkedIn
> <http://www.linkedin.com/in/agoncal> | Pluralsight
> <http://pluralsight.com/training/Authors/Details/antonio-goncalves> | Paris
> JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150830/fa6652cf/attachment.html 

From antoine at sabot-durand.net  Sun Aug 30 03:09:18 2015
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Sun, 30 Aug 2015 07:09:18 +0000
Subject: [cdi-dev] Time to start working on CDI lite
In-Reply-To: <CAE=-AhDa84QjHqwNLJD3+a1f2mD2d+Y_2kwqRVqzBRkuvf4Qfw@mail.gmail.com>
References: <CABu-YBQvgrVZcH31i+Uw9ZefsTZvLHJ4919PW=vnvRBa2RVoTQ@mail.gmail.com>
	<CA+ZZq9_C_nTH1YY1uNYnH2aW6RBBR7+xH9ZF+cduMhzOQHOO8g@mail.gmail.com>
	<CAE=-AhDa84QjHqwNLJD3+a1f2mD2d+Y_2kwqRVqzBRkuvf4Qfw@mail.gmail.com>
Message-ID: <CABu-YBQ9ZtUdSj6LUoROz2-JuqROtLTG1UKUSANOY4kiVHpTDg@mail.gmail.com>

Yes Arjan, I think it's the first reason. We really should work with them
to understand what should be added to CDI 2.0 to have it as a first citizen
DI in their spec.

Le sam. 29 ao?t 2015 ? 23:15, arjan tijms <arjan.tijms at gmail.com> a ?crit :

> On Sat, Aug 29, 2015 at 8:45 PM, Antonio Goncalves
> <antonio.goncalves at gmail.com> wrote:
> > I remember talking with the JAX-RS guys (Java EE), years ago (back in
> EE6),
> > and their answer for not adopting CDI was "too heavy".
>
> I can't find an exact reference anymore, but I somewhat remember that
> one of the reasons was also simply that CDI as a general solution
> finished late in Java EE 6, while JAX-RS finished earlier and had all
> the work for their own DI solution already done.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150830/54c50adb/attachment.html 

From antonio.goncalves at gmail.com  Sun Aug 30 08:06:33 2015
From: antonio.goncalves at gmail.com (Antonio Goncalves)
Date: Sun, 30 Aug 2015 14:06:33 +0200
Subject: [cdi-dev] Time to start working on CDI lite
In-Reply-To: <CABu-YBQ9ZtUdSj6LUoROz2-JuqROtLTG1UKUSANOY4kiVHpTDg@mail.gmail.com>
References: <CABu-YBQvgrVZcH31i+Uw9ZefsTZvLHJ4919PW=vnvRBa2RVoTQ@mail.gmail.com>
	<CA+ZZq9_C_nTH1YY1uNYnH2aW6RBBR7+xH9ZF+cduMhzOQHOO8g@mail.gmail.com>
	<CAE=-AhDa84QjHqwNLJD3+a1f2mD2d+Y_2kwqRVqzBRkuvf4Qfw@mail.gmail.com>
	<CABu-YBQ9ZtUdSj6LUoROz2-JuqROtLTG1UKUSANOY4kiVHpTDg@mail.gmail.com>
Message-ID: <CA+ZZq9-RW68R+o1c3n5J6KSGtki+o+89SvTpovSFL5ZKq6BTWQ@mail.gmail.com>

@Antoine, so which content do you see in CDI Lite ? Are you sure about
events ?

I'm in favor of a "fatter" 330 that would have :

   - @Inject : already there
   - @Qualifier : already there
   -
*Producers and disposers *
   -
*Programatic lookup *
   - *Java SE Bootstrap*

When you say "*The goal here is not to propose a new EE profile but a
subspec*", 330 could already be seen as a subspec. If you put events
apparts, what would be missing in this list in your point of view ? And
what obstacles do you see in archieving this ?

To boostrap CDI we have a CDIProvider, why not having an InjectionProvider
just to bootstrap 330 (then, CDIProvider could extend InjectionProvider, so
it bootstraps the all thing) ?

Antonio

On Sun, Aug 30, 2015 at 9:09 AM, Antoine Sabot-Durand <
antoine at sabot-durand.net> wrote:

> Yes Arjan, I think it's the first reason. We really should work with them
> to understand what should be added to CDI 2.0 to have it as a first citizen
> DI in their spec.
>
> Le sam. 29 ao?t 2015 ? 23:15, arjan tijms <arjan.tijms at gmail.com> a
> ?crit :
>
>> On Sat, Aug 29, 2015 at 8:45 PM, Antonio Goncalves
>> <antonio.goncalves at gmail.com> wrote:
>> > I remember talking with the JAX-RS guys (Java EE), years ago (back in
>> EE6),
>> > and their answer for not adopting CDI was "too heavy".
>>
>> I can't find an exact reference anymore, but I somewhat remember that
>> one of the reasons was also simply that CDI as a general solution
>> finished late in Java EE 6, while JAX-RS finished earlier and had all
>> the work for their own DI solution already done.
>>
>


-- 
Antonio Goncalves
Software architect, Java Champion and Pluralsight author

Web site <http://www.antoniogoncalves.org> | Twitter
<http://twitter.com/agoncal> | LinkedIn <http://www.linkedin.com/in/agoncal> |
Pluralsight
<http://pluralsight.com/training/Authors/Details/antonio-goncalves> | Paris
JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150830/6d57ffc9/attachment.html 

From john.d.ament at gmail.com  Sun Aug 30 09:22:04 2015
From: john.d.ament at gmail.com (John D. Ament)
Date: Sun, 30 Aug 2015 13:22:04 +0000
Subject: [cdi-dev] Time to start working on CDI lite
In-Reply-To: <CA+ZZq9-RW68R+o1c3n5J6KSGtki+o+89SvTpovSFL5ZKq6BTWQ@mail.gmail.com>
References: <CABu-YBQvgrVZcH31i+Uw9ZefsTZvLHJ4919PW=vnvRBa2RVoTQ@mail.gmail.com>
	<CA+ZZq9_C_nTH1YY1uNYnH2aW6RBBR7+xH9ZF+cduMhzOQHOO8g@mail.gmail.com>
	<CAE=-AhDa84QjHqwNLJD3+a1f2mD2d+Y_2kwqRVqzBRkuvf4Qfw@mail.gmail.com>
	<CABu-YBQ9ZtUdSj6LUoROz2-JuqROtLTG1UKUSANOY4kiVHpTDg@mail.gmail.com>
	<CA+ZZq9-RW68R+o1c3n5J6KSGtki+o+89SvTpovSFL5ZKq6BTWQ@mail.gmail.com>
Message-ID: <CAOqetn_Afc0BfGPcSRBQiKuvtOfZnQKzxHv59KhbJfLTGKoH4w@mail.gmail.com>

Personally, I'm not in favor of a slimmed down runtime.  It was tried with
EJB, but never implemented properly (most implementations that support
EJB-lite actually support the entire thing, except for deprecated stuff).

I think if we define SE properly we won't have a need for this.

John

On Sun, Aug 30, 2015 at 8:07 AM Antonio Goncalves <
antonio.goncalves at gmail.com> wrote:

> @Antoine, so which content do you see in CDI Lite ? Are you sure about
> events ?
>
> I'm in favor of a "fatter" 330 that would have :
>
>    - @Inject : already there
>    - @Qualifier : already there
>    -
> *Producers and disposers *
>    -
> *Programatic lookup *
>    - *Java SE Bootstrap*
>
> When you say "*The goal here is not to propose a new EE profile but a
> subspec*", 330 could already be seen as a subspec. If you put events
> apparts, what would be missing in this list in your point of view ? And
> what obstacles do you see in archieving this ?
>
> To boostrap CDI we have a CDIProvider, why not having an InjectionProvider
> just to bootstrap 330 (then, CDIProvider could extend InjectionProvider, so
> it bootstraps the all thing) ?
>
> Antonio
>
> On Sun, Aug 30, 2015 at 9:09 AM, Antoine Sabot-Durand <
> antoine at sabot-durand.net> wrote:
>
>> Yes Arjan, I think it's the first reason. We really should work with them
>> to understand what should be added to CDI 2.0 to have it as a first citizen
>> DI in their spec.
>>
>> Le sam. 29 ao?t 2015 ? 23:15, arjan tijms <arjan.tijms at gmail.com> a
>> ?crit :
>>
>>> On Sat, Aug 29, 2015 at 8:45 PM, Antonio Goncalves
>>> <antonio.goncalves at gmail.com> wrote:
>>> > I remember talking with the JAX-RS guys (Java EE), years ago (back in
>>> EE6),
>>> > and their answer for not adopting CDI was "too heavy".
>>>
>>> I can't find an exact reference anymore, but I somewhat remember that
>>> one of the reasons was also simply that CDI as a general solution
>>> finished late in Java EE 6, while JAX-RS finished earlier and had all
>>> the work for their own DI solution already done.
>>>
>>
>
>
> --
> Antonio Goncalves
> Software architect, Java Champion and Pluralsight author
>
> Web site <http://www.antoniogoncalves.org> | Twitter
> <http://twitter.com/agoncal> | LinkedIn
> <http://www.linkedin.com/in/agoncal> | Pluralsight
> <http://pluralsight.com/training/Authors/Details/antonio-goncalves> | Paris
> JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr>
> _______________________________________________
> 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/20150830/64394d4f/attachment-0001.html 

From antonio.goncalves at gmail.com  Sun Aug 30 09:40:29 2015
From: antonio.goncalves at gmail.com (Antonio Goncalves)
Date: Sun, 30 Aug 2015 15:40:29 +0200
Subject: [cdi-dev] Time to start working on CDI lite
In-Reply-To: <CAOqetn_Afc0BfGPcSRBQiKuvtOfZnQKzxHv59KhbJfLTGKoH4w@mail.gmail.com>
References: <CABu-YBQvgrVZcH31i+Uw9ZefsTZvLHJ4919PW=vnvRBa2RVoTQ@mail.gmail.com>
	<CA+ZZq9_C_nTH1YY1uNYnH2aW6RBBR7+xH9ZF+cduMhzOQHOO8g@mail.gmail.com>
	<CAE=-AhDa84QjHqwNLJD3+a1f2mD2d+Y_2kwqRVqzBRkuvf4Qfw@mail.gmail.com>
	<CABu-YBQ9ZtUdSj6LUoROz2-JuqROtLTG1UKUSANOY4kiVHpTDg@mail.gmail.com>
	<CA+ZZq9-RW68R+o1c3n5J6KSGtki+o+89SvTpovSFL5ZKq6BTWQ@mail.gmail.com>
	<CAOqetn_Afc0BfGPcSRBQiKuvtOfZnQKzxHv59KhbJfLTGKoH4w@mail.gmail.com>
Message-ID: <CA+ZZq98WBn2P34i9Uw+gHpPSKkRNYCfsOZZYE2zJm_pVJiMd0w@mail.gmail.com>

@John, I'm not mentioning any runtime here.

In Java EE, the "fatter" JSR 330 will get executed in a Java EE container,
as usual, no need extra runtime. On the other end, when I use WidlFly Swarm
to build some tiny services and I need basic injection, I need the full
CDI. What I'm saying is, with a fatter 330, Java SE will have basic
injection, but also Java EE. I know modularity is not in the EE roadmap for
now, but it will be. When it's the case, you will be able to say "I want a
Java EE app with basic injection" (and you will only get the 330 module) or
"I want the full thing" (and will get CDI, which depends on the fatter 330)

Antonio

On Sun, Aug 30, 2015 at 3:22 PM, John D. Ament <john.d.ament at gmail.com>
wrote:

> Personally, I'm not in favor of a slimmed down runtime.  It was tried with
> EJB, but never implemented properly (most implementations that support
> EJB-lite actually support the entire thing, except for deprecated stuff).
>
> I think if we define SE properly we won't have a need for this.
>
> John
>
> On Sun, Aug 30, 2015 at 8:07 AM Antonio Goncalves <
> antonio.goncalves at gmail.com> wrote:
>
>> @Antoine, so which content do you see in CDI Lite ? Are you sure about
>> events ?
>>
>> I'm in favor of a "fatter" 330 that would have :
>>
>>    - @Inject : already there
>>    - @Qualifier : already there
>>    -
>> *Producers and disposers *
>>    -
>> *Programatic lookup *
>>    - *Java SE Bootstrap*
>>
>> When you say "*The goal here is not to propose a new EE profile but a
>> subspec*", 330 could already be seen as a subspec. If you put events
>> apparts, what would be missing in this list in your point of view ? And
>> what obstacles do you see in archieving this ?
>>
>> To boostrap CDI we have a CDIProvider, why not having an
>> InjectionProvider just to bootstrap 330 (then, CDIProvider could extend
>> InjectionProvider, so it bootstraps the all thing) ?
>>
>> Antonio
>>
>> On Sun, Aug 30, 2015 at 9:09 AM, Antoine Sabot-Durand <
>> antoine at sabot-durand.net> wrote:
>>
>>> Yes Arjan, I think it's the first reason. We really should work with
>>> them to understand what should be added to CDI 2.0 to have it as a first
>>> citizen DI in their spec.
>>>
>>> Le sam. 29 ao?t 2015 ? 23:15, arjan tijms <arjan.tijms at gmail.com> a
>>> ?crit :
>>>
>>>> On Sat, Aug 29, 2015 at 8:45 PM, Antonio Goncalves
>>>> <antonio.goncalves at gmail.com> wrote:
>>>> > I remember talking with the JAX-RS guys (Java EE), years ago (back in
>>>> EE6),
>>>> > and their answer for not adopting CDI was "too heavy".
>>>>
>>>> I can't find an exact reference anymore, but I somewhat remember that
>>>> one of the reasons was also simply that CDI as a general solution
>>>> finished late in Java EE 6, while JAX-RS finished earlier and had all
>>>> the work for their own DI solution already done.
>>>>
>>>
>>
>>
>> --
>> Antonio Goncalves
>> Software architect, Java Champion and Pluralsight author
>>
>> Web site <http://www.antoniogoncalves.org> | Twitter
>> <http://twitter.com/agoncal> | LinkedIn
>> <http://www.linkedin.com/in/agoncal> | Pluralsight
>> <http://pluralsight.com/training/Authors/Details/antonio-goncalves> | Paris
>> JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr>
>> _______________________________________________
>> 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.
>
>


-- 
Antonio Goncalves
Software architect, Java Champion and Pluralsight author

Web site <http://www.antoniogoncalves.org> | Twitter
<http://twitter.com/agoncal> | LinkedIn <http://www.linkedin.com/in/agoncal> |
Pluralsight
<http://pluralsight.com/training/Authors/Details/antonio-goncalves> | Paris
JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150830/cfd53712/attachment.html 

From rmannibucau at gmail.com  Sun Aug 30 09:44:58 2015
From: rmannibucau at gmail.com (Romain Manni-Bucau)
Date: Sun, 30 Aug 2015 15:44:58 +0200
Subject: [cdi-dev] Time to start working on CDI lite
In-Reply-To: <CAOqetn_Afc0BfGPcSRBQiKuvtOfZnQKzxHv59KhbJfLTGKoH4w@mail.gmail.com>
References: <CABu-YBQvgrVZcH31i+Uw9ZefsTZvLHJ4919PW=vnvRBa2RVoTQ@mail.gmail.com>
	<CA+ZZq9_C_nTH1YY1uNYnH2aW6RBBR7+xH9ZF+cduMhzOQHOO8g@mail.gmail.com>
	<CAE=-AhDa84QjHqwNLJD3+a1f2mD2d+Y_2kwqRVqzBRkuvf4Qfw@mail.gmail.com>
	<CABu-YBQ9ZtUdSj6LUoROz2-JuqROtLTG1UKUSANOY4kiVHpTDg@mail.gmail.com>
	<CA+ZZq9-RW68R+o1c3n5J6KSGtki+o+89SvTpovSFL5ZKq6BTWQ@mail.gmail.com>
	<CAOqetn_Afc0BfGPcSRBQiKuvtOfZnQKzxHv59KhbJfLTGKoH4w@mail.gmail.com>
Message-ID: <CACLE=7MmgSVukPrN-fiu959w1zv7hj19VikGx-4JzA2mTRVG-w@mail.gmail.com>

2015-08-30 15:22 GMT+02:00 John D. Ament <john.d.ament at gmail.com>:

> Personally, I'm not in favor of a slimmed down runtime.  It was tried with
> EJB, but never implemented properly (most implementations that support
> EJB-lite actually support the entire thing, except for deprecated stuff).
>
>
+1, most of CDI is basic and quickly any light version will miss events or
other thing - in particular in maintaining micro services from experience.
Size of an implementation can easily be < 1M so not sure it would bring
anything. Only important point is what Antoine started to do ie ensuring EE
and SE parts are clearly identified and split in the spec.


> I think if we define SE properly we won't have a need for this.
>
> John
>
> On Sun, Aug 30, 2015 at 8:07 AM Antonio Goncalves <
> antonio.goncalves at gmail.com> wrote:
>
>> @Antoine, so which content do you see in CDI Lite ? Are you sure about
>> events ?
>>
>> I'm in favor of a "fatter" 330 that would have :
>>
>>    - @Inject : already there
>>    - @Qualifier : already there
>>    -
>> *Producers and disposers *
>>    -
>> *Programatic lookup *
>>    - *Java SE Bootstrap*
>>
>> When you say "*The goal here is not to propose a new EE profile but a
>> subspec*", 330 could already be seen as a subspec. If you put events
>> apparts, what would be missing in this list in your point of view ? And
>> what obstacles do you see in archieving this ?
>>
>> To boostrap CDI we have a CDIProvider, why not having an
>> InjectionProvider just to bootstrap 330 (then, CDIProvider could extend
>> InjectionProvider, so it bootstraps the all thing) ?
>>
>> Antonio
>>
>> On Sun, Aug 30, 2015 at 9:09 AM, Antoine Sabot-Durand <
>> antoine at sabot-durand.net> wrote:
>>
>>> Yes Arjan, I think it's the first reason. We really should work with
>>> them to understand what should be added to CDI 2.0 to have it as a first
>>> citizen DI in their spec.
>>>
>>> Le sam. 29 ao?t 2015 ? 23:15, arjan tijms <arjan.tijms at gmail.com> a
>>> ?crit :
>>>
>>>> On Sat, Aug 29, 2015 at 8:45 PM, Antonio Goncalves
>>>> <antonio.goncalves at gmail.com> wrote:
>>>> > I remember talking with the JAX-RS guys (Java EE), years ago (back in
>>>> EE6),
>>>> > and their answer for not adopting CDI was "too heavy".
>>>>
>>>> I can't find an exact reference anymore, but I somewhat remember that
>>>> one of the reasons was also simply that CDI as a general solution
>>>> finished late in Java EE 6, while JAX-RS finished earlier and had all
>>>> the work for their own DI solution already done.
>>>>
>>>
>>
>>
>> --
>> Antonio Goncalves
>> Software architect, Java Champion and Pluralsight author
>>
>> Web site <http://www.antoniogoncalves.org> | Twitter
>> <http://twitter.com/agoncal> | LinkedIn
>> <http://www.linkedin.com/in/agoncal> | Pluralsight
>> <http://pluralsight.com/training/Authors/Details/antonio-goncalves> | Paris
>> JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr>
>> _______________________________________________
>> 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/20150830/bf13e712/attachment.html 

From antonio.goncalves at gmail.com  Sun Aug 30 09:57:56 2015
From: antonio.goncalves at gmail.com (Antonio Goncalves)
Date: Sun, 30 Aug 2015 15:57:56 +0200
Subject: [cdi-dev] Time to start working on CDI lite
In-Reply-To: <CACLE=7MmgSVukPrN-fiu959w1zv7hj19VikGx-4JzA2mTRVG-w@mail.gmail.com>
References: <CABu-YBQvgrVZcH31i+Uw9ZefsTZvLHJ4919PW=vnvRBa2RVoTQ@mail.gmail.com>
	<CA+ZZq9_C_nTH1YY1uNYnH2aW6RBBR7+xH9ZF+cduMhzOQHOO8g@mail.gmail.com>
	<CAE=-AhDa84QjHqwNLJD3+a1f2mD2d+Y_2kwqRVqzBRkuvf4Qfw@mail.gmail.com>
	<CABu-YBQ9ZtUdSj6LUoROz2-JuqROtLTG1UKUSANOY4kiVHpTDg@mail.gmail.com>
	<CA+ZZq9-RW68R+o1c3n5J6KSGtki+o+89SvTpovSFL5ZKq6BTWQ@mail.gmail.com>
	<CAOqetn_Afc0BfGPcSRBQiKuvtOfZnQKzxHv59KhbJfLTGKoH4w@mail.gmail.com>
	<CACLE=7MmgSVukPrN-fiu959w1zv7hj19VikGx-4JzA2mTRVG-w@mail.gmail.com>
Message-ID: <CA+ZZq99XKDbwnqLPi-j4rcizU9EcuNzjsJTHo+Qy_djjtMCy_Q@mail.gmail.com>

It's funny, I feel I'm in Rod Johnson shoes back in Java EE 6 where he
forked 330 because he found CDI was doing too much  ;o)

For me, "CDI Lite" was just basic dependency injection. The fact that CDI
can now run on SE (like JPA....), is good... but for me it has nothing to
do with Light : it's the entire thing that can bootstrap in SE. Good.

So what is Lite for you guys ?

Antonio

On Sun, Aug 30, 2015 at 3:44 PM, Romain Manni-Bucau <rmannibucau at gmail.com>
wrote:

> 2015-08-30 15:22 GMT+02:00 John D. Ament <john.d.ament at gmail.com>:
>
>> Personally, I'm not in favor of a slimmed down runtime.  It was tried
>> with EJB, but never implemented properly (most implementations that support
>> EJB-lite actually support the entire thing, except for deprecated stuff).
>>
>>
> +1, most of CDI is basic and quickly any light version will miss events or
> other thing - in particular in maintaining micro services from experience.
> Size of an implementation can easily be < 1M so not sure it would bring
> anything. Only important point is what Antoine started to do ie ensuring EE
> and SE parts are clearly identified and split in the spec.
>
>
>> I think if we define SE properly we won't have a need for this.
>>
>> John
>>
>> On Sun, Aug 30, 2015 at 8:07 AM Antonio Goncalves <
>> antonio.goncalves at gmail.com> wrote:
>>
>>> @Antoine, so which content do you see in CDI Lite ? Are you sure about
>>> events ?
>>>
>>> I'm in favor of a "fatter" 330 that would have :
>>>
>>>    - @Inject : already there
>>>    - @Qualifier : already there
>>>    -
>>> *Producers and disposers *
>>>    -
>>> *Programatic lookup *
>>>    - *Java SE Bootstrap*
>>>
>>> When you say "*The goal here is not to propose a new EE profile but a
>>> subspec*", 330 could already be seen as a subspec. If you put events
>>> apparts, what would be missing in this list in your point of view ? And
>>> what obstacles do you see in archieving this ?
>>>
>>> To boostrap CDI we have a CDIProvider, why not having an
>>> InjectionProvider just to bootstrap 330 (then, CDIProvider could extend
>>> InjectionProvider, so it bootstraps the all thing) ?
>>>
>>> Antonio
>>>
>>> On Sun, Aug 30, 2015 at 9:09 AM, Antoine Sabot-Durand <
>>> antoine at sabot-durand.net> wrote:
>>>
>>>> Yes Arjan, I think it's the first reason. We really should work with
>>>> them to understand what should be added to CDI 2.0 to have it as a first
>>>> citizen DI in their spec.
>>>>
>>>> Le sam. 29 ao?t 2015 ? 23:15, arjan tijms <arjan.tijms at gmail.com> a
>>>> ?crit :
>>>>
>>>>> On Sat, Aug 29, 2015 at 8:45 PM, Antonio Goncalves
>>>>> <antonio.goncalves at gmail.com> wrote:
>>>>> > I remember talking with the JAX-RS guys (Java EE), years ago (back
>>>>> in EE6),
>>>>> > and their answer for not adopting CDI was "too heavy".
>>>>>
>>>>> I can't find an exact reference anymore, but I somewhat remember that
>>>>> one of the reasons was also simply that CDI as a general solution
>>>>> finished late in Java EE 6, while JAX-RS finished earlier and had all
>>>>> the work for their own DI solution already done.
>>>>>
>>>>
>>>
>>>
>>> --
>>> Antonio Goncalves
>>> Software architect, Java Champion and Pluralsight author
>>>
>>> Web site <http://www.antoniogoncalves.org> | Twitter
>>> <http://twitter.com/agoncal> | LinkedIn
>>> <http://www.linkedin.com/in/agoncal> | Pluralsight
>>> <http://pluralsight.com/training/Authors/Details/antonio-goncalves> | Paris
>>> JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr>
>>> _______________________________________________
>>> 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.
>>
>
>


-- 
Antonio Goncalves
Software architect, Java Champion and Pluralsight author

Web site <http://www.antoniogoncalves.org> | Twitter
<http://twitter.com/agoncal> | LinkedIn <http://www.linkedin.com/in/agoncal> |
Pluralsight
<http://pluralsight.com/training/Authors/Details/antonio-goncalves> | Paris
JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150830/be5fe977/attachment-0001.html 

From rmannibucau at gmail.com  Sun Aug 30 10:02:32 2015
From: rmannibucau at gmail.com (Romain Manni-Bucau)
Date: Sun, 30 Aug 2015 16:02:32 +0200
Subject: [cdi-dev] Time to start working on CDI lite
In-Reply-To: <CA+ZZq99XKDbwnqLPi-j4rcizU9EcuNzjsJTHo+Qy_djjtMCy_Q@mail.gmail.com>
References: <CABu-YBQvgrVZcH31i+Uw9ZefsTZvLHJ4919PW=vnvRBa2RVoTQ@mail.gmail.com>
	<CA+ZZq9_C_nTH1YY1uNYnH2aW6RBBR7+xH9ZF+cduMhzOQHOO8g@mail.gmail.com>
	<CAE=-AhDa84QjHqwNLJD3+a1f2mD2d+Y_2kwqRVqzBRkuvf4Qfw@mail.gmail.com>
	<CABu-YBQ9ZtUdSj6LUoROz2-JuqROtLTG1UKUSANOY4kiVHpTDg@mail.gmail.com>
	<CA+ZZq9-RW68R+o1c3n5J6KSGtki+o+89SvTpovSFL5ZKq6BTWQ@mail.gmail.com>
	<CAOqetn_Afc0BfGPcSRBQiKuvtOfZnQKzxHv59KhbJfLTGKoH4w@mail.gmail.com>
	<CACLE=7MmgSVukPrN-fiu959w1zv7hj19VikGx-4JzA2mTRVG-w@mail.gmail.com>
	<CA+ZZq99XKDbwnqLPi-j4rcizU9EcuNzjsJTHo+Qy_djjtMCy_Q@mail.gmail.com>
Message-ID: <CACLE=7Mu5mMB3tFWLtPxNXRpKrR82xKku5saFB9it3n-8RU1aQ@mail.gmail.com>

Lite can have several definition, let's try to list them up if it can help:

- binary size: for me until 3M for an app it is "Lite"
- features number: the whole IoC set of feature is light since you almost
always need it, it means you can do lighter but it wouldnt be used - check
spring, who uses only spring-ioc and not context or more?
- features complexity: sure we are not light here but supporting scopes
already breaks "Lite-ness" IMO so not a real issue

So my view is CDI "SE" is light enough - as a spec and spec can't affect
implementations so seems the fight is not on the right side to me.



Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com>

2015-08-30 15:57 GMT+02:00 Antonio Goncalves <antonio.goncalves at gmail.com>:

> It's funny, I feel I'm in Rod Johnson shoes back in Java EE 6 where he
> forked 330 because he found CDI was doing too much  ;o)
>
> For me, "CDI Lite" was just basic dependency injection. The fact that CDI
> can now run on SE (like JPA....), is good... but for me it has nothing to
> do with Light : it's the entire thing that can bootstrap in SE. Good.
>
> So what is Lite for you guys ?
>
> Antonio
>
> On Sun, Aug 30, 2015 at 3:44 PM, Romain Manni-Bucau <rmannibucau at gmail.com
> > wrote:
>
>> 2015-08-30 15:22 GMT+02:00 John D. Ament <john.d.ament at gmail.com>:
>>
>>> Personally, I'm not in favor of a slimmed down runtime.  It was tried
>>> with EJB, but never implemented properly (most implementations that support
>>> EJB-lite actually support the entire thing, except for deprecated stuff).
>>>
>>>
>> +1, most of CDI is basic and quickly any light version will miss events
>> or other thing - in particular in maintaining micro services from
>> experience. Size of an implementation can easily be < 1M so not sure it
>> would bring anything. Only important point is what Antoine started to do ie
>> ensuring EE and SE parts are clearly identified and split in the spec.
>>
>>
>>> I think if we define SE properly we won't have a need for this.
>>>
>>> John
>>>
>>> On Sun, Aug 30, 2015 at 8:07 AM Antonio Goncalves <
>>> antonio.goncalves at gmail.com> wrote:
>>>
>>>> @Antoine, so which content do you see in CDI Lite ? Are you sure about
>>>> events ?
>>>>
>>>> I'm in favor of a "fatter" 330 that would have :
>>>>
>>>>    - @Inject : already there
>>>>    - @Qualifier : already there
>>>>    -
>>>> *Producers and disposers *
>>>>    -
>>>> *Programatic lookup *
>>>>    - *Java SE Bootstrap*
>>>>
>>>> When you say "*The goal here is not to propose a new EE profile but a
>>>> subspec*", 330 could already be seen as a subspec. If you put events
>>>> apparts, what would be missing in this list in your point of view ? And
>>>> what obstacles do you see in archieving this ?
>>>>
>>>> To boostrap CDI we have a CDIProvider, why not having an
>>>> InjectionProvider just to bootstrap 330 (then, CDIProvider could extend
>>>> InjectionProvider, so it bootstraps the all thing) ?
>>>>
>>>> Antonio
>>>>
>>>> On Sun, Aug 30, 2015 at 9:09 AM, Antoine Sabot-Durand <
>>>> antoine at sabot-durand.net> wrote:
>>>>
>>>>> Yes Arjan, I think it's the first reason. We really should work with
>>>>> them to understand what should be added to CDI 2.0 to have it as a first
>>>>> citizen DI in their spec.
>>>>>
>>>>> Le sam. 29 ao?t 2015 ? 23:15, arjan tijms <arjan.tijms at gmail.com> a
>>>>> ?crit :
>>>>>
>>>>>> On Sat, Aug 29, 2015 at 8:45 PM, Antonio Goncalves
>>>>>> <antonio.goncalves at gmail.com> wrote:
>>>>>> > I remember talking with the JAX-RS guys (Java EE), years ago (back
>>>>>> in EE6),
>>>>>> > and their answer for not adopting CDI was "too heavy".
>>>>>>
>>>>>> I can't find an exact reference anymore, but I somewhat remember that
>>>>>> one of the reasons was also simply that CDI as a general solution
>>>>>> finished late in Java EE 6, while JAX-RS finished earlier and had all
>>>>>> the work for their own DI solution already done.
>>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Antonio Goncalves
>>>> Software architect, Java Champion and Pluralsight author
>>>>
>>>> Web site <http://www.antoniogoncalves.org> | Twitter
>>>> <http://twitter.com/agoncal> | LinkedIn
>>>> <http://www.linkedin.com/in/agoncal> | Pluralsight
>>>> <http://pluralsight.com/training/Authors/Details/antonio-goncalves> | Paris
>>>> JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr>
>>>> _______________________________________________
>>>> 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.
>>>
>>
>>
>
>
> --
> Antonio Goncalves
> Software architect, Java Champion and Pluralsight author
>
> Web site <http://www.antoniogoncalves.org> | Twitter
> <http://twitter.com/agoncal> | LinkedIn
> <http://www.linkedin.com/in/agoncal> | Pluralsight
> <http://pluralsight.com/training/Authors/Details/antonio-goncalves> | Paris
> JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150830/db8e0477/attachment.html 

From werner.keil at gmail.com  Sun Aug 30 10:11:29 2015
From: werner.keil at gmail.com (Werner Keil)
Date: Sun, 30 Aug 2015 16:11:29 +0200
Subject: [cdi-dev] Time to start working on CDI lite
Message-ID: <CAAGawe0pAd5xDiELes3gMr6zF-mPZsDtW69p90LOF+NNcFVM-w@mail.gmail.com>

Antonio/all,

JSR 330 was never a "subspec" of CDI, but CDI simply extended it. Just like
e.g. Portlet, JSP or JSF all extend and build around a standard like
Servlets.

Antoine mentioned Dagger, so if a CDI "lite" aims at SE, would the minimum
version also be SE 8 or could it be more widely usable, at least on the
Spec/API side?

We all know, Android is a bit of a red hering for Oracle with all that
lawsuit mess going on seemingly forever. Especially Dagger now that Google
took ownership again with 2.0 also aims at Android among other SE
environments. The minimum JVM version is Java SE 7 according to the POM.

If there's anything similar to a CDI lite as a subset, it's probably
CLDC/Java ME. Compared to Java SE it has a much smaller footprint with even
the same class often being reduced in its number of methods. Not sure, if
the latter was really necessary for CDI lite, but reducing the number of
overall API elements should help to get it small and useful enough for SE.

Werner

On Sun, Aug 30, 2015 at 3:22 PM, <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: Time to start working on CDI lite (Antoine Sabot-Durand)
>    2. Re: Time to start working on CDI lite (Antoine Sabot-Durand)
>    3. Re: Time to start working on CDI lite (Antonio Goncalves)
>    4. Re: Time to start working on CDI lite (John D. Ament)
>
>
> ------------------------------
>
> Message: 3
> Date: Sun, 30 Aug 2015 14:06:33 +0200
> From: Antonio Goncalves <antonio.goncalves at gmail.com>
> Subject: Re: [cdi-dev] Time to start working on CDI lite
> To: Antoine Sabot-Durand <antoine at sabot-durand.net>
> Cc: cdi-dev <cdi-dev at lists.jboss.org>
> Message-ID:
>         <
> CA+ZZq9-RW68R+o1c3n5J6KSGtki+o+89SvTpovSFL5ZKq6BTWQ at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> @Antoine, so which content do you see in CDI Lite ? Are you sure about
> events ?
>
> I'm in favor of a "fatter" 330 that would have :
>
>    - @Inject : already there
>    - @Qualifier : already there
>    -
> *Producers and disposers *
>    -
> *Programatic lookup *
>    - *Java SE Bootstrap*
>
> When you say "*The goal here is not to propose a new EE profile but a
> subspec*", 330 could already be seen as a subspec. If you put events
> apparts, what would be missing in this list in your point of view ? And
> what obstacles do you see in archieving this ?
>
> To boostrap CDI we have a CDIProvider, why not having an InjectionProvider
> just to bootstrap 330 (then, CDIProvider could extend InjectionProvider, so
> it bootstraps the all thing) ?
>
> Antonio
>
> On Sun, Aug 30, 2015 at 9:09 AM, Antoine Sabot-Durand <
> antoine at sabot-durand.net> wrote:
>
> > Yes Arjan, I think it's the first reason. We really should work with them
> > to understand what should be added to CDI 2.0 to have it as a first
> citizen
> > DI in their spec.
> >
> > Le sam. 29 ao?t 2015 ? 23:15, arjan tijms <arjan.tijms at gmail.com> a
> > ?crit :
> >
> >> On Sat, Aug 29, 2015 at 8:45 PM, Antonio Goncalves
> >> <antonio.goncalves at gmail.com> wrote:
> >> > I remember talking with the JAX-RS guys (Java EE), years ago (back in
> >> EE6),
> >> > and their answer for not adopting CDI was "too heavy".
> >>
> >> I can't find an exact reference anymore, but I somewhat remember that
> >> one of the reasons was also simply that CDI as a general solution
> >> finished late in Java EE 6, while JAX-RS finished earlier and had all
> >> the work for their own DI solution already done.
> >>
> >
>
>
> --
> Antonio Goncalves
> Software architect, Java Champion and Pluralsight author
>
> Web site <http://www.antoniogoncalves.org> | Twitter
> <http://twitter.com/agoncal> | LinkedIn <
> http://www.linkedin.com/in/agoncal> |
> Pluralsight
> <http://pluralsight.com/training/Authors/Details/antonio-goncalves> |
> Paris
> JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20150830/6d57ffc9/attachment-0001.html
>
> ------------------------------
>
> Message: 4
> Date: Sun, 30 Aug 2015 13:22:04 +0000
> From: "John D. Ament" <john.d.ament at gmail.com>
> Subject: Re: [cdi-dev] Time to start working on CDI lite
> To: Antonio Goncalves <antonio.goncalves at gmail.com>,    Antoine
>         Sabot-Durand <antoine at sabot-durand.net>
> Cc: cdi-dev <cdi-dev at lists.jboss.org>
> Message-ID:
>         <
> CAOqetn_Afc0BfGPcSRBQiKuvtOfZnQKzxHv59KhbJfLTGKoH4w at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Personally, I'm not in favor of a slimmed down runtime.  It was tried with
> EJB, but never implemented properly (most implementations that support
> EJB-lite actually support the entire thing, except for deprecated stuff).
>
> I think if we define SE properly we won't have a need for this.
>
> John
>
> On Sun, Aug 30, 2015 at 8:07 AM Antonio Goncalves <
> antonio.goncalves at gmail.com> wrote:
>
> > @Antoine, so which content do you see in CDI Lite ? Are you sure about
> > events ?
> >
> > I'm in favor of a "fatter" 330 that would have :
> >
> >    - @Inject : already there
> >    - @Qualifier : already there
> >    -
> > *Producers and disposers *
> >    -
> > *Programatic lookup *
> >    - *Java SE Bootstrap*
> >
> > When you say "*The goal here is not to propose a new EE profile but a
> > subspec*", 330 could already be seen as a subspec. If you put events
> > apparts, what would be missing in this list in your point of view ? And
> > what obstacles do you see in archieving this ?
> >
> > To boostrap CDI we have a CDIProvider, why not having an
> InjectionProvider
> > just to bootstrap 330 (then, CDIProvider could extend InjectionProvider,
> so
> > it bootstraps the all thing) ?
> >
> > Antonio
> >
> > On Sun, Aug 30, 2015 at 9:09 AM, Antoine Sabot-Durand <
> > antoine at sabot-durand.net> wrote:
> >
> >> Yes Arjan, I think it's the first reason. We really should work with
> them
> >> to understand what should be added to CDI 2.0 to have it as a first
> citizen
> >> DI in their spec.
> >>
> >> Le sam. 29 ao?t 2015 ? 23:15, arjan tijms <arjan.tijms at gmail.com> a
> >> ?crit :
> >>
> >>> On Sat, Aug 29, 2015 at 8:45 PM, Antonio Goncalves
> >>> <antonio.goncalves at gmail.com> wrote:
> >>> > I remember talking with the JAX-RS guys (Java EE), years ago (back in
> >>> EE6),
> >>> > and their answer for not adopting CDI was "too heavy".
> >>>
> >>> I can't find an exact reference anymore, but I somewhat remember that
> >>> one of the reasons was also simply that CDI as a general solution
> >>> finished late in Java EE 6, while JAX-RS finished earlier and had all
> >>> the work for their own DI solution already done.
> >>>
> >>
> >
> >
> > --
> > Antonio Goncalves
> > Software architect, Java Champion and Pluralsight author
> >
> > Web site <http://www.antoniogoncalves.org> | Twitter
> > <http://twitter.com/agoncal> | LinkedIn
> > <http://www.linkedin.com/in/agoncal> | Pluralsight
> > <http://pluralsight.com/training/Authors/Details/antonio-goncalves> |
> Paris
> > JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr>
> > _______________________________________________
> > 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/20150830/64394d4f/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 31
> ***************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150830/08ba2b50/attachment-0001.html 

From werner.keil at gmail.com  Sun Aug 30 10:29:44 2015
From: werner.keil at gmail.com (Werner Keil)
Date: Sun, 30 Aug 2015 16:29:44 +0200
Subject: [cdi-dev] cdi-dev Digest, Vol 57, Issue 33
In-Reply-To: <mailman.1716.1440943894.15730.cdi-dev@lists.jboss.org>
References: <mailman.1716.1440943894.15730.cdi-dev@lists.jboss.org>
Message-ID: <CAAGawe1b78FUAxAbwjDjGtOu=2cS9pjs3_u9Je8o6sZ0g5nKcg@mail.gmail.com>

Looking at the requirements for SE Embedded (on the lower side of SE)
probably helps:
http://www.oracle.com/technetwork/java/embedded/embedded-se/documentation/javase-embedded-sysreq-2043454.html

The 3 MB binary app size Romain mentioned is a good example. Could be a bit
steep for Embedded, but as an upper end it sounds reasonable.

Btw. although Rod Johnson and Bob Lee were listed as co Spec Leads, pretty
much every initial contribution and effort came from Google/Bob:
https://jcp.org/en/jsr/detail?id=330

The EG had a couple of others like Tapestry, but I am not sure, when it
e.g. adopted JSR 330 instead of its own DI library if it ever fully
supported it to date?

Werner

On Sun, Aug 30, 2015 at 4:11 PM, <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: Time to start working on CDI lite (Romain Manni-Bucau)
>    2. Re: Time to start working on CDI lite (Werner Keil)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sun, 30 Aug 2015 16:02:32 +0200
> From: Romain Manni-Bucau <rmannibucau at gmail.com>
> Subject: Re: [cdi-dev] Time to start working on CDI lite
> To: Antonio Goncalves <antonio.goncalves at gmail.com>
> Cc: cdi-dev <cdi-dev at lists.jboss.org>
> Message-ID:
>         <CACLE=
> 7Mu5mMB3tFWLtPxNXRpKrR82xKku5saFB9it3n-8RU1aQ at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Lite can have several definition, let's try to list them up if it can help:
>
> - binary size: for me until 3M for an app it is "Lite"
> - features number: the whole IoC set of feature is light since you almost
> always need it, it means you can do lighter but it wouldnt be used - check
> spring, who uses only spring-ioc and not context or more?
> - features complexity: sure we are not light here but supporting scopes
> already breaks "Lite-ness" IMO so not a real issue
>
> So my view is CDI "SE" is light enough - as a spec and spec can't affect
> implementations so seems the fight is not on the right side to me.
>
>
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> <http://www.tomitribe.com>
>
> 2015-08-30 15:57 GMT+02:00 Antonio Goncalves <antonio.goncalves at gmail.com
> >:
>
> > It's funny, I feel I'm in Rod Johnson shoes back in Java EE 6 where he
> > forked 330 because he found CDI was doing too much  ;o)
> >
> > For me, "CDI Lite" was just basic dependency injection. The fact that CDI
> > can now run on SE (like JPA....), is good... but for me it has nothing to
> > do with Light : it's the entire thing that can bootstrap in SE. Good.
> >
> > So what is Lite for you guys ?
> >
> > Antonio
> >
> > On Sun, Aug 30, 2015 at 3:44 PM, Romain Manni-Bucau <
> rmannibucau at gmail.com
> > > wrote:
> >
> >> 2015-08-30 15:22 GMT+02:00 John D. Ament <john.d.ament at gmail.com>:
> >>
> >>> Personally, I'm not in favor of a slimmed down runtime.  It was tried
> >>> with EJB, but never implemented properly (most implementations that
> support
> >>> EJB-lite actually support the entire thing, except for deprecated
> stuff).
> >>>
> >>>
> >> +1, most of CDI is basic and quickly any light version will miss events
> >> or other thing - in particular in maintaining micro services from
> >> experience. Size of an implementation can easily be < 1M so not sure it
> >> would bring anything. Only important point is what Antoine started to
> do ie
> >> ensuring EE and SE parts are clearly identified and split in the spec.
> >>
> >>
> >>> I think if we define SE properly we won't have a need for this.
> >>>
> >>> John
> >>>
> >>> On Sun, Aug 30, 2015 at 8:07 AM Antonio Goncalves <
> >>> antonio.goncalves at gmail.com> wrote:
> >>>
> >>>> @Antoine, so which content do you see in CDI Lite ? Are you sure about
> >>>> events ?
> >>>>
> >>>> I'm in favor of a "fatter" 330 that would have :
> >>>>
> >>>>    - @Inject : already there
> >>>>    - @Qualifier : already there
> >>>>    -
> >>>> *Producers and disposers *
> >>>>    -
> >>>> *Programatic lookup *
> >>>>    - *Java SE Bootstrap*
> >>>>
> >>>> When you say "*The goal here is not to propose a new EE profile but a
> >>>> subspec*", 330 could already be seen as a subspec. If you put events
> >>>> apparts, what would be missing in this list in your point of view ?
> And
> >>>> what obstacles do you see in archieving this ?
> >>>>
> >>>> To boostrap CDI we have a CDIProvider, why not having an
> >>>> InjectionProvider just to bootstrap 330 (then, CDIProvider could
> extend
> >>>> InjectionProvider, so it bootstraps the all thing) ?
> >>>>
> >>>> Antonio
> >>>>
> >>>> On Sun, Aug 30, 2015 at 9:09 AM, Antoine Sabot-Durand <
> >>>> antoine at sabot-durand.net> wrote:
> >>>>
> >>>>> Yes Arjan, I think it's the first reason. We really should work with
> >>>>> them to understand what should be added to CDI 2.0 to have it as a
> first
> >>>>> citizen DI in their spec.
> >>>>>
> >>>>> Le sam. 29 ao?t 2015 ? 23:15, arjan tijms <arjan.tijms at gmail.com> a
> >>>>> ?crit :
> >>>>>
> >>>>>> On Sat, Aug 29, 2015 at 8:45 PM, Antonio Goncalves
> >>>>>> <antonio.goncalves at gmail.com> wrote:
> >>>>>> > I remember talking with the JAX-RS guys (Java EE), years ago (back
> >>>>>> in EE6),
> >>>>>> > and their answer for not adopting CDI was "too heavy".
> >>>>>>
> >>>>>> I can't find an exact reference anymore, but I somewhat remember
> that
> >>>>>> one of the reasons was also simply that CDI as a general solution
> >>>>>> finished late in Java EE 6, while JAX-RS finished earlier and had
> all
> >>>>>> the work for their own DI solution already done.
> >>>>>>
> >>>>>
> >>>>
> >>>>
> >>>> --
> >>>> Antonio Goncalves
> >>>> Software architect, Java Champion and Pluralsight author
> >>>>
> >>>> Web site <http://www.antoniogoncalves.org> | Twitter
> >>>> <http://twitter.com/agoncal> | LinkedIn
> >>>> <http://www.linkedin.com/in/agoncal> | Pluralsight
> >>>> <http://pluralsight.com/training/Authors/Details/antonio-goncalves>
> | Paris
> >>>> JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr>
> >>>> _______________________________________________
> >>>> 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.
> >>>
> >>
> >>
> >
> >
> > --
> > Antonio Goncalves
> > Software architect, Java Champion and Pluralsight author
> >
> > Web site <http://www.antoniogoncalves.org> | Twitter
> > <http://twitter.com/agoncal> | LinkedIn
> > <http://www.linkedin.com/in/agoncal> | Pluralsight
> > <http://pluralsight.com/training/Authors/Details/antonio-goncalves> |
> Paris
> > JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr>
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20150830/db8e0477/attachment-0001.html
>
>
> End of cdi-dev Digest, Vol 57, Issue 33
> ***************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150830/d6056eff/attachment.html 

From werner.keil at gmail.com  Sun Aug 30 10:35:11 2015
From: werner.keil at gmail.com (Werner Keil)
Date: Sun, 30 Aug 2015 16:35:11 +0200
Subject: [cdi-dev] Time to start working on CDI lite
Message-ID: <CAAGawe39xJEzr0Y7u9yxOGroFxG3Btp7rc4Sf5K_V752JPnicQ@mail.gmail.com>

Seems, from Tapestry 5.3 on you can use both, so it doesn't look like it
completely abandoned its own:
https://tapestry.apache.org/using-jsr-330-standard-annotations.html

Luckily the 2 JSRs (with a bit of help and moderation by others) 299 and
330 did end up building on top of each other (in reverse order) rather than
reinventing the wheel and competing with other libraries even inside the
same platform or environment (like we see a lot in Java SE and to some
extent also in EE elsewhere;-)

Werner

On Sun, Aug 30, 2015 at 4:29 PM, Werner Keil <werner.keil at gmail.com> wrote:

> Looking at the requirements for SE Embedded (on the lower side of SE)
> probably helps:
>
> http://www.oracle.com/technetwork/java/embedded/embedded-se/documentation/javase-embedded-sysreq-2043454.html
>
> The 3 MB binary app size Romain mentioned is a good example. Could be a
> bit steep for Embedded, but as an upper end it sounds reasonable.
>
> Btw. although Rod Johnson and Bob Lee were listed as co Spec Leads, pretty
> much every initial contribution and effort came from Google/Bob:
> https://jcp.org/en/jsr/detail?id=330
>
> The EG had a couple of others like Tapestry, but I am not sure, when it
> e.g. adopted JSR 330 instead of its own DI library if it ever fully
> supported it to date?
>
> Werner
>
> On Sun, Aug 30, 2015 at 4:11 PM, <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: Time to start working on CDI lite (Romain Manni-Bucau)
>>    2. Re: Time to start working on CDI lite (Werner Keil)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Sun, 30 Aug 2015 16:02:32 +0200
>> From: Romain Manni-Bucau <rmannibucau at gmail.com>
>> Subject: Re: [cdi-dev] Time to start working on CDI lite
>> To: Antonio Goncalves <antonio.goncalves at gmail.com>
>> Cc: cdi-dev <cdi-dev at lists.jboss.org>
>> Message-ID:
>>         <CACLE=
>> 7Mu5mMB3tFWLtPxNXRpKrR82xKku5saFB9it3n-8RU1aQ at mail.gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> Lite can have several definition, let's try to list them up if it can
>> help:
>>
>> - binary size: for me until 3M for an app it is "Lite"
>> - features number: the whole IoC set of feature is light since you almost
>> always need it, it means you can do lighter but it wouldnt be used - check
>> spring, who uses only spring-ioc and not context or more?
>> - features complexity: sure we are not light here but supporting scopes
>> already breaks "Lite-ness" IMO so not a real issue
>>
>> So my view is CDI "SE" is light enough - as a spec and spec can't affect
>> implementations so seems the fight is not on the right side to me.
>>
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>> <http://rmannibucau.wordpress.com> | Github <
>> https://github.com/rmannibucau> |
>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
>> <http://www.tomitribe.com>
>>
>> 2015-08-30 15:57 GMT+02:00 Antonio Goncalves <antonio.goncalves at gmail.com
>> >:
>>
>> > It's funny, I feel I'm in Rod Johnson shoes back in Java EE 6 where he
>> > forked 330 because he found CDI was doing too much  ;o)
>> >
>> > For me, "CDI Lite" was just basic dependency injection. The fact that
>> CDI
>> > can now run on SE (like JPA....), is good... but for me it has nothing
>> to
>> > do with Light : it's the entire thing that can bootstrap in SE. Good.
>> >
>> > So what is Lite for you guys ?
>> >
>> > Antonio
>> >
>> > On Sun, Aug 30, 2015 at 3:44 PM, Romain Manni-Bucau <
>> rmannibucau at gmail.com
>> > > wrote:
>> >
>> >> 2015-08-30 15:22 GMT+02:00 John D. Ament <john.d.ament at gmail.com>:
>> >>
>> >>> Personally, I'm not in favor of a slimmed down runtime.  It was tried
>> >>> with EJB, but never implemented properly (most implementations that
>> support
>> >>> EJB-lite actually support the entire thing, except for deprecated
>> stuff).
>> >>>
>> >>>
>> >> +1, most of CDI is basic and quickly any light version will miss events
>> >> or other thing - in particular in maintaining micro services from
>> >> experience. Size of an implementation can easily be < 1M so not sure it
>> >> would bring anything. Only important point is what Antoine started to
>> do ie
>> >> ensuring EE and SE parts are clearly identified and split in the spec.
>> >>
>> >>
>> >>> I think if we define SE properly we won't have a need for this.
>> >>>
>> >>> John
>> >>>
>> >>> On Sun, Aug 30, 2015 at 8:07 AM Antonio Goncalves <
>> >>> antonio.goncalves at gmail.com> wrote:
>> >>>
>> >>>> @Antoine, so which content do you see in CDI Lite ? Are you sure
>> about
>> >>>> events ?
>> >>>>
>> >>>> I'm in favor of a "fatter" 330 that would have :
>> >>>>
>> >>>>    - @Inject : already there
>> >>>>    - @Qualifier : already there
>> >>>>    -
>> >>>> *Producers and disposers *
>> >>>>    -
>> >>>> *Programatic lookup *
>> >>>>    - *Java SE Bootstrap*
>> >>>>
>> >>>> When you say "*The goal here is not to propose a new EE profile but a
>> >>>> subspec*", 330 could already be seen as a subspec. If you put events
>> >>>> apparts, what would be missing in this list in your point of view ?
>> And
>> >>>> what obstacles do you see in archieving this ?
>> >>>>
>> >>>> To boostrap CDI we have a CDIProvider, why not having an
>> >>>> InjectionProvider just to bootstrap 330 (then, CDIProvider could
>> extend
>> >>>> InjectionProvider, so it bootstraps the all thing) ?
>> >>>>
>> >>>> Antonio
>> >>>>
>> >>>> On Sun, Aug 30, 2015 at 9:09 AM, Antoine Sabot-Durand <
>> >>>> antoine at sabot-durand.net> wrote:
>> >>>>
>> >>>>> Yes Arjan, I think it's the first reason. We really should work with
>> >>>>> them to understand what should be added to CDI 2.0 to have it as a
>> first
>> >>>>> citizen DI in their spec.
>> >>>>>
>> >>>>> Le sam. 29 ao?t 2015 ? 23:15, arjan tijms <arjan.tijms at gmail.com> a
>> >>>>> ?crit :
>> >>>>>
>> >>>>>> On Sat, Aug 29, 2015 at 8:45 PM, Antonio Goncalves
>> >>>>>> <antonio.goncalves at gmail.com> wrote:
>> >>>>>> > I remember talking with the JAX-RS guys (Java EE), years ago
>> (back
>> >>>>>> in EE6),
>> >>>>>> > and their answer for not adopting CDI was "too heavy".
>> >>>>>>
>> >>>>>> I can't find an exact reference anymore, but I somewhat remember
>> that
>> >>>>>> one of the reasons was also simply that CDI as a general solution
>> >>>>>> finished late in Java EE 6, while JAX-RS finished earlier and had
>> all
>> >>>>>> the work for their own DI solution already done.
>> >>>>>>
>> >>>>>
>> >>>>
>> >>>>
>> >>>> --
>> >>>> Antonio Goncalves
>> >>>> Software architect, Java Champion and Pluralsight author
>> >>>>
>> >>>> Web site <http://www.antoniogoncalves.org> | Twitter
>> >>>> <http://twitter.com/agoncal> | LinkedIn
>> >>>> <http://www.linkedin.com/in/agoncal> | Pluralsight
>> >>>> <http://pluralsight.com/training/Authors/Details/antonio-goncalves>
>> | Paris
>> >>>> JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr>
>> >>>> _______________________________________________
>> >>>> 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.
>> >>>
>> >>
>> >>
>> >
>> >
>> > --
>> > Antonio Goncalves
>> > Software architect, Java Champion and Pluralsight author
>> >
>> > Web site <http://www.antoniogoncalves.org> | Twitter
>> > <http://twitter.com/agoncal> | LinkedIn
>> > <http://www.linkedin.com/in/agoncal> | Pluralsight
>> > <http://pluralsight.com/training/Authors/Details/antonio-goncalves> |
>> Paris
>> > JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr>
>> >
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL:
>> http://lists.jboss.org/pipermail/cdi-dev/attachments/20150830/db8e0477/attachment-0001.html
>>
>>
>> End of cdi-dev Digest, Vol 57, Issue 33
>> ***************************************
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150830/8bf33ad0/attachment-0001.html 

From rmannibucau at gmail.com  Sun Aug 30 10:36:19 2015
From: rmannibucau at gmail.com (Romain Manni-Bucau)
Date: Sun, 30 Aug 2015 16:36:19 +0200
Subject: [cdi-dev] cdi-dev Digest, Vol 57, Issue 33
In-Reply-To: <CAAGawe1b78FUAxAbwjDjGtOu=2cS9pjs3_u9Je8o6sZ0g5nKcg@mail.gmail.com>
References: <mailman.1716.1440943894.15730.cdi-dev@lists.jboss.org>
	<CAAGawe1b78FUAxAbwjDjGtOu=2cS9pjs3_u9Je8o6sZ0g5nKcg@mail.gmail.com>
Message-ID: <CACLE=7NdZHvoAm_TSOcoTOZWhJxN=R3b6fw26TBzeQFNHHShBg@mail.gmail.com>

2015-08-30 16:29 GMT+02:00 Werner Keil <werner.keil at gmail.com>:

> Looking at the requirements for SE Embedded (on the lower side of SE)
> probably helps:
>
> http://www.oracle.com/technetwork/java/embedded/embedded-se/documentation/javase-embedded-sysreq-2043454.html
>
> The 3 MB binary app size Romain mentioned is a good example. Could be a
> bit steep for Embedded, but as an upper end it sounds reasonable.
>
>
Just to explain this 3M:
- CDI / IoC ~ 1M
- You always need at least another framework, considered 1M for it min
taking JAXRS as sample (with a json provider) but for a batch it would be
less ~ 500K min
- plus a JDBC driver, MySQL is 1M as well, hsqldb is 1.4M

So 3M seems a light app if only based on CDI. For a EE app it is a lot
(JPA, CDI, JAXRS are provided).


> Btw. although Rod Johnson and Bob Lee were listed as co Spec Leads, pretty
> much every initial contribution and effort came from Google/Bob:
> https://jcp.org/en/jsr/detail?id=330
>
> The EG had a couple of others like Tapestry, but I am not sure, when it
> e.g. adopted JSR 330 instead of its own DI library if it ever fully
> supported it to date?
>
> Werner
>
> On Sun, Aug 30, 2015 at 4:11 PM, <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: Time to start working on CDI lite (Romain Manni-Bucau)
>>    2. Re: Time to start working on CDI lite (Werner Keil)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Sun, 30 Aug 2015 16:02:32 +0200
>> From: Romain Manni-Bucau <rmannibucau at gmail.com>
>> Subject: Re: [cdi-dev] Time to start working on CDI lite
>> To: Antonio Goncalves <antonio.goncalves at gmail.com>
>> Cc: cdi-dev <cdi-dev at lists.jboss.org>
>> Message-ID:
>>         <CACLE=
>> 7Mu5mMB3tFWLtPxNXRpKrR82xKku5saFB9it3n-8RU1aQ at mail.gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> Lite can have several definition, let's try to list them up if it can
>> help:
>>
>> - binary size: for me until 3M for an app it is "Lite"
>> - features number: the whole IoC set of feature is light since you almost
>> always need it, it means you can do lighter but it wouldnt be used - check
>> spring, who uses only spring-ioc and not context or more?
>> - features complexity: sure we are not light here but supporting scopes
>> already breaks "Lite-ness" IMO so not a real issue
>>
>> So my view is CDI "SE" is light enough - as a spec and spec can't affect
>> implementations so seems the fight is not on the right side to me.
>>
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>> <http://rmannibucau.wordpress.com> | Github <
>> https://github.com/rmannibucau> |
>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
>> <http://www.tomitribe.com>
>>
>> 2015-08-30 15:57 GMT+02:00 Antonio Goncalves <antonio.goncalves at gmail.com
>> >:
>>
>> > It's funny, I feel I'm in Rod Johnson shoes back in Java EE 6 where he
>> > forked 330 because he found CDI was doing too much  ;o)
>> >
>> > For me, "CDI Lite" was just basic dependency injection. The fact that
>> CDI
>> > can now run on SE (like JPA....), is good... but for me it has nothing
>> to
>> > do with Light : it's the entire thing that can bootstrap in SE. Good.
>> >
>> > So what is Lite for you guys ?
>> >
>> > Antonio
>> >
>> > On Sun, Aug 30, 2015 at 3:44 PM, Romain Manni-Bucau <
>> rmannibucau at gmail.com
>> > > wrote:
>> >
>> >> 2015-08-30 15:22 GMT+02:00 John D. Ament <john.d.ament at gmail.com>:
>> >>
>> >>> Personally, I'm not in favor of a slimmed down runtime.  It was tried
>> >>> with EJB, but never implemented properly (most implementations that
>> support
>> >>> EJB-lite actually support the entire thing, except for deprecated
>> stuff).
>> >>>
>> >>>
>> >> +1, most of CDI is basic and quickly any light version will miss events
>> >> or other thing - in particular in maintaining micro services from
>> >> experience. Size of an implementation can easily be < 1M so not sure it
>> >> would bring anything. Only important point is what Antoine started to
>> do ie
>> >> ensuring EE and SE parts are clearly identified and split in the spec.
>> >>
>> >>
>> >>> I think if we define SE properly we won't have a need for this.
>> >>>
>> >>> John
>> >>>
>> >>> On Sun, Aug 30, 2015 at 8:07 AM Antonio Goncalves <
>> >>> antonio.goncalves at gmail.com> wrote:
>> >>>
>> >>>> @Antoine, so which content do you see in CDI Lite ? Are you sure
>> about
>> >>>> events ?
>> >>>>
>> >>>> I'm in favor of a "fatter" 330 that would have :
>> >>>>
>> >>>>    - @Inject : already there
>> >>>>    - @Qualifier : already there
>> >>>>    -
>> >>>> *Producers and disposers *
>> >>>>    -
>> >>>> *Programatic lookup *
>> >>>>    - *Java SE Bootstrap*
>> >>>>
>> >>>> When you say "*The goal here is not to propose a new EE profile but a
>> >>>> subspec*", 330 could already be seen as a subspec. If you put events
>> >>>> apparts, what would be missing in this list in your point of view ?
>> And
>> >>>> what obstacles do you see in archieving this ?
>> >>>>
>> >>>> To boostrap CDI we have a CDIProvider, why not having an
>> >>>> InjectionProvider just to bootstrap 330 (then, CDIProvider could
>> extend
>> >>>> InjectionProvider, so it bootstraps the all thing) ?
>> >>>>
>> >>>> Antonio
>> >>>>
>> >>>> On Sun, Aug 30, 2015 at 9:09 AM, Antoine Sabot-Durand <
>> >>>> antoine at sabot-durand.net> wrote:
>> >>>>
>> >>>>> Yes Arjan, I think it's the first reason. We really should work with
>> >>>>> them to understand what should be added to CDI 2.0 to have it as a
>> first
>> >>>>> citizen DI in their spec.
>> >>>>>
>> >>>>> Le sam. 29 ao?t 2015 ? 23:15, arjan tijms <arjan.tijms at gmail.com> a
>> >>>>> ?crit :
>> >>>>>
>> >>>>>> On Sat, Aug 29, 2015 at 8:45 PM, Antonio Goncalves
>> >>>>>> <antonio.goncalves at gmail.com> wrote:
>> >>>>>> > I remember talking with the JAX-RS guys (Java EE), years ago
>> (back
>> >>>>>> in EE6),
>> >>>>>> > and their answer for not adopting CDI was "too heavy".
>> >>>>>>
>> >>>>>> I can't find an exact reference anymore, but I somewhat remember
>> that
>> >>>>>> one of the reasons was also simply that CDI as a general solution
>> >>>>>> finished late in Java EE 6, while JAX-RS finished earlier and had
>> all
>> >>>>>> the work for their own DI solution already done.
>> >>>>>>
>> >>>>>
>> >>>>
>> >>>>
>> >>>> --
>> >>>> Antonio Goncalves
>> >>>> Software architect, Java Champion and Pluralsight author
>> >>>>
>> >>>> Web site <http://www.antoniogoncalves.org> | Twitter
>> >>>> <http://twitter.com/agoncal> | LinkedIn
>> >>>> <http://www.linkedin.com/in/agoncal> | Pluralsight
>> >>>> <http://pluralsight.com/training/Authors/Details/antonio-goncalves>
>> | Paris
>> >>>> JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr>
>> >>>> _______________________________________________
>> >>>> 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.
>> >>>
>> >>
>> >>
>> >
>> >
>> > --
>> > Antonio Goncalves
>> > Software architect, Java Champion and Pluralsight author
>> >
>> > Web site <http://www.antoniogoncalves.org> | Twitter
>> > <http://twitter.com/agoncal> | LinkedIn
>> > <http://www.linkedin.com/in/agoncal> | Pluralsight
>> > <http://pluralsight.com/training/Authors/Details/antonio-goncalves> |
>> Paris
>> > JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr>
>> >
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL:
>> http://lists.jboss.org/pipermail/cdi-dev/attachments/20150830/db8e0477/attachment-0001.html
>>
>>
>> End of cdi-dev Digest, Vol 57, Issue 33
>> ***************************************
>>
>
>
> _______________________________________________
> 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/20150830/720a6627/attachment.html 

From antonio.goncalves at gmail.com  Sun Aug 30 12:09:41 2015
From: antonio.goncalves at gmail.com (Antonio Goncalves)
Date: Sun, 30 Aug 2015 18:09:41 +0200
Subject: [cdi-dev] Time to start working on CDI lite
In-Reply-To: <CACLE=7Mu5mMB3tFWLtPxNXRpKrR82xKku5saFB9it3n-8RU1aQ@mail.gmail.com>
References: <CABu-YBQvgrVZcH31i+Uw9ZefsTZvLHJ4919PW=vnvRBa2RVoTQ@mail.gmail.com>
	<CA+ZZq9_C_nTH1YY1uNYnH2aW6RBBR7+xH9ZF+cduMhzOQHOO8g@mail.gmail.com>
	<CAE=-AhDa84QjHqwNLJD3+a1f2mD2d+Y_2kwqRVqzBRkuvf4Qfw@mail.gmail.com>
	<CABu-YBQ9ZtUdSj6LUoROz2-JuqROtLTG1UKUSANOY4kiVHpTDg@mail.gmail.com>
	<CA+ZZq9-RW68R+o1c3n5J6KSGtki+o+89SvTpovSFL5ZKq6BTWQ@mail.gmail.com>
	<CAOqetn_Afc0BfGPcSRBQiKuvtOfZnQKzxHv59KhbJfLTGKoH4w@mail.gmail.com>
	<CACLE=7MmgSVukPrN-fiu959w1zv7hj19VikGx-4JzA2mTRVG-w@mail.gmail.com>
	<CA+ZZq99XKDbwnqLPi-j4rcizU9EcuNzjsJTHo+Qy_djjtMCy_Q@mail.gmail.com>
	<CACLE=7Mu5mMB3tFWLtPxNXRpKrR82xKku5saFB9it3n-8RU1aQ@mail.gmail.com>
Message-ID: <CA+ZZq9-YFcTKuZr=+6v=wH-w670E++qgBrN36DsToFEidUzenQ@mail.gmail.com>

For me, a Light version of CDI is clearly the features number. That's why I
don't see events in it.

For me, a CDI Lite would just focus on DI. If CDI has @Produces and Spring
has @Bean, then it's because 330 lakes this functionality.

On Sun, Aug 30, 2015 at 4:02 PM, Romain Manni-Bucau <rmannibucau at gmail.com>
wrote:

> Lite can have several definition, let's try to list them up if it can help:
>
> - binary size: for me until 3M for an app it is "Lite"
> - features number: the whole IoC set of feature is light since you almost
> always need it, it means you can do lighter but it wouldnt be used - check
> spring, who uses only spring-ioc and not context or more?
> - features complexity: sure we are not light here but supporting scopes
> already breaks "Lite-ness" IMO so not a real issue
>
> So my view is CDI "SE" is light enough - as a spec and spec can't affect
> implementations so seems the fight is not on the right side to me.
>
>
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <http://rmannibucau.wordpress.com> | Github
> <https://github.com/rmannibucau> | LinkedIn
> <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> <http://www.tomitribe.com>
>
> 2015-08-30 15:57 GMT+02:00 Antonio Goncalves <antonio.goncalves at gmail.com>
> :
>
>> It's funny, I feel I'm in Rod Johnson shoes back in Java EE 6 where he
>> forked 330 because he found CDI was doing too much  ;o)
>>
>> For me, "CDI Lite" was just basic dependency injection. The fact that CDI
>> can now run on SE (like JPA....), is good... but for me it has nothing to
>> do with Light : it's the entire thing that can bootstrap in SE. Good.
>>
>> So what is Lite for you guys ?
>>
>> Antonio
>>
>> On Sun, Aug 30, 2015 at 3:44 PM, Romain Manni-Bucau <
>> rmannibucau at gmail.com> wrote:
>>
>>> 2015-08-30 15:22 GMT+02:00 John D. Ament <john.d.ament at gmail.com>:
>>>
>>>> Personally, I'm not in favor of a slimmed down runtime.  It was tried
>>>> with EJB, but never implemented properly (most implementations that support
>>>> EJB-lite actually support the entire thing, except for deprecated stuff).
>>>>
>>>>
>>> +1, most of CDI is basic and quickly any light version will miss events
>>> or other thing - in particular in maintaining micro services from
>>> experience. Size of an implementation can easily be < 1M so not sure it
>>> would bring anything. Only important point is what Antoine started to do ie
>>> ensuring EE and SE parts are clearly identified and split in the spec.
>>>
>>>
>>>> I think if we define SE properly we won't have a need for this.
>>>>
>>>> John
>>>>
>>>> On Sun, Aug 30, 2015 at 8:07 AM Antonio Goncalves <
>>>> antonio.goncalves at gmail.com> wrote:
>>>>
>>>>> @Antoine, so which content do you see in CDI Lite ? Are you sure about
>>>>> events ?
>>>>>
>>>>> I'm in favor of a "fatter" 330 that would have :
>>>>>
>>>>>    - @Inject : already there
>>>>>    - @Qualifier : already there
>>>>>    -
>>>>> *Producers and disposers *
>>>>>    -
>>>>> *Programatic lookup *
>>>>>    - *Java SE Bootstrap*
>>>>>
>>>>> When you say "*The goal here is not to propose a new EE profile but a
>>>>> subspec*", 330 could already be seen as a subspec. If you put events
>>>>> apparts, what would be missing in this list in your point of view ? And
>>>>> what obstacles do you see in archieving this ?
>>>>>
>>>>> To boostrap CDI we have a CDIProvider, why not having an
>>>>> InjectionProvider just to bootstrap 330 (then, CDIProvider could extend
>>>>> InjectionProvider, so it bootstraps the all thing) ?
>>>>>
>>>>> Antonio
>>>>>
>>>>> On Sun, Aug 30, 2015 at 9:09 AM, Antoine Sabot-Durand <
>>>>> antoine at sabot-durand.net> wrote:
>>>>>
>>>>>> Yes Arjan, I think it's the first reason. We really should work with
>>>>>> them to understand what should be added to CDI 2.0 to have it as a first
>>>>>> citizen DI in their spec.
>>>>>>
>>>>>> Le sam. 29 ao?t 2015 ? 23:15, arjan tijms <arjan.tijms at gmail.com> a
>>>>>> ?crit :
>>>>>>
>>>>>>> On Sat, Aug 29, 2015 at 8:45 PM, Antonio Goncalves
>>>>>>> <antonio.goncalves at gmail.com> wrote:
>>>>>>> > I remember talking with the JAX-RS guys (Java EE), years ago (back
>>>>>>> in EE6),
>>>>>>> > and their answer for not adopting CDI was "too heavy".
>>>>>>>
>>>>>>> I can't find an exact reference anymore, but I somewhat remember that
>>>>>>> one of the reasons was also simply that CDI as a general solution
>>>>>>> finished late in Java EE 6, while JAX-RS finished earlier and had all
>>>>>>> the work for their own DI solution already done.
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Antonio Goncalves
>>>>> Software architect, Java Champion and Pluralsight author
>>>>>
>>>>> Web site <http://www.antoniogoncalves.org> | Twitter
>>>>> <http://twitter.com/agoncal> | LinkedIn
>>>>> <http://www.linkedin.com/in/agoncal> | Pluralsight
>>>>> <http://pluralsight.com/training/Authors/Details/antonio-goncalves> | Paris
>>>>> JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr>
>>>>> _______________________________________________
>>>>> 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.
>>>>
>>>
>>>
>>
>>
>> --
>> Antonio Goncalves
>> Software architect, Java Champion and Pluralsight author
>>
>> Web site <http://www.antoniogoncalves.org> | Twitter
>> <http://twitter.com/agoncal> | LinkedIn
>> <http://www.linkedin.com/in/agoncal> | Pluralsight
>> <http://pluralsight.com/training/Authors/Details/antonio-goncalves> | Paris
>> JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr>
>>
>
>


-- 
Antonio Goncalves
Software architect, Java Champion and Pluralsight author

Web site <http://www.antoniogoncalves.org> | Twitter
<http://twitter.com/agoncal> | LinkedIn <http://www.linkedin.com/in/agoncal> |
Pluralsight
<http://pluralsight.com/training/Authors/Details/antonio-goncalves> | Paris
JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150830/41058591/attachment-0001.html 

From rmannibucau at gmail.com  Sun Aug 30 12:15:53 2015
From: rmannibucau at gmail.com (Romain Manni-Bucau)
Date: Sun, 30 Aug 2015 18:15:53 +0200
Subject: [cdi-dev] Time to start working on CDI lite
In-Reply-To: <CA+ZZq9-YFcTKuZr=+6v=wH-w670E++qgBrN36DsToFEidUzenQ@mail.gmail.com>
References: <CABu-YBQvgrVZcH31i+Uw9ZefsTZvLHJ4919PW=vnvRBa2RVoTQ@mail.gmail.com>
	<CA+ZZq9_C_nTH1YY1uNYnH2aW6RBBR7+xH9ZF+cduMhzOQHOO8g@mail.gmail.com>
	<CAE=-AhDa84QjHqwNLJD3+a1f2mD2d+Y_2kwqRVqzBRkuvf4Qfw@mail.gmail.com>
	<CABu-YBQ9ZtUdSj6LUoROz2-JuqROtLTG1UKUSANOY4kiVHpTDg@mail.gmail.com>
	<CA+ZZq9-RW68R+o1c3n5J6KSGtki+o+89SvTpovSFL5ZKq6BTWQ@mail.gmail.com>
	<CAOqetn_Afc0BfGPcSRBQiKuvtOfZnQKzxHv59KhbJfLTGKoH4w@mail.gmail.com>
	<CACLE=7MmgSVukPrN-fiu959w1zv7hj19VikGx-4JzA2mTRVG-w@mail.gmail.com>
	<CA+ZZq99XKDbwnqLPi-j4rcizU9EcuNzjsJTHo+Qy_djjtMCy_Q@mail.gmail.com>
	<CACLE=7Mu5mMB3tFWLtPxNXRpKrR82xKku5saFB9it3n-8RU1aQ@mail.gmail.com>
	<CA+ZZq9-YFcTKuZr=+6v=wH-w670E++qgBrN36DsToFEidUzenQ@mail.gmail.com>
Message-ID: <CACLE=7PNZFkp1n0_edLmiddLm-_JrKSQgOSkypY+pJsx9zQbhA@mail.gmail.com>

2015-08-30 18:09 GMT+02:00 Antonio Goncalves <antonio.goncalves at gmail.com>:

> For me, a Light version of CDI is clearly the features number. That's why
> I don't see events in it.
>
> For me, a CDI Lite would just focus on DI. If CDI has @Produces and Spring
> has @Bean, then it's because 330 lakes this functionality.
>
>
Agree on the need of this feature that said I understand 330 as some nice
set of common annotations but used by everybody differently - @Inject in
spring is different from @Inject in CDI or Tapestry typically.

About events i think they are common enough - in particular in term of
maintenance - to be there by default and size they imply is not important
enugh to not get them onboard IMO.

Now I see we dont agree on what "Lite" can mean - thought it was removing
features to be lighter in size - so we should maybe vote to decide the
actual target and just go ahead on it.

Do you share this point?


> On Sun, Aug 30, 2015 at 4:02 PM, Romain Manni-Bucau <rmannibucau at gmail.com
> > wrote:
>
>> Lite can have several definition, let's try to list them up if it can
>> help:
>>
>> - binary size: for me until 3M for an app it is "Lite"
>> - features number: the whole IoC set of feature is light since you almost
>> always need it, it means you can do lighter but it wouldnt be used - check
>> spring, who uses only spring-ioc and not context or more?
>> - features complexity: sure we are not light here but supporting scopes
>> already breaks "Lite-ness" IMO so not a real issue
>>
>> So my view is CDI "SE" is light enough - as a spec and spec can't affect
>> implementations so seems the fight is not on the right side to me.
>>
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>> <http://rmannibucau.wordpress.com> | Github
>> <https://github.com/rmannibucau> | LinkedIn
>> <https://www.linkedin.com/in/rmannibucau> | Tomitriber
>> <http://www.tomitribe.com>
>>
>> 2015-08-30 15:57 GMT+02:00 Antonio Goncalves <antonio.goncalves at gmail.com
>> >:
>>
>>> It's funny, I feel I'm in Rod Johnson shoes back in Java EE 6 where he
>>> forked 330 because he found CDI was doing too much  ;o)
>>>
>>> For me, "CDI Lite" was just basic dependency injection. The fact that
>>> CDI can now run on SE (like JPA....), is good... but for me it has nothing
>>> to do with Light : it's the entire thing that can bootstrap in SE. Good.
>>>
>>> So what is Lite for you guys ?
>>>
>>> Antonio
>>>
>>> On Sun, Aug 30, 2015 at 3:44 PM, Romain Manni-Bucau <
>>> rmannibucau at gmail.com> wrote:
>>>
>>>> 2015-08-30 15:22 GMT+02:00 John D. Ament <john.d.ament at gmail.com>:
>>>>
>>>>> Personally, I'm not in favor of a slimmed down runtime.  It was tried
>>>>> with EJB, but never implemented properly (most implementations that support
>>>>> EJB-lite actually support the entire thing, except for deprecated stuff).
>>>>>
>>>>>
>>>> +1, most of CDI is basic and quickly any light version will miss events
>>>> or other thing - in particular in maintaining micro services from
>>>> experience. Size of an implementation can easily be < 1M so not sure it
>>>> would bring anything. Only important point is what Antoine started to do ie
>>>> ensuring EE and SE parts are clearly identified and split in the spec.
>>>>
>>>>
>>>>> I think if we define SE properly we won't have a need for this.
>>>>>
>>>>> John
>>>>>
>>>>> On Sun, Aug 30, 2015 at 8:07 AM Antonio Goncalves <
>>>>> antonio.goncalves at gmail.com> wrote:
>>>>>
>>>>>> @Antoine, so which content do you see in CDI Lite ? Are you sure
>>>>>> about events ?
>>>>>>
>>>>>> I'm in favor of a "fatter" 330 that would have :
>>>>>>
>>>>>>    - @Inject : already there
>>>>>>    - @Qualifier : already there
>>>>>>    -
>>>>>> *Producers and disposers *
>>>>>>    -
>>>>>> *Programatic lookup *
>>>>>>    - *Java SE Bootstrap*
>>>>>>
>>>>>> When you say "*The goal here is not to propose a new EE profile but
>>>>>> a subspec*", 330 could already be seen as a subspec. If you put
>>>>>> events apparts, what would be missing in this list in your point of view ?
>>>>>> And what obstacles do you see in archieving this ?
>>>>>>
>>>>>> To boostrap CDI we have a CDIProvider, why not having an
>>>>>> InjectionProvider just to bootstrap 330 (then, CDIProvider could extend
>>>>>> InjectionProvider, so it bootstraps the all thing) ?
>>>>>>
>>>>>> Antonio
>>>>>>
>>>>>> On Sun, Aug 30, 2015 at 9:09 AM, Antoine Sabot-Durand <
>>>>>> antoine at sabot-durand.net> wrote:
>>>>>>
>>>>>>> Yes Arjan, I think it's the first reason. We really should work with
>>>>>>> them to understand what should be added to CDI 2.0 to have it as a first
>>>>>>> citizen DI in their spec.
>>>>>>>
>>>>>>> Le sam. 29 ao?t 2015 ? 23:15, arjan tijms <arjan.tijms at gmail.com> a
>>>>>>> ?crit :
>>>>>>>
>>>>>>>> On Sat, Aug 29, 2015 at 8:45 PM, Antonio Goncalves
>>>>>>>> <antonio.goncalves at gmail.com> wrote:
>>>>>>>> > I remember talking with the JAX-RS guys (Java EE), years ago
>>>>>>>> (back in EE6),
>>>>>>>> > and their answer for not adopting CDI was "too heavy".
>>>>>>>>
>>>>>>>> I can't find an exact reference anymore, but I somewhat remember
>>>>>>>> that
>>>>>>>> one of the reasons was also simply that CDI as a general solution
>>>>>>>> finished late in Java EE 6, while JAX-RS finished earlier and had
>>>>>>>> all
>>>>>>>> the work for their own DI solution already done.
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Antonio Goncalves
>>>>>> Software architect, Java Champion and Pluralsight author
>>>>>>
>>>>>> Web site <http://www.antoniogoncalves.org> | Twitter
>>>>>> <http://twitter.com/agoncal> | LinkedIn
>>>>>> <http://www.linkedin.com/in/agoncal> | Pluralsight
>>>>>> <http://pluralsight.com/training/Authors/Details/antonio-goncalves>
>>>>>>  | Paris JUG <http://www.parisjug.org> | Devoxx France
>>>>>> <http://www.devoxx.fr>
>>>>>> _______________________________________________
>>>>>> 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.
>>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Antonio Goncalves
>>> Software architect, Java Champion and Pluralsight author
>>>
>>> Web site <http://www.antoniogoncalves.org> | Twitter
>>> <http://twitter.com/agoncal> | LinkedIn
>>> <http://www.linkedin.com/in/agoncal> | Pluralsight
>>> <http://pluralsight.com/training/Authors/Details/antonio-goncalves> | Paris
>>> JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr>
>>>
>>
>>
>
>
> --
> Antonio Goncalves
> Software architect, Java Champion and Pluralsight author
>
> Web site <http://www.antoniogoncalves.org> | Twitter
> <http://twitter.com/agoncal> | LinkedIn
> <http://www.linkedin.com/in/agoncal> | Pluralsight
> <http://pluralsight.com/training/Authors/Details/antonio-goncalves> | Paris
> JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150830/bdee541f/attachment.html 

From werner.keil at gmail.com  Sun Aug 30 14:29:18 2015
From: werner.keil at gmail.com (Werner Keil)
Date: Sun, 30 Aug 2015 20:29:18 +0200
Subject: [cdi-dev] Time to start working on CDI lite
Message-ID: <CAAGawe2Gp0f=W7krJTiKTmRqjzis2eT8r-wbRZtpgmNrm3nAKQ@mail.gmail.com>

As there is well-established event handling on the SE and ME side, in most
cases based on java.util.EventObject, I could imagine CDI events being
either outside a "lite" profile or at least optional, should we consider
optionality.

Werner

On Sun, Aug 30, 2015 at 6:10 PM, <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: cdi-dev Digest, Vol 57, Issue 33 (Romain Manni-Bucau)
>    2. Re: Time to start working on CDI lite (Antonio Goncalves)
>
>
> ----------------------------------------------------------------------
>
> Message: 2
> Date: Sun, 30 Aug 2015 18:09:41 +0200
> From: Antonio Goncalves <antonio.goncalves at gmail.com>
> Subject: Re: [cdi-dev] Time to start working on CDI lite
> To: Romain Manni-Bucau <rmannibucau at gmail.com>
> Cc: cdi-dev <cdi-dev at lists.jboss.org>
> Message-ID:
>         <CA+ZZq9-YFcTKuZr=+6v=
> wH-w670E++qgBrN36DsToFEidUzenQ at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> For me, a Light version of CDI is clearly the features number. That's why I
> don't see events in it.
>
> For me, a CDI Lite would just focus on DI. If CDI has @Produces and Spring
> has @Bean, then it's because 330 lakes this functionality.
>
> On Sun, Aug 30, 2015 at 4:02 PM, Romain Manni-Bucau <rmannibucau at gmail.com
> >
> wrote:
>
> > Lite can have several definition, let's try to list them up if it can
> help:
> >
> > - binary size: for me until 3M for an app it is "Lite"
> > - features number: the whole IoC set of feature is light since you almost
> > always need it, it means you can do lighter but it wouldnt be used -
> check
> > spring, who uses only spring-ioc and not context or more?
> > - features complexity: sure we are not light here but supporting scopes
> > already breaks "Lite-ness" IMO so not a real issue
> >
> > So my view is CDI "SE" is light enough - as a spec and spec can't affect
> > implementations so seems the fight is not on the right side to me.
> >
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > <http://rmannibucau.wordpress.com> | Github
> > <https://github.com/rmannibucau> | LinkedIn
> > <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> > <http://www.tomitribe.com>
> >
> > 2015-08-30 15:57 GMT+02:00 Antonio Goncalves <
> antonio.goncalves at gmail.com>
> > :
> >
> >> It's funny, I feel I'm in Rod Johnson shoes back in Java EE 6 where he
> >> forked 330 because he found CDI was doing too much  ;o)
> >>
> >> For me, "CDI Lite" was just basic dependency injection. The fact that
> CDI
> >> can now run on SE (like JPA....), is good... but for me it has nothing
> to
> >> do with Light : it's the entire thing that can bootstrap in SE. Good.
> >>
> >> So what is Lite for you guys ?
> >>
> >> Antonio
> >>
> >> On Sun, Aug 30, 2015 at 3:44 PM, Romain Manni-Bucau <
> >> rmannibucau at gmail.com> wrote:
> >>
> >>> 2015-08-30 15:22 GMT+02:00 John D. Ament <john.d.ament at gmail.com>:
> >>>
> >>>> Personally, I'm not in favor of a slimmed down runtime.  It was tried
> >>>> with EJB, but never implemented properly (most implementations that
> support
> >>>> EJB-lite actually support the entire thing, except for deprecated
> stuff).
> >>>>
> >>>>
> >>> +1, most of CDI is basic and quickly any light version will miss events
> >>> or other thing - in particular in maintaining micro services from
> >>> experience. Size of an implementation can easily be < 1M so not sure it
> >>> would bring anything. Only important point is what Antoine started to
> do ie
> >>> ensuring EE and SE parts are clearly identified and split in the spec.
> >>>
> >>>
> >>>> I think if we define SE properly we won't have a need for this.
> >>>>
> >>>> John
> >>>>
> >>>> On Sun, Aug 30, 2015 at 8:07 AM Antonio Goncalves <
> >>>> antonio.goncalves at gmail.com> wrote:
> >>>>
> >>>>> @Antoine, so which content do you see in CDI Lite ? Are you sure
> about
> >>>>> events ?
> >>>>>
> >>>>> I'm in favor of a "fatter" 330 that would have :
> >>>>>
> >>>>>    - @Inject : already there
> >>>>>    - @Qualifier : already there
> >>>>>    -
> >>>>> *Producers and disposers *
> >>>>>    -
> >>>>> *Programatic lookup *
> >>>>>    - *Java SE Bootstrap*
> >>>>>
> >>>>> When you say "*The goal here is not to propose a new EE profile but a
> >>>>> subspec*", 330 could already be seen as a subspec. If you put events
> >>>>> apparts, what would be missing in this list in your point of view ?
> And
> >>>>> what obstacles do you see in archieving this ?
> >>>>>
> >>>>> To boostrap CDI we have a CDIProvider, why not having an
> >>>>> InjectionProvider just to bootstrap 330 (then, CDIProvider could
> extend
> >>>>> InjectionProvider, so it bootstraps the all thing) ?
> >>>>>
> >>>>> Antonio
> >>>>>
> >>>>> On Sun, Aug 30, 2015 at 9:09 AM, Antoine Sabot-Durand <
> >>>>> antoine at sabot-durand.net> wrote:
> >>>>>
> >>>>>> Yes Arjan, I think it's the first reason. We really should work with
> >>>>>> them to understand what should be added to CDI 2.0 to have it as a
> first
> >>>>>> citizen DI in their spec.
> >>>>>>
> >>>>>> Le sam. 29 ao?t 2015 ? 23:15, arjan tijms <arjan.tijms at gmail.com> a
> >>>>>> ?crit :
> >>>>>>
> >>>>>>> On Sat, Aug 29, 2015 at 8:45 PM, Antonio Goncalves
> >>>>>>> <antonio.goncalves at gmail.com> wrote:
> >>>>>>> > I remember talking with the JAX-RS guys (Java EE), years ago
> (back
> >>>>>>> in EE6),
> >>>>>>> > and their answer for not adopting CDI was "too heavy".
> >>>>>>>
> >>>>>>> I can't find an exact reference anymore, but I somewhat remember
> that
> >>>>>>> one of the reasons was also simply that CDI as a general solution
> >>>>>>> finished late in Java EE 6, while JAX-RS finished earlier and had
> all
> >>>>>>> the work for their own DI solution already done.
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Antonio Goncalves
> >>>>> Software architect, Java Champion and Pluralsight author
> >>>>>
> >>>>> Web site <http://www.antoniogoncalves.org> | Twitter
> >>>>> <http://twitter.com/agoncal> | LinkedIn
> >>>>> <http://www.linkedin.com/in/agoncal> | Pluralsight
> >>>>> <http://pluralsight.com/training/Authors/Details/antonio-goncalves>
> | Paris
> >>>>> JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr>
> >>>>> _______________________________________________
> >>>>> 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.
> >>>>
> >>>
> >>>
> >>
> >>
> >> --
> >> Antonio Goncalves
> >> Software architect, Java Champion and Pluralsight author
> >>
> >> Web site <http://www.antoniogoncalves.org> | Twitter
> >> <http://twitter.com/agoncal> | LinkedIn
> >> <http://www.linkedin.com/in/agoncal> | Pluralsight
> >> <http://pluralsight.com/training/Authors/Details/antonio-goncalves> |
> Paris
> >> JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr>
> >>
> >
> >
>
>
> --
> Antonio Goncalves
> Software architect, Java Champion and Pluralsight author
>
> Web site <http://www.antoniogoncalves.org> | Twitter
> <http://twitter.com/agoncal> | LinkedIn <
> http://www.linkedin.com/in/agoncal> |
> Pluralsight
> <http://pluralsight.com/training/Authors/Details/antonio-goncalves> |
> Paris
> JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20150830/41058591/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 35
> ***************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150830/6174d7c2/attachment-0001.html 

From rmannibucau at gmail.com  Sun Aug 30 15:11:24 2015
From: rmannibucau at gmail.com (Romain Manni-Bucau)
Date: Sun, 30 Aug 2015 21:11:24 +0200
Subject: [cdi-dev] Time to start working on CDI lite
In-Reply-To: <CAAGawe2Gp0f=W7krJTiKTmRqjzis2eT8r-wbRZtpgmNrm3nAKQ@mail.gmail.com>
References: <CAAGawe2Gp0f=W7krJTiKTmRqjzis2eT8r-wbRZtpgmNrm3nAKQ@mail.gmail.com>
Message-ID: <CACLE=7PgKRmCrKiN1+xxLvqCtm3V1AE8D3c7kz_1W_wp1fuxkw@mail.gmail.com>

2015-08-30 20:29 GMT+02:00 Werner Keil <werner.keil at gmail.com>:

> As there is well-established event handling on the SE and ME side, in most
> cases based on java.util.EventObject, I could imagine CDI events being
> either outside a "lite" profile or at least optional, should we consider
> optionality.
>
>
not sure I agree, SE has an event hierarchy but its listener model is not
as usable as CDI most of the time because of the register side


> Werner
>
> On Sun, Aug 30, 2015 at 6:10 PM, <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: cdi-dev Digest, Vol 57, Issue 33 (Romain Manni-Bucau)
>>    2. Re: Time to start working on CDI lite (Antonio Goncalves)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 2
>> Date: Sun, 30 Aug 2015 18:09:41 +0200
>> From: Antonio Goncalves <antonio.goncalves at gmail.com>
>> Subject: Re: [cdi-dev] Time to start working on CDI lite
>> To: Romain Manni-Bucau <rmannibucau at gmail.com>
>> Cc: cdi-dev <cdi-dev at lists.jboss.org>
>> Message-ID:
>>         <CA+ZZq9-YFcTKuZr=+6v=
>> wH-w670E++qgBrN36DsToFEidUzenQ at mail.gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> For me, a Light version of CDI is clearly the features number. That's why
>> I
>> don't see events in it.
>>
>> For me, a CDI Lite would just focus on DI. If CDI has @Produces and Spring
>> has @Bean, then it's because 330 lakes this functionality.
>>
>> On Sun, Aug 30, 2015 at 4:02 PM, Romain Manni-Bucau <
>> rmannibucau at gmail.com>
>> wrote:
>>
>> > Lite can have several definition, let's try to list them up if it can
>> help:
>> >
>> > - binary size: for me until 3M for an app it is "Lite"
>> > - features number: the whole IoC set of feature is light since you
>> almost
>> > always need it, it means you can do lighter but it wouldnt be used -
>> check
>> > spring, who uses only spring-ioc and not context or more?
>> > - features complexity: sure we are not light here but supporting scopes
>> > already breaks "Lite-ness" IMO so not a real issue
>> >
>> > So my view is CDI "SE" is light enough - as a spec and spec can't affect
>> > implementations so seems the fight is not on the right side to me.
>> >
>> >
>> >
>> > Romain Manni-Bucau
>> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>> > <http://rmannibucau.wordpress.com> | Github
>> > <https://github.com/rmannibucau> | LinkedIn
>> > <https://www.linkedin.com/in/rmannibucau> | Tomitriber
>> > <http://www.tomitribe.com>
>> >
>> > 2015-08-30 15:57 GMT+02:00 Antonio Goncalves <
>> antonio.goncalves at gmail.com>
>> > :
>> >
>> >> It's funny, I feel I'm in Rod Johnson shoes back in Java EE 6 where he
>> >> forked 330 because he found CDI was doing too much  ;o)
>> >>
>> >> For me, "CDI Lite" was just basic dependency injection. The fact that
>> CDI
>> >> can now run on SE (like JPA....), is good... but for me it has nothing
>> to
>> >> do with Light : it's the entire thing that can bootstrap in SE. Good.
>> >>
>> >> So what is Lite for you guys ?
>> >>
>> >> Antonio
>> >>
>> >> On Sun, Aug 30, 2015 at 3:44 PM, Romain Manni-Bucau <
>> >> rmannibucau at gmail.com> wrote:
>> >>
>> >>> 2015-08-30 15:22 GMT+02:00 John D. Ament <john.d.ament at gmail.com>:
>> >>>
>> >>>> Personally, I'm not in favor of a slimmed down runtime.  It was tried
>> >>>> with EJB, but never implemented properly (most implementations that
>> support
>> >>>> EJB-lite actually support the entire thing, except for deprecated
>> stuff).
>> >>>>
>> >>>>
>> >>> +1, most of CDI is basic and quickly any light version will miss
>> events
>> >>> or other thing - in particular in maintaining micro services from
>> >>> experience. Size of an implementation can easily be < 1M so not sure
>> it
>> >>> would bring anything. Only important point is what Antoine started to
>> do ie
>> >>> ensuring EE and SE parts are clearly identified and split in the spec.
>> >>>
>> >>>
>> >>>> I think if we define SE properly we won't have a need for this.
>> >>>>
>> >>>> John
>> >>>>
>> >>>> On Sun, Aug 30, 2015 at 8:07 AM Antonio Goncalves <
>> >>>> antonio.goncalves at gmail.com> wrote:
>> >>>>
>> >>>>> @Antoine, so which content do you see in CDI Lite ? Are you sure
>> about
>> >>>>> events ?
>> >>>>>
>> >>>>> I'm in favor of a "fatter" 330 that would have :
>> >>>>>
>> >>>>>    - @Inject : already there
>> >>>>>    - @Qualifier : already there
>> >>>>>    -
>> >>>>> *Producers and disposers *
>> >>>>>    -
>> >>>>> *Programatic lookup *
>> >>>>>    - *Java SE Bootstrap*
>> >>>>>
>> >>>>> When you say "*The goal here is not to propose a new EE profile but
>> a
>> >>>>> subspec*", 330 could already be seen as a subspec. If you put events
>> >>>>> apparts, what would be missing in this list in your point of view ?
>> And
>> >>>>> what obstacles do you see in archieving this ?
>> >>>>>
>> >>>>> To boostrap CDI we have a CDIProvider, why not having an
>> >>>>> InjectionProvider just to bootstrap 330 (then, CDIProvider could
>> extend
>> >>>>> InjectionProvider, so it bootstraps the all thing) ?
>> >>>>>
>> >>>>> Antonio
>> >>>>>
>> >>>>> On Sun, Aug 30, 2015 at 9:09 AM, Antoine Sabot-Durand <
>> >>>>> antoine at sabot-durand.net> wrote:
>> >>>>>
>> >>>>>> Yes Arjan, I think it's the first reason. We really should work
>> with
>> >>>>>> them to understand what should be added to CDI 2.0 to have it as a
>> first
>> >>>>>> citizen DI in their spec.
>> >>>>>>
>> >>>>>> Le sam. 29 ao?t 2015 ? 23:15, arjan tijms <arjan.tijms at gmail.com>
>> a
>> >>>>>> ?crit :
>> >>>>>>
>> >>>>>>> On Sat, Aug 29, 2015 at 8:45 PM, Antonio Goncalves
>> >>>>>>> <antonio.goncalves at gmail.com> wrote:
>> >>>>>>> > I remember talking with the JAX-RS guys (Java EE), years ago
>> (back
>> >>>>>>> in EE6),
>> >>>>>>> > and their answer for not adopting CDI was "too heavy".
>> >>>>>>>
>> >>>>>>> I can't find an exact reference anymore, but I somewhat remember
>> that
>> >>>>>>> one of the reasons was also simply that CDI as a general solution
>> >>>>>>> finished late in Java EE 6, while JAX-RS finished earlier and had
>> all
>> >>>>>>> the work for their own DI solution already done.
>> >>>>>>>
>> >>>>>>
>> >>>>>
>> >>>>>
>> >>>>> --
>> >>>>> Antonio Goncalves
>> >>>>> Software architect, Java Champion and Pluralsight author
>> >>>>>
>> >>>>> Web site <http://www.antoniogoncalves.org> | Twitter
>> >>>>> <http://twitter.com/agoncal> | LinkedIn
>> >>>>> <http://www.linkedin.com/in/agoncal> | Pluralsight
>> >>>>> <http://pluralsight.com/training/Authors/Details/antonio-goncalves>
>> | Paris
>> >>>>> JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr
>> >
>> >>>>> _______________________________________________
>> >>>>> 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.
>> >>>>
>> >>>
>> >>>
>> >>
>> >>
>> >> --
>> >> Antonio Goncalves
>> >> Software architect, Java Champion and Pluralsight author
>> >>
>> >> Web site <http://www.antoniogoncalves.org> | Twitter
>> >> <http://twitter.com/agoncal> | LinkedIn
>> >> <http://www.linkedin.com/in/agoncal> | Pluralsight
>> >> <http://pluralsight.com/training/Authors/Details/antonio-goncalves> |
>> Paris
>> >> JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr>
>> >>
>> >
>> >
>>
>>
>> --
>> Antonio Goncalves
>> Software architect, Java Champion and Pluralsight author
>>
>> Web site <http://www.antoniogoncalves.org> | Twitter
>> <http://twitter.com/agoncal> | LinkedIn <
>> http://www.linkedin.com/in/agoncal> |
>> Pluralsight
>> <http://pluralsight.com/training/Authors/Details/antonio-goncalves> |
>> Paris
>> JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr>
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL:
>> http://lists.jboss.org/pipermail/cdi-dev/attachments/20150830/41058591/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 35
>> ***************************************
>>
>
>
> _______________________________________________
> 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/20150830/717fde38/attachment-0001.html 

From werner.keil at gmail.com  Sun Aug 30 15:20:17 2015
From: werner.keil at gmail.com (Werner Keil)
Date: Sun, 30 Aug 2015 21:20:17 +0200
Subject: [cdi-dev] Time to start working on CDI lite
Message-ID: <CAAGawe20_oYGFg4tmiYbh4eakD2KNxQ65EGUtbqkWBA6qefdtw@mail.gmail.com>

Well if we found a way to offer some level of modularity and optionality
(despite SE or EE 8 not putting a strong emphasis on either yet) I would
certainly see it as an option. This could keep the size for some apps down
if they use other event systems already.

Werner

On Sun, Aug 30, 2015 at 9:11 PM, <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: Time to start working on CDI lite (Romain Manni-Bucau)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sun, 30 Aug 2015 21:11:24 +0200
> From: Romain Manni-Bucau <rmannibucau at gmail.com>
> Subject: Re: [cdi-dev] Time to start working on CDI lite
> To: Werner Keil <werner.keil at gmail.com>
> Cc: cdi-dev <cdi-dev at lists.jboss.org>
> Message-ID:
>         <CACLE=
> 7PgKRmCrKiN1+xxLvqCtm3V1AE8D3c7kz_1W_wp1fuxkw at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> 2015-08-30 20:29 GMT+02:00 Werner Keil <werner.keil at gmail.com>:
>
> > As there is well-established event handling on the SE and ME side, in
> most
> > cases based on java.util.EventObject, I could imagine CDI events being
> > either outside a "lite" profile or at least optional, should we consider
> > optionality.
> >
> >
> not sure I agree, SE has an event hierarchy but its listener model is not
> as usable as CDI most of the time because of the register side
>
>
> > Werner
> >
> > On Sun, Aug 30, 2015 at 6:10 PM, <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: cdi-dev Digest, Vol 57, Issue 33 (Romain Manni-Bucau)
> >>    2. Re: Time to start working on CDI lite (Antonio Goncalves)
> >>
> >>
> >> ----------------------------------------------------------------------
> >>
> >> Message: 2
> >> Date: Sun, 30 Aug 2015 18:09:41 +0200
> >> From: Antonio Goncalves <antonio.goncalves at gmail.com>
> >> Subject: Re: [cdi-dev] Time to start working on CDI lite
> >> To: Romain Manni-Bucau <rmannibucau at gmail.com>
> >> Cc: cdi-dev <cdi-dev at lists.jboss.org>
> >> Message-ID:
> >>         <CA+ZZq9-YFcTKuZr=+6v=
> >> wH-w670E++qgBrN36DsToFEidUzenQ at mail.gmail.com>
> >> Content-Type: text/plain; charset="utf-8"
> >>
> >> For me, a Light version of CDI is clearly the features number. That's
> why
> >> I
> >> don't see events in it.
> >>
> >> For me, a CDI Lite would just focus on DI. If CDI has @Produces and
> Spring
> >> has @Bean, then it's because 330 lakes this functionality.
> >>
> >> On Sun, Aug 30, 2015 at 4:02 PM, Romain Manni-Bucau <
> >> rmannibucau at gmail.com>
> >> wrote:
> >>
> >> > Lite can have several definition, let's try to list them up if it can
> >> help:
> >> >
> >> > - binary size: for me until 3M for an app it is "Lite"
> >> > - features number: the whole IoC set of feature is light since you
> >> almost
> >> > always need it, it means you can do lighter but it wouldnt be used -
> >> check
> >> > spring, who uses only spring-ioc and not context or more?
> >> > - features complexity: sure we are not light here but supporting
> scopes
> >> > already breaks "Lite-ness" IMO so not a real issue
> >> >
> >> > So my view is CDI "SE" is light enough - as a spec and spec can't
> affect
> >> > implementations so seems the fight is not on the right side to me.
> >> >
> >> >
> >> >
> >> > Romain Manni-Bucau
> >> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> >> > <http://rmannibucau.wordpress.com> | Github
> >> > <https://github.com/rmannibucau> | LinkedIn
> >> > <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> >> > <http://www.tomitribe.com>
> >> >
> >> > 2015-08-30 15:57 GMT+02:00 Antonio Goncalves <
> >> antonio.goncalves at gmail.com>
> >> > :
> >> >
> >> >> It's funny, I feel I'm in Rod Johnson shoes back in Java EE 6 where
> he
> >> >> forked 330 because he found CDI was doing too much  ;o)
> >> >>
> >> >> For me, "CDI Lite" was just basic dependency injection. The fact that
> >> CDI
> >> >> can now run on SE (like JPA....), is good... but for me it has
> nothing
> >> to
> >> >> do with Light : it's the entire thing that can bootstrap in SE. Good.
> >> >>
> >> >> So what is Lite for you guys ?
> >> >>
> >> >> Antonio
> >> >>
> >> >> On Sun, Aug 30, 2015 at 3:44 PM, Romain Manni-Bucau <
> >> >> rmannibucau at gmail.com> wrote:
> >> >>
> >> >>> 2015-08-30 15:22 GMT+02:00 John D. Ament <john.d.ament at gmail.com>:
> >> >>>
> >> >>>> Personally, I'm not in favor of a slimmed down runtime.  It was
> tried
> >> >>>> with EJB, but never implemented properly (most implementations that
> >> support
> >> >>>> EJB-lite actually support the entire thing, except for deprecated
> >> stuff).
> >> >>>>
> >> >>>>
> >> >>> +1, most of CDI is basic and quickly any light version will miss
> >> events
> >> >>> or other thing - in particular in maintaining micro services from
> >> >>> experience. Size of an implementation can easily be < 1M so not sure
> >> it
> >> >>> would bring anything. Only important point is what Antoine started
> to
> >> do ie
> >> >>> ensuring EE and SE parts are clearly identified and split in the
> spec.
> >> >>>
> >> >>>
> >> >>>> I think if we define SE properly we won't have a need for this.
> >> >>>>
> >> >>>> John
> >> >>>>
> >> >>>> On Sun, Aug 30, 2015 at 8:07 AM Antonio Goncalves <
> >> >>>> antonio.goncalves at gmail.com> wrote:
> >> >>>>
> >> >>>>> @Antoine, so which content do you see in CDI Lite ? Are you sure
> >> about
> >> >>>>> events ?
> >> >>>>>
> >> >>>>> I'm in favor of a "fatter" 330 that would have :
> >> >>>>>
> >> >>>>>    - @Inject : already there
> >> >>>>>    - @Qualifier : already there
> >> >>>>>    -
> >> >>>>> *Producers and disposers *
> >> >>>>>    -
> >> >>>>> *Programatic lookup *
> >> >>>>>    - *Java SE Bootstrap*
> >> >>>>>
> >> >>>>> When you say "*The goal here is not to propose a new EE profile
> but
> >> a
> >> >>>>> subspec*", 330 could already be seen as a subspec. If you put
> events
> >> >>>>> apparts, what would be missing in this list in your point of view
> ?
> >> And
> >> >>>>> what obstacles do you see in archieving this ?
> >> >>>>>
> >> >>>>> To boostrap CDI we have a CDIProvider, why not having an
> >> >>>>> InjectionProvider just to bootstrap 330 (then, CDIProvider could
> >> extend
> >> >>>>> InjectionProvider, so it bootstraps the all thing) ?
> >> >>>>>
> >> >>>>> Antonio
> >> >>>>>
> >> >>>>> On Sun, Aug 30, 2015 at 9:09 AM, Antoine Sabot-Durand <
> >> >>>>> antoine at sabot-durand.net> wrote:
> >> >>>>>
> >> >>>>>> Yes Arjan, I think it's the first reason. We really should work
> >> with
> >> >>>>>> them to understand what should be added to CDI 2.0 to have it as
> a
> >> first
> >> >>>>>> citizen DI in their spec.
> >> >>>>>>
> >> >>>>>> Le sam. 29 ao?t 2015 ? 23:15, arjan tijms <arjan.tijms at gmail.com
> >
> >> a
> >> >>>>>> ?crit :
> >> >>>>>>
> >> >>>>>>> On Sat, Aug 29, 2015 at 8:45 PM, Antonio Goncalves
> >> >>>>>>> <antonio.goncalves at gmail.com> wrote:
> >> >>>>>>> > I remember talking with the JAX-RS guys (Java EE), years ago
> >> (back
> >> >>>>>>> in EE6),
> >> >>>>>>> > and their answer for not adopting CDI was "too heavy".
> >> >>>>>>>
> >> >>>>>>> I can't find an exact reference anymore, but I somewhat remember
> >> that
> >> >>>>>>> one of the reasons was also simply that CDI as a general
> solution
> >> >>>>>>> finished late in Java EE 6, while JAX-RS finished earlier and
> had
> >> all
> >> >>>>>>> the work for their own DI solution already done.
> >> >>>>>>>
> >> >>>>>>
> >> >>>>>
> >> >>>>>
> >> >>>>> --
> >> >>>>> Antonio Goncalves
> >> >>>>> Software architect, Java Champion and Pluralsight author
> >> >>>>>
> >> >>>>> Web site <http://www.antoniogoncalves.org> | Twitter
> >> >>>>> <http://twitter.com/agoncal> | LinkedIn
> >> >>>>> <http://www.linkedin.com/in/agoncal> | Pluralsight
> >> >>>>> <
> http://pluralsight.com/training/Authors/Details/antonio-goncalves>
> >> | Paris
> >> >>>>> JUG <http://www.parisjug.org> | Devoxx France <
> http://www.devoxx.fr
> >> >
> >> >>>>> _______________________________________________
> >> >>>>> 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.
> >> >>>>
> >> >>>
> >> >>>
> >> >>
> >> >>
> >> >> --
> >> >> Antonio Goncalves
> >> >> Software architect, Java Champion and Pluralsight author
> >> >>
> >> >> Web site <http://www.antoniogoncalves.org> | Twitter
> >> >> <http://twitter.com/agoncal> | LinkedIn
> >> >> <http://www.linkedin.com/in/agoncal> | Pluralsight
> >> >> <http://pluralsight.com/training/Authors/Details/antonio-goncalves>
> |
> >> Paris
> >> >> JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr>
> >> >>
> >> >
> >> >
> >>
> >>
> >> --
> >> Antonio Goncalves
> >> Software architect, Java Champion and Pluralsight author
> >>
> >> Web site <http://www.antoniogoncalves.org> | Twitter
> >> <http://twitter.com/agoncal> | LinkedIn <
> >> http://www.linkedin.com/in/agoncal> |
> >> Pluralsight
> >> <http://pluralsight.com/training/Authors/Details/antonio-goncalves> |
> >> Paris
> >> JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr>
> >> -------------- next part --------------
> >> An HTML attachment was scrubbed...
> >> URL:
> >>
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20150830/41058591/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 35
> >> ***************************************
> >>
> >
> >
> > _______________________________________________
> > 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/20150830/717fde38/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 37
> ***************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150830/a688400d/attachment-0001.html 

From rmannibucau at gmail.com  Sun Aug 30 15:32:49 2015
From: rmannibucau at gmail.com (Romain Manni-Bucau)
Date: Sun, 30 Aug 2015 21:32:49 +0200
Subject: [cdi-dev] Time to start working on CDI lite
In-Reply-To: <CAAGawe20_oYGFg4tmiYbh4eakD2KNxQ65EGUtbqkWBA6qefdtw@mail.gmail.com>
References: <CAAGawe20_oYGFg4tmiYbh4eakD2KNxQ65EGUtbqkWBA6qefdtw@mail.gmail.com>
Message-ID: <CACLE=7NFQhQL8AUGbBgj0r1qj8UM2xy4WpTrtxTepMutBs94Mg@mail.gmail.com>

2015-08-30 21:20 GMT+02:00 Werner Keil <werner.keil at gmail.com>:

> Well if we found a way to offer some level of modularity and optionality
> (despite SE or EE 8 not putting a strong emphasis on either yet) I would
> certainly see it as an option. This could keep the size for some apps down
> if they use other event systems already.
>
>
strictly yes, in practice the event bus is rarely more than few kb so does
it worth the time the EG would spend on it?


> Werner
>
> On Sun, Aug 30, 2015 at 9:11 PM, <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: Time to start working on CDI lite (Romain Manni-Bucau)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Sun, 30 Aug 2015 21:11:24 +0200
>> From: Romain Manni-Bucau <rmannibucau at gmail.com>
>> Subject: Re: [cdi-dev] Time to start working on CDI lite
>> To: Werner Keil <werner.keil at gmail.com>
>> Cc: cdi-dev <cdi-dev at lists.jboss.org>
>> Message-ID:
>>         <CACLE=
>> 7PgKRmCrKiN1+xxLvqCtm3V1AE8D3c7kz_1W_wp1fuxkw at mail.gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>>
>> 2015-08-30 20:29 GMT+02:00 Werner Keil <werner.keil at gmail.com>:
>>
>> > As there is well-established event handling on the SE and ME side, in
>> most
>> > cases based on java.util.EventObject, I could imagine CDI events being
>> > either outside a "lite" profile or at least optional, should we consider
>> > optionality.
>> >
>> >
>> not sure I agree, SE has an event hierarchy but its listener model is not
>> as usable as CDI most of the time because of the register side
>>
>>
>> > Werner
>> >
>> > On Sun, Aug 30, 2015 at 6:10 PM, <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: cdi-dev Digest, Vol 57, Issue 33 (Romain Manni-Bucau)
>> >>    2. Re: Time to start working on CDI lite (Antonio Goncalves)
>> >>
>> >>
>> >> ----------------------------------------------------------------------
>> >>
>> >> Message: 2
>> >> Date: Sun, 30 Aug 2015 18:09:41 +0200
>> >> From: Antonio Goncalves <antonio.goncalves at gmail.com>
>> >> Subject: Re: [cdi-dev] Time to start working on CDI lite
>> >> To: Romain Manni-Bucau <rmannibucau at gmail.com>
>> >> Cc: cdi-dev <cdi-dev at lists.jboss.org>
>> >> Message-ID:
>> >>         <CA+ZZq9-YFcTKuZr=+6v=
>> >> wH-w670E++qgBrN36DsToFEidUzenQ at mail.gmail.com>
>> >> Content-Type: text/plain; charset="utf-8"
>> >>
>> >> For me, a Light version of CDI is clearly the features number. That's
>> why
>> >> I
>> >> don't see events in it.
>> >>
>> >> For me, a CDI Lite would just focus on DI. If CDI has @Produces and
>> Spring
>> >> has @Bean, then it's because 330 lakes this functionality.
>> >>
>> >> On Sun, Aug 30, 2015 at 4:02 PM, Romain Manni-Bucau <
>> >> rmannibucau at gmail.com>
>> >> wrote:
>> >>
>> >> > Lite can have several definition, let's try to list them up if it can
>> >> help:
>> >> >
>> >> > - binary size: for me until 3M for an app it is "Lite"
>> >> > - features number: the whole IoC set of feature is light since you
>> >> almost
>> >> > always need it, it means you can do lighter but it wouldnt be used -
>> >> check
>> >> > spring, who uses only spring-ioc and not context or more?
>> >> > - features complexity: sure we are not light here but supporting
>> scopes
>> >> > already breaks "Lite-ness" IMO so not a real issue
>> >> >
>> >> > So my view is CDI "SE" is light enough - as a spec and spec can't
>> affect
>> >> > implementations so seems the fight is not on the right side to me.
>> >> >
>> >> >
>> >> >
>> >> > Romain Manni-Bucau
>> >> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>> >> > <http://rmannibucau.wordpress.com> | Github
>> >> > <https://github.com/rmannibucau> | LinkedIn
>> >> > <https://www.linkedin.com/in/rmannibucau> | Tomitriber
>> >> > <http://www.tomitribe.com>
>> >> >
>> >> > 2015-08-30 15:57 GMT+02:00 Antonio Goncalves <
>> >> antonio.goncalves at gmail.com>
>> >> > :
>> >> >
>> >> >> It's funny, I feel I'm in Rod Johnson shoes back in Java EE 6 where
>> he
>> >> >> forked 330 because he found CDI was doing too much  ;o)
>> >> >>
>> >> >> For me, "CDI Lite" was just basic dependency injection. The fact
>> that
>> >> CDI
>> >> >> can now run on SE (like JPA....), is good... but for me it has
>> nothing
>> >> to
>> >> >> do with Light : it's the entire thing that can bootstrap in SE.
>> Good.
>> >> >>
>> >> >> So what is Lite for you guys ?
>> >> >>
>> >> >> Antonio
>> >> >>
>> >> >> On Sun, Aug 30, 2015 at 3:44 PM, Romain Manni-Bucau <
>> >> >> rmannibucau at gmail.com> wrote:
>> >> >>
>> >> >>> 2015-08-30 15:22 GMT+02:00 John D. Ament <john.d.ament at gmail.com>:
>> >> >>>
>> >> >>>> Personally, I'm not in favor of a slimmed down runtime.  It was
>> tried
>> >> >>>> with EJB, but never implemented properly (most implementations
>> that
>> >> support
>> >> >>>> EJB-lite actually support the entire thing, except for deprecated
>> >> stuff).
>> >> >>>>
>> >> >>>>
>> >> >>> +1, most of CDI is basic and quickly any light version will miss
>> >> events
>> >> >>> or other thing - in particular in maintaining micro services from
>> >> >>> experience. Size of an implementation can easily be < 1M so not
>> sure
>> >> it
>> >> >>> would bring anything. Only important point is what Antoine started
>> to
>> >> do ie
>> >> >>> ensuring EE and SE parts are clearly identified and split in the
>> spec.
>> >> >>>
>> >> >>>
>> >> >>>> I think if we define SE properly we won't have a need for this.
>> >> >>>>
>> >> >>>> John
>> >> >>>>
>> >> >>>> On Sun, Aug 30, 2015 at 8:07 AM Antonio Goncalves <
>> >> >>>> antonio.goncalves at gmail.com> wrote:
>> >> >>>>
>> >> >>>>> @Antoine, so which content do you see in CDI Lite ? Are you sure
>> >> about
>> >> >>>>> events ?
>> >> >>>>>
>> >> >>>>> I'm in favor of a "fatter" 330 that would have :
>> >> >>>>>
>> >> >>>>>    - @Inject : already there
>> >> >>>>>    - @Qualifier : already there
>> >> >>>>>    -
>> >> >>>>> *Producers and disposers *
>> >> >>>>>    -
>> >> >>>>> *Programatic lookup *
>> >> >>>>>    - *Java SE Bootstrap*
>> >> >>>>>
>> >> >>>>> When you say "*The goal here is not to propose a new EE profile
>> but
>> >> a
>> >> >>>>> subspec*", 330 could already be seen as a subspec. If you put
>> events
>> >> >>>>> apparts, what would be missing in this list in your point of
>> view ?
>> >> And
>> >> >>>>> what obstacles do you see in archieving this ?
>> >> >>>>>
>> >> >>>>> To boostrap CDI we have a CDIProvider, why not having an
>> >> >>>>> InjectionProvider just to bootstrap 330 (then, CDIProvider could
>> >> extend
>> >> >>>>> InjectionProvider, so it bootstraps the all thing) ?
>> >> >>>>>
>> >> >>>>> Antonio
>> >> >>>>>
>> >> >>>>> On Sun, Aug 30, 2015 at 9:09 AM, Antoine Sabot-Durand <
>> >> >>>>> antoine at sabot-durand.net> wrote:
>> >> >>>>>
>> >> >>>>>> Yes Arjan, I think it's the first reason. We really should work
>> >> with
>> >> >>>>>> them to understand what should be added to CDI 2.0 to have it
>> as a
>> >> first
>> >> >>>>>> citizen DI in their spec.
>> >> >>>>>>
>> >> >>>>>> Le sam. 29 ao?t 2015 ? 23:15, arjan tijms <
>> arjan.tijms at gmail.com>
>> >> a
>> >> >>>>>> ?crit :
>> >> >>>>>>
>> >> >>>>>>> On Sat, Aug 29, 2015 at 8:45 PM, Antonio Goncalves
>> >> >>>>>>> <antonio.goncalves at gmail.com> wrote:
>> >> >>>>>>> > I remember talking with the JAX-RS guys (Java EE), years ago
>> >> (back
>> >> >>>>>>> in EE6),
>> >> >>>>>>> > and their answer for not adopting CDI was "too heavy".
>> >> >>>>>>>
>> >> >>>>>>> I can't find an exact reference anymore, but I somewhat
>> remember
>> >> that
>> >> >>>>>>> one of the reasons was also simply that CDI as a general
>> solution
>> >> >>>>>>> finished late in Java EE 6, while JAX-RS finished earlier and
>> had
>> >> all
>> >> >>>>>>> the work for their own DI solution already done.
>> >> >>>>>>>
>> >> >>>>>>
>> >> >>>>>
>> >> >>>>>
>> >> >>>>> --
>> >> >>>>> Antonio Goncalves
>> >> >>>>> Software architect, Java Champion and Pluralsight author
>> >> >>>>>
>> >> >>>>> Web site <http://www.antoniogoncalves.org> | Twitter
>> >> >>>>> <http://twitter.com/agoncal> | LinkedIn
>> >> >>>>> <http://www.linkedin.com/in/agoncal> | Pluralsight
>> >> >>>>> <
>> http://pluralsight.com/training/Authors/Details/antonio-goncalves>
>> >> | Paris
>> >> >>>>> JUG <http://www.parisjug.org> | Devoxx France <
>> http://www.devoxx.fr
>> >> >
>> >> >>>>> _______________________________________________
>> >> >>>>> 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.
>> >> >>>>
>> >> >>>
>> >> >>>
>> >> >>
>> >> >>
>> >> >> --
>> >> >> Antonio Goncalves
>> >> >> Software architect, Java Champion and Pluralsight author
>> >> >>
>> >> >> Web site <http://www.antoniogoncalves.org> | Twitter
>> >> >> <http://twitter.com/agoncal> | LinkedIn
>> >> >> <http://www.linkedin.com/in/agoncal> | Pluralsight
>> >> >> <http://pluralsight.com/training/Authors/Details/antonio-goncalves>
>> |
>> >> Paris
>> >> >> JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr
>> >
>> >> >>
>> >> >
>> >> >
>> >>
>> >>
>> >> --
>> >> Antonio Goncalves
>> >> Software architect, Java Champion and Pluralsight author
>> >>
>> >> Web site <http://www.antoniogoncalves.org> | Twitter
>> >> <http://twitter.com/agoncal> | LinkedIn <
>> >> http://www.linkedin.com/in/agoncal> |
>> >> Pluralsight
>> >> <http://pluralsight.com/training/Authors/Details/antonio-goncalves> |
>> >> Paris
>> >> JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr>
>> >> -------------- next part --------------
>> >> An HTML attachment was scrubbed...
>> >> URL:
>> >>
>> http://lists.jboss.org/pipermail/cdi-dev/attachments/20150830/41058591/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 35
>> >> ***************************************
>> >>
>> >
>> >
>> > _______________________________________________
>> > 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/20150830/717fde38/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 37
>> ***************************************
>>
>
>
> _______________________________________________
> 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/20150830/4880ea38/attachment-0001.html 

From werner.keil at gmail.com  Sun Aug 30 15:40:18 2015
From: werner.keil at gmail.com (Werner Keil)
Date: Sun, 30 Aug 2015 21:40:18 +0200
Subject: [cdi-dev] Time to start working on CDI lite
Message-ID: <CAAGawe05hxafV01-s7+5HgEE7cH5L5SQ9gdco_EoQLLguX1=8A@mail.gmail.com>

Well for whatever reason Antonio sounded rather uneasy about events. If
it's not size it must be for another reason, but take the idea of
optionality for things that might have a relatively large footprint in the
end.

Werner

On Sun, Aug 30, 2015 at 9:33 PM, <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: Time to start working on CDI lite (Romain Manni-Bucau)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sun, 30 Aug 2015 21:32:49 +0200
> From: Romain Manni-Bucau <rmannibucau at gmail.com>
> Subject: Re: [cdi-dev] Time to start working on CDI lite
> To: Werner Keil <werner.keil at gmail.com>
> Cc: cdi-dev <cdi-dev at lists.jboss.org>
> Message-ID:
>         <CACLE=
> 7NFQhQL8AUGbBgj0r1qj8UM2xy4WpTrtxTepMutBs94Mg at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> 2015-08-30 21:20 GMT+02:00 Werner Keil <werner.keil at gmail.com>:
>
> > Well if we found a way to offer some level of modularity and optionality
> > (despite SE or EE 8 not putting a strong emphasis on either yet) I would
> > certainly see it as an option. This could keep the size for some apps
> down
> > if they use other event systems already.
> >
> >
> strictly yes, in practice the event bus is rarely more than few kb so does
> it worth the time the EG would spend on it?
>
>
> > Werner
> >
> > On Sun, Aug 30, 2015 at 9:11 PM, <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: Time to start working on CDI lite (Romain Manni-Bucau)
> >>
> >>
> >> ----------------------------------------------------------------------
> >>
> >> Message: 1
> >> Date: Sun, 30 Aug 2015 21:11:24 +0200
> >> From: Romain Manni-Bucau <rmannibucau at gmail.com>
> >> Subject: Re: [cdi-dev] Time to start working on CDI lite
> >> To: Werner Keil <werner.keil at gmail.com>
> >> Cc: cdi-dev <cdi-dev at lists.jboss.org>
> >> Message-ID:
> >>         <CACLE=
> >> 7PgKRmCrKiN1+xxLvqCtm3V1AE8D3c7kz_1W_wp1fuxkw at mail.gmail.com>
> >> Content-Type: text/plain; charset="utf-8"
> >>
> >>
> >> 2015-08-30 20:29 GMT+02:00 Werner Keil <werner.keil at gmail.com>:
> >>
> >> > As there is well-established event handling on the SE and ME side, in
> >> most
> >> > cases based on java.util.EventObject, I could imagine CDI events being
> >> > either outside a "lite" profile or at least optional, should we
> consider
> >> > optionality.
> >> >
> >> >
> >> not sure I agree, SE has an event hierarchy but its listener model is
> not
> >> as usable as CDI most of the time because of the register side
> >>
> >>
> >> > Werner
> >> >
> >> > On Sun, Aug 30, 2015 at 6:10 PM, <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: cdi-dev Digest, Vol 57, Issue 33 (Romain Manni-Bucau)
> >> >>    2. Re: Time to start working on CDI lite (Antonio Goncalves)
> >> >>
> >> >>
> >> >>
> ----------------------------------------------------------------------
> >> >>
> >> >> Message: 2
> >> >> Date: Sun, 30 Aug 2015 18:09:41 +0200
> >> >> From: Antonio Goncalves <antonio.goncalves at gmail.com>
> >> >> Subject: Re: [cdi-dev] Time to start working on CDI lite
> >> >> To: Romain Manni-Bucau <rmannibucau at gmail.com>
> >> >> Cc: cdi-dev <cdi-dev at lists.jboss.org>
> >> >> Message-ID:
> >> >>         <CA+ZZq9-YFcTKuZr=+6v=
> >> >> wH-w670E++qgBrN36DsToFEidUzenQ at mail.gmail.com>
> >> >> Content-Type: text/plain; charset="utf-8"
> >> >>
> >> >> For me, a Light version of CDI is clearly the features number. That's
> >> why
> >> >> I
> >> >> don't see events in it.
> >> >>
> >> >> For me, a CDI Lite would just focus on DI. If CDI has @Produces and
> >> Spring
> >> >> has @Bean, then it's because 330 lakes this functionality.
> >> >>
> >> >> On Sun, Aug 30, 2015 at 4:02 PM, Romain Manni-Bucau <
> >> >> rmannibucau at gmail.com>
> >> >> wrote:
> >> >>
> >> >> > Lite can have several definition, let's try to list them up if it
> can
> >> >> help:
> >> >> >
> >> >> > - binary size: for me until 3M for an app it is "Lite"
> >> >> > - features number: the whole IoC set of feature is light since you
> >> >> almost
> >> >> > always need it, it means you can do lighter but it wouldnt be used
> -
> >> >> check
> >> >> > spring, who uses only spring-ioc and not context or more?
> >> >> > - features complexity: sure we are not light here but supporting
> >> scopes
> >> >> > already breaks "Lite-ness" IMO so not a real issue
> >> >> >
> >> >> > So my view is CDI "SE" is light enough - as a spec and spec can't
> >> affect
> >> >> > implementations so seems the fight is not on the right side to me.
> >> >> >
> >> >> >
> >> >> >
> >> >> > Romain Manni-Bucau
> >> >> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> >> >> > <http://rmannibucau.wordpress.com> | Github
> >> >> > <https://github.com/rmannibucau> | LinkedIn
> >> >> > <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> >> >> > <http://www.tomitribe.com>
> >> >> >
> >> >> > 2015-08-30 15:57 GMT+02:00 Antonio Goncalves <
> >> >> antonio.goncalves at gmail.com>
> >> >> > :
> >> >> >
> >> >> >> It's funny, I feel I'm in Rod Johnson shoes back in Java EE 6
> where
> >> he
> >> >> >> forked 330 because he found CDI was doing too much  ;o)
> >> >> >>
> >> >> >> For me, "CDI Lite" was just basic dependency injection. The fact
> >> that
> >> >> CDI
> >> >> >> can now run on SE (like JPA....), is good... but for me it has
> >> nothing
> >> >> to
> >> >> >> do with Light : it's the entire thing that can bootstrap in SE.
> >> Good.
> >> >> >>
> >> >> >> So what is Lite for you guys ?
> >> >> >>
> >> >> >> Antonio
> >> >> >>
> >> >> >> On Sun, Aug 30, 2015 at 3:44 PM, Romain Manni-Bucau <
> >> >> >> rmannibucau at gmail.com> wrote:
> >> >> >>
> >> >> >>> 2015-08-30 15:22 GMT+02:00 John D. Ament <john.d.ament at gmail.com
> >:
> >> >> >>>
> >> >> >>>> Personally, I'm not in favor of a slimmed down runtime.  It was
> >> tried
> >> >> >>>> with EJB, but never implemented properly (most implementations
> >> that
> >> >> support
> >> >> >>>> EJB-lite actually support the entire thing, except for
> deprecated
> >> >> stuff).
> >> >> >>>>
> >> >> >>>>
> >> >> >>> +1, most of CDI is basic and quickly any light version will miss
> >> >> events
> >> >> >>> or other thing - in particular in maintaining micro services from
> >> >> >>> experience. Size of an implementation can easily be < 1M so not
> >> sure
> >> >> it
> >> >> >>> would bring anything. Only important point is what Antoine
> started
> >> to
> >> >> do ie
> >> >> >>> ensuring EE and SE parts are clearly identified and split in the
> >> spec.
> >> >> >>>
> >> >> >>>
> >> >> >>>> I think if we define SE properly we won't have a need for this.
> >> >> >>>>
> >> >> >>>> John
> >> >> >>>>
> >> >> >>>> On Sun, Aug 30, 2015 at 8:07 AM Antonio Goncalves <
> >> >> >>>> antonio.goncalves at gmail.com> wrote:
> >> >> >>>>
> >> >> >>>>> @Antoine, so which content do you see in CDI Lite ? Are you
> sure
> >> >> about
> >> >> >>>>> events ?
> >> >> >>>>>
> >> >> >>>>> I'm in favor of a "fatter" 330 that would have :
> >> >> >>>>>
> >> >> >>>>>    - @Inject : already there
> >> >> >>>>>    - @Qualifier : already there
> >> >> >>>>>    -
> >> >> >>>>> *Producers and disposers *
> >> >> >>>>>    -
> >> >> >>>>> *Programatic lookup *
> >> >> >>>>>    - *Java SE Bootstrap*
> >> >> >>>>>
> >> >> >>>>> When you say "*The goal here is not to propose a new EE profile
> >> but
> >> >> a
> >> >> >>>>> subspec*", 330 could already be seen as a subspec. If you put
> >> events
> >> >> >>>>> apparts, what would be missing in this list in your point of
> >> view ?
> >> >> And
> >> >> >>>>> what obstacles do you see in archieving this ?
> >> >> >>>>>
> >> >> >>>>> To boostrap CDI we have a CDIProvider, why not having an
> >> >> >>>>> InjectionProvider just to bootstrap 330 (then, CDIProvider
> could
> >> >> extend
> >> >> >>>>> InjectionProvider, so it bootstraps the all thing) ?
> >> >> >>>>>
> >> >> >>>>> Antonio
> >> >> >>>>>
> >> >> >>>>> On Sun, Aug 30, 2015 at 9:09 AM, Antoine Sabot-Durand <
> >> >> >>>>> antoine at sabot-durand.net> wrote:
> >> >> >>>>>
> >> >> >>>>>> Yes Arjan, I think it's the first reason. We really should
> work
> >> >> with
> >> >> >>>>>> them to understand what should be added to CDI 2.0 to have it
> >> as a
> >> >> first
> >> >> >>>>>> citizen DI in their spec.
> >> >> >>>>>>
> >> >> >>>>>> Le sam. 29 ao?t 2015 ? 23:15, arjan tijms <
> >> arjan.tijms at gmail.com>
> >> >> a
> >> >> >>>>>> ?crit :
> >> >> >>>>>>
> >> >> >>>>>>> On Sat, Aug 29, 2015 at 8:45 PM, Antonio Goncalves
> >> >> >>>>>>> <antonio.goncalves at gmail.com> wrote:
> >> >> >>>>>>> > I remember talking with the JAX-RS guys (Java EE), years
> ago
> >> >> (back
> >> >> >>>>>>> in EE6),
> >> >> >>>>>>> > and their answer for not adopting CDI was "too heavy".
> >> >> >>>>>>>
> >> >> >>>>>>> I can't find an exact reference anymore, but I somewhat
> >> remember
> >> >> that
> >> >> >>>>>>> one of the reasons was also simply that CDI as a general
> >> solution
> >> >> >>>>>>> finished late in Java EE 6, while JAX-RS finished earlier and
> >> had
> >> >> all
> >> >> >>>>>>> the work for their own DI solution already done.
> >> >> >>>>>>>
> >> >> >>>>>>
> >> >> >>>>>
> >> >> >>>>>
> >> >> >>>>> --
> >> >> >>>>> Antonio Goncalves
> >> >> >>>>> Software architect, Java Champion and Pluralsight author
> >> >> >>>>>
> >> >> >>>>> Web site <http://www.antoniogoncalves.org> | Twitter
> >> >> >>>>> <http://twitter.com/agoncal> | LinkedIn
> >> >> >>>>> <http://www.linkedin.com/in/agoncal> | Pluralsight
> >> >> >>>>> <
> >> http://pluralsight.com/training/Authors/Details/antonio-goncalves>
> >> >> | Paris
> >> >> >>>>> JUG <http://www.parisjug.org> | Devoxx France <
> >> http://www.devoxx.fr
> >> >> >
> >> >> >>>>> _______________________________________________
> >> >> >>>>> 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.
> >> >> >>>>
> >> >> >>>
> >> >> >>>
> >> >> >>
> >> >> >>
> >> >> >> --
> >> >> >> Antonio Goncalves
> >> >> >> Software architect, Java Champion and Pluralsight author
> >> >> >>
> >> >> >> Web site <http://www.antoniogoncalves.org> | Twitter
> >> >> >> <http://twitter.com/agoncal> | LinkedIn
> >> >> >> <http://www.linkedin.com/in/agoncal> | Pluralsight
> >> >> >> <
> http://pluralsight.com/training/Authors/Details/antonio-goncalves>
> >> |
> >> >> Paris
> >> >> >> JUG <http://www.parisjug.org> | Devoxx France <
> http://www.devoxx.fr
> >> >
> >> >> >>
> >> >> >
> >> >> >
> >> >>
> >> >>
> >> >> --
> >> >> Antonio Goncalves
> >> >> Software architect, Java Champion and Pluralsight author
> >> >>
> >> >> Web site <http://www.antoniogoncalves.org> | Twitter
> >> >> <http://twitter.com/agoncal> | LinkedIn <
> >> >> http://www.linkedin.com/in/agoncal> |
> >> >> Pluralsight
> >> >> <http://pluralsight.com/training/Authors/Details/antonio-goncalves>
> |
> >> >> Paris
> >> >> JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr>
> >> >> -------------- next part --------------
> >> >> An HTML attachment was scrubbed...
> >> >> URL:
> >> >>
> >>
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20150830/41058591/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 35
> >> >> ***************************************
> >> >>
> >> >
> >> >
> >> > _______________________________________________
> >> > 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/20150830/717fde38/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 37
> >> ***************************************
> >>
> >
> >
> > _______________________________________________
> > 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/20150830/4880ea38/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 39
> ***************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150830/8b61ac68/attachment-0001.html 

From rmannibucau at gmail.com  Sun Aug 30 15:44:30 2015
From: rmannibucau at gmail.com (Romain Manni-Bucau)
Date: Sun, 30 Aug 2015 21:44:30 +0200
Subject: [cdi-dev] Time to start working on CDI lite
In-Reply-To: <CAAGawe05hxafV01-s7+5HgEE7cH5L5SQ9gdco_EoQLLguX1=8A@mail.gmail.com>
References: <CAAGawe05hxafV01-s7+5HgEE7cH5L5SQ9gdco_EoQLLguX1=8A@mail.gmail.com>
Message-ID: <CACLE=7MT4Eiqok1ds_v_RbbGdUtT=X2+u1oguB=q=VDQ8UNLcA@mail.gmail.com>

2015-08-30 21:40 GMT+02:00 Werner Keil <werner.keil at gmail.com>:

> Well for whatever reason Antonio sounded rather uneasy about events. If
> it's not size it must be for another reason, but take the idea of
> optionality for things that might have a relatively large footprint in the
> end.
>
>
I feel like we speak about the old Weld - didnt check recent version - and
not the spec itself here. If so this thread should move over weld@ and
openwebbeans@ but spec should really be about usability. One feature which
has a serious impact on size and runtime is proxying/subclassing. Remove it
and you get a different runtime, lighter in term of size, sure, but also
assumptions about classes and environment but this one doesnt seem
important in these discussions so my understanding is CDI is good enough
today for its SE part and things to work on are surely elsewhere at spec
level.


> Werner
>
> On Sun, Aug 30, 2015 at 9:33 PM, <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: Time to start working on CDI lite (Romain Manni-Bucau)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Sun, 30 Aug 2015 21:32:49 +0200
>> From: Romain Manni-Bucau <rmannibucau at gmail.com>
>> Subject: Re: [cdi-dev] Time to start working on CDI lite
>> To: Werner Keil <werner.keil at gmail.com>
>> Cc: cdi-dev <cdi-dev at lists.jboss.org>
>> Message-ID:
>>         <CACLE=
>> 7NFQhQL8AUGbBgj0r1qj8UM2xy4WpTrtxTepMutBs94Mg at mail.gmail.com>
>>
>> Content-Type: text/plain; charset="utf-8"
>>
>> 2015-08-30 21:20 GMT+02:00 Werner Keil <werner.keil at gmail.com>:
>>
>> > Well if we found a way to offer some level of modularity and optionality
>> > (despite SE or EE 8 not putting a strong emphasis on either yet) I would
>> > certainly see it as an option. This could keep the size for some apps
>> down
>> > if they use other event systems already.
>> >
>> >
>> strictly yes, in practice the event bus is rarely more than few kb so does
>> it worth the time the EG would spend on it?
>>
>>
>> > Werner
>> >
>> > On Sun, Aug 30, 2015 at 9:11 PM, <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: Time to start working on CDI lite (Romain Manni-Bucau)
>> >>
>> >>
>> >> ----------------------------------------------------------------------
>> >>
>> >> Message: 1
>> >> Date: Sun, 30 Aug 2015 21:11:24 +0200
>> >> From: Romain Manni-Bucau <rmannibucau at gmail.com>
>> >> Subject: Re: [cdi-dev] Time to start working on CDI lite
>> >> To: Werner Keil <werner.keil at gmail.com>
>> >> Cc: cdi-dev <cdi-dev at lists.jboss.org>
>> >> Message-ID:
>> >>         <CACLE=
>> >> 7PgKRmCrKiN1+xxLvqCtm3V1AE8D3c7kz_1W_wp1fuxkw at mail.gmail.com>
>> >> Content-Type: text/plain; charset="utf-8"
>> >>
>> >>
>> >> 2015-08-30 20:29 GMT+02:00 Werner Keil <werner.keil at gmail.com>:
>> >>
>> >> > As there is well-established event handling on the SE and ME side, in
>> >> most
>> >> > cases based on java.util.EventObject, I could imagine CDI events
>> being
>> >> > either outside a "lite" profile or at least optional, should we
>> consider
>> >> > optionality.
>> >> >
>> >> >
>> >> not sure I agree, SE has an event hierarchy but its listener model is
>> not
>> >> as usable as CDI most of the time because of the register side
>> >>
>> >>
>> >> > Werner
>> >> >
>> >> > On Sun, Aug 30, 2015 at 6:10 PM, <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: cdi-dev Digest, Vol 57, Issue 33 (Romain Manni-Bucau)
>> >> >>    2. Re: Time to start working on CDI lite (Antonio Goncalves)
>> >> >>
>> >> >>
>> >> >>
>> ----------------------------------------------------------------------
>> >> >>
>> >> >> Message: 2
>> >> >> Date: Sun, 30 Aug 2015 18:09:41 +0200
>> >> >> From: Antonio Goncalves <antonio.goncalves at gmail.com>
>> >> >> Subject: Re: [cdi-dev] Time to start working on CDI lite
>> >> >> To: Romain Manni-Bucau <rmannibucau at gmail.com>
>> >> >> Cc: cdi-dev <cdi-dev at lists.jboss.org>
>> >> >> Message-ID:
>> >> >>         <CA+ZZq9-YFcTKuZr=+6v=
>> >> >> wH-w670E++qgBrN36DsToFEidUzenQ at mail.gmail.com>
>> >> >> Content-Type: text/plain; charset="utf-8"
>> >> >>
>> >> >> For me, a Light version of CDI is clearly the features number.
>> That's
>> >> why
>> >> >> I
>> >> >> don't see events in it.
>> >> >>
>> >> >> For me, a CDI Lite would just focus on DI. If CDI has @Produces and
>> >> Spring
>> >> >> has @Bean, then it's because 330 lakes this functionality.
>> >> >>
>> >> >> On Sun, Aug 30, 2015 at 4:02 PM, Romain Manni-Bucau <
>> >> >> rmannibucau at gmail.com>
>> >> >> wrote:
>> >> >>
>> >> >> > Lite can have several definition, let's try to list them up if it
>> can
>> >> >> help:
>> >> >> >
>> >> >> > - binary size: for me until 3M for an app it is "Lite"
>> >> >> > - features number: the whole IoC set of feature is light since you
>> >> >> almost
>> >> >> > always need it, it means you can do lighter but it wouldnt be
>> used -
>> >> >> check
>> >> >> > spring, who uses only spring-ioc and not context or more?
>> >> >> > - features complexity: sure we are not light here but supporting
>> >> scopes
>> >> >> > already breaks "Lite-ness" IMO so not a real issue
>> >> >> >
>> >> >> > So my view is CDI "SE" is light enough - as a spec and spec can't
>> >> affect
>> >> >> > implementations so seems the fight is not on the right side to me.
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > Romain Manni-Bucau
>> >> >> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>> >> >> > <http://rmannibucau.wordpress.com> | Github
>> >> >> > <https://github.com/rmannibucau> | LinkedIn
>> >> >> > <https://www.linkedin.com/in/rmannibucau> | Tomitriber
>> >> >> > <http://www.tomitribe.com>
>> >> >> >
>> >> >> > 2015-08-30 15:57 GMT+02:00 Antonio Goncalves <
>> >> >> antonio.goncalves at gmail.com>
>> >> >> > :
>> >> >> >
>> >> >> >> It's funny, I feel I'm in Rod Johnson shoes back in Java EE 6
>> where
>> >> he
>> >> >> >> forked 330 because he found CDI was doing too much  ;o)
>> >> >> >>
>> >> >> >> For me, "CDI Lite" was just basic dependency injection. The fact
>> >> that
>> >> >> CDI
>> >> >> >> can now run on SE (like JPA....), is good... but for me it has
>> >> nothing
>> >> >> to
>> >> >> >> do with Light : it's the entire thing that can bootstrap in SE.
>> >> Good.
>> >> >> >>
>> >> >> >> So what is Lite for you guys ?
>> >> >> >>
>> >> >> >> Antonio
>> >> >> >>
>> >> >> >> On Sun, Aug 30, 2015 at 3:44 PM, Romain Manni-Bucau <
>> >> >> >> rmannibucau at gmail.com> wrote:
>> >> >> >>
>> >> >> >>> 2015-08-30 15:22 GMT+02:00 John D. Ament <
>> john.d.ament at gmail.com>:
>> >> >> >>>
>> >> >> >>>> Personally, I'm not in favor of a slimmed down runtime.  It was
>> >> tried
>> >> >> >>>> with EJB, but never implemented properly (most implementations
>> >> that
>> >> >> support
>> >> >> >>>> EJB-lite actually support the entire thing, except for
>> deprecated
>> >> >> stuff).
>> >> >> >>>>
>> >> >> >>>>
>> >> >> >>> +1, most of CDI is basic and quickly any light version will miss
>> >> >> events
>> >> >> >>> or other thing - in particular in maintaining micro services
>> from
>> >> >> >>> experience. Size of an implementation can easily be < 1M so not
>> >> sure
>> >> >> it
>> >> >> >>> would bring anything. Only important point is what Antoine
>> started
>> >> to
>> >> >> do ie
>> >> >> >>> ensuring EE and SE parts are clearly identified and split in the
>> >> spec.
>> >> >> >>>
>> >> >> >>>
>> >> >> >>>> I think if we define SE properly we won't have a need for this.
>> >> >> >>>>
>> >> >> >>>> John
>> >> >> >>>>
>> >> >> >>>> On Sun, Aug 30, 2015 at 8:07 AM Antonio Goncalves <
>> >> >> >>>> antonio.goncalves at gmail.com> wrote:
>> >> >> >>>>
>> >> >> >>>>> @Antoine, so which content do you see in CDI Lite ? Are you
>> sure
>> >> >> about
>> >> >> >>>>> events ?
>> >> >> >>>>>
>> >> >> >>>>> I'm in favor of a "fatter" 330 that would have :
>> >> >> >>>>>
>> >> >> >>>>>    - @Inject : already there
>> >> >> >>>>>    - @Qualifier : already there
>> >> >> >>>>>    -
>> >> >> >>>>> *Producers and disposers *
>> >> >> >>>>>    -
>> >> >> >>>>> *Programatic lookup *
>> >> >> >>>>>    - *Java SE Bootstrap*
>> >> >> >>>>>
>> >> >> >>>>> When you say "*The goal here is not to propose a new EE
>> profile
>> >> but
>> >> >> a
>> >> >> >>>>> subspec*", 330 could already be seen as a subspec. If you put
>> >> events
>> >> >> >>>>> apparts, what would be missing in this list in your point of
>> >> view ?
>> >> >> And
>> >> >> >>>>> what obstacles do you see in archieving this ?
>> >> >> >>>>>
>> >> >> >>>>> To boostrap CDI we have a CDIProvider, why not having an
>> >> >> >>>>> InjectionProvider just to bootstrap 330 (then, CDIProvider
>> could
>> >> >> extend
>> >> >> >>>>> InjectionProvider, so it bootstraps the all thing) ?
>> >> >> >>>>>
>> >> >> >>>>> Antonio
>> >> >> >>>>>
>> >> >> >>>>> On Sun, Aug 30, 2015 at 9:09 AM, Antoine Sabot-Durand <
>> >> >> >>>>> antoine at sabot-durand.net> wrote:
>> >> >> >>>>>
>> >> >> >>>>>> Yes Arjan, I think it's the first reason. We really should
>> work
>> >> >> with
>> >> >> >>>>>> them to understand what should be added to CDI 2.0 to have it
>> >> as a
>> >> >> first
>> >> >> >>>>>> citizen DI in their spec.
>> >> >> >>>>>>
>> >> >> >>>>>> Le sam. 29 ao?t 2015 ? 23:15, arjan tijms <
>> >> arjan.tijms at gmail.com>
>> >> >> a
>> >> >> >>>>>> ?crit :
>> >> >> >>>>>>
>> >> >> >>>>>>> On Sat, Aug 29, 2015 at 8:45 PM, Antonio Goncalves
>> >> >> >>>>>>> <antonio.goncalves at gmail.com> wrote:
>> >> >> >>>>>>> > I remember talking with the JAX-RS guys (Java EE), years
>> ago
>> >> >> (back
>> >> >> >>>>>>> in EE6),
>> >> >> >>>>>>> > and their answer for not adopting CDI was "too heavy".
>> >> >> >>>>>>>
>> >> >> >>>>>>> I can't find an exact reference anymore, but I somewhat
>> >> remember
>> >> >> that
>> >> >> >>>>>>> one of the reasons was also simply that CDI as a general
>> >> solution
>> >> >> >>>>>>> finished late in Java EE 6, while JAX-RS finished earlier
>> and
>> >> had
>> >> >> all
>> >> >> >>>>>>> the work for their own DI solution already done.
>> >> >> >>>>>>>
>> >> >> >>>>>>
>> >> >> >>>>>
>> >> >> >>>>>
>> >> >> >>>>> --
>> >> >> >>>>> Antonio Goncalves
>> >> >> >>>>> Software architect, Java Champion and Pluralsight author
>> >> >> >>>>>
>> >> >> >>>>> Web site <http://www.antoniogoncalves.org> | Twitter
>> >> >> >>>>> <http://twitter.com/agoncal> | LinkedIn
>> >> >> >>>>> <http://www.linkedin.com/in/agoncal> | Pluralsight
>> >> >> >>>>> <
>> >> http://pluralsight.com/training/Authors/Details/antonio-goncalves>
>> >> >> | Paris
>> >> >> >>>>> JUG <http://www.parisjug.org> | Devoxx France <
>> >> http://www.devoxx.fr
>> >> >> >
>> >> >> >>>>> _______________________________________________
>> >> >> >>>>> 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.
>> >> >> >>>>
>> >> >> >>>
>> >> >> >>>
>> >> >> >>
>> >> >> >>
>> >> >> >> --
>> >> >> >> Antonio Goncalves
>> >> >> >> Software architect, Java Champion and Pluralsight author
>> >> >> >>
>> >> >> >> Web site <http://www.antoniogoncalves.org> | Twitter
>> >> >> >> <http://twitter.com/agoncal> | LinkedIn
>> >> >> >> <http://www.linkedin.com/in/agoncal> | Pluralsight
>> >> >> >> <
>> http://pluralsight.com/training/Authors/Details/antonio-goncalves>
>> >> |
>> >> >> Paris
>> >> >> >> JUG <http://www.parisjug.org> | Devoxx France <
>> http://www.devoxx.fr
>> >> >
>> >> >> >>
>> >> >> >
>> >> >> >
>> >> >>
>> >> >>
>> >> >> --
>> >> >> Antonio Goncalves
>> >> >> Software architect, Java Champion and Pluralsight author
>> >> >>
>> >> >> Web site <http://www.antoniogoncalves.org> | Twitter
>> >> >> <http://twitter.com/agoncal> | LinkedIn <
>> >> >> http://www.linkedin.com/in/agoncal> |
>> >> >> Pluralsight
>> >> >> <http://pluralsight.com/training/Authors/Details/antonio-goncalves>
>> |
>> >> >> Paris
>> >> >> JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr
>> >
>> >> >> -------------- next part --------------
>> >> >> An HTML attachment was scrubbed...
>> >> >> URL:
>> >> >>
>> >>
>> http://lists.jboss.org/pipermail/cdi-dev/attachments/20150830/41058591/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 35
>> >> >> ***************************************
>> >> >>
>> >> >
>> >> >
>> >> > _______________________________________________
>> >> > 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/20150830/717fde38/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 37
>> >> ***************************************
>> >>
>> >
>> >
>> > _______________________________________________
>> > 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/20150830/4880ea38/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 39
>> ***************************************
>>
>
>
> _______________________________________________
> 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/20150830/e38bd4d3/attachment-0001.html 

From struberg at yahoo.de  Mon Aug 31 02:08:12 2015
From: struberg at yahoo.de (Mark Struberg)
Date: Mon, 31 Aug 2015 08:08:12 +0200
Subject: [cdi-dev] Time to start working on CDI lite
In-Reply-To: <CA+ZZq9-RW68R+o1c3n5J6KSGtki+o+89SvTpovSFL5ZKq6BTWQ@mail.gmail.com>
References: <CABu-YBQvgrVZcH31i+Uw9ZefsTZvLHJ4919PW=vnvRBa2RVoTQ@mail.gmail.com>
	<CA+ZZq9_C_nTH1YY1uNYnH2aW6RBBR7+xH9ZF+cduMhzOQHOO8g@mail.gmail.com>
	<CAE=-AhDa84QjHqwNLJD3+a1f2mD2d+Y_2kwqRVqzBRkuvf4Qfw@mail.gmail.com>
	<CABu-YBQ9ZtUdSj6LUoROz2-JuqROtLTG1UKUSANOY4kiVHpTDg@mail.gmail.com>
	<CA+ZZq9-RW68R+o1c3n5J6KSGtki+o+89SvTpovSFL5ZKq6BTWQ@mail.gmail.com>
Message-ID: <3714654B-A2C2-4AD7-97AC-A9DAB65A0724@yahoo.de>

I don?t grok many of the points to be honest. Please let me question a few practical points:

1.) big size: nope, thats implementation specific. OWB core has 500k + apis + asm -> way below 1MB jar size altogether. And this even includes OSGi stuff. And I think there is a weld-se package as well, right?

2.) slow boot: nope, both OWB and Weld in the meantime provide SPIs to switch out to custom scanning. Now the default scanning plugins could be replaced with a manually pre-configured class list (build time generated) etc. Thus I see no real need to change the spec. Of course, the bootstrap events could be improved. But that?s a matter of CDI event performance. Just do a few benchmarks and you will see that there is lots of room for improvement (10 mio CDI events OWB 6s, weld 19s). Do we really have anything near 10 mio classes in an embedded scenario? :)

What is left is that we _might_ drop the ?contextual instance? paradigma alltogether to spare bytecode tinkering and class proxies. But this basically is dropping the ?C? from CDI just for saving 150kByte. Imo that?s not worth it. Especially as it would mean that the (C)DI-SE has a totally different programming paradigma as CDI-EE.


Don?t get me wrong! I think it is really important to grow new ideas and let them flourish for a while. But at some point we also need to check them against the real world.


LieGrue,
strub


> Am 30.08.2015 um 14:06 schrieb Antonio Goncalves <antonio.goncalves at gmail.com>:
> 
> @Antoine, so which content do you see in CDI Lite ? Are you sure about events ? 
> 
> I'm in favor of a "fatter" 330 that would have :
> 	? @Inject : already there
> 	? @Qualifier : already there
> 	? Producers and disposers
> 	? Programatic lookup
> 	? Java SE Bootstrap
> When you say "The goal here is not to propose a new EE profile but a subspec", 330 could already be seen as a subspec. If you put events apparts, what would be missing in this list in your point of view ? And what obstacles do you see in archieving this ?
> 
> To boostrap CDI we have a CDIProvider, why not having an InjectionProvider just to bootstrap 330 (then, CDIProvider could extend InjectionProvider, so it bootstraps the all thing) ?
> 
> Antonio
> 
> On Sun, Aug 30, 2015 at 9:09 AM, Antoine Sabot-Durand <antoine at sabot-durand.net> wrote:
> Yes Arjan, I think it's the first reason. We really should work with them to understand what should be added to CDI 2.0 to have it as a first citizen DI in their spec.
> 
> Le sam. 29 ao?t 2015 ? 23:15, arjan tijms <arjan.tijms at gmail.com> a ?crit :
> On Sat, Aug 29, 2015 at 8:45 PM, Antonio Goncalves
> <antonio.goncalves at gmail.com> wrote:
> > I remember talking with the JAX-RS guys (Java EE), years ago (back in EE6),
> > and their answer for not adopting CDI was "too heavy".
> 
> I can't find an exact reference anymore, but I somewhat remember that
> one of the reasons was also simply that CDI as a general solution
> finished late in Java EE 6, while JAX-RS finished earlier and had all
> the work for their own DI solution already done.
> 
> 
> 
> -- 
> Antonio Goncalves 
> Software architect, Java Champion and Pluralsight author
> 
> Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France
> _______________________________________________
> 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.



From struberg at yahoo.de  Mon Aug 31 02:17:33 2015
From: struberg at yahoo.de (Mark Struberg)
Date: Mon, 31 Aug 2015 08:17:33 +0200
Subject: [cdi-dev] Time to start working on CDI lite
In-Reply-To: <CAAGawe0pAd5xDiELes3gMr6zF-mPZsDtW69p90LOF+NNcFVM-w@mail.gmail.com>
References: <CAAGawe0pAd5xDiELes3gMr6zF-mPZsDtW69p90LOF+NNcFVM-w@mail.gmail.com>
Message-ID: <78914AC1-C116-4480-A35D-DEB487F5DA54@yahoo.de>

> JSR 330 was never a "subspec" of CDI, but CDI simply extended it. Just like e.g. Portlet, JSP or JSF all extend and build around a standard like Servlets.


No that?s not really true. Many things you see in JSR-330 have been a mixture of features from CDI with other containers. Some things even got moved over from WebBeans (as it has been called back then) almost 1:1. 
Simply check the spec dates. JSR-330 got introduced WAY later than 299.
Even if we (CDI) _later_ (somewhen around early 2009?) decided to drop parts of our own annotations and go for the JSR-330 ones (e.g. Qualifiers, @Current got renamed to @Inject, Instance now extends Provider, etc) and 299 is _now_ based on 330.

LieGrue,
strub

From struberg at yahoo.de  Mon Aug 31 02:25:33 2015
From: struberg at yahoo.de (Mark Struberg)
Date: Mon, 31 Aug 2015 08:25:33 +0200
Subject: [cdi-dev] Time to start working on CDI lite
In-Reply-To: <CA+ZZq9-YFcTKuZr=+6v=wH-w670E++qgBrN36DsToFEidUzenQ@mail.gmail.com>
References: <CABu-YBQvgrVZcH31i+Uw9ZefsTZvLHJ4919PW=vnvRBa2RVoTQ@mail.gmail.com>
	<CA+ZZq9_C_nTH1YY1uNYnH2aW6RBBR7+xH9ZF+cduMhzOQHOO8g@mail.gmail.com>
	<CAE=-AhDa84QjHqwNLJD3+a1f2mD2d+Y_2kwqRVqzBRkuvf4Qfw@mail.gmail.com>
	<CABu-YBQ9ZtUdSj6LUoROz2-JuqROtLTG1UKUSANOY4kiVHpTDg@mail.gmail.com>
	<CA+ZZq9-RW68R+o1c3n5J6KSGtki+o+89SvTpovSFL5ZKq6BTWQ@mail.gmail.com>
	<CAOqetn_Afc0BfGPcSRBQiKuvtOfZnQKzxHv59KhbJfLTGKoH4w@mail.gmail.com>
	<CACLE=7MmgSVukPrN-fiu959w1zv7hj19VikGx-4JzA2mTRVG-w@mail.gmail.com>
	<CA+ZZq99XKDbwnqLPi-j4rcizU9EcuNzjsJTHo+Qy_djjtMCy_Q@mail.gmail.com>
	<CACLE=7Mu5mMB3tFWLtPxNXRpKrR82xKku5saFB9it3n-8RU1aQ@mail.gmail.com>
	<CA+ZZq9-YFcTKuZr=+6v=wH-w670E++qgBrN36DsToFEidUzenQ@mail.gmail.com>
Message-ID: <47B00263-144C-4B41-A1F7-73176012C22F@yahoo.de>

> For me, a Light version of CDI is clearly the features number. That's why I don't see events in it. 

We did discuss this last year on the f2f meeting. The problem lies within our Extension mechanism. Without events you also need to drop the Extension mechanism. And to be honest, this is THE major hit in all CDI?
Sorry to be the bad guy busting all those ideas. I really don?t want to, but better now than too late down the road ;)

It?s really tricky as many features are heavily based on each other. E.g. by removing scanning you could get rid of javassist/asm/etc ? nope, we also have our class proxies which need bytecode tinkering. So remove interceptors and decorators too? Well yea, but we still have normalscoping -> what is left? basically spring prototype and singleton. Hmm.  that?s not that much compared to full CDI. And all that for only 200kByte?
(Btw we also discussed generating the bytecode classes at build time, but then we still miss the dynamics we get from Extensions, e.g. PAT adding an interceptor annotation)
Just to give you a rough idea how this all works together when it comes to implementation details?
Please feel free to ask Jozef and me for further infos on ?dependencies?.

LieGrue,
strub


> Am 30.08.2015 um 18:09 schrieb Antonio Goncalves <antonio.goncalves at gmail.com>:
> 
> For me, a Light version of CDI is clearly the features number. That's why I don't see events in it. 
> 
> For me, a CDI Lite would just focus on DI. If CDI has @Produces and Spring has @Bean, then it's because 330 lakes this functionality. 
> 
> On Sun, Aug 30, 2015 at 4:02 PM, Romain Manni-Bucau <rmannibucau at gmail.com> wrote:
> Lite can have several definition, let's try to list them up if it can help:
> 
> - binary size: for me until 3M for an app it is "Lite"
> - features number: the whole IoC set of feature is light since you almost always need it, it means you can do lighter but it wouldnt be used - check spring, who uses only spring-ioc and not context or more?
> - features complexity: sure we are not light here but supporting scopes already breaks "Lite-ness" IMO so not a real issue
> 
> So my view is CDI "SE" is light enough - as a spec and spec can't affect implementations so seems the fight is not on the right side to me.
> 
> 
> 
> Romain Manni-Bucau
> @rmannibucau |  Blog | Github | LinkedIn | Tomitriber
> 
> 2015-08-30 15:57 GMT+02:00 Antonio Goncalves <antonio.goncalves at gmail.com>:
> It's funny, I feel I'm in Rod Johnson shoes back in Java EE 6 where he forked 330 because he found CDI was doing too much  ;o)
> 
> For me, "CDI Lite" was just basic dependency injection. The fact that CDI can now run on SE (like JPA....), is good... but for me it has nothing to do with Light : it's the entire thing that can bootstrap in SE. Good. 
> 
> So what is Lite for you guys ?
> 
> Antonio
> 
> On Sun, Aug 30, 2015 at 3:44 PM, Romain Manni-Bucau <rmannibucau at gmail.com> wrote:
> 2015-08-30 15:22 GMT+02:00 John D. Ament <john.d.ament at gmail.com>:
> Personally, I'm not in favor of a slimmed down runtime.  It was tried with EJB, but never implemented properly (most implementations that support EJB-lite actually support the entire thing, except for deprecated stuff).
> 
> 
> +1, most of CDI is basic and quickly any light version will miss events or other thing - in particular in maintaining micro services from experience. Size of an implementation can easily be < 1M so not sure it would bring anything. Only important point is what Antoine started to do ie ensuring EE and SE parts are clearly identified and split in the spec.
>  
> I think if we define SE properly we won't have a need for this.  
> 
> John
> 
> On Sun, Aug 30, 2015 at 8:07 AM Antonio Goncalves <antonio.goncalves at gmail.com> wrote:
> @Antoine, so which content do you see in CDI Lite ? Are you sure about events ? 
> 
> I'm in favor of a "fatter" 330 that would have :
> 	? @Inject : already there
> 	? @Qualifier : already there
> 	? Producers and disposers
> 	? Programatic lookup
> 	? Java SE Bootstrap
> When you say "The goal here is not to propose a new EE profile but a subspec", 330 could already be seen as a subspec. If you put events apparts, what would be missing in this list in your point of view ? And what obstacles do you see in archieving this ?
> 
> To boostrap CDI we have a CDIProvider, why not having an InjectionProvider just to bootstrap 330 (then, CDIProvider could extend InjectionProvider, so it bootstraps the all thing) ?
> 
> Antonio
> 
> On Sun, Aug 30, 2015 at 9:09 AM, Antoine Sabot-Durand <antoine at sabot-durand.net> wrote:
> Yes Arjan, I think it's the first reason. We really should work with them to understand what should be added to CDI 2.0 to have it as a first citizen DI in their spec.
> 
> Le sam. 29 ao?t 2015 ? 23:15, arjan tijms <arjan.tijms at gmail.com> a ?crit :
> On Sat, Aug 29, 2015 at 8:45 PM, Antonio Goncalves
> <antonio.goncalves at gmail.com> wrote:
> > I remember talking with the JAX-RS guys (Java EE), years ago (back in EE6),
> > and their answer for not adopting CDI was "too heavy".
> 
> I can't find an exact reference anymore, but I somewhat remember that
> one of the reasons was also simply that CDI as a general solution
> finished late in Java EE 6, while JAX-RS finished earlier and had all
> the work for their own DI solution already done.
> 
> 
> 
> -- 
> Antonio Goncalves 
> Software architect, Java Champion and Pluralsight author
> 
> Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France
> _______________________________________________
> 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.
> 
> 
> 
> 
> -- 
> Antonio Goncalves 
> Software architect, Java Champion and Pluralsight author
> 
> Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France
> 
> 
> 
> 
> -- 
> Antonio Goncalves 
> Software architect, Java Champion and Pluralsight author
> 
> Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France
> _______________________________________________
> 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.



From antonio.goncalves at gmail.com  Mon Aug 31 03:57:35 2015
From: antonio.goncalves at gmail.com (Antonio Goncalves)
Date: Mon, 31 Aug 2015 09:57:35 +0200
Subject: [cdi-dev] Time to start working on CDI lite
In-Reply-To: <47B00263-144C-4B41-A1F7-73176012C22F@yahoo.de>
References: <CABu-YBQvgrVZcH31i+Uw9ZefsTZvLHJ4919PW=vnvRBa2RVoTQ@mail.gmail.com>
	<CA+ZZq9_C_nTH1YY1uNYnH2aW6RBBR7+xH9ZF+cduMhzOQHOO8g@mail.gmail.com>
	<CAE=-AhDa84QjHqwNLJD3+a1f2mD2d+Y_2kwqRVqzBRkuvf4Qfw@mail.gmail.com>
	<CABu-YBQ9ZtUdSj6LUoROz2-JuqROtLTG1UKUSANOY4kiVHpTDg@mail.gmail.com>
	<CA+ZZq9-RW68R+o1c3n5J6KSGtki+o+89SvTpovSFL5ZKq6BTWQ@mail.gmail.com>
	<CAOqetn_Afc0BfGPcSRBQiKuvtOfZnQKzxHv59KhbJfLTGKoH4w@mail.gmail.com>
	<CACLE=7MmgSVukPrN-fiu959w1zv7hj19VikGx-4JzA2mTRVG-w@mail.gmail.com>
	<CA+ZZq99XKDbwnqLPi-j4rcizU9EcuNzjsJTHo+Qy_djjtMCy_Q@mail.gmail.com>
	<CACLE=7Mu5mMB3tFWLtPxNXRpKrR82xKku5saFB9it3n-8RU1aQ@mail.gmail.com>
	<CA+ZZq9-YFcTKuZr=+6v=wH-w670E++qgBrN36DsToFEidUzenQ@mail.gmail.com>
	<47B00263-144C-4B41-A1F7-73176012C22F@yahoo.de>
Message-ID: <CA+ZZq99QchL8uZY_E8=kWetNEHiUGJV+T=GBS8W0doRf7S-Kiw@mail.gmail.com>

I don't see Events in a "Lite" version because the other DI frameworks
don't use them. A "fatter" 330 with producers, programmatic lookup and
bootstrap, could be "easily" implemented by Spring, Guice... If we leave
events in a Lite version, then it won't be the case, and Weld and OWB will
be the only two implementations.

For me, a Lite version would just be about DI. If Weld uses events
internally to archieve basic DI, well, it's just an implementation
decision, not a spec. I would not even try to standardize the way @Inject
works (like Romain said, @Inject doesn't work the same in Weld or Spring),
let's leave it like this. If you take back Antoine sentence "*This would
allow using CDI in constrained environment like mobile or embedded devices*",
then I don't think events would fit here.

Antonio

On Mon, Aug 31, 2015 at 8:25 AM, Mark Struberg <struberg at yahoo.de> wrote:

> > For me, a Light version of CDI is clearly the features number. That's
> why I don't see events in it.
>
> We did discuss this last year on the f2f meeting. The problem lies within
> our Extension mechanism. Without events you also need to drop the Extension
> mechanism. And to be honest, this is THE major hit in all CDI?
> Sorry to be the bad guy busting all those ideas. I really don?t want to,
> but better now than too late down the road ;)
>
> It?s really tricky as many features are heavily based on each other. E.g.
> by removing scanning you could get rid of javassist/asm/etc ? nope, we also
> have our class proxies which need bytecode tinkering. So remove
> interceptors and decorators too? Well yea, but we still have normalscoping
> -> what is left? basically spring prototype and singleton. Hmm.  that?s not
> that much compared to full CDI. And all that for only 200kByte?
> (Btw we also discussed generating the bytecode classes at build time, but
> then we still miss the dynamics we get from Extensions, e.g. PAT adding an
> interceptor annotation)
> Just to give you a rough idea how this all works together when it comes to
> implementation details?
> Please feel free to ask Jozef and me for further infos on ?dependencies?.
>
> LieGrue,
> strub
>
>
> > Am 30.08.2015 um 18:09 schrieb Antonio Goncalves <
> antonio.goncalves at gmail.com>:
> >
> > For me, a Light version of CDI is clearly the features number. That's
> why I don't see events in it.
> >
> > For me, a CDI Lite would just focus on DI. If CDI has @Produces and
> Spring has @Bean, then it's because 330 lakes this functionality.
> >
> > On Sun, Aug 30, 2015 at 4:02 PM, Romain Manni-Bucau <
> rmannibucau at gmail.com> wrote:
> > Lite can have several definition, let's try to list them up if it can
> help:
> >
> > - binary size: for me until 3M for an app it is "Lite"
> > - features number: the whole IoC set of feature is light since you
> almost always need it, it means you can do lighter but it wouldnt be used -
> check spring, who uses only spring-ioc and not context or more?
> > - features complexity: sure we are not light here but supporting scopes
> already breaks "Lite-ness" IMO so not a real issue
> >
> > So my view is CDI "SE" is light enough - as a spec and spec can't affect
> implementations so seems the fight is not on the right side to me.
> >
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau |  Blog | Github | LinkedIn | Tomitriber
> >
> > 2015-08-30 15:57 GMT+02:00 Antonio Goncalves <
> antonio.goncalves at gmail.com>:
> > It's funny, I feel I'm in Rod Johnson shoes back in Java EE 6 where he
> forked 330 because he found CDI was doing too much  ;o)
> >
> > For me, "CDI Lite" was just basic dependency injection. The fact that
> CDI can now run on SE (like JPA....), is good... but for me it has nothing
> to do with Light : it's the entire thing that can bootstrap in SE. Good.
> >
> > So what is Lite for you guys ?
> >
> > Antonio
> >
> > On Sun, Aug 30, 2015 at 3:44 PM, Romain Manni-Bucau <
> rmannibucau at gmail.com> wrote:
> > 2015-08-30 15:22 GMT+02:00 John D. Ament <john.d.ament at gmail.com>:
> > Personally, I'm not in favor of a slimmed down runtime.  It was tried
> with EJB, but never implemented properly (most implementations that support
> EJB-lite actually support the entire thing, except for deprecated stuff).
> >
> >
> > +1, most of CDI is basic and quickly any light version will miss events
> or other thing - in particular in maintaining micro services from
> experience. Size of an implementation can easily be < 1M so not sure it
> would bring anything. Only important point is what Antoine started to do ie
> ensuring EE and SE parts are clearly identified and split in the spec.
> >
> > I think if we define SE properly we won't have a need for this.
> >
> > John
> >
> > On Sun, Aug 30, 2015 at 8:07 AM Antonio Goncalves <
> antonio.goncalves at gmail.com> wrote:
> > @Antoine, so which content do you see in CDI Lite ? Are you sure about
> events ?
> >
> > I'm in favor of a "fatter" 330 that would have :
> >       ? @Inject : already there
> >       ? @Qualifier : already there
> >       ? Producers and disposers
> >       ? Programatic lookup
> >       ? Java SE Bootstrap
> > When you say "The goal here is not to propose a new EE profile but a
> subspec", 330 could already be seen as a subspec. If you put events
> apparts, what would be missing in this list in your point of view ? And
> what obstacles do you see in archieving this ?
> >
> > To boostrap CDI we have a CDIProvider, why not having an
> InjectionProvider just to bootstrap 330 (then, CDIProvider could extend
> InjectionProvider, so it bootstraps the all thing) ?
> >
> > Antonio
> >
> > On Sun, Aug 30, 2015 at 9:09 AM, Antoine Sabot-Durand <
> antoine at sabot-durand.net> wrote:
> > Yes Arjan, I think it's the first reason. We really should work with
> them to understand what should be added to CDI 2.0 to have it as a first
> citizen DI in their spec.
> >
> > Le sam. 29 ao?t 2015 ? 23:15, arjan tijms <arjan.tijms at gmail.com> a
> ?crit :
> > On Sat, Aug 29, 2015 at 8:45 PM, Antonio Goncalves
> > <antonio.goncalves at gmail.com> wrote:
> > > I remember talking with the JAX-RS guys (Java EE), years ago (back in
> EE6),
> > > and their answer for not adopting CDI was "too heavy".
> >
> > I can't find an exact reference anymore, but I somewhat remember that
> > one of the reasons was also simply that CDI as a general solution
> > finished late in Java EE 6, while JAX-RS finished earlier and had all
> > the work for their own DI solution already done.
> >
> >
> >
> > --
> > Antonio Goncalves
> > Software architect, Java Champion and Pluralsight author
> >
> > Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France
> > _______________________________________________
> > 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.
> >
> >
> >
> >
> > --
> > Antonio Goncalves
> > Software architect, Java Champion and Pluralsight author
> >
> > Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France
> >
> >
> >
> >
> > --
> > Antonio Goncalves
> > Software architect, Java Champion and Pluralsight author
> >
> > Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France
> > _______________________________________________
> > 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.
>
>


-- 
Antonio Goncalves
Software architect, Java Champion and Pluralsight author

Web site <http://www.antoniogoncalves.org> | Twitter
<http://twitter.com/agoncal> | LinkedIn <http://www.linkedin.com/in/agoncal> |
Pluralsight
<http://pluralsight.com/training/Authors/Details/antonio-goncalves> | Paris
JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150831/c3b0dac2/attachment-0001.html 

From rmannibucau at gmail.com  Mon Aug 31 04:00:58 2015
From: rmannibucau at gmail.com (Romain Manni-Bucau)
Date: Mon, 31 Aug 2015 10:00:58 +0200
Subject: [cdi-dev] Time to start working on CDI lite
In-Reply-To: <CA+ZZq99QchL8uZY_E8=kWetNEHiUGJV+T=GBS8W0doRf7S-Kiw@mail.gmail.com>
References: <CABu-YBQvgrVZcH31i+Uw9ZefsTZvLHJ4919PW=vnvRBa2RVoTQ@mail.gmail.com>
	<CA+ZZq9_C_nTH1YY1uNYnH2aW6RBBR7+xH9ZF+cduMhzOQHOO8g@mail.gmail.com>
	<CAE=-AhDa84QjHqwNLJD3+a1f2mD2d+Y_2kwqRVqzBRkuvf4Qfw@mail.gmail.com>
	<CABu-YBQ9ZtUdSj6LUoROz2-JuqROtLTG1UKUSANOY4kiVHpTDg@mail.gmail.com>
	<CA+ZZq9-RW68R+o1c3n5J6KSGtki+o+89SvTpovSFL5ZKq6BTWQ@mail.gmail.com>
	<CAOqetn_Afc0BfGPcSRBQiKuvtOfZnQKzxHv59KhbJfLTGKoH4w@mail.gmail.com>
	<CACLE=7MmgSVukPrN-fiu959w1zv7hj19VikGx-4JzA2mTRVG-w@mail.gmail.com>
	<CA+ZZq99XKDbwnqLPi-j4rcizU9EcuNzjsJTHo+Qy_djjtMCy_Q@mail.gmail.com>
	<CACLE=7Mu5mMB3tFWLtPxNXRpKrR82xKku5saFB9it3n-8RU1aQ@mail.gmail.com>
	<CA+ZZq9-YFcTKuZr=+6v=wH-w670E++qgBrN36DsToFEidUzenQ@mail.gmail.com>
	<47B00263-144C-4B41-A1F7-73176012C22F@yahoo.de>
	<CA+ZZq99QchL8uZY_E8=kWetNEHiUGJV+T=GBS8W0doRf7S-Kiw@mail.gmail.com>
Message-ID: <CACLE=7MzVcBrhnoeUpo6ZAMpDu_04SOWSttWc-hRJL4wm8vpDw@mail.gmail.com>

@Antonio: spring and guice have events, they just dont work the same way
CDI defined them but not a big deal IMO to support them (just one more
processor for spring for instance).


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com>

2015-08-31 9:57 GMT+02:00 Antonio Goncalves <antonio.goncalves at gmail.com>:

> I don't see Events in a "Lite" version because the other DI frameworks
> don't use them. A "fatter" 330 with producers, programmatic lookup and
> bootstrap, could be "easily" implemented by Spring, Guice... If we leave
> events in a Lite version, then it won't be the case, and Weld and OWB will
> be the only two implementations.
>
> For me, a Lite version would just be about DI. If Weld uses events
> internally to archieve basic DI, well, it's just an implementation
> decision, not a spec. I would not even try to standardize the way @Inject
> works (like Romain said, @Inject doesn't work the same in Weld or Spring),
> let's leave it like this. If you take back Antoine sentence "*This would
> allow using CDI in constrained environment like mobile or embedded devices*",
> then I don't think events would fit here.
>
> Antonio
>
> On Mon, Aug 31, 2015 at 8:25 AM, Mark Struberg <struberg at yahoo.de> wrote:
>
>> > For me, a Light version of CDI is clearly the features number. That's
>> why I don't see events in it.
>>
>> We did discuss this last year on the f2f meeting. The problem lies within
>> our Extension mechanism. Without events you also need to drop the Extension
>> mechanism. And to be honest, this is THE major hit in all CDI?
>> Sorry to be the bad guy busting all those ideas. I really don?t want to,
>> but better now than too late down the road ;)
>>
>> It?s really tricky as many features are heavily based on each other. E.g.
>> by removing scanning you could get rid of javassist/asm/etc ? nope, we also
>> have our class proxies which need bytecode tinkering. So remove
>> interceptors and decorators too? Well yea, but we still have normalscoping
>> -> what is left? basically spring prototype and singleton. Hmm.  that?s not
>> that much compared to full CDI. And all that for only 200kByte?
>> (Btw we also discussed generating the bytecode classes at build time, but
>> then we still miss the dynamics we get from Extensions, e.g. PAT adding an
>> interceptor annotation)
>> Just to give you a rough idea how this all works together when it comes
>> to implementation details?
>> Please feel free to ask Jozef and me for further infos on ?dependencies?.
>>
>> LieGrue,
>> strub
>>
>>
>> > Am 30.08.2015 um 18:09 schrieb Antonio Goncalves <
>> antonio.goncalves at gmail.com>:
>> >
>> > For me, a Light version of CDI is clearly the features number. That's
>> why I don't see events in it.
>> >
>> > For me, a CDI Lite would just focus on DI. If CDI has @Produces and
>> Spring has @Bean, then it's because 330 lakes this functionality.
>> >
>> > On Sun, Aug 30, 2015 at 4:02 PM, Romain Manni-Bucau <
>> rmannibucau at gmail.com> wrote:
>> > Lite can have several definition, let's try to list them up if it can
>> help:
>> >
>> > - binary size: for me until 3M for an app it is "Lite"
>> > - features number: the whole IoC set of feature is light since you
>> almost always need it, it means you can do lighter but it wouldnt be used -
>> check spring, who uses only spring-ioc and not context or more?
>> > - features complexity: sure we are not light here but supporting scopes
>> already breaks "Lite-ness" IMO so not a real issue
>> >
>> > So my view is CDI "SE" is light enough - as a spec and spec can't
>> affect implementations so seems the fight is not on the right side to me.
>> >
>> >
>> >
>> > Romain Manni-Bucau
>> > @rmannibucau |  Blog | Github | LinkedIn | Tomitriber
>> >
>> > 2015-08-30 15:57 GMT+02:00 Antonio Goncalves <
>> antonio.goncalves at gmail.com>:
>> > It's funny, I feel I'm in Rod Johnson shoes back in Java EE 6 where he
>> forked 330 because he found CDI was doing too much  ;o)
>> >
>> > For me, "CDI Lite" was just basic dependency injection. The fact that
>> CDI can now run on SE (like JPA....), is good... but for me it has nothing
>> to do with Light : it's the entire thing that can bootstrap in SE. Good.
>> >
>> > So what is Lite for you guys ?
>> >
>> > Antonio
>> >
>> > On Sun, Aug 30, 2015 at 3:44 PM, Romain Manni-Bucau <
>> rmannibucau at gmail.com> wrote:
>> > 2015-08-30 15:22 GMT+02:00 John D. Ament <john.d.ament at gmail.com>:
>> > Personally, I'm not in favor of a slimmed down runtime.  It was tried
>> with EJB, but never implemented properly (most implementations that support
>> EJB-lite actually support the entire thing, except for deprecated stuff).
>> >
>> >
>> > +1, most of CDI is basic and quickly any light version will miss events
>> or other thing - in particular in maintaining micro services from
>> experience. Size of an implementation can easily be < 1M so not sure it
>> would bring anything. Only important point is what Antoine started to do ie
>> ensuring EE and SE parts are clearly identified and split in the spec.
>> >
>> > I think if we define SE properly we won't have a need for this.
>> >
>> > John
>> >
>> > On Sun, Aug 30, 2015 at 8:07 AM Antonio Goncalves <
>> antonio.goncalves at gmail.com> wrote:
>> > @Antoine, so which content do you see in CDI Lite ? Are you sure about
>> events ?
>> >
>> > I'm in favor of a "fatter" 330 that would have :
>> >       ? @Inject : already there
>> >       ? @Qualifier : already there
>> >       ? Producers and disposers
>> >       ? Programatic lookup
>> >       ? Java SE Bootstrap
>> > When you say "The goal here is not to propose a new EE profile but a
>> subspec", 330 could already be seen as a subspec. If you put events
>> apparts, what would be missing in this list in your point of view ? And
>> what obstacles do you see in archieving this ?
>> >
>> > To boostrap CDI we have a CDIProvider, why not having an
>> InjectionProvider just to bootstrap 330 (then, CDIProvider could extend
>> InjectionProvider, so it bootstraps the all thing) ?
>> >
>> > Antonio
>> >
>> > On Sun, Aug 30, 2015 at 9:09 AM, Antoine Sabot-Durand <
>> antoine at sabot-durand.net> wrote:
>> > Yes Arjan, I think it's the first reason. We really should work with
>> them to understand what should be added to CDI 2.0 to have it as a first
>> citizen DI in their spec.
>> >
>> > Le sam. 29 ao?t 2015 ? 23:15, arjan tijms <arjan.tijms at gmail.com> a
>> ?crit :
>> > On Sat, Aug 29, 2015 at 8:45 PM, Antonio Goncalves
>> > <antonio.goncalves at gmail.com> wrote:
>> > > I remember talking with the JAX-RS guys (Java EE), years ago (back in
>> EE6),
>> > > and their answer for not adopting CDI was "too heavy".
>> >
>> > I can't find an exact reference anymore, but I somewhat remember that
>> > one of the reasons was also simply that CDI as a general solution
>> > finished late in Java EE 6, while JAX-RS finished earlier and had all
>> > the work for their own DI solution already done.
>> >
>> >
>> >
>> > --
>> > Antonio Goncalves
>> > Software architect, Java Champion and Pluralsight author
>> >
>> > Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France
>> > _______________________________________________
>> > 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.
>> >
>> >
>> >
>> >
>> > --
>> > Antonio Goncalves
>> > Software architect, Java Champion and Pluralsight author
>> >
>> > Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France
>> >
>> >
>> >
>> >
>> > --
>> > Antonio Goncalves
>> > Software architect, Java Champion and Pluralsight author
>> >
>> > Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France
>> > _______________________________________________
>> > 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.
>>
>>
>
>
> --
> Antonio Goncalves
> Software architect, Java Champion and Pluralsight author
>
> Web site <http://www.antoniogoncalves.org> | Twitter
> <http://twitter.com/agoncal> | LinkedIn
> <http://www.linkedin.com/in/agoncal> | Pluralsight
> <http://pluralsight.com/training/Authors/Details/antonio-goncalves> | Paris
> JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150831/4d1b9468/attachment.html 

From mkouba at redhat.com  Mon Aug 31 04:11:54 2015
From: mkouba at redhat.com (Martin Kouba)
Date: Mon, 31 Aug 2015 10:11:54 +0200
Subject: [cdi-dev] Time to start working on CDI lite
In-Reply-To: <CA+ZZq99QchL8uZY_E8=kWetNEHiUGJV+T=GBS8W0doRf7S-Kiw@mail.gmail.com>
References: <CABu-YBQvgrVZcH31i+Uw9ZefsTZvLHJ4919PW=vnvRBa2RVoTQ@mail.gmail.com>
	<CA+ZZq9_C_nTH1YY1uNYnH2aW6RBBR7+xH9ZF+cduMhzOQHOO8g@mail.gmail.com>
	<CAE=-AhDa84QjHqwNLJD3+a1f2mD2d+Y_2kwqRVqzBRkuvf4Qfw@mail.gmail.com>
	<CABu-YBQ9ZtUdSj6LUoROz2-JuqROtLTG1UKUSANOY4kiVHpTDg@mail.gmail.com>
	<CA+ZZq9-RW68R+o1c3n5J6KSGtki+o+89SvTpovSFL5ZKq6BTWQ@mail.gmail.com>
	<CAOqetn_Afc0BfGPcSRBQiKuvtOfZnQKzxHv59KhbJfLTGKoH4w@mail.gmail.com>
	<CACLE=7MmgSVukPrN-fiu959w1zv7hj19VikGx-4JzA2mTRVG-w@mail.gmail.com>
	<CA+ZZq99XKDbwnqLPi-j4rcizU9EcuNzjsJTHo+Qy_djjtMCy_Q@mail.gmail.com>
	<CACLE=7Mu5mMB3tFWLtPxNXRpKrR82xKku5saFB9it3n-8RU1aQ@mail.gmail.com>
	<CA+ZZq9-YFcTKuZr=+6v=wH-w670E++qgBrN36DsToFEidUzenQ@mail.gmail.com>
	<47B00263-144C-4B41-A1F7-73176012C22F@yahoo.de>
	<CA+ZZq99QchL8uZY_E8=kWetNEHiUGJV+T=GBS8W0doRf7S-Kiw@mail.gmail.com>
Message-ID: <55E40C4A.4090905@redhat.com>

Dne 31.8.2015 v 09:57 Antonio Goncalves napsal(a):
> I don't see Events in a "Lite" version because the other DI frameworks
> don't use them. A "fatter" 330 with producers, programmatic lookup and
> bootstrap, could be "easily" implemented by Spring, Guice... If we leave
> events in a Lite version, then it won't be the case, and Weld and OWB
> will be the only two implementations.
>
> For me, a Lite version would just be about DI. If Weld uses events
> internally to archieve basic DI, well, it's just an implementation
> decision, not a spec. I would not even try to standardize the way
> @Inject works (like Romain said, @Inject doesn't work the same in Weld
> or Spring), let's leave it like this.

If you don't standardize how @Inject works then what's the purpose of 
having something like CDI Lite and many implementations which work 
differently? A user of implementation "A" will not be able to switch to 
implementation "B" easily. And that's one of the most important benefits 
of standardization...

If you take back Antoine sentence
> "/This would allow using CDI in constrained environment like mobile or
> embedded devices/", then I don't think events would fit here.
>
> Antonio
>
> On Mon, Aug 31, 2015 at 8:25 AM, Mark Struberg <struberg at yahoo.de
> <mailto:struberg at yahoo.de>> wrote:
>
>     > For me, a Light version of CDI is clearly the features number. That's why I don't see events in it.
>
>     We did discuss this last year on the f2f meeting. The problem lies
>     within our Extension mechanism. Without events you also need to drop
>     the Extension mechanism. And to be honest, this is THE major hit in
>     all CDI?
>     Sorry to be the bad guy busting all those ideas. I really don?t want
>     to, but better now than too late down the road ;)
>
>     It?s really tricky as many features are heavily based on each other.
>     E.g. by removing scanning you could get rid of javassist/asm/etc ?
>     nope, we also have our class proxies which need bytecode tinkering.
>     So remove interceptors and decorators too? Well yea, but we still
>     have normalscoping -> what is left? basically spring prototype and
>     singleton. Hmm.  that?s not that much compared to full CDI. And all
>     that for only 200kByte?
>     (Btw we also discussed generating the bytecode classes at build
>     time, but then we still miss the dynamics we get from Extensions,
>     e.g. PAT adding an interceptor annotation)
>     Just to give you a rough idea how this all works together when it
>     comes to implementation details?
>     Please feel free to ask Jozef and me for further infos on
>     ?dependencies?.
>
>     LieGrue,
>     strub
>
>
>      > Am 30.08.2015 um 18:09 schrieb Antonio Goncalves
>     <antonio.goncalves at gmail.com <mailto:antonio.goncalves at gmail.com>>:
>      >
>      > For me, a Light version of CDI is clearly the features number.
>     That's why I don't see events in it.
>      >
>      > For me, a CDI Lite would just focus on DI. If CDI has @Produces
>     and Spring has @Bean, then it's because 330 lakes this functionality.
>      >
>      > On Sun, Aug 30, 2015 at 4:02 PM, Romain Manni-Bucau
>     <rmannibucau at gmail.com <mailto:rmannibucau at gmail.com>> wrote:
>      > Lite can have several definition, let's try to list them up if it
>     can help:
>      >
>      > - binary size: for me until 3M for an app it is "Lite"
>      > - features number: the whole IoC set of feature is light since
>     you almost always need it, it means you can do lighter but it
>     wouldnt be used - check spring, who uses only spring-ioc and not
>     context or more?
>      > - features complexity: sure we are not light here but supporting
>     scopes already breaks "Lite-ness" IMO so not a real issue
>      >
>      > So my view is CDI "SE" is light enough - as a spec and spec can't
>     affect implementations so seems the fight is not on the right side
>     to me.
>      >
>      >
>      >
>      > Romain Manni-Bucau
>      > @rmannibucau |  Blog | Github | LinkedIn | Tomitriber
>      >
>      > 2015-08-30 15:57 GMT+02:00 Antonio Goncalves
>     <antonio.goncalves at gmail.com <mailto:antonio.goncalves at gmail.com>>:
>      > It's funny, I feel I'm in Rod Johnson shoes back in Java EE 6
>     where he forked 330 because he found CDI was doing too much  ;o)
>      >
>      > For me, "CDI Lite" was just basic dependency injection. The fact
>     that CDI can now run on SE (like JPA....), is good... but for me it
>     has nothing to do with Light : it's the entire thing that can
>     bootstrap in SE. Good.
>      >
>      > So what is Lite for you guys ?
>      >
>      > Antonio
>      >
>      > On Sun, Aug 30, 2015 at 3:44 PM, Romain Manni-Bucau
>     <rmannibucau at gmail.com <mailto:rmannibucau at gmail.com>> wrote:
>      > 2015-08-30 15:22 GMT+02:00 John D. Ament <john.d.ament at gmail.com
>     <mailto:john.d.ament at gmail.com>>:
>      > Personally, I'm not in favor of a slimmed down runtime.  It was
>     tried with EJB, but never implemented properly (most implementations
>     that support EJB-lite actually support the entire thing, except for
>     deprecated stuff).
>      >
>      >
>      > +1, most of CDI is basic and quickly any light version will miss
>     events or other thing - in particular in maintaining micro services
>     from experience. Size of an implementation can easily be < 1M so not
>     sure it would bring anything. Only important point is what Antoine
>     started to do ie ensuring EE and SE parts are clearly identified and
>     split in the spec.
>      >
>      > I think if we define SE properly we won't have a need for this.
>      >
>      > John
>      >
>      > On Sun, Aug 30, 2015 at 8:07 AM Antonio Goncalves
>     <antonio.goncalves at gmail.com <mailto:antonio.goncalves at gmail.com>>
>     wrote:
>      > @Antoine, so which content do you see in CDI Lite ? Are you sure
>     about events ?
>      >
>      > I'm in favor of a "fatter" 330 that would have :
>      >       ? @Inject : already there
>      >       ? @Qualifier : already there
>      >       ? Producers and disposers
>      >       ? Programatic lookup
>      >       ? Java SE Bootstrap
>      > When you say "The goal here is not to propose a new EE profile
>     but a subspec", 330 could already be seen as a subspec. If you put
>     events apparts, what would be missing in this list in your point of
>     view ? And what obstacles do you see in archieving this ?
>      >
>      > To boostrap CDI we have a CDIProvider, why not having an
>     InjectionProvider just to bootstrap 330 (then, CDIProvider could
>     extend InjectionProvider, so it bootstraps the all thing) ?
>      >
>      > Antonio
>      >
>      > On Sun, Aug 30, 2015 at 9:09 AM, Antoine Sabot-Durand
>     <antoine at sabot-durand.net <mailto:antoine at sabot-durand.net>> wrote:
>      > Yes Arjan, I think it's the first reason. We really should work
>     with them to understand what should be added to CDI 2.0 to have it
>     as a first citizen DI in their spec.
>      >
>      > Le sam. 29 ao?t 2015 ? 23:15, arjan tijms <arjan.tijms at gmail.com
>     <mailto:arjan.tijms at gmail.com>> a ?crit :
>      > On Sat, Aug 29, 2015 at 8:45 PM, Antonio Goncalves
>      > <antonio.goncalves at gmail.com
>     <mailto:antonio.goncalves at gmail.com>> wrote:
>      > > I remember talking with the JAX-RS guys (Java EE), years ago
>     (back in EE6),
>      > > and their answer for not adopting CDI was "too heavy".
>      >
>      > I can't find an exact reference anymore, but I somewhat remember that
>      > one of the reasons was also simply that CDI as a general solution
>      > finished late in Java EE 6, while JAX-RS finished earlier and had all
>      > the work for their own DI solution already done.
>      >
>      >
>      >
>      > --
>      > Antonio Goncalves
>      > Software architect, Java Champion and Pluralsight author
>      >
>      > Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx
>     France
>      > _______________________________________________
>      > cdi-dev mailing list
>      > cdi-dev at lists.jboss.org <mailto: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 <mailto: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.
>      >
>      >
>      >
>      >
>      > --
>      > Antonio Goncalves
>      > Software architect, Java Champion and Pluralsight author
>      >
>      > Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx
>     France
>      >
>      >
>      >
>      >
>      > --
>      > Antonio Goncalves
>      > Software architect, Java Champion and Pluralsight author
>      >
>      > Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx
>     France
>      > _______________________________________________
>      > cdi-dev mailing list
>      > cdi-dev at lists.jboss.org <mailto: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.
>
>
>
>
> --
> Antonio Goncalves
> Software architect, Java Champion and Pluralsight author
>
> Web site <http://www.antoniogoncalves.org> | Twitter
> <http://twitter.com/agoncal> | LinkedIn
> <http://www.linkedin.com/in/agoncal> | Pluralsight
> <http://pluralsight.com/training/Authors/Details/antonio-goncalves> |
> Paris JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr>
>
>
> _______________________________________________
> 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

From werner.keil at gmail.com  Mon Aug 31 04:22:34 2015
From: werner.keil at gmail.com (Werner Keil)
Date: Mon, 31 Aug 2015 10:22:34 +0200
Subject: [cdi-dev] Time to start working on CDI lite
Message-ID: <CAAGawe0di_i0e_07fXoSpHDT5abQO1SWg05WM1sFe_M_snLE1Q@mail.gmail.com>

Good points by both of you.

@Mark about your earlier posts
Sure, 330 started a bit later than 299, and I know best (because I was one
of the few EC members also actively participating in discussion threads
like Google Groups to help them find synergies) there was a bit of "pissing
contest" or "not invented here" friction between Spec Leads and experts of
299 and 330 (in itself the "least common denominator" of several other
ideas including Spring or Guice)

We saw these things go pretty wrong in cases like JSR 310 (the Spec Lead
just figured everything was "crap" that hd did not invent, and only a bit
of naming or feature cropping was possible by JDK architects and Oracle,
but a lot of things are reinvented even when it comes to formatting, etc.
not at all in line with other parts Java SE) or 107 vs. 347 (where the
latter simply gave up due to lack of interest or resources, despite
proposed by the compnay that also leads the CDI spec) but for most parts
I'd say, it went reasonably well for 330 and 299+


Werner

On Mon, Aug 31, 2015 at 10:11 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: Time to start working on CDI lite (Romain Manni-Bucau)
>    2. Re: Time to start working on CDI lite (Martin Kouba)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 31 Aug 2015 10:00:58 +0200
> From: Romain Manni-Bucau <rmannibucau at gmail.com>
> Subject: Re: [cdi-dev] Time to start working on CDI lite
> To: Antonio Goncalves <antonio.goncalves at gmail.com>
> Cc: cdi-dev <cdi-dev at lists.jboss.org>
> Message-ID:
>         <CACLE=
> 7MzVcBrhnoeUpo6ZAMpDu_04SOWSttWc-hRJL4wm8vpDw at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> @Antonio: spring and guice have events, they just dont work the same way
> CDI defined them but not a big deal IMO to support them (just one more
> processor for spring for instance).
>
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> <http://www.tomitribe.com>
>
> 2015-08-31 9:57 GMT+02:00 Antonio Goncalves <antonio.goncalves at gmail.com>:
>
> > I don't see Events in a "Lite" version because the other DI frameworks
> > don't use them. A "fatter" 330 with producers, programmatic lookup and
> > bootstrap, could be "easily" implemented by Spring, Guice... If we leave
> > events in a Lite version, then it won't be the case, and Weld and OWB
> will
> > be the only two implementations.
> >
> > For me, a Lite version would just be about DI. If Weld uses events
> > internally to archieve basic DI, well, it's just an implementation
> > decision, not a spec. I would not even try to standardize the way @Inject
> > works (like Romain said, @Inject doesn't work the same in Weld or
> Spring),
> > let's leave it like this. If you take back Antoine sentence "*This would
> > allow using CDI in constrained environment like mobile or embedded
> devices*",
> > then I don't think events would fit here.
> >
> > Antonio
> >
> > On Mon, Aug 31, 2015 at 8:25 AM, Mark Struberg <struberg at yahoo.de>
> wrote:
> >
> >> > For me, a Light version of CDI is clearly the features number. That's
> >> why I don't see events in it.
> >>
> >> We did discuss this last year on the f2f meeting. The problem lies
> within
> >> our Extension mechanism. Without events you also need to drop the
> Extension
> >> mechanism. And to be honest, this is THE major hit in all CDI?
> >> Sorry to be the bad guy busting all those ideas. I really don?t want to,
> >> but better now than too late down the road ;)
> >>
> >> It?s really tricky as many features are heavily based on each other.
> E.g.
> >> by removing scanning you could get rid of javassist/asm/etc ? nope, we
> also
> >> have our class proxies which need bytecode tinkering. So remove
> >> interceptors and decorators too? Well yea, but we still have
> normalscoping
> >> -> what is left? basically spring prototype and singleton. Hmm.  that?s
> not
> >> that much compared to full CDI. And all that for only 200kByte?
> >> (Btw we also discussed generating the bytecode classes at build time,
> but
> >> then we still miss the dynamics we get from Extensions, e.g. PAT adding
> an
> >> interceptor annotation)
> >> Just to give you a rough idea how this all works together when it comes
> >> to implementation details?
> >> Please feel free to ask Jozef and me for further infos on
> ?dependencies?.
> >>
> >> LieGrue,
> >> strub
> >>
> >>
> >> > Am 30.08.2015 um 18:09 schrieb Antonio Goncalves <
> >> antonio.goncalves at gmail.com>:
> >> >
> >> > For me, a Light version of CDI is clearly the features number. That's
> >> why I don't see events in it.
> >> >
> >> > For me, a CDI Lite would just focus on DI. If CDI has @Produces and
> >> Spring has @Bean, then it's because 330 lakes this functionality.
> >> >
> >> > On Sun, Aug 30, 2015 at 4:02 PM, Romain Manni-Bucau <
> >> rmannibucau at gmail.com> wrote:
> >> > Lite can have several definition, let's try to list them up if it can
> >> help:
> >> >
> >> > - binary size: for me until 3M for an app it is "Lite"
> >> > - features number: the whole IoC set of feature is light since you
> >> almost always need it, it means you can do lighter but it wouldnt be
> used -
> >> check spring, who uses only spring-ioc and not context or more?
> >> > - features complexity: sure we are not light here but supporting
> scopes
> >> already breaks "Lite-ness" IMO so not a real issue
> >> >
> >> > So my view is CDI "SE" is light enough - as a spec and spec can't
> >> affect implementations so seems the fight is not on the right side to
> me.
> >> >
> >> >
> >> >
> >> > Romain Manni-Bucau
> >> > @rmannibucau |  Blog | Github | LinkedIn | Tomitriber
> >> >
> >> > 2015-08-30 15:57 GMT+02:00 Antonio Goncalves <
> >> antonio.goncalves at gmail.com>:
> >> > It's funny, I feel I'm in Rod Johnson shoes back in Java EE 6 where he
> >> forked 330 because he found CDI was doing too much  ;o)
> >> >
> >> > For me, "CDI Lite" was just basic dependency injection. The fact that
> >> CDI can now run on SE (like JPA....), is good... but for me it has
> nothing
> >> to do with Light : it's the entire thing that can bootstrap in SE. Good.
> >> >
> >> > So what is Lite for you guys ?
> >> >
> >> > Antonio
> >> >
> >> > On Sun, Aug 30, 2015 at 3:44 PM, Romain Manni-Bucau <
> >> rmannibucau at gmail.com> wrote:
> >> > 2015-08-30 15:22 GMT+02:00 John D. Ament <john.d.ament at gmail.com>:
> >> > Personally, I'm not in favor of a slimmed down runtime.  It was tried
> >> with EJB, but never implemented properly (most implementations that
> support
> >> EJB-lite actually support the entire thing, except for deprecated
> stuff).
> >> >
> >> >
> >> > +1, most of CDI is basic and quickly any light version will miss
> events
> >> or other thing - in particular in maintaining micro services from
> >> experience. Size of an implementation can easily be < 1M so not sure it
> >> would bring anything. Only important point is what Antoine started to
> do ie
> >> ensuring EE and SE parts are clearly identified and split in the spec.
> >> >
> >> > I think if we define SE properly we won't have a need for this.
> >> >
> >> > John
> >> >
> >> > On Sun, Aug 30, 2015 at 8:07 AM Antonio Goncalves <
> >> antonio.goncalves at gmail.com> wrote:
> >> > @Antoine, so which content do you see in CDI Lite ? Are you sure about
> >> events ?
> >> >
> >> > I'm in favor of a "fatter" 330 that would have :
> >> >       ? @Inject : already there
> >> >       ? @Qualifier : already there
> >> >       ? Producers and disposers
> >> >       ? Programatic lookup
> >> >       ? Java SE Bootstrap
> >> > When you say "The goal here is not to propose a new EE profile but a
> >> subspec", 330 could already be seen as a subspec. If you put events
> >> apparts, what would be missing in this list in your point of view ? And
> >> what obstacles do you see in archieving this ?
> >> >
> >> > To boostrap CDI we have a CDIProvider, why not having an
> >> InjectionProvider just to bootstrap 330 (then, CDIProvider could extend
> >> InjectionProvider, so it bootstraps the all thing) ?
> >> >
> >> > Antonio
> >> >
> >> > On Sun, Aug 30, 2015 at 9:09 AM, Antoine Sabot-Durand <
> >> antoine at sabot-durand.net> wrote:
> >> > Yes Arjan, I think it's the first reason. We really should work with
> >> them to understand what should be added to CDI 2.0 to have it as a first
> >> citizen DI in their spec.
> >> >
> >> > Le sam. 29 ao?t 2015 ? 23:15, arjan tijms <arjan.tijms at gmail.com> a
> >> ?crit :
> >> > On Sat, Aug 29, 2015 at 8:45 PM, Antonio Goncalves
> >> > <antonio.goncalves at gmail.com> wrote:
> >> > > I remember talking with the JAX-RS guys (Java EE), years ago (back
> in
> >> EE6),
> >> > > and their answer for not adopting CDI was "too heavy".
> >> >
> >> > I can't find an exact reference anymore, but I somewhat remember that
> >> > one of the reasons was also simply that CDI as a general solution
> >> > finished late in Java EE 6, while JAX-RS finished earlier and had all
> >> > the work for their own DI solution already done.
> >> >
> >> >
> >> >
> >> > --
> >> > Antonio Goncalves
> >> > Software architect, Java Champion and Pluralsight author
> >> >
> >> > Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx
> France
> >> > _______________________________________________
> >> > 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.
> >> >
> >> >
> >> >
> >> >
> >> > --
> >> > Antonio Goncalves
> >> > Software architect, Java Champion and Pluralsight author
> >> >
> >> > Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx
> France
> >> >
> >> >
> >> >
> >> >
> >> > --
> >> > Antonio Goncalves
> >> > Software architect, Java Champion and Pluralsight author
> >> >
> >> > Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx
> France
> >> > _______________________________________________
> >> > 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.
> >>
> >>
> >
> >
> > --
> > Antonio Goncalves
> > Software architect, Java Champion and Pluralsight author
> >
> > Web site <http://www.antoniogoncalves.org> | Twitter
> > <http://twitter.com/agoncal> | LinkedIn
> > <http://www.linkedin.com/in/agoncal> | Pluralsight
> > <http://pluralsight.com/training/Authors/Details/antonio-goncalves> |
> Paris
> > JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr>
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20150831/4d1b9468/attachment-0001.html
>
> ------------------------------
>
> Message: 2
> Date: Mon, 31 Aug 2015 10:11:54 +0200
> From: Martin Kouba <mkouba at redhat.com>
> Subject: Re: [cdi-dev] Time to start working on CDI lite
> To: Antonio Goncalves <antonio.goncalves at gmail.com>,    Mark Struberg
>         <struberg at yahoo.de>
> Cc: cdi-dev <cdi-dev at lists.jboss.org>
> Message-ID: <55E40C4A.4090905 at redhat.com>
> Content-Type: text/plain; charset=windows-1252; format=flowed
>
> Dne 31.8.2015 v 09:57 Antonio Goncalves napsal(a):
> > I don't see Events in a "Lite" version because the other DI frameworks
> > don't use them. A "fatter" 330 with producers, programmatic lookup and
> > bootstrap, could be "easily" implemented by Spring, Guice... If we leave
> > events in a Lite version, then it won't be the case, and Weld and OWB
> > will be the only two implementations.
> >
> > For me, a Lite version would just be about DI. If Weld uses events
> > internally to archieve basic DI, well, it's just an implementation
> > decision, not a spec. I would not even try to standardize the way
> > @Inject works (like Romain said, @Inject doesn't work the same in Weld
> > or Spring), let's leave it like this.
>
> If you don't standardize how @Inject works then what's the purpose of
> having something like CDI Lite and many implementations which work
> differently? A user of implementation "A" will not be able to switch to
> implementation "B" easily. And that's one of the most important benefits
> of standardization...
>
> If you take back Antoine sentence
> > "/This would allow using CDI in constrained environment like mobile or
> > embedded devices/", then I don't think events would fit here.
> >
> > Antonio
> >
> > On Mon, Aug 31, 2015 at 8:25 AM, Mark Struberg <struberg at yahoo.de
> > <mailto:struberg at yahoo.de>> wrote:
> >
> >     > For me, a Light version of CDI is clearly the features number.
> That's why I don't see events in it.
> >
> >     We did discuss this last year on the f2f meeting. The problem lies
> >     within our Extension mechanism. Without events you also need to drop
> >     the Extension mechanism. And to be honest, this is THE major hit in
> >     all CDI?
> >     Sorry to be the bad guy busting all those ideas. I really don?t want
> >     to, but better now than too late down the road ;)
> >
> >     It?s really tricky as many features are heavily based on each other.
> >     E.g. by removing scanning you could get rid of javassist/asm/etc ?
> >     nope, we also have our class proxies which need bytecode tinkering.
> >     So remove interceptors and decorators too? Well yea, but we still
> >     have normalscoping -> what is left? basically spring prototype and
> >     singleton. Hmm.  that?s not that much compared to full CDI. And all
> >     that for only 200kByte?
> >     (Btw we also discussed generating the bytecode classes at build
> >     time, but then we still miss the dynamics we get from Extensions,
> >     e.g. PAT adding an interceptor annotation)
> >     Just to give you a rough idea how this all works together when it
> >     comes to implementation details?
> >     Please feel free to ask Jozef and me for further infos on
> >     ?dependencies?.
> >
> >     LieGrue,
> >     strub
> >
> >
> >      > Am 30.08.2015 um 18:09 schrieb Antonio Goncalves
> >     <antonio.goncalves at gmail.com <mailto:antonio.goncalves at gmail.com>>:
> >      >
> >      > For me, a Light version of CDI is clearly the features number.
> >     That's why I don't see events in it.
> >      >
> >      > For me, a CDI Lite would just focus on DI. If CDI has @Produces
> >     and Spring has @Bean, then it's because 330 lakes this functionality.
> >      >
> >      > On Sun, Aug 30, 2015 at 4:02 PM, Romain Manni-Bucau
> >     <rmannibucau at gmail.com <mailto:rmannibucau at gmail.com>> wrote:
> >      > Lite can have several definition, let's try to list them up if it
> >     can help:
> >      >
> >      > - binary size: for me until 3M for an app it is "Lite"
> >      > - features number: the whole IoC set of feature is light since
> >     you almost always need it, it means you can do lighter but it
> >     wouldnt be used - check spring, who uses only spring-ioc and not
> >     context or more?
> >      > - features complexity: sure we are not light here but supporting
> >     scopes already breaks "Lite-ness" IMO so not a real issue
> >      >
> >      > So my view is CDI "SE" is light enough - as a spec and spec can't
> >     affect implementations so seems the fight is not on the right side
> >     to me.
> >      >
> >      >
> >      >
> >      > Romain Manni-Bucau
> >      > @rmannibucau |  Blog | Github | LinkedIn | Tomitriber
> >      >
> >      > 2015-08-30 15:57 GMT+02:00 Antonio Goncalves
> >     <antonio.goncalves at gmail.com <mailto:antonio.goncalves at gmail.com>>:
> >      > It's funny, I feel I'm in Rod Johnson shoes back in Java EE 6
> >     where he forked 330 because he found CDI was doing too much  ;o)
> >      >
> >      > For me, "CDI Lite" was just basic dependency injection. The fact
> >     that CDI can now run on SE (like JPA....), is good... but for me it
> >     has nothing to do with Light : it's the entire thing that can
> >     bootstrap in SE. Good.
> >      >
> >      > So what is Lite for you guys ?
> >      >
> >      > Antonio
> >      >
> >      > On Sun, Aug 30, 2015 at 3:44 PM, Romain Manni-Bucau
> >     <rmannibucau at gmail.com <mailto:rmannibucau at gmail.com>> wrote:
> >      > 2015-08-30 15:22 GMT+02:00 John D. Ament <john.d.ament at gmail.com
> >     <mailto:john.d.ament at gmail.com>>:
> >      > Personally, I'm not in favor of a slimmed down runtime.  It was
> >     tried with EJB, but never implemented properly (most implementations
> >     that support EJB-lite actually support the entire thing, except for
> >     deprecated stuff).
> >      >
> >      >
> >      > +1, most of CDI is basic and quickly any light version will miss
> >     events or other thing - in particular in maintaining micro services
> >     from experience. Size of an implementation can easily be < 1M so not
> >     sure it would bring anything. Only important point is what Antoine
> >     started to do ie ensuring EE and SE parts are clearly identified and
> >     split in the spec.
> >      >
> >      > I think if we define SE properly we won't have a need for this.
> >      >
> >      > John
> >      >
> >      > On Sun, Aug 30, 2015 at 8:07 AM Antonio Goncalves
> >     <antonio.goncalves at gmail.com <mailto:antonio.goncalves at gmail.com>>
> >     wrote:
> >      > @Antoine, so which content do you see in CDI Lite ? Are you sure
> >     about events ?
> >      >
> >      > I'm in favor of a "fatter" 330 that would have :
> >      >       ? @Inject : already there
> >      >       ? @Qualifier : already there
> >      >       ? Producers and disposers
> >      >       ? Programatic lookup
> >      >       ? Java SE Bootstrap
> >      > When you say "The goal here is not to propose a new EE profile
> >     but a subspec", 330 could already be seen as a subspec. If you put
> >     events apparts, what would be missing in this list in your point of
> >     view ? And what obstacles do you see in archieving this ?
> >      >
> >      > To boostrap CDI we have a CDIProvider, why not having an
> >     InjectionProvider just to bootstrap 330 (then, CDIProvider could
> >     extend InjectionProvider, so it bootstraps the all thing) ?
> >      >
> >      > Antonio
> >      >
> >      > On Sun, Aug 30, 2015 at 9:09 AM, Antoine Sabot-Durand
> >     <antoine at sabot-durand.net <mailto:antoine at sabot-durand.net>> wrote:
> >      > Yes Arjan, I think it's the first reason. We really should work
> >     with them to understand what should be added to CDI 2.0 to have it
> >     as a first citizen DI in their spec.
> >      >
> >      > Le sam. 29 ao?t 2015 ? 23:15, arjan tijms <arjan.tijms at gmail.com
> >     <mailto:arjan.tijms at gmail.com>> a ?crit :
> >      > On Sat, Aug 29, 2015 at 8:45 PM, Antonio Goncalves
> >      > <antonio.goncalves at gmail.com
> >     <mailto:antonio.goncalves at gmail.com>> wrote:
> >      > > I remember talking with the JAX-RS guys (Java EE), years ago
> >     (back in EE6),
> >      > > and their answer for not adopting CDI was "too heavy".
> >      >
> >      > I can't find an exact reference anymore, but I somewhat remember
> that
> >      > one of the reasons was also simply that CDI as a general solution
> >      > finished late in Java EE 6, while JAX-RS finished earlier and had
> all
> >      > the work for their own DI solution already done.
> >      >
> >      >
> >      >
> >      > --
> >      > Antonio Goncalves
> >      > Software architect, Java Champion and Pluralsight author
> >      >
> >      > Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx
> >     France
> >      > _______________________________________________
> >      > cdi-dev mailing list
> >      > cdi-dev at lists.jboss.org <mailto: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 <mailto: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.
> >      >
> >      >
> >      >
> >      >
> >      > --
> >      > Antonio Goncalves
> >      > Software architect, Java Champion and Pluralsight author
> >      >
> >      > Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx
> >     France
> >      >
> >      >
> >      >
> >      >
> >      > --
> >      > Antonio Goncalves
> >      > Software architect, Java Champion and Pluralsight author
> >      >
> >      > Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx
> >     France
> >      > _______________________________________________
> >      > cdi-dev mailing list
> >      > cdi-dev at lists.jboss.org <mailto: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.
> >
> >
> >
> >
> > --
> > Antonio Goncalves
> > Software architect, Java Champion and Pluralsight author
> >
> > Web site <http://www.antoniogoncalves.org> | Twitter
> > <http://twitter.com/agoncal> | LinkedIn
> > <http://www.linkedin.com/in/agoncal> | Pluralsight
> > <http://pluralsight.com/training/Authors/Details/antonio-goncalves> |
> > Paris JUG <http://www.parisjug.org> | Devoxx France <
> http://www.devoxx.fr>
> >
> >
> > _______________________________________________
> > 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.
>
> End of cdi-dev Digest, Vol 57, Issue 43
> ***************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150831/8b8b1b7d/attachment-0001.html 

From antonio.goncalves at gmail.com  Mon Aug 31 04:28:04 2015
From: antonio.goncalves at gmail.com (Antonio Goncalves)
Date: Mon, 31 Aug 2015 10:28:04 +0200
Subject: [cdi-dev] Time to start working on CDI lite
In-Reply-To: <55E40C4A.4090905@redhat.com>
References: <CABu-YBQvgrVZcH31i+Uw9ZefsTZvLHJ4919PW=vnvRBa2RVoTQ@mail.gmail.com>
	<CA+ZZq9_C_nTH1YY1uNYnH2aW6RBBR7+xH9ZF+cduMhzOQHOO8g@mail.gmail.com>
	<CAE=-AhDa84QjHqwNLJD3+a1f2mD2d+Y_2kwqRVqzBRkuvf4Qfw@mail.gmail.com>
	<CABu-YBQ9ZtUdSj6LUoROz2-JuqROtLTG1UKUSANOY4kiVHpTDg@mail.gmail.com>
	<CA+ZZq9-RW68R+o1c3n5J6KSGtki+o+89SvTpovSFL5ZKq6BTWQ@mail.gmail.com>
	<CAOqetn_Afc0BfGPcSRBQiKuvtOfZnQKzxHv59KhbJfLTGKoH4w@mail.gmail.com>
	<CACLE=7MmgSVukPrN-fiu959w1zv7hj19VikGx-4JzA2mTRVG-w@mail.gmail.com>
	<CA+ZZq99XKDbwnqLPi-j4rcizU9EcuNzjsJTHo+Qy_djjtMCy_Q@mail.gmail.com>
	<CACLE=7Mu5mMB3tFWLtPxNXRpKrR82xKku5saFB9it3n-8RU1aQ@mail.gmail.com>
	<CA+ZZq9-YFcTKuZr=+6v=wH-w670E++qgBrN36DsToFEidUzenQ@mail.gmail.com>
	<47B00263-144C-4B41-A1F7-73176012C22F@yahoo.de>
	<CA+ZZq99QchL8uZY_E8=kWetNEHiUGJV+T=GBS8W0doRf7S-Kiw@mail.gmail.com>
	<55E40C4A.4090905@redhat.com>
Message-ID: <CA+ZZq9-76Q8nug_q-uJmGTuxC9imzc9My2YHLHf7JoRmNZRCfA@mail.gmail.com>

The way @Inject works is not specified in 330, and it's better to leave it
like this, otherwise we will loose Spring and Guice as implementations.

Antonio

On Mon, Aug 31, 2015 at 10:11 AM, Martin Kouba <mkouba at redhat.com> wrote:

> Dne 31.8.2015 v 09:57 Antonio Goncalves napsal(a):
>
>> I don't see Events in a "Lite" version because the other DI frameworks
>> don't use them. A "fatter" 330 with producers, programmatic lookup and
>> bootstrap, could be "easily" implemented by Spring, Guice... If we leave
>> events in a Lite version, then it won't be the case, and Weld and OWB
>> will be the only two implementations.
>>
>> For me, a Lite version would just be about DI. If Weld uses events
>> internally to archieve basic DI, well, it's just an implementation
>> decision, not a spec. I would not even try to standardize the way
>> @Inject works (like Romain said, @Inject doesn't work the same in Weld
>> or Spring), let's leave it like this.
>>
>
> If you don't standardize how @Inject works then what's the purpose of
> having something like CDI Lite and many implementations which work
> differently? A user of implementation "A" will not be able to switch to
> implementation "B" easily. And that's one of the most important benefits of
> standardization...
>
> If you take back Antoine sentence
>
>> "/This would allow using CDI in constrained environment like mobile or
>> embedded devices/", then I don't think events would fit here.
>>
>> Antonio
>>
>> On Mon, Aug 31, 2015 at 8:25 AM, Mark Struberg <struberg at yahoo.de
>> <mailto:struberg at yahoo.de>> wrote:
>>
>>     > For me, a Light version of CDI is clearly the features number.
>> That's why I don't see events in it.
>>
>>     We did discuss this last year on the f2f meeting. The problem lies
>>     within our Extension mechanism. Without events you also need to drop
>>     the Extension mechanism. And to be honest, this is THE major hit in
>>     all CDI?
>>     Sorry to be the bad guy busting all those ideas. I really don?t want
>>     to, but better now than too late down the road ;)
>>
>>     It?s really tricky as many features are heavily based on each other.
>>     E.g. by removing scanning you could get rid of javassist/asm/etc ?
>>     nope, we also have our class proxies which need bytecode tinkering.
>>     So remove interceptors and decorators too? Well yea, but we still
>>     have normalscoping -> what is left? basically spring prototype and
>>     singleton. Hmm.  that?s not that much compared to full CDI. And all
>>     that for only 200kByte?
>>     (Btw we also discussed generating the bytecode classes at build
>>     time, but then we still miss the dynamics we get from Extensions,
>>     e.g. PAT adding an interceptor annotation)
>>     Just to give you a rough idea how this all works together when it
>>     comes to implementation details?
>>     Please feel free to ask Jozef and me for further infos on
>>     ?dependencies?.
>>
>>     LieGrue,
>>     strub
>>
>>
>>      > Am 30.08.2015 um 18:09 schrieb Antonio Goncalves
>>     <antonio.goncalves at gmail.com <mailto:antonio.goncalves at gmail.com>>:
>>      >
>>      > For me, a Light version of CDI is clearly the features number.
>>     That's why I don't see events in it.
>>      >
>>      > For me, a CDI Lite would just focus on DI. If CDI has @Produces
>>     and Spring has @Bean, then it's because 330 lakes this functionality.
>>      >
>>      > On Sun, Aug 30, 2015 at 4:02 PM, Romain Manni-Bucau
>>     <rmannibucau at gmail.com <mailto:rmannibucau at gmail.com>> wrote:
>>      > Lite can have several definition, let's try to list them up if it
>>     can help:
>>      >
>>      > - binary size: for me until 3M for an app it is "Lite"
>>      > - features number: the whole IoC set of feature is light since
>>     you almost always need it, it means you can do lighter but it
>>     wouldnt be used - check spring, who uses only spring-ioc and not
>>     context or more?
>>      > - features complexity: sure we are not light here but supporting
>>     scopes already breaks "Lite-ness" IMO so not a real issue
>>      >
>>      > So my view is CDI "SE" is light enough - as a spec and spec can't
>>     affect implementations so seems the fight is not on the right side
>>     to me.
>>      >
>>      >
>>      >
>>      > Romain Manni-Bucau
>>      > @rmannibucau |  Blog | Github | LinkedIn | Tomitriber
>>      >
>>      > 2015-08-30 15:57 GMT+02:00 Antonio Goncalves
>>     <antonio.goncalves at gmail.com <mailto:antonio.goncalves at gmail.com>>:
>>      > It's funny, I feel I'm in Rod Johnson shoes back in Java EE 6
>>     where he forked 330 because he found CDI was doing too much  ;o)
>>      >
>>      > For me, "CDI Lite" was just basic dependency injection. The fact
>>     that CDI can now run on SE (like JPA....), is good... but for me it
>>     has nothing to do with Light : it's the entire thing that can
>>     bootstrap in SE. Good.
>>      >
>>      > So what is Lite for you guys ?
>>      >
>>      > Antonio
>>      >
>>      > On Sun, Aug 30, 2015 at 3:44 PM, Romain Manni-Bucau
>>     <rmannibucau at gmail.com <mailto:rmannibucau at gmail.com>> wrote:
>>      > 2015-08-30 15:22 GMT+02:00 John D. Ament <john.d.ament at gmail.com
>>     <mailto:john.d.ament at gmail.com>>:
>>      > Personally, I'm not in favor of a slimmed down runtime.  It was
>>     tried with EJB, but never implemented properly (most implementations
>>     that support EJB-lite actually support the entire thing, except for
>>     deprecated stuff).
>>      >
>>      >
>>      > +1, most of CDI is basic and quickly any light version will miss
>>     events or other thing - in particular in maintaining micro services
>>     from experience. Size of an implementation can easily be < 1M so not
>>     sure it would bring anything. Only important point is what Antoine
>>     started to do ie ensuring EE and SE parts are clearly identified and
>>     split in the spec.
>>      >
>>      > I think if we define SE properly we won't have a need for this.
>>      >
>>      > John
>>      >
>>      > On Sun, Aug 30, 2015 at 8:07 AM Antonio Goncalves
>>     <antonio.goncalves at gmail.com <mailto:antonio.goncalves at gmail.com>>
>>     wrote:
>>      > @Antoine, so which content do you see in CDI Lite ? Are you sure
>>     about events ?
>>      >
>>      > I'm in favor of a "fatter" 330 that would have :
>>      >       ? @Inject : already there
>>      >       ? @Qualifier : already there
>>      >       ? Producers and disposers
>>      >       ? Programatic lookup
>>      >       ? Java SE Bootstrap
>>      > When you say "The goal here is not to propose a new EE profile
>>     but a subspec", 330 could already be seen as a subspec. If you put
>>     events apparts, what would be missing in this list in your point of
>>     view ? And what obstacles do you see in archieving this ?
>>      >
>>      > To boostrap CDI we have a CDIProvider, why not having an
>>     InjectionProvider just to bootstrap 330 (then, CDIProvider could
>>     extend InjectionProvider, so it bootstraps the all thing) ?
>>      >
>>      > Antonio
>>      >
>>      > On Sun, Aug 30, 2015 at 9:09 AM, Antoine Sabot-Durand
>>     <antoine at sabot-durand.net <mailto:antoine at sabot-durand.net>> wrote:
>>      > Yes Arjan, I think it's the first reason. We really should work
>>     with them to understand what should be added to CDI 2.0 to have it
>>     as a first citizen DI in their spec.
>>      >
>>      > Le sam. 29 ao?t 2015 ? 23:15, arjan tijms <arjan.tijms at gmail.com
>>     <mailto:arjan.tijms at gmail.com>> a ?crit :
>>      > On Sat, Aug 29, 2015 at 8:45 PM, Antonio Goncalves
>>      > <antonio.goncalves at gmail.com
>>     <mailto:antonio.goncalves at gmail.com>> wrote:
>>      > > I remember talking with the JAX-RS guys (Java EE), years ago
>>     (back in EE6),
>>      > > and their answer for not adopting CDI was "too heavy".
>>      >
>>      > I can't find an exact reference anymore, but I somewhat remember
>> that
>>      > one of the reasons was also simply that CDI as a general solution
>>      > finished late in Java EE 6, while JAX-RS finished earlier and had
>> all
>>      > the work for their own DI solution already done.
>>      >
>>      >
>>      >
>>      > --
>>      > Antonio Goncalves
>>      > Software architect, Java Champion and Pluralsight author
>>      >
>>      > Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx
>>     France
>>      > _______________________________________________
>>      > cdi-dev mailing list
>>      > cdi-dev at lists.jboss.org <mailto: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 <mailto: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.
>>      >
>>      >
>>      >
>>      >
>>      > --
>>      > Antonio Goncalves
>>      > Software architect, Java Champion and Pluralsight author
>>      >
>>      > Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx
>>     France
>>      >
>>      >
>>      >
>>      >
>>      > --
>>      > Antonio Goncalves
>>      > Software architect, Java Champion and Pluralsight author
>>      >
>>      > Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx
>>     France
>>      > _______________________________________________
>>      > cdi-dev mailing list
>>      > cdi-dev at lists.jboss.org <mailto: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.
>>
>>
>>
>>
>> --
>> Antonio Goncalves
>> Software architect, Java Champion and Pluralsight author
>>
>> Web site <http://www.antoniogoncalves.org> | Twitter
>> <http://twitter.com/agoncal> | LinkedIn
>> <http://www.linkedin.com/in/agoncal> | Pluralsight
>> <http://pluralsight.com/training/Authors/Details/antonio-goncalves> |
>> Paris JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr
>> >
>>
>>
>> _______________________________________________
>> 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
>



-- 
Antonio Goncalves
Software architect, Java Champion and Pluralsight author

Web site <http://www.antoniogoncalves.org> | Twitter
<http://twitter.com/agoncal> | LinkedIn <http://www.linkedin.com/in/agoncal> |
Pluralsight
<http://pluralsight.com/training/Authors/Details/antonio-goncalves> | Paris
JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150831/639a074c/attachment-0001.html 

From werner.keil at gmail.com  Mon Aug 31 05:03:19 2015
From: werner.keil at gmail.com (Werner Keil)
Date: Mon, 31 Aug 2015 11:03:19 +0200
Subject: [cdi-dev] Time to start working on CDI lite
Message-ID: <CAAGawe26TvTTXRBZ26217eM=2iGx616FfKBVkBN37hXyiOBvkQ@mail.gmail.com>

Unless CDI 2 still ended up redefining the @Inject (aka JSR 330) standard
at least as MR, there is no change of that spec. So if it is free for
implementations to decide how @Inject works or if some (like Tapestry)
prefer their own parallel @Inject annotations side-by-side, that won't
change with a "CDI lite" profile or module.

Werner

On Mon, Aug 31, 2015 at 10:28 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: Time to start working on CDI lite (Antonio Goncalves)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 31 Aug 2015 10:28:04 +0200
> From: Antonio Goncalves <antonio.goncalves at gmail.com>
> Subject: Re: [cdi-dev] Time to start working on CDI lite
> To: Martin Kouba <mkouba at redhat.com>
> Cc: cdi-dev <cdi-dev at lists.jboss.org>
> Message-ID:
>         <
> CA+ZZq9-76Q8nug_q-uJmGTuxC9imzc9My2YHLHf7JoRmNZRCfA at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> The way @Inject works is not specified in 330, and it's better to leave it
> like this, otherwise we will loose Spring and Guice as implementations.
>
> Antonio
>
> On Mon, Aug 31, 2015 at 10:11 AM, Martin Kouba <mkouba at redhat.com> wrote:
>
> > Dne 31.8.2015 v 09:57 Antonio Goncalves napsal(a):
> >
> >> I don't see Events in a "Lite" version because the other DI frameworks
> >> don't use them. A "fatter" 330 with producers, programmatic lookup and
> >> bootstrap, could be "easily" implemented by Spring, Guice... If we leave
> >> events in a Lite version, then it won't be the case, and Weld and OWB
> >> will be the only two implementations.
> >>
> >> For me, a Lite version would just be about DI. If Weld uses events
> >> internally to archieve basic DI, well, it's just an implementation
> >> decision, not a spec. I would not even try to standardize the way
> >> @Inject works (like Romain said, @Inject doesn't work the same in Weld
> >> or Spring), let's leave it like this.
> >>
> >
> > If you don't standardize how @Inject works then what's the purpose of
> > having something like CDI Lite and many implementations which work
> > differently? A user of implementation "A" will not be able to switch to
> > implementation "B" easily. And that's one of the most important benefits
> of
> > standardization...
> >
> > If you take back Antoine sentence
> >
> >> "/This would allow using CDI in constrained environment like mobile or
> >> embedded devices/", then I don't think events would fit here.
> >>
> >> Antonio
> >>
> >> On Mon, Aug 31, 2015 at 8:25 AM, Mark Struberg <struberg at yahoo.de
> >> <mailto:struberg at yahoo.de>> wrote:
> >>
> >>     > For me, a Light version of CDI is clearly the features number.
> >> That's why I don't see events in it.
> >>
> >>     We did discuss this last year on the f2f meeting. The problem lies
> >>     within our Extension mechanism. Without events you also need to drop
> >>     the Extension mechanism. And to be honest, this is THE major hit in
> >>     all CDI?
> >>     Sorry to be the bad guy busting all those ideas. I really don?t want
> >>     to, but better now than too late down the road ;)
> >>
> >>     It?s really tricky as many features are heavily based on each other.
> >>     E.g. by removing scanning you could get rid of javassist/asm/etc ?
> >>     nope, we also have our class proxies which need bytecode tinkering.
> >>     So remove interceptors and decorators too? Well yea, but we still
> >>     have normalscoping -> what is left? basically spring prototype and
> >>     singleton. Hmm.  that?s not that much compared to full CDI. And all
> >>     that for only 200kByte?
> >>     (Btw we also discussed generating the bytecode classes at build
> >>     time, but then we still miss the dynamics we get from Extensions,
> >>     e.g. PAT adding an interceptor annotation)
> >>     Just to give you a rough idea how this all works together when it
> >>     comes to implementation details?
> >>     Please feel free to ask Jozef and me for further infos on
> >>     ?dependencies?.
> >>
> >>     LieGrue,
> >>     strub
> >>
> >>
> >>      > Am 30.08.2015 um 18:09 schrieb Antonio Goncalves
> >>     <antonio.goncalves at gmail.com <mailto:antonio.goncalves at gmail.com>>:
> >>      >
> >>      > For me, a Light version of CDI is clearly the features number.
> >>     That's why I don't see events in it.
> >>      >
> >>      > For me, a CDI Lite would just focus on DI. If CDI has @Produces
> >>     and Spring has @Bean, then it's because 330 lakes this
> functionality.
> >>      >
> >>      > On Sun, Aug 30, 2015 at 4:02 PM, Romain Manni-Bucau
> >>     <rmannibucau at gmail.com <mailto:rmannibucau at gmail.com>> wrote:
> >>      > Lite can have several definition, let's try to list them up if it
> >>     can help:
> >>      >
> >>      > - binary size: for me until 3M for an app it is "Lite"
> >>      > - features number: the whole IoC set of feature is light since
> >>     you almost always need it, it means you can do lighter but it
> >>     wouldnt be used - check spring, who uses only spring-ioc and not
> >>     context or more?
> >>      > - features complexity: sure we are not light here but supporting
> >>     scopes already breaks "Lite-ness" IMO so not a real issue
> >>      >
> >>      > So my view is CDI "SE" is light enough - as a spec and spec can't
> >>     affect implementations so seems the fight is not on the right side
> >>     to me.
> >>      >
> >>      >
> >>      >
> >>      > Romain Manni-Bucau
> >>      > @rmannibucau |  Blog | Github | LinkedIn | Tomitriber
> >>      >
> >>      > 2015-08-30 15:57 GMT+02:00 Antonio Goncalves
> >>     <antonio.goncalves at gmail.com <mailto:antonio.goncalves at gmail.com>>:
> >>      > It's funny, I feel I'm in Rod Johnson shoes back in Java EE 6
> >>     where he forked 330 because he found CDI was doing too much  ;o)
> >>      >
> >>      > For me, "CDI Lite" was just basic dependency injection. The fact
> >>     that CDI can now run on SE (like JPA....), is good... but for me it
> >>     has nothing to do with Light : it's the entire thing that can
> >>     bootstrap in SE. Good.
> >>      >
> >>      > So what is Lite for you guys ?
> >>      >
> >>      > Antonio
> >>      >
> >>      > On Sun, Aug 30, 2015 at 3:44 PM, Romain Manni-Bucau
> >>     <rmannibucau at gmail.com <mailto:rmannibucau at gmail.com>> wrote:
> >>      > 2015-08-30 15:22 GMT+02:00 John D. Ament <john.d.ament at gmail.com
> >>     <mailto:john.d.ament at gmail.com>>:
> >>      > Personally, I'm not in favor of a slimmed down runtime.  It was
> >>     tried with EJB, but never implemented properly (most implementations
> >>     that support EJB-lite actually support the entire thing, except for
> >>     deprecated stuff).
> >>      >
> >>      >
> >>      > +1, most of CDI is basic and quickly any light version will miss
> >>     events or other thing - in particular in maintaining micro services
> >>     from experience. Size of an implementation can easily be < 1M so not
> >>     sure it would bring anything. Only important point is what Antoine
> >>     started to do ie ensuring EE and SE parts are clearly identified and
> >>     split in the spec.
> >>      >
> >>      > I think if we define SE properly we won't have a need for this.
> >>      >
> >>      > John
> >>      >
> >>      > On Sun, Aug 30, 2015 at 8:07 AM Antonio Goncalves
> >>     <antonio.goncalves at gmail.com <mailto:antonio.goncalves at gmail.com>>
> >>     wrote:
> >>      > @Antoine, so which content do you see in CDI Lite ? Are you sure
> >>     about events ?
> >>      >
> >>      > I'm in favor of a "fatter" 330 that would have :
> >>      >       ? @Inject : already there
> >>      >       ? @Qualifier : already there
> >>      >       ? Producers and disposers
> >>      >       ? Programatic lookup
> >>      >       ? Java SE Bootstrap
> >>      > When you say "The goal here is not to propose a new EE profile
> >>     but a subspec", 330 could already be seen as a subspec. If you put
> >>     events apparts, what would be missing in this list in your point of
> >>     view ? And what obstacles do you see in archieving this ?
> >>      >
> >>      > To boostrap CDI we have a CDIProvider, why not having an
> >>     InjectionProvider just to bootstrap 330 (then, CDIProvider could
> >>     extend InjectionProvider, so it bootstraps the all thing) ?
> >>      >
> >>      > Antonio
> >>      >
> >>      > On Sun, Aug 30, 2015 at 9:09 AM, Antoine Sabot-Durand
> >>     <antoine at sabot-durand.net <mailto:antoine at sabot-durand.net>> wrote:
> >>      > Yes Arjan, I think it's the first reason. We really should work
> >>     with them to understand what should be added to CDI 2.0 to have it
> >>     as a first citizen DI in their spec.
> >>      >
> >>      > Le sam. 29 ao?t 2015 ? 23:15, arjan tijms <arjan.tijms at gmail.com
> >>     <mailto:arjan.tijms at gmail.com>> a ?crit :
> >>      > On Sat, Aug 29, 2015 at 8:45 PM, Antonio Goncalves
> >>      > <antonio.goncalves at gmail.com
> >>     <mailto:antonio.goncalves at gmail.com>> wrote:
> >>      > > I remember talking with the JAX-RS guys (Java EE), years ago
> >>     (back in EE6),
> >>      > > and their answer for not adopting CDI was "too heavy".
> >>      >
> >>      > I can't find an exact reference anymore, but I somewhat remember
> >> that
> >>      > one of the reasons was also simply that CDI as a general solution
> >>      > finished late in Java EE 6, while JAX-RS finished earlier and had
> >> all
> >>      > the work for their own DI solution already done.
> >>      >
> >>      >
> >>      >
> >>      > --
> >>      > Antonio Goncalves
> >>      > Software architect, Java Champion and Pluralsight author
> >>      >
> >>      > Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx
> >>     France
> >>      > _______________________________________________
> >>      > cdi-dev mailing list
> >>      > cdi-dev at lists.jboss.org <mailto: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 <mailto: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.
> >>      >
> >>      >
> >>      >
> >>      >
> >>      > --
> >>      > Antonio Goncalves
> >>      > Software architect, Java Champion and Pluralsight author
> >>      >
> >>      > Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx
> >>     France
> >>      >
> >>      >
> >>      >
> >>      >
> >>      > --
> >>      > Antonio Goncalves
> >>      > Software architect, Java Champion and Pluralsight author
> >>      >
> >>      > Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx
> >>     France
> >>      > _______________________________________________
> >>      > cdi-dev mailing list
> >>      > cdi-dev at lists.jboss.org <mailto: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.
> >>
> >>
> >>
> >>
> >> --
> >> Antonio Goncalves
> >> Software architect, Java Champion and Pluralsight author
> >>
> >> Web site <http://www.antoniogoncalves.org> | Twitter
> >> <http://twitter.com/agoncal> | LinkedIn
> >> <http://www.linkedin.com/in/agoncal> | Pluralsight
> >> <http://pluralsight.com/training/Authors/Details/antonio-goncalves> |
> >> Paris JUG <http://www.parisjug.org> | Devoxx France <
> http://www.devoxx.fr
> >> >
> >>
> >>
> >> _______________________________________________
> >> 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
> >
>
>
>
> --
> Antonio Goncalves
> Software architect, Java Champion and Pluralsight author
>
> Web site <http://www.antoniogoncalves.org> | Twitter
> <http://twitter.com/agoncal> | LinkedIn <
> http://www.linkedin.com/in/agoncal> |
> Pluralsight
> <http://pluralsight.com/training/Authors/Details/antonio-goncalves> |
> Paris
> JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20150831/639a074c/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 45
> ***************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150831/a6cca5be/attachment-0001.html 

From struberg at yahoo.de  Mon Aug 31 05:30:49 2015
From: struberg at yahoo.de (Mark Struberg)
Date: Mon, 31 Aug 2015 11:30:49 +0200
Subject: [cdi-dev] Time to start working on CDI lite
In-Reply-To: <CA+ZZq99QchL8uZY_E8=kWetNEHiUGJV+T=GBS8W0doRf7S-Kiw@mail.gmail.com>
References: <CABu-YBQvgrVZcH31i+Uw9ZefsTZvLHJ4919PW=vnvRBa2RVoTQ@mail.gmail.com>
	<CA+ZZq9_C_nTH1YY1uNYnH2aW6RBBR7+xH9ZF+cduMhzOQHOO8g@mail.gmail.com>
	<CAE=-AhDa84QjHqwNLJD3+a1f2mD2d+Y_2kwqRVqzBRkuvf4Qfw@mail.gmail.com>
	<CABu-YBQ9ZtUdSj6LUoROz2-JuqROtLTG1UKUSANOY4kiVHpTDg@mail.gmail.com>
	<CA+ZZq9-RW68R+o1c3n5J6KSGtki+o+89SvTpovSFL5ZKq6BTWQ@mail.gmail.com>
	<CAOqetn_Afc0BfGPcSRBQiKuvtOfZnQKzxHv59KhbJfLTGKoH4w@mail.gmail.com>
	<CACLE=7MmgSVukPrN-fiu959w1zv7hj19VikGx-4JzA2mTRVG-w@mail.gmail.com>
	<CA+ZZq99XKDbwnqLPi-j4rcizU9EcuNzjsJTHo+Qy_djjtMCy_Q@mail.gmail.com>
	<CACLE=7Mu5mMB3tFWLtPxNXRpKrR82xKku5saFB9it3n-8RU1aQ@mail.gmail.com>
	<CA+ZZq9-YFcTKuZr=+6v=wH-w670E++qgBrN36DsToFEidUzenQ@mail.gmail.com>
	<47B00263-144C-4B41-A1F7-73176012C22F@yahoo.de>
	<CA+ZZq99QchL8uZY_E8=kWetNEHiUGJV+T=GBS8W0doRf7S-Kiw@mail.gmail.com>
Message-ID: <19E62B90-B7E2-40F6-9E69-139D8AB3D92C@yahoo.de>

> 
> I don't see Events in a "Lite" version because the other DI frameworks don't use them. A "fatter" 330 with producers, programmatic lookup and bootstrap, could be "easily" implemented by Spring, Guice... If we leave events in a Lite version, then it won?t be the case, and Weld and OWB will be the only two implementations. 

No, it?s not an impl thing at all but all the Extension events and it?s usage are specified deep in the CDI spec. 
Of course the impls could use different code parts for Extension events and ?user events? but you still would need an event bus OR you would get rid of Extensions alltogether. But that would be pretty insane imo ;)

There is also no need to go further in the JSR-330-only area. All CDI containers must pass the atinject TCK and thus are fully certified JSR-330 containers as well. Add guice, Spring, picocontainer, etc to this. There is really no need to go down even further in this road imo. We are not here for world domination. We don?t need to do _every_ situation. Let?s instead do OUR main goal really well.


> If you take back Antoine sentence "This would allow using CDI in constrained environment like mobile or embedded devices", then I don't think events would fit here.


Forget about all the Android area for now. In android there are not even Annotations afaik. And Android is NOT Java. The runtime and all the bytecode stuff we do here wont work that easily. So we would get rid of TONS of neat stuff a JavaSE app most of the times would LOVE to have.


IF we say that CDI-lite is targetting android then this is fine as well. But then we aim for a TOTALLY different goal! This would not even be useful in a SE. If you really like to have a lightweight-as-possible DI container, such a project already exists. It is called Apache Avalon [1] and got written in 1999. So it even predates Spring for about 5 years?

LieGrue,
strub

[1] https://en.wikipedia.org/wiki/Apache_Avalon



> Am 31.08.2015 um 09:57 schrieb Antonio Goncalves <antonio.goncalves at gmail.com>:
> 
> I don't see Events in a "Lite" version because the other DI frameworks don't use them. A "fatter" 330 with producers, programmatic lookup and bootstrap, could be "easily" implemented by Spring, Guice... If we leave events in a Lite version, then it won't be the case, and Weld and OWB will be the only two implementations. 
> 
> For me, a Lite version would just be about DI. If Weld uses events internally to archieve basic DI, well, it's just an implementation decision, not a spec. I would not even try to standardize the way @Inject works (like Romain said, @Inject doesn't work the same in Weld or Spring), let's leave it like this. If you take back Antoine sentence "This would allow using CDI in constrained environment like mobile or embedded devices", then I don't think events would fit here.
> 
> Antonio
> 
> On Mon, Aug 31, 2015 at 8:25 AM, Mark Struberg <struberg at yahoo.de> wrote:
> > For me, a Light version of CDI is clearly the features number. That's why I don't see events in it.
> 
> We did discuss this last year on the f2f meeting. The problem lies within our Extension mechanism. Without events you also need to drop the Extension mechanism. And to be honest, this is THE major hit in all CDI?
> Sorry to be the bad guy busting all those ideas. I really don?t want to, but better now than too late down the road ;)
> 
> It?s really tricky as many features are heavily based on each other. E.g. by removing scanning you could get rid of javassist/asm/etc ? nope, we also have our class proxies which need bytecode tinkering. So remove interceptors and decorators too? Well yea, but we still have normalscoping -> what is left? basically spring prototype and singleton. Hmm.  that?s not that much compared to full CDI. And all that for only 200kByte?
> (Btw we also discussed generating the bytecode classes at build time, but then we still miss the dynamics we get from Extensions, e.g. PAT adding an interceptor annotation)
> Just to give you a rough idea how this all works together when it comes to implementation details?
> Please feel free to ask Jozef and me for further infos on ?dependencies?.
> 
> LieGrue,
> strub
> 
> 
> > Am 30.08.2015 um 18:09 schrieb Antonio Goncalves <antonio.goncalves at gmail.com>:
> >
> > For me, a Light version of CDI is clearly the features number. That's why I don't see events in it.
> >
> > For me, a CDI Lite would just focus on DI. If CDI has @Produces and Spring has @Bean, then it's because 330 lakes this functionality.
> >
> > On Sun, Aug 30, 2015 at 4:02 PM, Romain Manni-Bucau <rmannibucau at gmail.com> wrote:
> > Lite can have several definition, let's try to list them up if it can help:
> >
> > - binary size: for me until 3M for an app it is "Lite"
> > - features number: the whole IoC set of feature is light since you almost always need it, it means you can do lighter but it wouldnt be used - check spring, who uses only spring-ioc and not context or more?
> > - features complexity: sure we are not light here but supporting scopes already breaks "Lite-ness" IMO so not a real issue
> >
> > So my view is CDI "SE" is light enough - as a spec and spec can't affect implementations so seems the fight is not on the right side to me.
> >
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau |  Blog | Github | LinkedIn | Tomitriber
> >
> > 2015-08-30 15:57 GMT+02:00 Antonio Goncalves <antonio.goncalves at gmail.com>:
> > It's funny, I feel I'm in Rod Johnson shoes back in Java EE 6 where he forked 330 because he found CDI was doing too much  ;o)
> >
> > For me, "CDI Lite" was just basic dependency injection. The fact that CDI can now run on SE (like JPA....), is good... but for me it has nothing to do with Light : it's the entire thing that can bootstrap in SE. Good.
> >
> > So what is Lite for you guys ?
> >
> > Antonio
> >
> > On Sun, Aug 30, 2015 at 3:44 PM, Romain Manni-Bucau <rmannibucau at gmail.com> wrote:
> > 2015-08-30 15:22 GMT+02:00 John D. Ament <john.d.ament at gmail.com>:
> > Personally, I'm not in favor of a slimmed down runtime.  It was tried with EJB, but never implemented properly (most implementations that support EJB-lite actually support the entire thing, except for deprecated stuff).
> >
> >
> > +1, most of CDI is basic and quickly any light version will miss events or other thing - in particular in maintaining micro services from experience. Size of an implementation can easily be < 1M so not sure it would bring anything. Only important point is what Antoine started to do ie ensuring EE and SE parts are clearly identified and split in the spec.
> >
> > I think if we define SE properly we won't have a need for this.
> >
> > John
> >
> > On Sun, Aug 30, 2015 at 8:07 AM Antonio Goncalves <antonio.goncalves at gmail.com> wrote:
> > @Antoine, so which content do you see in CDI Lite ? Are you sure about events ?
> >
> > I'm in favor of a "fatter" 330 that would have :
> >       ? @Inject : already there
> >       ? @Qualifier : already there
> >       ? Producers and disposers
> >       ? Programatic lookup
> >       ? Java SE Bootstrap
> > When you say "The goal here is not to propose a new EE profile but a subspec", 330 could already be seen as a subspec. If you put events apparts, what would be missing in this list in your point of view ? And what obstacles do you see in archieving this ?
> >
> > To boostrap CDI we have a CDIProvider, why not having an InjectionProvider just to bootstrap 330 (then, CDIProvider could extend InjectionProvider, so it bootstraps the all thing) ?
> >
> > Antonio
> >
> > On Sun, Aug 30, 2015 at 9:09 AM, Antoine Sabot-Durand <antoine at sabot-durand.net> wrote:
> > Yes Arjan, I think it's the first reason. We really should work with them to understand what should be added to CDI 2.0 to have it as a first citizen DI in their spec.
> >
> > Le sam. 29 ao?t 2015 ? 23:15, arjan tijms <arjan.tijms at gmail.com> a ?crit :
> > On Sat, Aug 29, 2015 at 8:45 PM, Antonio Goncalves
> > <antonio.goncalves at gmail.com> wrote:
> > > I remember talking with the JAX-RS guys (Java EE), years ago (back in EE6),
> > > and their answer for not adopting CDI was "too heavy".
> >
> > I can't find an exact reference anymore, but I somewhat remember that
> > one of the reasons was also simply that CDI as a general solution
> > finished late in Java EE 6, while JAX-RS finished earlier and had all
> > the work for their own DI solution already done.
> >
> >
> >
> > --
> > Antonio Goncalves
> > Software architect, Java Champion and Pluralsight author
> >
> > Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France
> > _______________________________________________
> > 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.
> >
> >
> >
> >
> > --
> > Antonio Goncalves
> > Software architect, Java Champion and Pluralsight author
> >
> > Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France
> >
> >
> >
> >
> > --
> > Antonio Goncalves
> > Software architect, Java Champion and Pluralsight author
> >
> > Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France
> > _______________________________________________
> > 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.
> 
> 
> 
> 
> -- 
> Antonio Goncalves 
> Software architect, Java Champion and Pluralsight author
> 
> Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France