Send cdi-dev mailing list submissions to
cdi-dev@lists.jboss.org
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.jboss.org/mailman/listinfo/cdi-dev
or, via email, send a message with subject or body 'help' to
cdi-dev-request@lists.jboss.org
You can reach the person managing the list at
cdi-dev-owner@lists.jboss.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of cdi-dev digest..."
Today's Topics:
1. Re: 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@yahoo.de>
Subject: Re: [cdi-dev] master branch in cdi-spec GIT repo
To: "antoine@sabot-durand.net" <antoine@sabot-durand.net>,
"jharting@redhat.com" <jharting@redhat.com>, "cdi-dev@lists.jboss.org"
<cdi-dev@lists.jboss.org>
Message-ID:
<1440480969.74018.YahooMailIosMobile@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@jboss.org>
Subject: [cdi-dev] [JBoss JIRA] (CDI-552) Add support for injection,
decorators and interceptors on "new-ed" objects
To: cdi-dev@lists.jboss.org
Message-ID:
<JIRA.12579311.1437747419000.25496.1440487588980@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@sabot-durand.net>
Subject: [cdi-dev] F2F meeting Prioritization
To: CDI Java EE Specification <cdi-dev@lists.jboss.org>
Message-ID:
<CABu-YBSgPkzMaTYh5U3+Z+SSqAceG_6iDOAOfYCGqdGGZZoy6Q@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@sabot-durand.net>
Subject: [cdi-dev] F2F participants
To: cdi-dev <cdi-dev@lists.jboss.org>
Message-ID:
<CABu-YBRHvvUYMRk5tQbOT8TKuZwys_HijSakfA_nWGgLx1mEOg@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@gmail.com>
Subject: Re: [cdi-dev] F2F participants
To: Antoine Sabot-Durand <antoine@sabot-durand.net>
Cc: cdi-dev <cdi-dev@lists.jboss.org>
Message-ID:
<CA+ZZq99Ph8U2wSKWabMO2i=n9DR-xwv9GmdRggE13qPdZepuyA@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@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@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@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@gmail.com>, Nigel Deakin
<nigel.deakin@oracle.com>
Cc: cdi-dev <cdi-dev@lists.jboss.org>
Message-ID:
<CAOqetn8mn0eWGWVo3AiwJZu_A4nDngsgzj3cjiSqVGUPx09UEA@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@gmail.com> wrote:
> Hi,
>
> On Mon, Aug 24, 2015 at 9:47 PM, Nigel Deakin <nigel.deakin@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@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@jms-spec.java.net alias.
> >>
> >> Thanks,
> >>
> >> Nigel
> >> JMS 2.1 specification lead
> >> _______________________________________________
> >> cdi-dev mailing list
> >> cdi-dev@lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/cdi-dev
> >>
> >> Note that for all code provided on this list, the provider licenses the
> >> code under the Apache License, Version 2
> >> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> >> provided on this list, the provider waives all patent and other
> intellectual
> >> property rights inherent in such information.
> >
> >
> >
> >
> > --
> > Antonio Goncalves
> > Software architect, Java Champion and Pluralsight author
> >
> > Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France
> >
> >
> >
> > _______________________________________________
> > cdi-dev mailing list
> > cdi-dev@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/cdi-dev
> >
> > Note that for all code provided on this list, the provider licenses the
> code
> > under the Apache License, Version 2
> > (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> > provided on this list, the provider waives all patent and other
> intellectual
> > property rights inherent in such information.
> _______________________________________________
> cdi-dev mailing list
> cdi-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the
> code under the Apache License, Version 2 (
> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> provided on this list, the provider waives all patent and other
> intellectual property rights inherent in such information.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150825/9ed0c209/attachment.html
------------------------------
_______________________________________________
cdi-dev mailing list
cdi-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev
Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
End of cdi-dev Digest, Vol 57, Issue 16
***************************************