Re: [cdi-dev] F2F participants

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&gt; Subject: Re: [cdi-dev] master branch in cdi-spec GIT repo To: &quot;antoine(a)sabot-durand.net&quot; <antoine(a)sabot-durand.net&gt;, &quot;jharting(a)redhat.com&quot; <jharting(a)redhat.com&gt;, " cdi-dev(a)lists.jboss.org&quot; <cdi-dev(a)lists.jboss.org&gt; Message-ID: <1440480969.74018.YahooMailIosMobile(a)web121604.mail.ne1.yahoo.com&gt; 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&gt; 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&gt; 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&gt; Subject: [cdi-dev] F2F meeting Prioritization To: CDI Java EE Specification <cdi-dev(a)lists.jboss.org&gt; Message-ID: < CABu-YBSgPkzMaTYh5U3+Z+SSqAceG_6iDOAOfYCGqdGGZZoy6Q(a)mail.gmail.com&gt; 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&gt; Subject: [cdi-dev] F2F participants To: cdi-dev <cdi-dev(a)lists.jboss.org&gt; Message-ID: < CABu-YBRHvvUYMRk5tQbOT8TKuZwys_HijSakfA_nWGgLx1mEOg(a)mail.gmail.com&gt; 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&gt; Subject: Re: [cdi-dev] F2F participants To: Antoine Sabot-Durand <antoine(a)sabot-durand.net&gt; Cc: cdi-dev <cdi-dev(a)lists.jboss.org&gt; Message-ID: <CA+ZZq99Ph8U2wSKWabMO2i= n9DR-xwv9GmdRggE13qPdZepuyA(a)mail.gmail.com&gt; 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&gt; 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&gt; 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&gt;, Nigel Deakin <nigel.deakin(a)oracle.com&gt; Cc: cdi-dev <cdi-dev(a)lists.jboss.org&gt; Message-ID: < CAOqetn8mn0eWGWVo3AiwJZu_A4nDngsgzj3cjiSqVGUPx09UEA(a)mail.gmail.com&gt; 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&gt; wrote: > Hi, > > On Mon, Aug 24, 2015 at 9:47 PM, Nigel Deakin <nigel.deakin(a)oracle.com&gt; > 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 ***************************************