Re: [cdi-dev] F2F participants
by Werner Keil
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(a)lists.jboss.org> wrote:
> Send cdi-dev mailing list submissions to
> cdi-dev(a)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(a)lists.jboss.org
>
> You can reach the person managing the list at
> cdi-dev-owner(a)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(a)yahoo.de>
> Subject: Re: [cdi-dev] master branch in cdi-spec GIT repo
> To: "antoine(a)sabot-durand.net" <antoine(a)sabot-durand.net>,
> "jharting(a)redhat.com" <jharting(a)redhat.com>, "
> cdi-dev(a)lists.jboss.org"
> <cdi-dev(a)lists.jboss.org>
> Message-ID:
> <1440480969.74018.YahooMailIosMobile(a)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/at...
>
> ------------------------------
>
> Message: 2
> Date: Tue, 25 Aug 2015 03:26:28 -0400 (EDT)
> From: "Antoine Sabot-Durand (JIRA)" <issues(a)jboss.org>
> Subject: [cdi-dev] [JBoss JIRA] (CDI-552) Add support for injection,
> decorators and interceptors on "new-ed" objects
> To: cdi-dev(a)lists.jboss.org
> Message-ID:
> <JIRA.12579311.1437747419000.25496.1440487588980(a)Atlassian.JIRA>
> Content-Type: text/plain; charset=UTF-8
>
>
> [
> https://issues.jboss.org/browse/CDI-552?page=com.atlassian.jira.plugin.sy...
> ]
>
> 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/htm...
>
>
>
> --
> 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(a)sabot-durand.net>
> Subject: [cdi-dev] F2F meeting Prioritization
> To: CDI Java EE Specification <cdi-dev(a)lists.jboss.org>
> Message-ID:
> <
> CABu-YBSgPkzMaTYh5U3+Z+SSqAceG_6iDOAOfYCGqdGGZZoy6Q(a)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/1Frlfv39Nixalt7...
>
> 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/at...
>
> ------------------------------
>
> Message: 4
> Date: Tue, 25 Aug 2015 08:23:58 +0000
> From: Antoine Sabot-Durand <antoine(a)sabot-durand.net>
> Subject: [cdi-dev] F2F participants
> To: cdi-dev <cdi-dev(a)lists.jboss.org>
> Message-ID:
> <
> CABu-YBRHvvUYMRk5tQbOT8TKuZwys_HijSakfA_nWGgLx1mEOg(a)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/1Frlfv39Nixalt7...
>
> 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/at...
>
> ------------------------------
>
> Message: 5
> Date: Tue, 25 Aug 2015 11:51:23 +0200
> From: Antonio Goncalves <antonio.goncalves(a)gmail.com>
> Subject: Re: [cdi-dev] F2F participants
> To: Antoine Sabot-Durand <antoine(a)sabot-durand.net>
> Cc: cdi-dev <cdi-dev(a)lists.jboss.org>
> Message-ID:
> <CA+ZZq99Ph8U2wSKWabMO2i=
> n9DR-xwv9GmdRggE13qPdZepuyA(a)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(a)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/1Frlfv39Nixalt7...
> >
> > You can add your name and other informations there.
> >
> > Antoine
> >
> > _______________________________________________
> > cdi-dev mailing list
> > cdi-dev(a)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/at...
>
> ------------------------------
>
> Message: 6
> Date: Tue, 25 Aug 2015 11:19:16 +0000
> From: "John D. Ament" <john.d.ament(a)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(a)gmail.com>, Nigel Deakin
> <nigel.deakin(a)oracle.com>
> Cc: cdi-dev <cdi-dev(a)lists.jboss.org>
> Message-ID:
> <
> CAOqetn8mn0eWGWVo3AiwJZu_A4nDngsgzj3cjiSqVGUPx09UEA(a)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(a)gmail.com> wrote:
>
> > Hi,
> >
> > On Mon, Aug 24, 2015 at 9:47 PM, Nigel Deakin <nigel.deakin(a)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(a)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(a)jms-spec.java.net alias.
> > >>
> > >> Thanks,
> > >>
> > >> Nigel
> > >> JMS 2.1 specification lead
> > >> _______________________________________________
> > >> cdi-dev mailing list
> > >> cdi-dev(a)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(a)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(a)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/at...
>
> ------------------------------
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev(a)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
> ***************************************
>
10 years, 1 month
[JBoss JIRA] (CDI-552) Add support for injection, decorators and interceptors on "new-ed" objects
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-552?page=com.atlassian.jira.plugin.sy... ]
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/htm...
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 1 month
master branch in cdi-spec GIT repo
by Mark Struberg
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
10 years, 1 month
Re: [cdi-dev] Proposal to allow any CDI managed bean in a Java EE application to listen for JMS messages
by Werner Keil
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(a)lists.jboss.org> wrote:
> Send cdi-dev mailing list submissions to
> cdi-dev(a)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(a)lists.jboss.org
>
> You can reach the person managing the list at
> cdi-dev-owner(a)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(a)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(a)oracle.com>, cdi-dev(a)lists.jboss.org
> Message-ID:
> <CABu-YBTqjtdMxbLO=
> TcFikN9XM-zgjfDP8Chhj5bqFSy6ueKOQ(a)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(a)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(a)jms-spec.java.net alias.
> >
> > Thanks,
> >
> > Nigel
> > JMS 2.1 specification lead
> > _______________________________________________
> > cdi-dev mailing list
> > cdi-dev(a)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/at...
>
> ------------------------------
>
> Message: 2
> Date: Mon, 24 Aug 2015 19:42:41 +0200
> From: Antonio Goncalves <antonio.goncalves(a)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(a)oracle.com>
> Cc: cdi-dev <cdi-dev(a)lists.jboss.org>
> Message-ID:
> <CA+ZZq9_Brvtks=
> jxQ1TbtXMNm+ab3w3GZfG-2sGQYeMK2mu2jA(a)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(a)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(a)jms-spec.java.net alias.
> >
> > Thanks,
> >
> > Nigel
> > JMS 2.1 specification lead
> > _______________________________________________
> > cdi-dev mailing list
> > cdi-dev(a)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/at...
>
> ------------------------------
>
> Message: 3
> Date: Mon, 24 Aug 2015 20:47:51 +0100
> From: Nigel Deakin <nigel.deakin(a)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(a)gmail.com>
> Cc: cdi-dev <cdi-dev(a)lists.jboss.org>
> Message-ID: <55DB74E7.4080609(a)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(a)oracle.com
> <mailto:nigel.deakin@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(a)jms-spec.java.net <mailto:users@jms-spec.java.net> alias.
> >
> > Thanks,
> >
> > Nigel
> > JMS 2.1 specification lead
> > _______________________________________________
> > cdi-dev mailing list
> > cdi-dev(a)lists.jboss.org <mailto:cdi-dev@lists.jboss.org>
> > https://lists.jboss.org/mailman/listinfo/cdi-dev
> >
> > Note that for all code provided on this list, the provider licenses
> the code under the Apache License, Version 2
> > (http://www.apache.org/licenses/LICENSE-2.0.html). For all other
> ideas provided on this list, the provider waives
> > all patent and other intellectual property rights inherent in such
> information.
> >
> >
> >
> >
> > --
> > 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/at...
>
> ------------------------------
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev(a)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
> ***************************************
>
10 years, 1 month
preparing the face to face meeting
by Antoine Sabot-Durand
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
10 years, 1 month
Spam
by Anatole Tresch
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*
10 years, 1 month
WithAnnotations with ProcessInjectionTarget events
by Nigel Deakin
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
10 years, 1 month
