From antoine at sabot-durand.net Mon Nov 3 12:00:08 2014 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Mon, 3 Nov 2014 18:00:08 +0100 Subject: [cdi-dev] Meeting time slot and daylight saving Message-ID: <6DBB1951-36AA-4080-BCA1-BE769F6574A4@sabot-durand.net> Hi, As DST is over for most of us, I propose we follow the time shift and keep the meeting time slot at the same time : 6:00 pm CET / 5:00 pm GMT / 9:00 PST Antoine From antoine at sabot-durand.net Mon Nov 3 12:02:25 2014 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Mon, 3 Nov 2014 18:02:25 +0100 Subject: [cdi-dev] More CDI integration on JSF 2.3 In-Reply-To: References: Message-ID: Hi Antonio, No contact with Manfred, but it?s a good idea. Right now I?m drowned in Devoxx university preparation but I?ll get in touch with just after Devoxx. Antoine > Le 31 oct. 2014 ? 07:08, Antonio Goncalves a ?crit : > > Hi all, > > You might have followed Manfred Riem blog, but if not, take a look at what he's doing in JSF 2.3 : integrating even more CDI into his spec : > https://weblogs.java.net/blog/mriem/archive/2014/10/30/jsf-23-changes > https://weblogs.java.net/blog/mriem/archive/2014/10/29/jsf-23-injecting-uiviewroot > https://weblogs.java.net/blog/mriem/archive/2014/10/27/jsf-23-allow-cdi-handle-application > https://weblogs.java.net/blog/mriem/archive/2014/10/23/jsf-23-changes > https://weblogs.java.net/blog/mriem/archive/2014/10/16/jsf-23-changes > https://weblogs.java.net/blog/mriem/archive/2014/10/15/jsf-23-injecting-application-map > https://weblogs.java.net/blog/mriem/archive/2014/10/13/jsf-23-inject-externalcontext > https://weblogs.java.net/blog/mriem/archive/2014/10/10/jsf-23-inject-facescontext > Antoine, any special contact with Manfred ? What having "interviewing" him and write a blog (on the cdi-spec website) about "advantages of having stronger CDI integration" ? That could benefit other spec leads (and therefore, other specs, I'm thinking about Servlet 4 and MVC with Manfred and Ed Burns). > > WDYT ? > > -- > Antonio Goncalves > Software architect, Java Champion and Pluralsight author > > Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20141103/13f44ebc/attachment-0001.html From antonio.goncalves at gmail.com Mon Nov 3 12:05:05 2014 From: antonio.goncalves at gmail.com (Antonio Goncalves) Date: Mon, 3 Nov 2014 18:05:05 +0100 Subject: [cdi-dev] More CDI integration on JSF 2.3 In-Reply-To: References: Message-ID: And I'll attend your university ;o) On Mon, Nov 3, 2014 at 6:02 PM, Antoine Sabot-Durand < antoine at sabot-durand.net> wrote: > Hi Antonio, > > No contact with Manfred, but it?s a good idea. Right now I?m drowned in > Devoxx university preparation but I?ll > get in touch with just after Devoxx. > > Antoine > > Le 31 oct. 2014 ? 07:08, Antonio Goncalves > a ?crit : > > Hi all, > > You might have followed Manfred Riem blog, but if not, take a look at what > he's doing in JSF 2.3 : integrating even more CDI into his spec : > > - https://weblogs.java.net/blog/mriem/archive/2014/10/30/jsf-23-changes > - > https://weblogs.java.net/blog/mriem/archive/2014/10/29/jsf-23-injecting-uiviewroot > - > https://weblogs.java.net/blog/mriem/archive/2014/10/27/jsf-23-allow-cdi-handle-application > - https://weblogs.java.net/blog/mriem/archive/2014/10/23/jsf-23-changes > - https://weblogs.java.net/blog/mriem/archive/2014/10/16/jsf-23-changes > - > https://weblogs.java.net/blog/mriem/archive/2014/10/15/jsf-23-injecting-application-map > - > https://weblogs.java.net/blog/mriem/archive/2014/10/13/jsf-23-inject-externalcontext > - > https://weblogs.java.net/blog/mriem/archive/2014/10/10/jsf-23-inject-facescontext > > Antoine, any special contact with Manfred ? What having "interviewing" him > and write a blog (on the cdi-spec website) about "advantages of having > stronger CDI integration" ? That could benefit other spec leads (and > therefore, other specs, I'm thinking about Servlet 4 and MVC with Manfred > and Ed Burns). > > WDYT ? > > -- > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20141103/961bffae/attachment.html From werner.keil at gmail.com Mon Nov 3 12:27:06 2014 From: werner.keil at gmail.com (Werner Keil) Date: Mon, 3 Nov 2014 18:27:06 +0100 Subject: [cdi-dev] More CDI integration on JSF 2.3 Message-ID: I suggested exactly that when I spoke to Manfred and Ed during a combined MVC/Servlet 4 kick-off at JavaOne;-) Given JSF Flow in 2.2 already took quite some "inspiration" from Spring (and then VMWare had at least 2 EG members) while I don't know, if somebody from Pivotal joins the MVC EG, it will likely reassemble Spring MVC quite a bit. And Events are among key Features of CDI it shall benefit from. I recently joined the JMS 2.1 EG and its proposal also aims at further Integration with CDI 2: https://jcp.org/en/jsr/detail?id=368 P.s.: JMS Spec Lead Nigel Deakin said, he expects to be at DevoXX BE, so maybe those of you who are there could hitch up with him, too;-) Cheers, Werner Keil | JCP Executive Committee Member, JSR 363 Co Spec Lead | Eclipse UOMo Lead, Babel Language Champion | Apache Committer | Java Godfather Twitter @wernerkeil | @UnitAPI | @JSR354 | #EclipseUOMo | @AgoravaProj | #DevOps Skype werner.keil | Google+ gplus.to/wernerkeil * JMaghreb 3.0: 6 Nov 2014, Casablanca, Morocco. Werner Keil, JCP EC Member, JSR 363 Spec Lead, DevOps Guy will present "Triple-E' class DevOps", "JSR 363" * ApacheCon Europe: 17 Nov 2014, Budapest, Hungary. Werner Keil, JCP EC Member, Apache DeviceMap Committer will present "Apache DeviceMap" * Mobile Developer Conference kompakt: 18 Nov 2014, Hamburg, Germany. Werner Keil, JCP EC Member, Apache DeviceMap Committer will present "DevOps for Android", "Apache DeviceMap" (GER) On Mon, Nov 3, 2014 at 6:02 PM, 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. working doc for Java SE booter and context control? > (Mark Struberg) > 2. Re: working doc for Java SE booter and context control? > (Antonio Goncalves) > 3. Re: [VOTE] Using @Priority to order events instead of adding > a parameter in @Observes (Antoine Sabot-Durand) > 4. More CDI integration on JSF 2.3 (Antonio Goncalves) > 5. Meeting time slot and daylight saving (Antoine Sabot-Durand) > 6. Re: More CDI integration on JSF 2.3 (Antoine Sabot-Durand) > > > ---------------------------------------------------------------------- > > Message: 6 > Date: Mon, 3 Nov 2014 18:02:25 +0100 > From: Antoine Sabot-Durand > Subject: Re: [cdi-dev] More CDI integration on JSF 2.3 > To: Antonio Goncalves > Cc: cdi-dev > Message-ID: > Content-Type: text/plain; charset="utf-8" > > Hi Antonio, > > No contact with Manfred, but it?s a good idea. Right now I?m drowned in > Devoxx university preparation but I?ll > get in touch with just after Devoxx. > > Antoine > > > Le 31 oct. 2014 ? 07:08, Antonio Goncalves > a ?crit : > > > > Hi all, > > > > You might have followed Manfred Riem blog, but if not, take a look at > what he's doing in JSF 2.3 : integrating even more CDI into his spec : > > https://weblogs.java.net/blog/mriem/archive/2014/10/30/jsf-23-changes < > https://weblogs.java.net/blog/mriem/archive/2014/10/30/jsf-23-changes> > > > https://weblogs.java.net/blog/mriem/archive/2014/10/29/jsf-23-injecting-uiviewroot > < > https://weblogs.java.net/blog/mriem/archive/2014/10/29/jsf-23-injecting-uiviewroot > > > > > https://weblogs.java.net/blog/mriem/archive/2014/10/27/jsf-23-allow-cdi-handle-application > < > https://weblogs.java.net/blog/mriem/archive/2014/10/27/jsf-23-allow-cdi-handle-application > > > > https://weblogs.java.net/blog/mriem/archive/2014/10/23/jsf-23-changes < > https://weblogs.java.net/blog/mriem/archive/2014/10/23/jsf-23-changes> > > https://weblogs.java.net/blog/mriem/archive/2014/10/16/jsf-23-changes < > https://weblogs.java.net/blog/mriem/archive/2014/10/16/jsf-23-changes> > > > https://weblogs.java.net/blog/mriem/archive/2014/10/15/jsf-23-injecting-application-map > < > https://weblogs.java.net/blog/mriem/archive/2014/10/15/jsf-23-injecting-application-map > > > > > https://weblogs.java.net/blog/mriem/archive/2014/10/13/jsf-23-inject-externalcontext > < > https://weblogs.java.net/blog/mriem/archive/2014/10/13/jsf-23-inject-externalcontext > > > > > https://weblogs.java.net/blog/mriem/archive/2014/10/10/jsf-23-inject-facescontext > < > https://weblogs.java.net/blog/mriem/archive/2014/10/10/jsf-23-inject-facescontext > > > > Antoine, any special contact with Manfred ? What having "interviewing" > him and write a blog (on the cdi-spec website) about "advantages of having > stronger CDI integration" ? That could benefit other spec leads (and > therefore, other specs, I'm thinking about Servlet 4 and MVC with Manfred > and Ed Burns). > > > > WDYT ? > > > > -- > > Antonio Goncalves > > Software architect, Java Champion and Pluralsight author > > > > Web site | Twitter < > http://twitter.com/agoncal> | LinkedIn > | Pluralsight < > http://pluralsight.com/training/Authors/Details/antonio-goncalves> | > Paris JUG | Devoxx France < > http://www.devoxx.fr/> > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://lists.jboss.org/pipermail/cdi-dev/attachments/20141103/13f44ebc/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 48, Issue 1 > ************************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20141103/3af4f6f9/attachment-0001.html From antonio.goncalves at gmail.com Mon Nov 3 14:09:08 2014 From: antonio.goncalves at gmail.com (Antonio Goncalves) Date: Mon, 3 Nov 2014 20:09:08 +0100 Subject: [cdi-dev] Devoxx BE Message-ID: Hi all, For those of you coming to Devoxx Belgium : there are plenty of CDI / Java EE things happening, but make sure you attend the BOF on Wednesday evening : http://cfp.devoxx.be/2014/talk/QZL-5570/The_Future_of_Java_in_the_Enterprise See you -- Antonio Goncalves Software architect, Java Champion and Pluralsight author Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20141103/9efca5df/attachment.html From issues at jboss.org Wed Nov 5 03:15:39 2014 From: issues at jboss.org (Jozef Hartinger (JIRA)) Date: Wed, 5 Nov 2014 03:15:39 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-490) Clarify what happens when an interceptor/decorator is enabled using both @Priority and beans.xml In-Reply-To: References: Message-ID: Jozef Hartinger created CDI-490: ----------------------------------- Summary: Clarify what happens when an interceptor/decorator is enabled using both @Priority and beans.xml Key: CDI-490 URL: https://issues.jboss.org/browse/CDI-490 Project: CDI Specification Issues Issue Type: Clarification Components: Decorators, Interceptors Affects Versions: 1.2.Final Reporter: Jozef Hartinger Suppose an InterceptorA has @Priority and is also listed in the beans.xml file of a particular BDA. Such interceptor is for sure enabled because: {quote}An interceptor is said to be enabled if it is enabled in at least one bean archive or is listed in the final list of interceptors for the application, as defined in Section 11.5.2, ?AfterTypeDiscovery event?.{quote} it matches both parts of the statement. As for ordering, the following statement defines invocation order: {quote}Interceptors enabled using @Priority are called before interceptors enabled using beans.xml.{quote} Since InterceptorA is enabled by both @Priority and beans.xml, the following applies: "Interceptors enabled using @Priority" = \{ InterceptorA \} "interceptors enabled using beans.xml" = \{ InterceptorA \} We can perform substitution in the statement and we get: *\{ InterceptorA \} are called before \{ InterceptorA \}* which does not seem right. The specification should explicitly address this scenario. There are several options (some of them are better, some are worse): 1) Invoke the interceptor twice - each time in the corresponding order given by priority and position in beans.xml 2) Invoke the interceptor once in the @Priority part of the invocation chain (@Priority has precedence) 3) Invoke the interceptor once in the beans.xml part of the invocation chain (beans.xml has precedence) 4) Forbid an interceptor to be enabled by both @Priority and beans.xml -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Nov 5 03:40:35 2014 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Wed, 5 Nov 2014 03:40:35 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-490) Clarify what happens when an interceptor/decorator is enabled using both @Priority and beans.xml In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13017354#comment-13017354 ] Martin Kouba commented on CDI-490: ---------------------------------- For options 2) and 3) there should be also a big warning about the fact, that the ordering may be different on CDI 1.0 and CDI 1.1+. For option 2), consider the following beans.xml: {code} com.acme.myfwk.TransactionInterceptor com.acme.myfwk.LoggingInterceptor {code} and interceptor classes: {code} class TransactionInterceptor {} @Priority(100) class LoggingInterceptor {} {code} The ordering would be: * CDI 1.0 ## TransactionInterceptor ## LoggingInterceptor * CDI 1.1+ ## LoggingInterceptor ## TransactionInterceptor To fix this a user would either have to add {{@Priority}} to relevant interceptor classes or modify {{javax.enterprise.inject.spi.AfterTypeDiscovery.getInterceptors()}}. > Clarify what happens when an interceptor/decorator is enabled using both @Priority and beans.xml > ------------------------------------------------------------------------------------------------ > > Key: CDI-490 > URL: https://issues.jboss.org/browse/CDI-490 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Decorators, Interceptors > Affects Versions: 1.2.Final > Reporter: Jozef Hartinger > > Suppose an InterceptorA has @Priority and is also listed in the beans.xml file of a particular BDA. Such interceptor is for sure enabled because: > {quote}An interceptor is said to be enabled if it is enabled in at least one bean archive or is listed in the final > list of interceptors for the application, as defined in Section 11.5.2, ?AfterTypeDiscovery event?.{quote} > it matches both parts of the statement. > As for ordering, the following statement defines invocation order: > {quote}Interceptors enabled using @Priority are called before interceptors enabled using beans.xml.{quote} > Since InterceptorA is enabled by both @Priority and beans.xml, the following applies: > "Interceptors enabled using @Priority" = \{ InterceptorA \} > "interceptors enabled using beans.xml" = \{ InterceptorA \} > We can perform substitution in the statement and we get: > *\{ InterceptorA \} are called before \{ InterceptorA \}* > which does not seem right. > The specification should explicitly address this scenario. There are several options (some of them are better, some are worse): > 1) Invoke the interceptor twice - each time in the corresponding order given by priority and position in beans.xml > 2) Invoke the interceptor once in the @Priority part of the invocation chain (@Priority has precedence) > 3) Invoke the interceptor once in the beans.xml part of the invocation chain (beans.xml has precedence) > 4) Forbid an interceptor to be enabled by both @Priority and beans.xml -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Nov 5 04:31:35 2014 From: issues at jboss.org (Antonio Goncalves (JIRA)) Date: Wed, 5 Nov 2014 04:31:35 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-491) Clarify what happens when an interceptor doesn't have any @AroundInvoke or lifecycle annotation In-Reply-To: References: Message-ID: Antonio Goncalves created CDI-491: ------------------------------------- Summary: Clarify what happens when an interceptor doesn't have any @AroundInvoke or lifecycle annotation Key: CDI-491 URL: https://issues.jboss.org/browse/CDI-491 Project: CDI Specification Issues Issue Type: Clarification Components: Interceptors Affects Versions: 1.2.Final Reporter: Antonio Goncalves At the moment, if you enable an interceptor in {{beans.xml}} and the class is not annotated with {{@Inteceptor}}, WELD throws an exception. But if the interceptor has no {{@AroundInvoke}}, {{@AroundConstrcut}}, {{@PostConstruct}} or {{@PreDestroy}}, then WELD stays silent and the interceptor doesn't work. The spec should clarify that, at least, one of these four annotation has to be used otherwise it's not considered a valid interceptor. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Nov 5 04:48:35 2014 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Wed, 5 Nov 2014 04:48:35 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-491) Clarify what happens when an interceptor doesn't have any @AroundInvoke or lifecycle annotation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13017377#comment-13017377 ] Martin Kouba commented on CDI-491: ---------------------------------- I believe this should be clarified in the Interceptors spec. > Clarify what happens when an interceptor doesn't have any @AroundInvoke or lifecycle annotation > ----------------------------------------------------------------------------------------------- > > Key: CDI-491 > URL: https://issues.jboss.org/browse/CDI-491 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Interceptors > Affects Versions: 1.2.Final > Reporter: Antonio Goncalves > > At the moment, if you enable an interceptor in {{beans.xml}} and the class is not annotated with {{@Inteceptor}}, WELD throws an exception. But if the interceptor has no {{@AroundInvoke}}, {{@AroundConstrcut}}, {{@PostConstruct}} or {{@PreDestroy}}, then WELD stays silent and the interceptor doesn't work. > The spec should clarify that, at least, one of these four annotation has to be used otherwise it's not considered a valid interceptor. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From antoine at sabot-durand.net Wed Nov 5 10:47:53 2014 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Wed, 5 Nov 2014 16:47:53 +0100 Subject: [cdi-dev] Cancelling today's meeting Message-ID: <8F3CF078-1B3A-43F7-A7D8-EB2243B358BB@sabot-durand.net> Hi guys, I have to drive my son to the hospital, he just had a bike accident. Nothing too serious but he definitely needs stitches. Antoine From arjan.tijms at gmail.com Wed Nov 5 13:21:11 2014 From: arjan.tijms at gmail.com (arjan tijms) Date: Wed, 5 Nov 2014 19:21:11 +0100 Subject: [cdi-dev] JSF 2.3 and specifying alternatives for build-in producers Message-ID: Hi, For JSF 2.3 we're currently working on providing build-in producers for various JSF artefacts.We're basically using the approach that I outlined here: http://jdevelopment.nl/dynamic-cdi-producers I noticed CDI is using a similar approach for its build-in producers, e.g. the one for HttpServletRequest (in Weld: org.jboss.weld.bean.builtin.ee.HttpServletRequestBean). Now we're currently putting these producers in an API package, to give the user a chance to override them, but I noticed CDI is not doing this. All producers are in implementation packages. After some experimentation I couldn't really succeed in providing an alternative producer for the CDI produced HttpServletRequest. I tried the obvious things, like an @Produces method in a bean annotated with @Alternative but that didn't work. Registered the bean as alternative in beans.xml, tried the uhm alternative @Priority method, tried different priority ranges, etc but my own producer was never called. Am I missing something very obvious, or is it not trivial to provide an alternative for build-in producers? Kind regards, Arjan Tijms From jharting at redhat.com Thu Nov 6 03:08:57 2014 From: jharting at redhat.com (Jozef Hartinger) Date: Thu, 06 Nov 2014 09:08:57 +0100 Subject: [cdi-dev] JSF 2.3 and specifying alternatives for build-in producers In-Reply-To: References: Message-ID: <545B2C99.60904@redhat.com> Hi Arjan, comments inline. On 11/05/2014 07:21 PM, arjan tijms wrote: > Hi, > > For JSF 2.3 we're currently working on providing build-in producers > for various JSF artefacts.We're basically using the approach that I > outlined here: http://jdevelopment.nl/dynamic-cdi-producers > > I noticed CDI is using a similar approach for its build-in producers, > e.g. the one for HttpServletRequest (in Weld: > org.jboss.weld.bean.builtin.ee.HttpServletRequestBean). > > Now we're currently putting these producers in an API package, to give > the user a chance to override them, but I noticed CDI is not doing > this. All producers are in implementation packages. Not sure what you mean here. How is a producer in an API package supposed to be overriden? A CDI producer is an implementation detail and should not be part of the API > > After some experimentation I couldn't really succeed in providing an > alternative producer for the CDI produced HttpServletRequest. I tried > the obvious things, like an @Produces method in a bean annotated with > @Alternative but that didn't work. Registered the bean as alternative > in beans.xml, tried the uhm alternative @Priority method, tried > different priority ranges, etc but my own producer was never called. > > Am I missing something very obvious, or is it not trivial to provide > an alternative for build-in producers? This should work. Sounds like an issue with your setup. Can you paste your code? It should be something like this: http://pastebin.com/TkzDtaAE > > 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 Thu Nov 6 08:24:48 2014 From: arjan.tijms at gmail.com (arjan tijms) Date: Thu, 6 Nov 2014 14:24:48 +0100 Subject: [cdi-dev] JSF 2.3 and specifying alternatives for build-in producers In-Reply-To: <545B2C99.60904@redhat.com> References: <545B2C99.60904@redhat.com> Message-ID: Hi, On Thu, Nov 6, 2014 at 9:08 AM, Jozef Hartinger wrote: >> Now we're currently putting these producers in an API package, to give >> the user a chance to override them, but I noticed CDI is not doing >> this. All producers are in implementation packages. > > Not sure what you mean here. How is a producer in an API package supposed to > be overriden? A CDI producer is an implementation detail and should not be > part of the API Okay. Well, in Mojarra 2.3 it is now indeed in the API, see e.g. https://github.com/svn2github/mojarra/blob/master/trunk/jsf-api/src/main/java/javax/faces/application/ApplicationProducer.java It's registered in an extension here: https://github.com/svn2github/mojarra/blob/master/trunk/jsf-ri/src/main/java/com/sun/faces/FacesCDIExtension.java We indeed put it there since we thought that otherwise you could not override it with your own alternative. But this now seems to be the wrong approach indeed. I guess we're still somewhat novices when it comes to CDI. > This should work. Sounds like an issue with your setup. Can you paste your > code? It should be something like this: http://pastebin.com/TkzDtaAE My code was identical, except for the @Dependent annotation. Putting that annotation there and it starts to work, but still not for all situations. In a web application without any beans.xml and with this @Alternative producer in WEB-INF/classes and a bean that also lives in WEB-INF/classes injected with an HttpServletRequest this works beautifully. However, in my test a jar file in WEB-INF/lib containing a bean that's also injected with an HttpServletRequest does not get injected with the one from the alternative producer, but gets an instance from the original CDI provided producer. Reading 5.1.1 in the CDI spec (http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#declaring_selected_alternatives) gave me the impression that @Priority should cause the alternative to be selected for the entire application, but that's not the case? Kind regards, Arjan From jharting at redhat.com Fri Nov 7 06:59:17 2014 From: jharting at redhat.com (Jozef Hartinger) Date: Fri, 07 Nov 2014 12:59:17 +0100 Subject: [cdi-dev] JSF 2.3 and specifying alternatives for build-in producers In-Reply-To: References: <545B2C99.60904@redhat.com> Message-ID: <545CB415.4050303@redhat.com> On 11/06/2014 02:24 PM, arjan tijms wrote: > Hi, > > On Thu, Nov 6, 2014 at 9:08 AM, Jozef Hartinger wrote: >>> Now we're currently putting these producers in an API package, to give >>> the user a chance to override them, but I noticed CDI is not doing >>> this. All producers are in implementation packages. >> Not sure what you mean here. How is a producer in an API package supposed to >> be overriden? A CDI producer is an implementation detail and should not be >> part of the API > Okay. Well, in Mojarra 2.3 it is now indeed in the API, see e.g. > https://github.com/svn2github/mojarra/blob/master/trunk/jsf-api/src/main/java/javax/faces/application/ApplicationProducer.java > It's registered in an extension here: > https://github.com/svn2github/mojarra/blob/master/trunk/jsf-ri/src/main/java/com/sun/faces/FacesCDIExtension.java > > We indeed put it there since we thought that otherwise you could not > override it with your own alternative. > > But this now seems to be the wrong approach indeed. I guess we're > still somewhat novices when it comes to CDI. > >> This should work. Sounds like an issue with your setup. Can you paste your >> code? It should be something like this: http://pastebin.com/TkzDtaAE > My code was identical, except for the @Dependent annotation. Putting > that annotation there and it starts to work, but still not for all > situations. > > In a web application without any beans.xml and with this @Alternative > producer in WEB-INF/classes and a bean that also lives in > WEB-INF/classes injected with an HttpServletRequest this works > beautifully. > > However, in my test a jar file in WEB-INF/lib containing a bean that's > also injected with an HttpServletRequest does not get injected with > the one from the alternative producer, but gets an instance from the > original CDI provided producer. > > Reading 5.1.1 in the CDI spec > (http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#declaring_selected_alternatives) > gave me the impression that @Priority should cause the alternative to > be selected for the entire application, but that's not the case? Yes, the @Alternative is globally enabled and will be injected everywhere from where the defining class is visible. That should cover your case. You may be observing an integration bug? What is the container? > > Kind regards, > Arjan From arjan.tijms at gmail.com Fri Nov 7 08:04:59 2014 From: arjan.tijms at gmail.com (arjan tijms) Date: Fri, 7 Nov 2014 14:04:59 +0100 Subject: [cdi-dev] JSF 2.3 and specifying alternatives for build-in producers In-Reply-To: <545CB415.4050303@redhat.com> References: <545B2C99.60904@redhat.com> <545CB415.4050303@redhat.com> Message-ID: Hi, On Fri, Nov 7, 2014 at 12:59 PM, Jozef Hartinger wrote: > Yes, the @Alternative is globally enabled and will be injected everywhere > from where the defining class is visible. That should cover your case. You > may be observing an integration bug? What is the container? The container is WildFly 8.1.0 in this test case. The exact situation is a BeanValidation contraint validator, being injected with said request: @SupportedValidationTarget(PARAMETERS) public class RolesAllowedValidator implements ConstraintValidator { private String[] roles; @Inject private HttpServletRequest request; // will be produced by CDI's build-in Bean @EJB private EJBSecurityBean securityBean; // [more code] } The above code is jar'ed up and put in the WEB-INF/lib folder of the mentioned project, where a method from a JAX-RS method is annotated with the corresponding bean validation annotation: @Path("/someroot") public class SomeEndpoint { @Inject private HttpServletRequest request; // will be produced by alternative producer @GET @Path("/somePath") @RolesAllowed({"foo", "bar"}) // triggers RolesAllowedValidator to be called public Foo method() { ...} } I understand there's a lot of different cross-spec integration going on here. I'll next try to create another test that just uses CDI and see what happens there. Thanks for all your help! Kind regards, Arjan > >> >> Kind regards, >> Arjan > > From issues at jboss.org Sun Nov 9 14:05:30 2014 From: issues at jboss.org (arjan tijms (JIRA)) Date: Sun, 9 Nov 2014 14:05:30 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-10) Add ability to access a bean instance from a proxy In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-10?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13018477#comment-13018477 ] arjan tijms commented on CDI-10: -------------------------------- {quote}If an Extension hacker really needs such a hardcore hack, then he might as well take the direct route:{quote} Given an unknown proxy, how do you know the scope, type and qualifiers? I think the original request is stall valid, for instance for those case where you need to take action based on a bean's class (it's class name may be a key into some map for instance) but all you got is the proxy. The workaround seems a bit circular, but maybe I misunderstood. If you want to find out the original bean type of a proxy, you need the type to obtain a Bean instance via which you can obtain the original type. But if I had the type already, I wouldn't need to obtain a Bean instance in the first place. See also http://stackoverflow.com/questions/14511433/original-class-name-of-a-proxy-without-manual-string-manipulation > Add ability to access a bean instance from a proxy > -------------------------------------------------- > > Key: CDI-10 > URL: https://issues.jboss.org/browse/CDI-10 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 1.0 > Reporter: Stuart Douglas > > There are occasions when it would be useful to access a bean instance directly from a proxy. This could be achieved by making all proxies assignable to an interface (say BeanProxy) that provides a getBeanInstance() method. > Client code that needs access to the actual instance can check if the object is assignable to the BeanProxy interface and then call getBeanInstance() to get the actual instance if required. > This is something that is probably more useful to extension writers than the end user, but there have already been a few requests on the weld forum about this so it is probably worth considering. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From arjan.tijms at gmail.com Mon Nov 10 08:59:07 2014 From: arjan.tijms at gmail.com (arjan tijms) Date: Mon, 10 Nov 2014 14:59:07 +0100 Subject: [cdi-dev] Destroying beans from an interceptor Message-ID: Hi, I wonder if it would be allowed according to the CDI spec to destroy a bean instance from within an interceptor. To test this (on Weld) I used the following code: @Interceptor @DestroyOnError @Priority(APPLICATION) public class DestroyOnErrorInterceptor implements Serializable { private static final long serialVersionUID = 1L; @AroundInvoke public Object tryInvoke(InvocationContext ctx) throws Exception { try { return ctx.proceed(); } catch (Exception e) { destroy(ctx.getMethod().getDeclaringClass()); throw e; } } private void destroy(Class clazz) { Instance instance = CDI.current().select(clazz); instance.destroy(instance.get()); } } When I use this interceptor on a SessionScoped bean: @SessionScoped public class TestBean implements Serializable { private static final long serialVersionUID = 1L; @DestroyOnError public void test() { throw new IllegalStateException(); } } And then inject said bean in say a Servlet and call the test() method, destruction of the bean happens partially, but as soon as Weld tried to invocate a preDestroy method, it goes through the bean proxy again, detects that "the" interceptor handler is already active, promptly skips its attempt to call a preDestroy method and then to add insult to injury tries to call a "proceed" method which is always null and thus throws a NPE. (this happens in org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke) I tried some alternative methods to destroy the bean such as: Bean bean = resolve(beanManager, beanClass); AlterableContext context = (AlterableContext) beanManager.getContext(bean.getScope()); context.destroy(bean); with resolve being: public static Bean resolve(BeanManager beanManager, Class beanClass) { Set> beans = beanManager.getBeans(beanClass); for (Bean bean : beans) { if (bean.getBeanClass() == beanClass) { return (Bean) beanManager.resolve(Collections.>singleton(bean)); } } return (Bean) beanManager.resolve(beans); } But this resulted in the same problem. Any idea? Kind regards, Arjan Tijms From struberg at yahoo.de Mon Nov 10 10:21:30 2014 From: struberg at yahoo.de (Mark Struberg) Date: Mon, 10 Nov 2014 15:21:30 +0000 Subject: [cdi-dev] Destroying beans from an interceptor In-Reply-To: References: Message-ID: <1415632890.18311.YahooMailNeo@web28902.mail.ir2.yahoo.com> Did I understand this correctly? You like to destroy the contextual instance you are currently intercepting? If so, then I fear you would effectively kill yourself. Please remember that an interceptor and decorator is per specification always a @Dependent scoped 1:1 instance of the contextual instance it intercepts or decorates. Thus it also gets stored in the CreationalContext of your very contextual instance. And by destroying the contextual instance it's CreationalContext gets properly cleaned up and destroyed as well. While doing so it will also destroy your interceptor/decorator. Doesn't sound that healthy to me... Maybe that might work for simple examples, but don't forget that real world apps are no samples but much more complex and the side effects might be really ugly and highly non-portable. Have a bad gut feeling about it. LieGrue, strub > On Monday, 10 November 2014, 14:59, arjan tijms wrote: > > Hi, > > I wonder if it would be allowed according to the CDI spec to destroy a > bean instance from within an interceptor. > > To test this (on Weld) I used the following code: > > @Interceptor > @DestroyOnError > @Priority(APPLICATION) > public class DestroyOnErrorInterceptor implements Serializable { > > private static final long serialVersionUID = 1L; > > @AroundInvoke > public Object tryInvoke(InvocationContext ctx) throws Exception { > > try { > return ctx.proceed(); > } catch (Exception e) { > destroy(ctx.getMethod().getDeclaringClass()); > throw e; > } > } > > private void destroy(Class clazz) { > Instance instance = CDI.current().select(clazz); > instance.destroy(instance.get()); > } > > } > > > When I use this interceptor on a SessionScoped bean: > > @SessionScoped > public class TestBean implements Serializable { > > private static final long serialVersionUID = 1L; > > @DestroyOnError > public void test() { > throw new IllegalStateException(); > } > } > > And then inject said bean in say a Servlet and call the test() method, > destruction of the bean happens partially, but as soon as Weld tried > to invocate a preDestroy method, it goes through the bean proxy again, > detects that "the" interceptor handler is already active, promptly > skips its attempt to call a preDestroy method and then to add insult > to injury tries to call a "proceed" method which is always null and > thus throws a NPE. > > (this happens in > org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke) > > I tried some alternative methods to destroy the bean such as: > > > Bean bean = resolve(beanManager, beanClass); > > AlterableContext context = (AlterableContext) > beanManager.getContext(bean.getScope()); > context.destroy(bean); > > with resolve being: > > public static Bean resolve(BeanManager beanManager, > Class beanClass) { > Set> beans = beanManager.getBeans(beanClass); > > for (Bean bean : beans) { > if (bean.getBeanClass() == beanClass) { > return (Bean) > beanManager.resolve(Collections.>singleton(bean)); > } > } > > return (Bean) beanManager.resolve(beans); > } > > But this resulted in the same problem. > > Any idea? > > 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 Mon Nov 10 10:43:55 2014 From: arjan.tijms at gmail.com (arjan tijms) Date: Mon, 10 Nov 2014 16:43:55 +0100 Subject: [cdi-dev] Destroying beans from an interceptor In-Reply-To: <1415632890.18311.YahooMailNeo@web28902.mail.ir2.yahoo.com> References: <1415632890.18311.YahooMailNeo@web28902.mail.ir2.yahoo.com> Message-ID: Hi, On Mon, Nov 10, 2014 at 4:21 PM, Mark Struberg wrote: > Did I understand this correctly? You like to destroy the contextual instance you are currently intercepting? Indeed, I hoped that if the interceptor method that called the destroy doesn't do anything after that call and just immediately exits there could be little harm done. > If so, then I fear you would effectively kill yourself. Perhaps, so that's unfortunate indeed. It -does- work when another request thread within the same session calls the destroy method, even when the first thread is still inside the session scoped bean or interceptor. This other thread apparently gets a different proxy instance. > Doesn't sound that healthy to me... Do you know of any other way via which I could automatically destroy a bean after an exception? What I'm looking for is more of a "pure interceptor"; a stateless interceptor that depends on nothing. Basically what I would get if I manually wrapped an object. As such I've been looking for a way to wrap the proxy that CDI injects, but as of yet I haven't found a way to do so. What I'm trying to implement is a copy of the feature EJB session beans have, where a bean instance is by default automatically destroyed after a (system) exception. Kind regards, Arjan Tijms > > Maybe that might work for simple examples, but don't forget that real world apps are no samples but much more complex and the side effects might be really ugly and highly non-portable. Have a bad gut feeling about it. > > > LieGrue, > strub > > > > >> On Monday, 10 November 2014, 14:59, arjan tijms wrote: >> > Hi, >> >> I wonder if it would be allowed according to the CDI spec to destroy a >> bean instance from within an interceptor. >> >> To test this (on Weld) I used the following code: >> >> @Interceptor >> @DestroyOnError >> @Priority(APPLICATION) >> public class DestroyOnErrorInterceptor implements Serializable { >> >> private static final long serialVersionUID = 1L; >> >> @AroundInvoke >> public Object tryInvoke(InvocationContext ctx) throws Exception { >> >> try { >> return ctx.proceed(); >> } catch (Exception e) { >> destroy(ctx.getMethod().getDeclaringClass()); >> throw e; >> } >> } >> >> private void destroy(Class clazz) { >> Instance instance = CDI.current().select(clazz); >> instance.destroy(instance.get()); >> } >> >> } >> >> >> When I use this interceptor on a SessionScoped bean: >> >> @SessionScoped >> public class TestBean implements Serializable { >> >> private static final long serialVersionUID = 1L; >> >> @DestroyOnError >> public void test() { >> throw new IllegalStateException(); >> } >> } >> >> And then inject said bean in say a Servlet and call the test() method, >> destruction of the bean happens partially, but as soon as Weld tried >> to invocate a preDestroy method, it goes through the bean proxy again, >> detects that "the" interceptor handler is already active, promptly >> skips its attempt to call a preDestroy method and then to add insult >> to injury tries to call a "proceed" method which is always null and >> thus throws a NPE. >> >> (this happens in >> org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke) >> >> I tried some alternative methods to destroy the bean such as: >> >> >> Bean bean = resolve(beanManager, beanClass); >> >> AlterableContext context = (AlterableContext) >> beanManager.getContext(bean.getScope()); >> context.destroy(bean); >> >> with resolve being: >> >> public static Bean resolve(BeanManager beanManager, >> Class beanClass) { >> Set> beans = beanManager.getBeans(beanClass); >> >> for (Bean bean : beans) { >> if (bean.getBeanClass() == beanClass) { >> return (Bean) >> beanManager.resolve(Collections.>singleton(bean)); >> } >> } >> >> return (Bean) beanManager.resolve(beans); >> } >> >> But this resulted in the same problem. >> >> Any idea? >> >> 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 Mon Nov 10 11:18:26 2014 From: arjan.tijms at gmail.com (arjan tijms) Date: Mon, 10 Nov 2014 17:18:26 +0100 Subject: [cdi-dev] Destroying beans from an interceptor In-Reply-To: <1415632890.18311.YahooMailNeo@web28902.mail.ir2.yahoo.com> References: <1415632890.18311.YahooMailNeo@web28902.mail.ir2.yahoo.com> Message-ID: p.s. Not sure if I'm venturing even deeper in no-no land now, but if I wrap the InjectionTarget for a bean with the @DestroyOnError annotation and subsequently do nothing in the void preDestroy(X instance) method, then everything -seems- to work. From antonio.goncalves at gmail.com Tue Nov 11 05:02:20 2014 From: antonio.goncalves at gmail.com (Antonio Goncalves) Date: Tue, 11 Nov 2014 11:02:20 +0100 Subject: [cdi-dev] Funny exception in generating rest endoint Message-ID: During the HoL one guy had this problem (on windows) generating REST endpoints. The generated code is ok, and everything works fine, but here is the stack trace ---------- Forwarded message ---------- From: Ilya Masharov Date: 2014-11-11 10:30 GMT+01:00 Subject: Forge stacktrace To: antonio.goncalves at gmail.com 11:29:22,655 SEVERE [org.jboss.forge.addon.ui.impl.controller.AbstractCommandController] (AeshProcess: 45) Error while notifying listeners: java.lang.ClassCastException: java.util.ArrayList cannot be cast to org.jboss.forge.addon.resource.FileResource at org.jboss.forge.addon.projects.Projects.getSelectedProject(Projects.java:37) at org.jboss.forge.addon.projects.ui.ProjectBuildStatusListener.postCommandExecuted(ProjectBuildStatusListener.java:41) at sun.reflect.GeneratedMethodAccessor135.invoke(Unknown Source) [:1.8.0_05] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_05] at java.lang.reflect.Method.invoke(Method.java:483) [rt.jar:1.8.0_05] at org.jboss.forge.furnace.proxy.ClassLoaderInterceptor$1.call(ClassLoaderInterceptor.java:87) [furnace-proxy-2.10.1.Final.jar:2.10.1.Final] at org.jboss.forge.furnace.util.ClassLoaders.executeIn(ClassLoaders.java:42) [furnace-api-2.10.1.Final.jar:2.10.1.Final] at org.jboss.forge.furnace.proxy.ClassLoaderInterceptor.invoke(ClassLoaderInterceptor.java:103) [furnace-proxy-2.10.1.Final.jar:2.10.1.Final] at org.jboss.forge.addon.projects.ui.ProjectBuildStatusListener_$$_javassist_55c47aad-8fa7-4e5a-86e8-9fc7e27f9cef.postCommandExecuted(ProjectBuildStatusListener_$$_javassist_55c47aad-8fa7-4e5a-86e8-9fc7e27f9cef.java) at org.jboss.forge.addon.ui.impl.controller.AbstractCommandController.firePostCommandExecuted(AbstractCommandController.java:144) [ui-impl-2.10.1.Final.jar:2.10.1.Final] at org.jboss.forge.addon.ui.impl.controller.SingleCommandControllerImpl.execute(SingleCommandControllerImpl.java:89) [ui-impl-2.10.1.Final.jar:2.10.1.Final] at org.jboss.forge.addon.shell.aesh.CommandAdapter.execute(CommandAdapter.java:74) [shell-impl-2.10.1.Final.jar:2.10.1.Final] at org.jboss.aesh.console.AeshConsoleImpl$AeshConsoleCallbackImpl.execute(AeshConsoleImpl.java:325) [aesh-0.56.1.jar:0.56.1] at org.jboss.aesh.console.AeshProcess.run(AeshProcess.java:40) [aesh-0.56.1.jar:0.56.1] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_05] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_05] at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_05] -- -- Antonio Goncalves (antonio.goncalves at gmail.com) Software architect Web site : www.antoniogoncalves.org Blog: agoncal.wordpress.com Feed: feeds2.feedburner.com/AntonioGoncalves Paris JUG leader : www.parisjug.org LinkedIn: www.linkedin.com/in/agoncal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20141111/588cb52c/attachment.html From antoine at sabot-durand.net Wed Nov 12 08:03:18 2014 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Wed, 12 Nov 2014 14:03:18 +0100 Subject: [cdi-dev] Canceling meeting Message-ID: <8AE098CD-E2FB-4714-AB0F-143A06D77E03@sabot-durand.net> Hi guys, I'm having meeting with other spec leads at Devoxx during our time slot so won't be available for today's meeting. We'll catch up next week Antoine Sabot-Durand From jharting at redhat.com Wed Nov 12 13:49:51 2014 From: jharting at redhat.com (Jozef Hartinger) Date: Wed, 12 Nov 2014 19:49:51 +0100 Subject: [cdi-dev] Destroying beans from an interceptor In-Reply-To: References: Message-ID: <5463ABCF.9020405@redhat.com> Hi Arjan, there is a bug in Weld (WELD-1785) preventing this from working which is going to be fixed in the next release. What you are doing should work IMO as long as the interceptor does not call any other methods on the target instance. In addition it must count with the target instance being destroyed within the instance.destroy() call. Perhaps a nicer way of doing this would be: @Inject @Intercepted private Bean bean; Context context = manager.getContext(bean.getScope()); if (!(context instanceof AlterableContext)) { throw new IllegalStateException("Context does not support removal of instances"); } AlterableContext alterableContext = AlterableContext.class.cast(context); alterableContext.destroy(bean); On 11/10/2014 02:59 PM, arjan tijms wrote: > Hi, > > I wonder if it would be allowed according to the CDI spec to destroy a > bean instance from within an interceptor. > > To test this (on Weld) I used the following code: > > @Interceptor > @DestroyOnError > @Priority(APPLICATION) > public class DestroyOnErrorInterceptor implements Serializable { > > private static final long serialVersionUID = 1L; > > @AroundInvoke > public Object tryInvoke(InvocationContext ctx) throws Exception { > > try { > return ctx.proceed(); > } catch (Exception e) { > destroy(ctx.getMethod().getDeclaringClass()); > throw e; > } > } > > private void destroy(Class clazz) { > Instance instance = CDI.current().select(clazz); > instance.destroy(instance.get()); > } > > } > > > When I use this interceptor on a SessionScoped bean: > > @SessionScoped > public class TestBean implements Serializable { > > private static final long serialVersionUID = 1L; > > @DestroyOnError > public void test() { > throw new IllegalStateException(); > } > } > > And then inject said bean in say a Servlet and call the test() method, > destruction of the bean happens partially, but as soon as Weld tried > to invocate a preDestroy method, it goes through the bean proxy again, > detects that "the" interceptor handler is already active, promptly > skips its attempt to call a preDestroy method and then to add insult > to injury tries to call a "proceed" method which is always null and > thus throws a NPE. > > (this happens in > org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke) > > I tried some alternative methods to destroy the bean such as: > > > Bean bean = resolve(beanManager, beanClass); > > AlterableContext context = (AlterableContext) > beanManager.getContext(bean.getScope()); > context.destroy(bean); > > with resolve being: > > public static Bean resolve(BeanManager beanManager, Class beanClass) { > Set> beans = beanManager.getBeans(beanClass); > > for (Bean bean : beans) { > if (bean.getBeanClass() == beanClass) { > return (Bean) > beanManager.resolve(Collections.>singleton(bean)); > } > } > > return (Bean) beanManager.resolve(beans); > } > > But this resulted in the same problem. > > Any idea? > > 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 Thu Nov 13 10:27:43 2014 From: arjan.tijms at gmail.com (arjan tijms) Date: Thu, 13 Nov 2014 16:27:43 +0100 Subject: [cdi-dev] Destroying beans from an interceptor In-Reply-To: <5463ABCF.9020405@redhat.com> References: <5463ABCF.9020405@redhat.com> Message-ID: Hi, On Wednesday, November 12, 2014, Jozef Hartinger wrote: > Hi Arjan, > > there is a bug in Weld (WELD-1785) preventing this from working which is > going to be fixed in the next release. What you are doing should work IMO > as long as the interceptor does not call any other methods on the target > instance. That's great to hear really. I'm slightly confused through why Mark thinks this cannot really work, while you say it should. Is there something in the spec that may need to be clarified here? Ie some words about what an interceptor is at least allowed to do and what is definitely not allowed? > In addition it must count with the target instance being destroyed within > the instance.destroy() call. Sorry, I don't fully follow this. You mean something must be counted? > > Perhaps a nicer way of doing this would be: > > @Inject > @Intercepted > private Bean bean; > > Context context = manager.getContext(bean.getScope()); > if (!(context instanceof AlterableContext)) { > throw new IllegalStateException("Context does not support > removal of instances"); > } > AlterableContext alterableContext = AlterableContext.class.cast( > context); > alterableContext.destroy(bean); I tried something close to that as well, just used the bean manager to resolve a Bean from the target object. Thanks for the suggestion! Kind regards, Arjan > > On 11/10/2014 02:59 PM, arjan tijms wrote: > >> Hi, >> >> I wonder if it would be allowed according to the CDI spec to destroy a >> bean instance from within an interceptor. >> >> To test this (on Weld) I used the following code: >> >> @Interceptor >> @DestroyOnError >> @Priority(APPLICATION) >> public class DestroyOnErrorInterceptor implements Serializable { >> >> private static final long serialVersionUID = 1L; >> >> @AroundInvoke >> public Object tryInvoke(InvocationContext ctx) throws Exception { >> >> try { >> return ctx.proceed(); >> } catch (Exception e) { >> destroy(ctx.getMethod().getDeclaringClass()); >> throw e; >> } >> } >> >> private void destroy(Class clazz) { >> Instance instance = CDI.current().select(clazz); >> instance.destroy(instance.get()); >> } >> >> } >> >> >> When I use this interceptor on a SessionScoped bean: >> >> @SessionScoped >> public class TestBean implements Serializable { >> >> private static final long serialVersionUID = 1L; >> >> @DestroyOnError >> public void test() { >> throw new IllegalStateException(); >> } >> } >> >> And then inject said bean in say a Servlet and call the test() method, >> destruction of the bean happens partially, but as soon as Weld tried >> to invocate a preDestroy method, it goes through the bean proxy again, >> detects that "the" interceptor handler is already active, promptly >> skips its attempt to call a preDestroy method and then to add insult >> to injury tries to call a "proceed" method which is always null and >> thus throws a NPE. >> >> (this happens in >> org.jboss.weld.bean.proxy.CombinedInterceptorAndDecorato >> rStackMethodHandler.invoke) >> >> I tried some alternative methods to destroy the bean such as: >> >> >> Bean bean = resolve(beanManager, beanClass); >> >> AlterableContext context = (AlterableContext) >> beanManager.getContext(bean.getScope()); >> context.destroy(bean); >> >> with resolve being: >> >> public static Bean resolve(BeanManager beanManager, Class >> beanClass) { >> Set> beans = beanManager.getBeans(beanClass); >> >> for (Bean bean : beans) { >> if (bean.getBeanClass() == beanClass) { >> return (Bean) >> beanManager.resolve(Collections.>singleton(bean)); >> } >> } >> >> return (Bean) beanManager.resolve(beans); >> } >> >> But this resulted in the same problem. >> >> Any idea? >> >> 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/20141113/2be8fc7c/attachment-0001.html From struberg at yahoo.de Fri Nov 14 03:14:17 2014 From: struberg at yahoo.de (Mark Struberg) Date: Fri, 14 Nov 2014 08:14:17 +0000 Subject: [cdi-dev] Destroying beans from an interceptor In-Reply-To: References: <5463ABCF.9020405@redhat.com> Message-ID: <1415952857.93146.YahooMailNeo@web28904.mail.ir2.yahoo.com> I did not say it cannot work but that it is not guaranteed to work. It's just totally up to implementation details of the container and your actual situation. Basically it's non-portable at best. E.g. consider the case that you are NOT the outermost interceptor but there are 2 other decorators and interceptors. The decorators will probably not hurt much as they are defined to be called _after_ interceptors. But if there is an interceptor in addition to yours then you will probably kill em and after returning from the chain you might end up in a dead bean (the other interceptor). There are just so many things which can go wrong. Even though I like the general idea what you like to do with that interceptor. But I suggest you probably use another trick. Every CDI bean must (as per the interceptors spec) support 'self-interception'. Means you only need to add an @AroundInvoke method and do the re-setup of your CONNECTION inside your @ApplicationScoped bean (with full access to the underlying business infrastructure). This is fundamentally different to your approach as I do not ditch the whole service but only fix the thing which broke in it. LieGrue, strub On Thursday, 13 November 2014, 16:28, arjan tijms wrote: >Hi, > >On Wednesday, November 12, 2014, Jozef Hartinger wrote: > >Hi Arjan, >> >>there is a bug in Weld (WELD-1785) preventing this from working which is going to be fixed in the next release. What you are doing should work IMO as long as the interceptor does not call any other methods on the target instance. > > >That's great to hear really. > > >I'm slightly confused through why Mark thinks this cannot really work, while you say it should. > > >Is there something in the spec that may need to be clarified here? Ie some words about what an interceptor is at least allowed to do and what is definitely not allowed? > > > >In addition it must count with the target instance being destroyed within the instance.destroy() call. > > >Sorry, I don't fully follow this. You mean something must be counted? > > >>Perhaps a nicer way of doing this would be: >> >>@Inject >>@Intercepted >>private Bean bean; >> >> Context context = manager.getContext(bean.getScope()); >> if (!(context instanceof AlterableContext)) { >> throw new IllegalStateException("Context does not support removal of instances"); >> } >> AlterableContext alterableContext = AlterableContext.class.cast(context); >> alterableContext.destroy(bean); > > >I tried something close to that as well, just used the bean manager to resolve a Bean from the target object. Thanks for the suggestion! > > >Kind regards, >Arjan > > > > >>On 11/10/2014 02:59 PM, arjan tijms wrote: >> >>Hi, >>> >>>I wonder if it would be allowed according to the CDI spec to destroy a >>>bean instance from within an interceptor. >>> >>>To test this (on Weld) I used the following code: >>> >>>@Interceptor >>>@DestroyOnError >>>@Priority(APPLICATION) >>>public class DestroyOnErrorInterceptor implements Serializable { >>> >>> private static final long serialVersionUID = 1L; >>> >>> @AroundInvoke >>> public Object tryInvoke(InvocationContext ctx) throws Exception { >>> >>> try { >>> return ctx.proceed(); >>> } catch (Exception e) { >>> destroy(ctx.getMethod().getDeclaringClass()); >>> throw e; >>> } >>> } >>> >>> private void destroy(Class clazz) { >>> Instance instance = CDI.current().select(clazz); >>> instance.destroy(instance.get()); >>> } >>> >>>} >>> >>> >>>When I use this interceptor on a SessionScoped bean: >>> >>>@SessionScoped >>>public class TestBean implements Serializable { >>> >>> private static final long serialVersionUID = 1L; >>> >>> @DestroyOnError >>> public void test() { >>> throw new IllegalStateException(); >>> } >>>} >>> >>>And then inject said bean in say a Servlet and call the test() method, >>>destruction of the bean happens partially, but as soon as Weld tried >>>to invocate a preDestroy method, it goes through the bean proxy again, >>>detects that "the" interceptor handler is already active, promptly >>>skips its attempt to call a preDestroy method and then to add insult >>>to injury tries to call a "proceed" method which is always null and >>>thus throws a NPE. >>> >>>(this happens in >>>org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke) >>> >>>I tried some alternative methods to destroy the bean such as: >>> >>> >>>Bean bean = resolve(beanManager, beanClass); >>> >>>AlterableContext context = (AlterableContext) >>>beanManager.getContext(bean.getScope()); >>>context.destroy(bean); >>> >>>with resolve being: >>> >>>public static Bean resolve(BeanManager beanManager, Class beanClass) { >>> Set> beans = beanManager.getBeans(beanClass); >>> >>> for (Bean bean : beans) { >>> if (bean.getBeanClass() == beanClass) { >>> return (Bean) >>>beanManager.resolve(Collections.>singleton(bean)); >>> } >>> } >>> >>> return (Bean) beanManager.resolve(beans); >>> } >>> >>>But this resulted in the same problem. >>> >>>Any idea? >>> >>>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. > > From jharting at redhat.com Fri Nov 14 04:46:50 2014 From: jharting at redhat.com (Jozef Hartinger) Date: Fri, 14 Nov 2014 10:46:50 +0100 Subject: [cdi-dev] Destroying beans from an interceptor In-Reply-To: <1415952857.93146.YahooMailNeo@web28904.mail.ir2.yahoo.com> References: <5463ABCF.9020405@redhat.com> <1415952857.93146.YahooMailNeo@web28904.mail.ir2.yahoo.com> Message-ID: <5465CF8A.5010508@redhat.com> On 11/14/2014 09:14 AM, Mark Struberg wrote: > I did not say it cannot work but that it is not guaranteed to work. It's just totally up to implementation details of the container and your actual situation. Basically it's non-portable at best. > > > E.g. consider the case that you are NOT the outermost interceptor but there are 2 other decorators and interceptors. The decorators will probably not hurt much as they are defined to be called _after_ interceptors. But if there is an interceptor in addition to yours then you will probably kill em and after returning from the chain you might end up in a dead bean (the other interceptor). You are right Mark but I think this is not a problem of whether you call AlterableContext.destroy() from within an interceptor or not. This is a more general problem of destroying instances. Say you have an intercepted @ApplicationScoped bean Foo. Thread 1 is calling an intercepted method and is currently in the middle of the interceptor chain. Thread 2 calls AlterableContext.destroy(Foo) in a Servlet (not from an interceptor!). Foo is destroyed together with its interceptors by Thread 2. Thread 1 finds itself executing a dead interceptor chain for a destroyed bean. > > There are just so many things which can go wrong. Even though I like the general idea what you like to do with that interceptor. But I suggest you probably use another trick. Every CDI bean must (as per the interceptors spec) support 'self-interception'. Means you only need to add an @AroundInvoke method and do the re-setup of your CONNECTION inside your @ApplicationScoped bean (with full access to the underlying business infrastructure). > > > This is fundamentally different to your approach as I do not ditch the whole service but only fix the thing which broke in it. > > > LieGrue, > strub > > > > On Thursday, 13 November 2014, 16:28, arjan tijms wrote: >> Hi, >> >> On Wednesday, November 12, 2014, Jozef Hartinger wrote: >> >> Hi Arjan, >>> there is a bug in Weld (WELD-1785) preventing this from working which is going to be fixed in the next release. What you are doing should work IMO as long as the interceptor does not call any other methods on the target instance. >> >> That's great to hear really. >> >> >> I'm slightly confused through why Mark thinks this cannot really work, while you say it should. >> >> >> Is there something in the spec that may need to be clarified here? Ie some words about what an interceptor is at least allowed to do and what is definitely not allowed? >> >> >> >> In addition it must count with the target instance being destroyed within the instance.destroy() call. >> >> >> Sorry, I don't fully follow this. You mean something must be counted? >> >> >>> Perhaps a nicer way of doing this would be: >>> >>> @Inject >>> @Intercepted >>> private Bean bean; >>> >>> Context context = manager.getContext(bean.getScope()); >>> if (!(context instanceof AlterableContext)) { >>> throw new IllegalStateException("Context does not support removal of instances"); >>> } >>> AlterableContext alterableContext = AlterableContext.class.cast(context); >>> alterableContext.destroy(bean); >> >> I tried something close to that as well, just used the bean manager to resolve a Bean from the target object. Thanks for the suggestion! >> >> >> Kind regards, >> Arjan >> >> >> >> >>> On 11/10/2014 02:59 PM, arjan tijms wrote: >>> >>> Hi, >>>> I wonder if it would be allowed according to the CDI spec to destroy a >>>> bean instance from within an interceptor. >>>> >>>> To test this (on Weld) I used the following code: >>>> >>>> @Interceptor >>>> @DestroyOnError >>>> @Priority(APPLICATION) >>>> public class DestroyOnErrorInterceptor implements Serializable { >>>> >>>> private static final long serialVersionUID = 1L; >>>> >>>> @AroundInvoke >>>> public Object tryInvoke(InvocationContext ctx) throws Exception { >>>> >>>> try { >>>> return ctx.proceed(); >>>> } catch (Exception e) { >>>> destroy(ctx.getMethod().getDeclaringClass()); >>>> throw e; >>>> } >>>> } >>>> >>>> private void destroy(Class clazz) { >>>> Instance instance = CDI.current().select(clazz); >>>> instance.destroy(instance.get()); >>>> } >>>> >>>> } >>>> >>>> >>>> When I use this interceptor on a SessionScoped bean: >>>> >>>> @SessionScoped >>>> public class TestBean implements Serializable { >>>> >>>> private static final long serialVersionUID = 1L; >>>> >>>> @DestroyOnError >>>> public void test() { >>>> throw new IllegalStateException(); >>>> } >>>> } >>>> >>>> And then inject said bean in say a Servlet and call the test() method, >>>> destruction of the bean happens partially, but as soon as Weld tried >>>> to invocate a preDestroy method, it goes through the bean proxy again, >>>> detects that "the" interceptor handler is already active, promptly >>>> skips its attempt to call a preDestroy method and then to add insult >>>> to injury tries to call a "proceed" method which is always null and >>>> thus throws a NPE. >>>> >>>> (this happens in >>>> org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke) >>>> >>>> I tried some alternative methods to destroy the bean such as: >>>> >>>> >>>> Bean bean = resolve(beanManager, beanClass); >>>> >>>> AlterableContext context = (AlterableContext) >>>> beanManager.getContext(bean.getScope()); >>>> context.destroy(bean); >>>> >>>> with resolve being: >>>> >>>> public static Bean resolve(BeanManager beanManager, Class beanClass) { >>>> Set> beans = beanManager.getBeans(beanClass); >>>> >>>> for (Bean bean : beans) { >>>> if (bean.getBeanClass() == beanClass) { >>>> return (Bean) >>>> beanManager.resolve(Collections.>singleton(bean)); >>>> } >>>> } >>>> >>>> return (Bean) beanManager.resolve(beans); >>>> } >>>> >>>> But this resulted in the same problem. >>>> >>>> Any idea? >>>> >>>> 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. >> >> From jharting at redhat.com Fri Nov 14 04:49:05 2014 From: jharting at redhat.com (Jozef Hartinger) Date: Fri, 14 Nov 2014 10:49:05 +0100 Subject: [cdi-dev] Destroying beans from an interceptor In-Reply-To: References: <5463ABCF.9020405@redhat.com> Message-ID: <5465D011.9010102@redhat.com> On 11/13/2014 04:27 PM, arjan tijms wrote: > Hi, > > On Wednesday, November 12, 2014, Jozef Hartinger > wrote: > > Hi Arjan, > > there is a bug in Weld (WELD-1785) preventing this from working > which is going to be fixed in the next release. What you are doing > should work IMO as long as the interceptor does not call any other > methods on the target instance. > > > That's great to hear really. > > I'm slightly confused through why Mark thinks this cannot really work, > while you say it should. Don't be confused by that. This often happens to me and Mark :-) > > Is there something in the spec that may need to be clarified here? Ie > some words about what an interceptor is at least allowed to do and > what is definitely not allowed? > > In addition it must count with the target instance being destroyed > within the instance.destroy() call. > > > Sorry, I don't fully follow this. You mean something must be counted? I mean that the interceptor (and others in the chain) should be tolerant and not be surprised finding itself and the target bean destroyed immediately after the instance.destroy() call. > > > Perhaps a nicer way of doing this would be: > > @Inject > @Intercepted > private Bean bean; > > Context context = manager.getContext(bean.getScope()); > if (!(context instanceof AlterableContext)) { > throw new IllegalStateException("Context does not > support removal of instances"); > } > AlterableContext alterableContext = > AlterableContext.class.cast(context); > alterableContext.destroy(bean); > > > I tried something close to that as well, just used the bean manager to > resolve a Bean from the target object. Thanks for the suggestion! > > Kind regards, > Arjan > > > On 11/10/2014 02:59 PM, arjan tijms wrote: > > Hi, > > I wonder if it would be allowed according to the CDI spec to > destroy a > bean instance from within an interceptor. > > To test this (on Weld) I used the following code: > > @Interceptor > @DestroyOnError > @Priority(APPLICATION) > public class DestroyOnErrorInterceptor implements Serializable { > > private static final long serialVersionUID = 1L; > > @AroundInvoke > public Object tryInvoke(InvocationContext ctx) throws > Exception { > > try { > return ctx.proceed(); > } catch (Exception e) { > destroy(ctx.getMethod().getDeclaringClass()); > throw e; > } > } > > private void destroy(Class clazz) { > Instance instance = CDI.current().select(clazz); > instance.destroy(instance.get()); > } > > } > > > When I use this interceptor on a SessionScoped bean: > > @SessionScoped > public class TestBean implements Serializable { > > private static final long serialVersionUID = 1L; > > @DestroyOnError > public void test() { > throw new IllegalStateException(); > } > } > > And then inject said bean in say a Servlet and call the test() > method, > destruction of the bean happens partially, but as soon as Weld > tried > to invocate a preDestroy method, it goes through the bean > proxy again, > detects that "the" interceptor handler is already active, promptly > skips its attempt to call a preDestroy method and then to add > insult > to injury tries to call a "proceed" method which is always > null and > thus throws a NPE. > > (this happens in > org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke) > > I tried some alternative methods to destroy the bean such as: > > > Bean bean = resolve(beanManager, beanClass); > > AlterableContext context = (AlterableContext) > beanManager.getContext(bean.getScope()); > context.destroy(bean); > > with resolve being: > > public static Bean resolve(BeanManager beanManager, > Class beanClass) { > Set> beans = beanManager.getBeans(beanClass); > > for (Bean bean : beans) { > if (bean.getBeanClass() == beanClass) { > return (Bean) > beanManager.resolve(Collections.>singleton(bean)); > } > } > > return (Bean) beanManager.resolve(beans); > } > > But this resulted in the same problem. > > Any idea? > > 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/20141114/3ad08a78/attachment-0001.html From struberg at yahoo.de Fri Nov 14 05:01:18 2014 From: struberg at yahoo.de (Mark Struberg) Date: Fri, 14 Nov 2014 10:01:18 +0000 Subject: [cdi-dev] Destroying beans from an interceptor In-Reply-To: <5465CF8A.5010508@redhat.com> References: <5463ABCF.9020405@redhat.com> <1415952857.93146.YahooMailNeo@web28904.mail.ir2.yahoo.com> <5465CF8A.5010508@redhat.com> Message-ID: <1415959278.30743.YahooMailNeo@web28901.mail.ir2.yahoo.com> I got your point Jozef, and I fear you are right. This is just pretty dangerous in highly concurrent scenarios :/ LieGrue, strub > On Friday, 14 November 2014, 10:47, Jozef Hartinger wrote: > > > On 11/14/2014 09:14 AM, Mark Struberg wrote: >> I did not say it cannot work but that it is not guaranteed to work. > It's just totally up to implementation details of the container and your > actual situation. Basically it's non-portable at best. >> >> >> E.g. consider the case that you are NOT the outermost interceptor but there > are 2 other decorators and interceptors. The decorators will probably not hurt > much as they are defined to be called _after_ interceptors. But if there is an > interceptor in addition to yours then you will probably kill em and after > returning from the chain you might end up in a dead bean (the other > interceptor). > You are right Mark but I think this is not a problem of whether you call > AlterableContext.destroy() from within an interceptor or not. This is a > more general problem of destroying instances. Say you have an > intercepted @ApplicationScoped bean Foo. Thread 1 is calling an > intercepted method and is currently in the middle of the interceptor > chain. Thread 2 calls AlterableContext.destroy(Foo) in a Servlet (not > from an interceptor!). Foo is destroyed together with its interceptors > by Thread 2. Thread 1 finds itself executing a dead interceptor chain > for a destroyed bean. > >> >> There are just so many things which can go wrong. Even though I like the > general idea what you like to do with that interceptor. But I suggest you > probably use another trick. Every CDI bean must (as per the interceptors spec) > support 'self-interception'. Means you only need to add an @AroundInvoke > method and do the re-setup of your CONNECTION inside your @ApplicationScoped > bean (with full access to the underlying business infrastructure). >> >> >> This is fundamentally different to your approach as I do not ditch the > whole service but only fix the thing which broke in it. >> >> >> LieGrue, >> strub >> >> >> >> On Thursday, 13 November 2014, 16:28, arjan tijms > wrote: >>> Hi, >>> >>> On Wednesday, November 12, 2014, Jozef Hartinger > wrote: >>> >>> Hi Arjan, >>>> there is a bug in Weld (WELD-1785) preventing this from working > which is going to be fixed in the next release. What you are doing should work > IMO as long as the interceptor does not call any other methods on the target > instance. >>> >>> That's great to hear really. >>> >>> >>> I'm slightly confused through why Mark thinks this cannot really > work, while you say it should. >>> >>> >>> Is there something in the spec that may need to be clarified here? Ie > some words about what an interceptor is at least allowed to do and what is > definitely not allowed? >>> >>> >>> >>> In addition it must count with the target instance being destroyed > within the instance.destroy() call. >>> >>> >>> Sorry, I don't fully follow this. You mean something must be > counted? >>> >>> >>>> Perhaps a nicer way of doing this would be: >>>> >>>> @Inject >>>> @Intercepted >>>> private Bean bean; >>>> >>>> Context context = manager.getContext(bean.getScope()); >>>> if (!(context instanceof AlterableContext)) { >>>> throw new IllegalStateException("Context does not > support removal of instances"); >>>> } >>>> AlterableContext alterableContext = > AlterableContext.class.cast(context); >>>> alterableContext.destroy(bean); >>> >>> I tried something close to that as well, just used the bean manager to > resolve a Bean from the target object. Thanks for the suggestion! >>> >>> >>> Kind regards, >>> Arjan >>> >>> >>> >>> >>>> On 11/10/2014 02:59 PM, arjan tijms wrote: >>>> >>>> Hi, >>>>> I wonder if it would be allowed according to the CDI spec to > destroy a >>>>> bean instance from within an interceptor. >>>>> >>>>> To test this (on Weld) I used the following code: >>>>> >>>>> @Interceptor >>>>> @DestroyOnError >>>>> @Priority(APPLICATION) >>>>> public class DestroyOnErrorInterceptor implements Serializable > { >>>>> >>>>> private static final long serialVersionUID = 1L; >>>>> >>>>> @AroundInvoke >>>>> public Object tryInvoke(InvocationContext ctx) throws > Exception { >>>>> >>>>> try { >>>>> return ctx.proceed(); >>>>> } catch (Exception e) { >>>>> destroy(ctx.getMethod().getDeclaringClass()); >>>>> throw e; >>>>> } >>>>> } >>>>> >>>>> private void destroy(Class clazz) > { >>>>> Instance instance = > CDI.current().select(clazz); >>>>> instance.destroy(instance.get()); >>>>> } >>>>> >>>>> } >>>>> >>>>> >>>>> When I use this interceptor on a SessionScoped bean: >>>>> >>>>> @SessionScoped >>>>> public class TestBean implements Serializable { >>>>> >>>>> private static final long serialVersionUID = 1L; >>>>> >>>>> @DestroyOnError >>>>> public void test() { >>>>> throw new IllegalStateException(); >>>>> } >>>>> } >>>>> >>>>> And then inject said bean in say a Servlet and call the test() > method, >>>>> destruction of the bean happens partially, but as soon as Weld > tried >>>>> to invocate a preDestroy method, it goes through the bean proxy > again, >>>>> detects that "the" interceptor handler is already > active, promptly >>>>> skips its attempt to call a preDestroy method and then to add > insult >>>>> to injury tries to call a "proceed" method which is > always null and >>>>> thus throws a NPE. >>>>> >>>>> (this happens in >>>>> > org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke) >>>>> >>>>> I tried some alternative methods to destroy the bean such as: >>>>> >>>>> >>>>> Bean bean = resolve(beanManager, beanClass); >>>>> >>>>> AlterableContext context = (AlterableContext) >>>>> beanManager.getContext(bean.getScope()); >>>>> context.destroy(bean); >>>>> >>>>> with resolve being: >>>>> >>>>> public static Bean resolve(BeanManager > beanManager, Class beanClass) { >>>>> Set> beans = > beanManager.getBeans(beanClass); >>>>> >>>>> for (Bean bean : beans) { >>>>> if (bean.getBeanClass() == beanClass) { >>>>> return (Bean) >>>>> > beanManager.resolve(Collections.>singleton(bean)); >>>>> } >>>>> } >>>>> >>>>> return (Bean) beanManager.resolve(beans); >>>>> } >>>>> >>>>> But this resulted in the same problem. >>>>> >>>>> Any idea? >>>>> >>>>> 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. >>> >>> > From arjan.tijms at gmail.com Fri Nov 14 11:27:18 2014 From: arjan.tijms at gmail.com (arjan tijms) Date: Fri, 14 Nov 2014 17:27:18 +0100 Subject: [cdi-dev] Destroying beans from an interceptor In-Reply-To: <5465CF8A.5010508@redhat.com> References: <5463ABCF.9020405@redhat.com> <1415952857.93146.YahooMailNeo@web28904.mail.ir2.yahoo.com> <5465CF8A.5010508@redhat.com> Message-ID: Hi, On Friday, November 14, 2014, Jozef Hartinger > wrote: > > On 11/14/2014 09:14 AM, Mark Struberg wrote: > >> I did not say it cannot work but that it is not guaranteed to work. It's >> just totally up to implementation details of the container and your actual >> situation. Basically it's non-portable at best. >> >> >> E.g. consider the case that you are NOT the outermost interceptor but >> there are 2 other decorators and interceptors. The decorators will probably >> not hurt much as they are defined to be called _after_ interceptors. But if >> there is an interceptor in addition to yours then you will probably kill em >> and after returning from the chain you might end up in a dead bean (the >> other interceptor). >> > You are right Mark but I think this is not a problem of whether you call > AlterableContext.destroy() from within an interceptor or not. This is a > more general problem of destroying instances. Say you have an intercepted > @ApplicationScoped bean Foo. Thread 1 is calling an intercepted method and > is currently in the middle of the interceptor chain. Thread 2 calls > AlterableContext.destroy(Foo) in a Servlet (not from an interceptor!). Foo > is destroyed together with its interceptors by Thread 2. Thread 1 finds > itself executing a dead interceptor chain for a destroyed bean. It looks like the issue may be even more general. I have to do some more tests to confirm, but I think I observed a situation where thread 1 at the end of a request destroyed session scoped bean Foo in a Servlet. At that point thread 2 was already using bean Foo, and it kept getting the same instance from the proxy and could even destroy the bean again. Meanwhile, while thread 2 was getting the destroyed bean instance, thread 3 that started after the instance was destroyed by thread 1 did get a new instance. It looked like some TLS caching issue, but as said I have to do some more tests to see if this can be reproduced. Kind regards, Arjan Tijms >> There are just so many things which can go wrong. Even though I like the >> general idea what you like to do with that interceptor. But I suggest you >> probably use another trick. Every CDI bean must (as per the interceptors >> spec) support 'self-interception'. Means you only need to add an >> @AroundInvoke method and do the re-setup of your CONNECTION inside your >> @ApplicationScoped bean (with full access to the underlying business >> infrastructure). >> >> >> This is fundamentally different to your approach as I do not ditch the >> whole service but only fix the thing which broke in it. >> >> >> LieGrue, >> strub >> >> >> >> On Thursday, 13 November 2014, 16:28, arjan tijms >> wrote: >> >>> Hi, >>> >>> On Wednesday, November 12, 2014, Jozef Hartinger >>> wrote: >>> >>> Hi Arjan, >>> >>>> there is a bug in Weld (WELD-1785) preventing this from working which >>>> is going to be fixed in the next release. What you are doing should work >>>> IMO as long as the interceptor does not call any other methods on the >>>> target instance. >>>> >>> >>> That's great to hear really. >>> >>> >>> I'm slightly confused through why Mark thinks this cannot really work, >>> while you say it should. >>> >>> >>> Is there something in the spec that may need to be clarified here? Ie >>> some words about what an interceptor is at least allowed to do and what is >>> definitely not allowed? >>> >>> >>> >>> In addition it must count with the target instance being destroyed >>> within the instance.destroy() call. >>> >>> >>> Sorry, I don't fully follow this. You mean something must be counted? >>> >>> >>> Perhaps a nicer way of doing this would be: >>>> >>>> @Inject >>>> @Intercepted >>>> private Bean bean; >>>> >>>> Context context = manager.getContext(bean.getScope()); >>>> if (!(context instanceof AlterableContext)) { >>>> throw new IllegalStateException("Context does not support >>>> removal of instances"); >>>> } >>>> AlterableContext alterableContext = AlterableContext.class.cast( >>>> context); >>>> alterableContext.destroy(bean); >>>> >>> >>> I tried something close to that as well, just used the bean manager to >>> resolve a Bean from the target object. Thanks for the suggestion! >>> >>> >>> Kind regards, >>> Arjan >>> >>> >>> >>> >>> On 11/10/2014 02:59 PM, arjan tijms wrote: >>>> >>>> Hi, >>>> >>>>> I wonder if it would be allowed according to the CDI spec to destroy a >>>>> bean instance from within an interceptor. >>>>> >>>>> To test this (on Weld) I used the following code: >>>>> >>>>> @Interceptor >>>>> @DestroyOnError >>>>> @Priority(APPLICATION) >>>>> public class DestroyOnErrorInterceptor implements Serializable { >>>>> >>>>> private static final long serialVersionUID = 1L; >>>>> >>>>> @AroundInvoke >>>>> public Object tryInvoke(InvocationContext ctx) throws Exception { >>>>> >>>>> try { >>>>> return ctx.proceed(); >>>>> } catch (Exception e) { >>>>> destroy(ctx.getMethod().getDeclaringClass()); >>>>> throw e; >>>>> } >>>>> } >>>>> >>>>> private void destroy(Class clazz) { >>>>> Instance instance = CDI.current().select(clazz); >>>>> instance.destroy(instance.get()); >>>>> } >>>>> >>>>> } >>>>> >>>>> >>>>> When I use this interceptor on a SessionScoped bean: >>>>> >>>>> @SessionScoped >>>>> public class TestBean implements Serializable { >>>>> >>>>> private static final long serialVersionUID = 1L; >>>>> >>>>> @DestroyOnError >>>>> public void test() { >>>>> throw new IllegalStateException(); >>>>> } >>>>> } >>>>> >>>>> And then inject said bean in say a Servlet and call the test() method, >>>>> destruction of the bean happens partially, but as soon as Weld tried >>>>> to invocate a preDestroy method, it goes through the bean proxy again, >>>>> detects that "the" interceptor handler is already active, promptly >>>>> skips its attempt to call a preDestroy method and then to add insult >>>>> to injury tries to call a "proceed" method which is always null and >>>>> thus throws a NPE. >>>>> >>>>> (this happens in >>>>> org.jboss.weld.bean.proxy.CombinedInterceptorAndDecorato >>>>> rStackMethodHandler.invoke) >>>>> >>>>> I tried some alternative methods to destroy the bean such as: >>>>> >>>>> >>>>> Bean bean = resolve(beanManager, beanClass); >>>>> >>>>> AlterableContext context = (AlterableContext) >>>>> beanManager.getContext(bean.getScope()); >>>>> context.destroy(bean); >>>>> >>>>> with resolve being: >>>>> >>>>> public static Bean resolve(BeanManager beanManager, Class >>>>> beanClass) { >>>>> Set> beans = beanManager.getBeans(beanClass); >>>>> >>>>> for (Bean bean : beans) { >>>>> if (bean.getBeanClass() == beanClass) { >>>>> return (Bean) >>>>> beanManager.resolve(Collections.>singleton(bean)); >>>>> } >>>>> } >>>>> >>>>> return (Bean) beanManager.resolve(beans); >>>>> } >>>>> >>>>> But this resulted in the same problem. >>>>> >>>>> Any idea? >>>>> >>>>> 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/20141114/ac70ce62/attachment-0001.html From antoine at sabot-durand.net Mon Nov 17 01:17:02 2014 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Mon, 17 Nov 2014 07:17:02 +0100 Subject: [cdi-dev] Next meeting proposed agenda Message-ID: Hi All, Sorry for the 2 previous meeting I had to cancel for personal issue and Devoxx. I propose we adopt the following agenda for the next meeting (wednesday 18:00 CET / 17:00 GMT) - Java SE support (I?ll try to provide a doc before the meeting) - Asynchronous event scenarios - Feedback on AtInject initiative. If you want to add something else, please let me know. Regards Antoine From antoine at sabot-durand.net Mon Nov 17 08:57:27 2014 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Mon, 17 Nov 2014 14:57:27 +0100 Subject: [cdi-dev] Feedback from Devoxx Message-ID: Hi all, Just to give you a small feedback of my Devoxx week regarding CDI and CDI 2.0 (for the rest, what happens in Devoxx stays in Devoxx ;) ) 1) Great expectations: I?m not going to state the obvious, but end user and other specs are watching us and expect a lot from CDI 2.0 (the question of total EJB replacement came more than once) 2) Antonin Stefanutti and myself delivered a very valuable content in our CDI advanced university. I don?t remember being so proud of a talk material I released before. I encourage you to give it an eye and use it if you want. you can watch it on Slideshare [1] or grab the source slides on Antonin?s Github repo [2] 3) Other spec are really willing to have a better integration. I met JMS, Servlet, JSF and MVC spec leaders, they all are looking for a better integration with CDI and are ok to take CDI specific part related to their spec back in their spec (Servlet and JSF mostly). Working with them will bring a more consistent Java EE and will reduce extra code from the spec. 4) After months of discussion I finally met Jurgen Hoeller (Spring Framework) and Christian Gruber (Dagger and Guice) and we all agreed on a new version or MR of AtInject spec. Juergen will probably be the spec lead and we hope to have the big work done before mid 2015 (cross finger) to met our various agenda. That will probably add extra work for CDI 2.0 but will bring clarity and a good signal to the community. Thanks to Antonio who helped me on this. For those who remember the history of JSR 330 and JSR 299 the following picture will be nearly an historical one ;) [3] Antoine [1] http://www.slideshare.net/antoinesd/going-further-with-cdi-41411812 [2] https://github.com/astefanutti/further-cdi [3] http://twitter.com/antoine_sd/status/533710069255667712/photo/1 From arjan.tijms at gmail.com Mon Nov 17 10:28:08 2014 From: arjan.tijms at gmail.com (arjan tijms) Date: Mon, 17 Nov 2014 16:28:08 +0100 Subject: [cdi-dev] Feedback from Devoxx In-Reply-To: References: Message-ID: Hi, On Mon, Nov 17, 2014 at 2:57 PM, Antoine Sabot-Durand wrote: > Just to give you a small feedback of my Devoxx week regarding CDI and CDI 2.0 (for the rest, what happens in Devoxx stays in Devoxx ;) ) > > 1) Great expectations: > [...] (the question of total EJB replacement came more than once) I heard this a number of times as well, both before and during Devoxx. A great number of issues for decoupling EJB features (meaning, providing CDI based replacements) have already been created as spec issues: * Decoupling the @Schedule annotation from the EJB component model (EJB_SPEC-1) * Decoupling the TimerService API from the EJB component model (EJB_SPEC-2) * Decoupling the @Asynchronous annotation from the EJB component model (EJB_SPEC-3) * Decoupling the @Lock/@AccessTimeout annotations from the EJB component model (EJB_SPEC-4) * Decoupling the @Startup/@DependsOn annotations from the EJB component model (EJB_SPEC-19) * Standardize Pooling and Decouple from EJB Component Model (EJB_SPEC-113) * Redefine Message Driven Beans as Managed Beans (EJB_SPEC-18) * Standardize Abstractions for Common Message Processing Patterns (JMS_SPEC-154) * Allow Java EE components other than MDBs to consume messages asynchronously (JMS_SPEC-100) * Bind JMS to CDI events and/or business interfaces (JMS_SPEC-88) * Support for "self" injection (CDI-414) * Allow access-control related JSR-250 security annotations on managed beans (JAVASERVERFACES_SPEC_PUBLIC-495) * Support @RolesAllowed on a Servlet (SERVLET_SPEC-29) There are some additional features that may not yet have been covered (but maybe I missed them), such as: * Control over passivation * Support for the extended persistence context * Destroying a bean whenever an exception occurs (I was just working on this the other week) * Logging the exception thrown by a bean (yes, trivial, but part of EJB) * The concept where every method call on a proxy is routed to another bean instance, which is then automatically unavailable for other calls as long as it doesn't return (related to the "Standardize Pooling" issue) * Binary remoting without all the explicit mapping that's needed for say JAX-RS (yes, thorny issue which we may not wish to support anymore?) * General support for @RolesAllowed/@RunAs etc (often mentioned, and two issues for JSF managed beans resp Servlets were created, but no general issue) The question is perhaps where all this functionality should live. TimerService and @Asynchronous in the concurrency spec? All JMS/messaging listener stuff (aka MDB replacements) in the JMS spec? @RolesAllowed etc in the security spec (if that spec will actually happen) @Startup in the CDI spec itself? Destroying bean on exception in CDI spec? But where should e.g. pooling belong? Kind regards, Arjan Tijms From antonio.goncalves at gmail.com Mon Nov 17 10:53:11 2014 From: antonio.goncalves at gmail.com (Antonio Goncalves) Date: Mon, 17 Nov 2014 16:53:11 +0100 Subject: [cdi-dev] Feedback from Devoxx In-Reply-To: References: Message-ID: @Startup could also make sense in Concurrency in Java EE, like @Pooling (there's thread pools behind). BTW I was talking to the Oracle guys and it looks like the Concurrency spec will be updated in EE 8... I don't know how far the update will go. As for the JMS stuff, we talked with Nigel and he likes the idea of MDB replacement going to where it belongs : the JMS spec Antonio On Mon, Nov 17, 2014 at 4:28 PM, arjan tijms wrote: > Hi, > > On Mon, Nov 17, 2014 at 2:57 PM, Antoine Sabot-Durand > wrote: > > Just to give you a small feedback of my Devoxx week regarding CDI and > CDI 2.0 (for the rest, what happens in Devoxx stays in Devoxx ;) ) > > > > 1) Great expectations: > > [...] (the question of total EJB replacement came more than once) > > I heard this a number of times as well, both before and during Devoxx. > > A great number of issues for decoupling EJB features (meaning, > providing CDI based replacements) have already been created as spec > issues: > > * Decoupling the @Schedule annotation from the EJB component model > (EJB_SPEC-1) > * Decoupling the TimerService API from the EJB component model (EJB_SPEC-2) > * Decoupling the @Asynchronous annotation from the EJB component model > (EJB_SPEC-3) > * Decoupling the @Lock/@AccessTimeout annotations from the EJB > component model (EJB_SPEC-4) > * Decoupling the @Startup/@DependsOn annotations from the EJB > component model (EJB_SPEC-19) > * Standardize Pooling and Decouple from EJB Component Model (EJB_SPEC-113) > * Redefine Message Driven Beans as Managed Beans (EJB_SPEC-18) > * Standardize Abstractions for Common Message Processing Patterns > (JMS_SPEC-154) > * Allow Java EE components other than MDBs to consume messages > asynchronously (JMS_SPEC-100) > * Bind JMS to CDI events and/or business interfaces (JMS_SPEC-88) > * Support for "self" injection (CDI-414) > * Allow access-control related JSR-250 security annotations on managed > beans (JAVASERVERFACES_SPEC_PUBLIC-495) > * Support @RolesAllowed on a Servlet (SERVLET_SPEC-29) > > > There are some additional features that may not yet have been covered > (but maybe I missed them), such as: > > * Control over passivation > * Support for the extended persistence context > * Destroying a bean whenever an exception occurs (I was just working > on this the other week) > * Logging the exception thrown by a bean (yes, trivial, but part of EJB) > * The concept where every method call on a proxy is routed to another > bean instance, which is then automatically unavailable for other calls > as long as it doesn't return (related to the "Standardize Pooling" > issue) > * Binary remoting without all the explicit mapping that's needed for > say JAX-RS (yes, thorny issue which we may not wish to support > anymore?) > * General support for @RolesAllowed/@RunAs etc (often mentioned, and > two issues for JSF managed beans resp Servlets were created, but no > general issue) > > The question is perhaps where all this functionality should live. > > TimerService and @Asynchronous in the concurrency spec? > All JMS/messaging listener stuff (aka MDB replacements) in the JMS spec? > @RolesAllowed etc in the security spec (if that spec will actually happen) > @Startup in the CDI spec itself? > Destroying bean on exception in CDI spec? > > But where should e.g. pooling belong? > > 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. > -- Antonio Goncalves Software architect, Java Champion and Pluralsight author Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20141117/433e8f0f/attachment.html From rmannibucau at gmail.com Mon Nov 17 10:55:45 2014 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Mon, 17 Nov 2014 16:55:45 +0100 Subject: [cdi-dev] Feedback from Devoxx In-Reply-To: References: Message-ID: 2014-11-17 16:53 GMT+01:00 Antonio Goncalves : > @Startup could also make sense in Concurrency in Java EE, like @Pooling > (there's thread pools behind). BTW I was talking to the Oracle guys and it > looks like the Concurrency spec will be updated in EE 8... I don't know how > far the update will go. > > As for the JMS stuff, we talked with Nigel and he likes the idea of MDB > replacement going to where it belongs : the JMS spec > MDBs are not all JMS so IMO MDBs don't belong to JMS at all. Would be a big regression to do it. In particular when EE 8/9 will bring nicer connectors > Antonio > > On Mon, Nov 17, 2014 at 4:28 PM, arjan tijms wrote: >> >> Hi, >> >> On Mon, Nov 17, 2014 at 2:57 PM, Antoine Sabot-Durand >> wrote: >> > Just to give you a small feedback of my Devoxx week regarding CDI and >> > CDI 2.0 (for the rest, what happens in Devoxx stays in Devoxx ;) ) >> > >> > 1) Great expectations: >> > [...] (the question of total EJB replacement came more than once) >> >> I heard this a number of times as well, both before and during Devoxx. >> >> A great number of issues for decoupling EJB features (meaning, >> providing CDI based replacements) have already been created as spec >> issues: >> >> * Decoupling the @Schedule annotation from the EJB component model >> (EJB_SPEC-1) >> * Decoupling the TimerService API from the EJB component model >> (EJB_SPEC-2) >> * Decoupling the @Asynchronous annotation from the EJB component model >> (EJB_SPEC-3) >> * Decoupling the @Lock/@AccessTimeout annotations from the EJB >> component model (EJB_SPEC-4) >> * Decoupling the @Startup/@DependsOn annotations from the EJB >> component model (EJB_SPEC-19) >> * Standardize Pooling and Decouple from EJB Component Model (EJB_SPEC-113) >> * Redefine Message Driven Beans as Managed Beans (EJB_SPEC-18) >> * Standardize Abstractions for Common Message Processing Patterns >> (JMS_SPEC-154) >> * Allow Java EE components other than MDBs to consume messages >> asynchronously (JMS_SPEC-100) >> * Bind JMS to CDI events and/or business interfaces (JMS_SPEC-88) >> * Support for "self" injection (CDI-414) >> * Allow access-control related JSR-250 security annotations on managed >> beans (JAVASERVERFACES_SPEC_PUBLIC-495) >> * Support @RolesAllowed on a Servlet (SERVLET_SPEC-29) >> >> >> There are some additional features that may not yet have been covered >> (but maybe I missed them), such as: >> >> * Control over passivation >> * Support for the extended persistence context >> * Destroying a bean whenever an exception occurs (I was just working >> on this the other week) >> * Logging the exception thrown by a bean (yes, trivial, but part of EJB) >> * The concept where every method call on a proxy is routed to another >> bean instance, which is then automatically unavailable for other calls >> as long as it doesn't return (related to the "Standardize Pooling" >> issue) >> * Binary remoting without all the explicit mapping that's needed for >> say JAX-RS (yes, thorny issue which we may not wish to support >> anymore?) >> * General support for @RolesAllowed/@RunAs etc (often mentioned, and >> two issues for JSF managed beans resp Servlets were created, but no >> general issue) >> >> The question is perhaps where all this functionality should live. >> >> TimerService and @Asynchronous in the concurrency spec? >> All JMS/messaging listener stuff (aka MDB replacements) in the JMS spec? >> @RolesAllowed etc in the security spec (if that spec will actually happen) >> @Startup in the CDI spec itself? >> Destroying bean on exception in CDI spec? >> >> But where should e.g. pooling belong? >> >> 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. > > > > > -- > 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 Nov 17 10:58:36 2014 From: antonio.goncalves at gmail.com (Antonio Goncalves) Date: Mon, 17 Nov 2014 16:58:36 +0100 Subject: [cdi-dev] Feedback from Devoxx In-Reply-To: References: Message-ID: It won't be called "MDBs", just "Managed Listeners". The JMS spec will still have listeners and now it will get managed listeners. Antonio On Mon, Nov 17, 2014 at 4:55 PM, Romain Manni-Bucau wrote: > 2014-11-17 16:53 GMT+01:00 Antonio Goncalves >: > > @Startup could also make sense in Concurrency in Java EE, like @Pooling > > (there's thread pools behind). BTW I was talking to the Oracle guys and > it > > looks like the Concurrency spec will be updated in EE 8... I don't know > how > > far the update will go. > > > > As for the JMS stuff, we talked with Nigel and he likes the idea of MDB > > replacement going to where it belongs : the JMS spec > > > > MDBs are not all JMS so IMO MDBs don't belong to JMS at all. Would be > a big regression to do it. In particular when EE 8/9 will bring nicer > connectors > > > Antonio > > > > On Mon, Nov 17, 2014 at 4:28 PM, arjan tijms > wrote: > >> > >> Hi, > >> > >> On Mon, Nov 17, 2014 at 2:57 PM, Antoine Sabot-Durand > >> wrote: > >> > Just to give you a small feedback of my Devoxx week regarding CDI and > >> > CDI 2.0 (for the rest, what happens in Devoxx stays in Devoxx ;) ) > >> > > >> > 1) Great expectations: > >> > [...] (the question of total EJB replacement came more than once) > >> > >> I heard this a number of times as well, both before and during Devoxx. > >> > >> A great number of issues for decoupling EJB features (meaning, > >> providing CDI based replacements) have already been created as spec > >> issues: > >> > >> * Decoupling the @Schedule annotation from the EJB component model > >> (EJB_SPEC-1) > >> * Decoupling the TimerService API from the EJB component model > >> (EJB_SPEC-2) > >> * Decoupling the @Asynchronous annotation from the EJB component model > >> (EJB_SPEC-3) > >> * Decoupling the @Lock/@AccessTimeout annotations from the EJB > >> component model (EJB_SPEC-4) > >> * Decoupling the @Startup/@DependsOn annotations from the EJB > >> component model (EJB_SPEC-19) > >> * Standardize Pooling and Decouple from EJB Component Model > (EJB_SPEC-113) > >> * Redefine Message Driven Beans as Managed Beans (EJB_SPEC-18) > >> * Standardize Abstractions for Common Message Processing Patterns > >> (JMS_SPEC-154) > >> * Allow Java EE components other than MDBs to consume messages > >> asynchronously (JMS_SPEC-100) > >> * Bind JMS to CDI events and/or business interfaces (JMS_SPEC-88) > >> * Support for "self" injection (CDI-414) > >> * Allow access-control related JSR-250 security annotations on managed > >> beans (JAVASERVERFACES_SPEC_PUBLIC-495) > >> * Support @RolesAllowed on a Servlet (SERVLET_SPEC-29) > >> > >> > >> There are some additional features that may not yet have been covered > >> (but maybe I missed them), such as: > >> > >> * Control over passivation > >> * Support for the extended persistence context > >> * Destroying a bean whenever an exception occurs (I was just working > >> on this the other week) > >> * Logging the exception thrown by a bean (yes, trivial, but part of EJB) > >> * The concept where every method call on a proxy is routed to another > >> bean instance, which is then automatically unavailable for other calls > >> as long as it doesn't return (related to the "Standardize Pooling" > >> issue) > >> * Binary remoting without all the explicit mapping that's needed for > >> say JAX-RS (yes, thorny issue which we may not wish to support > >> anymore?) > >> * General support for @RolesAllowed/@RunAs etc (often mentioned, and > >> two issues for JSF managed beans resp Servlets were created, but no > >> general issue) > >> > >> The question is perhaps where all this functionality should live. > >> > >> TimerService and @Asynchronous in the concurrency spec? > >> All JMS/messaging listener stuff (aka MDB replacements) in the JMS spec? > >> @RolesAllowed etc in the security spec (if that spec will actually > happen) > >> @Startup in the CDI spec itself? > >> Destroying bean on exception in CDI spec? > >> > >> But where should e.g. pooling belong? > >> > >> 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. > > > > > > > > > > -- > > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20141117/79877f1b/attachment.html From rmannibucau at gmail.com Mon Nov 17 11:04:35 2014 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Mon, 17 Nov 2014 17:04:35 +0100 Subject: [cdi-dev] Feedback from Devoxx In-Reply-To: References: Message-ID: 2014-11-17 16:58 GMT+01:00 Antonio Goncalves : > It won't be called "MDBs", just "Managed Listeners". The JMS spec will still > have listeners and now it will get managed listeners. > Ok get it, what I meant was mainly that connectors should integrate with CDI rather than doing anything specific for MDBs, no? > Antonio > > On Mon, Nov 17, 2014 at 4:55 PM, Romain Manni-Bucau > wrote: >> >> 2014-11-17 16:53 GMT+01:00 Antonio Goncalves >> : >> > @Startup could also make sense in Concurrency in Java EE, like @Pooling >> > (there's thread pools behind). BTW I was talking to the Oracle guys and >> > it >> > looks like the Concurrency spec will be updated in EE 8... I don't know >> > how >> > far the update will go. >> > >> > As for the JMS stuff, we talked with Nigel and he likes the idea of MDB >> > replacement going to where it belongs : the JMS spec >> > >> >> MDBs are not all JMS so IMO MDBs don't belong to JMS at all. Would be >> a big regression to do it. In particular when EE 8/9 will bring nicer >> connectors >> >> > Antonio >> > >> > On Mon, Nov 17, 2014 at 4:28 PM, arjan tijms >> > wrote: >> >> >> >> Hi, >> >> >> >> On Mon, Nov 17, 2014 at 2:57 PM, Antoine Sabot-Durand >> >> wrote: >> >> > Just to give you a small feedback of my Devoxx week regarding CDI and >> >> > CDI 2.0 (for the rest, what happens in Devoxx stays in Devoxx ;) ) >> >> > >> >> > 1) Great expectations: >> >> > [...] (the question of total EJB replacement came more than once) >> >> >> >> I heard this a number of times as well, both before and during Devoxx. >> >> >> >> A great number of issues for decoupling EJB features (meaning, >> >> providing CDI based replacements) have already been created as spec >> >> issues: >> >> >> >> * Decoupling the @Schedule annotation from the EJB component model >> >> (EJB_SPEC-1) >> >> * Decoupling the TimerService API from the EJB component model >> >> (EJB_SPEC-2) >> >> * Decoupling the @Asynchronous annotation from the EJB component model >> >> (EJB_SPEC-3) >> >> * Decoupling the @Lock/@AccessTimeout annotations from the EJB >> >> component model (EJB_SPEC-4) >> >> * Decoupling the @Startup/@DependsOn annotations from the EJB >> >> component model (EJB_SPEC-19) >> >> * Standardize Pooling and Decouple from EJB Component Model >> >> (EJB_SPEC-113) >> >> * Redefine Message Driven Beans as Managed Beans (EJB_SPEC-18) >> >> * Standardize Abstractions for Common Message Processing Patterns >> >> (JMS_SPEC-154) >> >> * Allow Java EE components other than MDBs to consume messages >> >> asynchronously (JMS_SPEC-100) >> >> * Bind JMS to CDI events and/or business interfaces (JMS_SPEC-88) >> >> * Support for "self" injection (CDI-414) >> >> * Allow access-control related JSR-250 security annotations on managed >> >> beans (JAVASERVERFACES_SPEC_PUBLIC-495) >> >> * Support @RolesAllowed on a Servlet (SERVLET_SPEC-29) >> >> >> >> >> >> There are some additional features that may not yet have been covered >> >> (but maybe I missed them), such as: >> >> >> >> * Control over passivation >> >> * Support for the extended persistence context >> >> * Destroying a bean whenever an exception occurs (I was just working >> >> on this the other week) >> >> * Logging the exception thrown by a bean (yes, trivial, but part of >> >> EJB) >> >> * The concept where every method call on a proxy is routed to another >> >> bean instance, which is then automatically unavailable for other calls >> >> as long as it doesn't return (related to the "Standardize Pooling" >> >> issue) >> >> * Binary remoting without all the explicit mapping that's needed for >> >> say JAX-RS (yes, thorny issue which we may not wish to support >> >> anymore?) >> >> * General support for @RolesAllowed/@RunAs etc (often mentioned, and >> >> two issues for JSF managed beans resp Servlets were created, but no >> >> general issue) >> >> >> >> The question is perhaps where all this functionality should live. >> >> >> >> TimerService and @Asynchronous in the concurrency spec? >> >> All JMS/messaging listener stuff (aka MDB replacements) in the JMS >> >> spec? >> >> @RolesAllowed etc in the security spec (if that spec will actually >> >> happen) >> >> @Startup in the CDI spec itself? >> >> Destroying bean on exception in CDI spec? >> >> >> >> But where should e.g. pooling belong? >> >> >> >> 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. >> > >> > >> > >> > >> > -- >> > 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 From antoine at sabot-durand.net Mon Nov 17 11:30:35 2014 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Mon, 17 Nov 2014 17:30:35 +0100 Subject: [cdi-dev] Feedback from Devoxx In-Reply-To: References: Message-ID: <8D99A825-908E-4EB3-A1CA-93CFAD477F6A@sabot-durand.net> Guys, don?t forget the commons annotation specification since we?re going to ask for a MR for it. It could be a convenient solution to share annotation without having a huge dependency to have it (think of SE). Antoine > Le 17 nov. 2014 ? 16:53, Antonio Goncalves a ?crit : > > @Startup could also make sense in Concurrency in Java EE, like @Pooling (there's thread pools behind). BTW I was talking to the Oracle guys and it looks like the Concurrency spec will be updated in EE 8... I don't know how far the update will go. > > As for the JMS stuff, we talked with Nigel and he likes the idea of MDB replacement going to where it belongs : the JMS spec > > Antonio > > On Mon, Nov 17, 2014 at 4:28 PM, arjan tijms > wrote: > Hi, > > On Mon, Nov 17, 2014 at 2:57 PM, Antoine Sabot-Durand > > wrote: > > Just to give you a small feedback of my Devoxx week regarding CDI and CDI 2.0 (for the rest, what happens in Devoxx stays in Devoxx ;) ) > > > > 1) Great expectations: > > [...] (the question of total EJB replacement came more than once) > > I heard this a number of times as well, both before and during Devoxx. > > A great number of issues for decoupling EJB features (meaning, > providing CDI based replacements) have already been created as spec > issues: > > * Decoupling the @Schedule annotation from the EJB component model (EJB_SPEC-1) > * Decoupling the TimerService API from the EJB component model (EJB_SPEC-2) > * Decoupling the @Asynchronous annotation from the EJB component model > (EJB_SPEC-3) > * Decoupling the @Lock/@AccessTimeout annotations from the EJB > component model (EJB_SPEC-4) > * Decoupling the @Startup/@DependsOn annotations from the EJB > component model (EJB_SPEC-19) > * Standardize Pooling and Decouple from EJB Component Model (EJB_SPEC-113) > * Redefine Message Driven Beans as Managed Beans (EJB_SPEC-18) > * Standardize Abstractions for Common Message Processing Patterns (JMS_SPEC-154) > * Allow Java EE components other than MDBs to consume messages > asynchronously (JMS_SPEC-100) > * Bind JMS to CDI events and/or business interfaces (JMS_SPEC-88) > * Support for "self" injection (CDI-414) > * Allow access-control related JSR-250 security annotations on managed > beans (JAVASERVERFACES_SPEC_PUBLIC-495) > * Support @RolesAllowed on a Servlet (SERVLET_SPEC-29) > > > There are some additional features that may not yet have been covered > (but maybe I missed them), such as: > > * Control over passivation > * Support for the extended persistence context > * Destroying a bean whenever an exception occurs (I was just working > on this the other week) > * Logging the exception thrown by a bean (yes, trivial, but part of EJB) > * The concept where every method call on a proxy is routed to another > bean instance, which is then automatically unavailable for other calls > as long as it doesn't return (related to the "Standardize Pooling" > issue) > * Binary remoting without all the explicit mapping that's needed for > say JAX-RS (yes, thorny issue which we may not wish to support > anymore?) > * General support for @RolesAllowed/@RunAs etc (often mentioned, and > two issues for JSF managed beans resp Servlets were created, but no > general issue) > > The question is perhaps where all this functionality should live. > > TimerService and @Asynchronous in the concurrency spec? > All JMS/messaging listener stuff (aka MDB replacements) in the JMS spec? > @RolesAllowed etc in the security spec (if that spec will actually happen) > @Startup in the CDI spec itself? > Destroying bean on exception in CDI spec? > > But where should e.g. pooling belong? > > 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. > > > > -- > Antonio Goncalves > Software architect, Java Champion and Pluralsight author > > Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20141117/e208f8c5/attachment-0001.html From andraschko.thomas at gmail.com Mon Nov 17 14:48:50 2014 From: andraschko.thomas at gmail.com (Thomas Andraschko) Date: Mon, 17 Nov 2014 20:48:50 +0100 Subject: [cdi-dev] Important improvements for product development in CDI 2.0 In-Reply-To: References: Message-ID: Hi, Did you already had a change to think about #224? Sorry for the bump but its very important for me ;) Regards, Thomas Am Freitag, 17. Oktober 2014 schrieb Thomas Andraschko : > Hi, > > we have a big product with many subproducts/projects and customizations > for some customers. > CDI and JSF is really doing a great job here but i found 2 really annoying > issues which could be improved: > > - CDI-224: Allow decoration on classes, not only on interfaces > > We created many interfaces the last months for our beans just to get > decoration working > This is really annoying as this interfaces are just overhead and > actually senseless for us. > > > - CDI-407: Specify @Named @Alternatives > > Currently its not defined what should happen if a alternative has a > @Named and is activated via beans.xml in the current app: > > @Named public class A > @Named @Alternative public class B extends A > > or even something like: > > @Named public class A > @Specializes public class B extends A > @Named @Alternative public class B2 extends B > > IMO B and B2 should also be available via EL "a". > > > > This are really important issues for standard cases. > It would be great to see it in CDI 2.0. > > Best regards, > Thomas > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20141117/381ee66f/attachment.html From antonio.goncalves at gmail.com Mon Nov 17 15:53:22 2014 From: antonio.goncalves at gmail.com (Antonio Goncalves) Date: Mon, 17 Nov 2014 21:53:22 +0100 Subject: [cdi-dev] Feedback from Devoxx In-Reply-To: <8D99A825-908E-4EB3-A1CA-93CFAD477F6A@sabot-durand.net> References: <8D99A825-908E-4EB3-A1CA-93CFAD477F6A@sabot-durand.net> Message-ID: Would you like to see @Inject in JSR 250 ? I don't think it's a good idea to put everything in Commons Annotations. It makes sense to have @Startup, @Pooling, @Scedule, @Asynchronous where it fits better. Antonio On Mon, Nov 17, 2014 at 5:30 PM, Antoine Sabot-Durand < antoine at sabot-durand.net> wrote: > Guys, don?t forget the commons annotation specification since we?re going > to ask for a MR for it. It could be a convenient solution to share > annotation without having a huge dependency to have it (think of SE). > > Antoine > > > Le 17 nov. 2014 ? 16:53, Antonio Goncalves > a ?crit : > > @Startup could also make sense in Concurrency in Java EE, like @Pooling > (there's thread pools behind). BTW I was talking to the Oracle guys and > it looks like the Concurrency spec will be updated in EE 8... I don't know > how far the update will go. > > As for the JMS stuff, we talked with Nigel and he likes the idea of MDB > replacement going to where it belongs : the JMS spec > > Antonio > > On Mon, Nov 17, 2014 at 4:28 PM, arjan tijms > wrote: > >> Hi, >> >> On Mon, Nov 17, 2014 at 2:57 PM, Antoine Sabot-Durand >> wrote: >> > Just to give you a small feedback of my Devoxx week regarding CDI and >> CDI 2.0 (for the rest, what happens in Devoxx stays in Devoxx ;) ) >> > >> > 1) Great expectations: >> > [...] (the question of total EJB replacement came more than once) >> >> I heard this a number of times as well, both before and during Devoxx. >> >> A great number of issues for decoupling EJB features (meaning, >> providing CDI based replacements) have already been created as spec >> issues: >> >> * Decoupling the @Schedule annotation from the EJB component model >> (EJB_SPEC-1) >> * Decoupling the TimerService API from the EJB component model >> (EJB_SPEC-2) >> * Decoupling the @Asynchronous annotation from the EJB component model >> (EJB_SPEC-3) >> * Decoupling the @Lock/@AccessTimeout annotations from the EJB >> component model (EJB_SPEC-4) >> * Decoupling the @Startup/@DependsOn annotations from the EJB >> component model (EJB_SPEC-19) >> * Standardize Pooling and Decouple from EJB Component Model (EJB_SPEC-113) >> * Redefine Message Driven Beans as Managed Beans (EJB_SPEC-18) >> * Standardize Abstractions for Common Message Processing Patterns >> (JMS_SPEC-154) >> * Allow Java EE components other than MDBs to consume messages >> asynchronously (JMS_SPEC-100) >> * Bind JMS to CDI events and/or business interfaces (JMS_SPEC-88) >> * Support for "self" injection (CDI-414) >> * Allow access-control related JSR-250 security annotations on managed >> beans (JAVASERVERFACES_SPEC_PUBLIC-495) >> * Support @RolesAllowed on a Servlet (SERVLET_SPEC-29) >> >> >> There are some additional features that may not yet have been covered >> (but maybe I missed them), such as: >> >> * Control over passivation >> * Support for the extended persistence context >> * Destroying a bean whenever an exception occurs (I was just working >> on this the other week) >> * Logging the exception thrown by a bean (yes, trivial, but part of EJB) >> * The concept where every method call on a proxy is routed to another >> bean instance, which is then automatically unavailable for other calls >> as long as it doesn't return (related to the "Standardize Pooling" >> issue) >> * Binary remoting without all the explicit mapping that's needed for >> say JAX-RS (yes, thorny issue which we may not wish to support >> anymore?) >> * General support for @RolesAllowed/@RunAs etc (often mentioned, and >> two issues for JSF managed beans resp Servlets were created, but no >> general issue) >> >> The question is perhaps where all this functionality should live. >> >> TimerService and @Asynchronous in the concurrency spec? >> All JMS/messaging listener stuff (aka MDB replacements) in the JMS spec? >> @RolesAllowed etc in the security spec (if that spec will actually happen) >> @Startup in the CDI spec itself? >> Destroying bean on exception in CDI spec? >> >> But where should e.g. pooling belong? >> >> 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. >> > > > > -- > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20141117/3d454f67/attachment.html From rmannibucau at gmail.com Mon Nov 17 15:55:34 2014 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Mon, 17 Nov 2014 21:55:34 +0100 Subject: [cdi-dev] Feedback from Devoxx In-Reply-To: References: <8D99A825-908E-4EB3-A1CA-93CFAD477F6A@sabot-durand.net> Message-ID: 2014-11-17 21:53 GMT+01:00 Antonio Goncalves : > Would you like to see @Inject in JSR 250 ? I don't think it's a good idea to > put everything in Commons Annotations. It makes sense to have @Startup, > @Pooling, @Scedule, @Asynchronous where it fits better. > Why not keeping in EJBs (even if it needs to be renamed for historical reasons)? ie a spec on top of CDI, not <= CDI. > Antonio > > On Mon, Nov 17, 2014 at 5:30 PM, Antoine Sabot-Durand > wrote: >> >> Guys, don?t forget the commons annotation specification since we?re going >> to ask for a MR for it. It could be a convenient solution to share >> annotation without having a huge dependency to have it (think of SE). >> >> Antoine >> >> >> Le 17 nov. 2014 ? 16:53, Antonio Goncalves a >> ?crit : >> >> @Startup could also make sense in Concurrency in Java EE, like @Pooling >> (there's thread pools behind). BTW I was talking to the Oracle guys and it >> looks like the Concurrency spec will be updated in EE 8... I don't know how >> far the update will go. >> >> As for the JMS stuff, we talked with Nigel and he likes the idea of MDB >> replacement going to where it belongs : the JMS spec >> >> Antonio >> >> On Mon, Nov 17, 2014 at 4:28 PM, arjan tijms >> wrote: >>> >>> Hi, >>> >>> On Mon, Nov 17, 2014 at 2:57 PM, Antoine Sabot-Durand >>> wrote: >>> > Just to give you a small feedback of my Devoxx week regarding CDI and >>> > CDI 2.0 (for the rest, what happens in Devoxx stays in Devoxx ;) ) >>> > >>> > 1) Great expectations: >>> > [...] (the question of total EJB replacement came more than once) >>> >>> I heard this a number of times as well, both before and during Devoxx. >>> >>> A great number of issues for decoupling EJB features (meaning, >>> providing CDI based replacements) have already been created as spec >>> issues: >>> >>> * Decoupling the @Schedule annotation from the EJB component model >>> (EJB_SPEC-1) >>> * Decoupling the TimerService API from the EJB component model >>> (EJB_SPEC-2) >>> * Decoupling the @Asynchronous annotation from the EJB component model >>> (EJB_SPEC-3) >>> * Decoupling the @Lock/@AccessTimeout annotations from the EJB >>> component model (EJB_SPEC-4) >>> * Decoupling the @Startup/@DependsOn annotations from the EJB >>> component model (EJB_SPEC-19) >>> * Standardize Pooling and Decouple from EJB Component Model >>> (EJB_SPEC-113) >>> * Redefine Message Driven Beans as Managed Beans (EJB_SPEC-18) >>> * Standardize Abstractions for Common Message Processing Patterns >>> (JMS_SPEC-154) >>> * Allow Java EE components other than MDBs to consume messages >>> asynchronously (JMS_SPEC-100) >>> * Bind JMS to CDI events and/or business interfaces (JMS_SPEC-88) >>> * Support for "self" injection (CDI-414) >>> * Allow access-control related JSR-250 security annotations on managed >>> beans (JAVASERVERFACES_SPEC_PUBLIC-495) >>> * Support @RolesAllowed on a Servlet (SERVLET_SPEC-29) >>> >>> >>> There are some additional features that may not yet have been covered >>> (but maybe I missed them), such as: >>> >>> * Control over passivation >>> * Support for the extended persistence context >>> * Destroying a bean whenever an exception occurs (I was just working >>> on this the other week) >>> * Logging the exception thrown by a bean (yes, trivial, but part of EJB) >>> * The concept where every method call on a proxy is routed to another >>> bean instance, which is then automatically unavailable for other calls >>> as long as it doesn't return (related to the "Standardize Pooling" >>> issue) >>> * Binary remoting without all the explicit mapping that's needed for >>> say JAX-RS (yes, thorny issue which we may not wish to support >>> anymore?) >>> * General support for @RolesAllowed/@RunAs etc (often mentioned, and >>> two issues for JSF managed beans resp Servlets were created, but no >>> general issue) >>> >>> The question is perhaps where all this functionality should live. >>> >>> TimerService and @Asynchronous in the concurrency spec? >>> All JMS/messaging listener stuff (aka MDB replacements) in the JMS spec? >>> @RolesAllowed etc in the security spec (if that spec will actually >>> happen) >>> @Startup in the CDI spec itself? >>> Destroying bean on exception in CDI spec? >>> >>> But where should e.g. pooling belong? >>> >>> 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. >> >> >> >> >> -- >> 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 Nov 17 16:04:18 2014 From: antonio.goncalves at gmail.com (Antonio Goncalves) Date: Mon, 17 Nov 2014 22:04:18 +0100 Subject: [cdi-dev] Feedback from Devoxx In-Reply-To: References: <8D99A825-908E-4EB3-A1CA-93CFAD477F6A@sabot-durand.net> Message-ID: Like @dblevins once said "EJB was a super hype spec with all the cool features... and became blotted throughout the years". If we are not careful, CDI (the super hype spec at the moment) will become blotted too. Context and Dependency Injection should not deal with pooling, scheduling, security.... but yes, allow the other specs to implement such concerns. I can easily see most of these concerns implemented with interceptor bindings or extensions. When we talked to Nigel (JMS spec lead) he was really enthousiast to learn more about CDI and use it to help develop JMS internals. Manfred (JSF / MVC) who has already implemented most of the JSF stuff with CDI (@ViewScoped and so on) was really encouraging. I think that part of the job this CDI 2.0 expert group has is to evangelize current specs leads to use CDI in their internals. Antonio On Mon, Nov 17, 2014 at 9:55 PM, Romain Manni-Bucau wrote: > 2014-11-17 21:53 GMT+01:00 Antonio Goncalves >: > > Would you like to see @Inject in JSR 250 ? I don't think it's a good > idea to > > put everything in Commons Annotations. It makes sense to have @Startup, > > @Pooling, @Scedule, @Asynchronous where it fits better. > > > > Why not keeping in EJBs (even if it needs to be renamed for historical > reasons)? ie a spec on top of CDI, not <= CDI. > > > Antonio > > > > On Mon, Nov 17, 2014 at 5:30 PM, Antoine Sabot-Durand > > wrote: > >> > >> Guys, don?t forget the commons annotation specification since we?re > going > >> to ask for a MR for it. It could be a convenient solution to share > >> annotation without having a huge dependency to have it (think of SE). > >> > >> Antoine > >> > >> > >> Le 17 nov. 2014 ? 16:53, Antonio Goncalves > a > >> ?crit : > >> > >> @Startup could also make sense in Concurrency in Java EE, like @Pooling > >> (there's thread pools behind). BTW I was talking to the Oracle guys > and it > >> looks like the Concurrency spec will be updated in EE 8... I don't know > how > >> far the update will go. > >> > >> As for the JMS stuff, we talked with Nigel and he likes the idea of MDB > >> replacement going to where it belongs : the JMS spec > >> > >> Antonio > >> > >> On Mon, Nov 17, 2014 at 4:28 PM, arjan tijms > >> wrote: > >>> > >>> Hi, > >>> > >>> On Mon, Nov 17, 2014 at 2:57 PM, Antoine Sabot-Durand > >>> wrote: > >>> > Just to give you a small feedback of my Devoxx week regarding CDI and > >>> > CDI 2.0 (for the rest, what happens in Devoxx stays in Devoxx ;) ) > >>> > > >>> > 1) Great expectations: > >>> > [...] (the question of total EJB replacement came more than once) > >>> > >>> I heard this a number of times as well, both before and during Devoxx. > >>> > >>> A great number of issues for decoupling EJB features (meaning, > >>> providing CDI based replacements) have already been created as spec > >>> issues: > >>> > >>> * Decoupling the @Schedule annotation from the EJB component model > >>> (EJB_SPEC-1) > >>> * Decoupling the TimerService API from the EJB component model > >>> (EJB_SPEC-2) > >>> * Decoupling the @Asynchronous annotation from the EJB component model > >>> (EJB_SPEC-3) > >>> * Decoupling the @Lock/@AccessTimeout annotations from the EJB > >>> component model (EJB_SPEC-4) > >>> * Decoupling the @Startup/@DependsOn annotations from the EJB > >>> component model (EJB_SPEC-19) > >>> * Standardize Pooling and Decouple from EJB Component Model > >>> (EJB_SPEC-113) > >>> * Redefine Message Driven Beans as Managed Beans (EJB_SPEC-18) > >>> * Standardize Abstractions for Common Message Processing Patterns > >>> (JMS_SPEC-154) > >>> * Allow Java EE components other than MDBs to consume messages > >>> asynchronously (JMS_SPEC-100) > >>> * Bind JMS to CDI events and/or business interfaces (JMS_SPEC-88) > >>> * Support for "self" injection (CDI-414) > >>> * Allow access-control related JSR-250 security annotations on managed > >>> beans (JAVASERVERFACES_SPEC_PUBLIC-495) > >>> * Support @RolesAllowed on a Servlet (SERVLET_SPEC-29) > >>> > >>> > >>> There are some additional features that may not yet have been covered > >>> (but maybe I missed them), such as: > >>> > >>> * Control over passivation > >>> * Support for the extended persistence context > >>> * Destroying a bean whenever an exception occurs (I was just working > >>> on this the other week) > >>> * Logging the exception thrown by a bean (yes, trivial, but part of > EJB) > >>> * The concept where every method call on a proxy is routed to another > >>> bean instance, which is then automatically unavailable for other calls > >>> as long as it doesn't return (related to the "Standardize Pooling" > >>> issue) > >>> * Binary remoting without all the explicit mapping that's needed for > >>> say JAX-RS (yes, thorny issue which we may not wish to support > >>> anymore?) > >>> * General support for @RolesAllowed/@RunAs etc (often mentioned, and > >>> two issues for JSF managed beans resp Servlets were created, but no > >>> general issue) > >>> > >>> The question is perhaps where all this functionality should live. > >>> > >>> TimerService and @Asynchronous in the concurrency spec? > >>> All JMS/messaging listener stuff (aka MDB replacements) in the JMS > spec? > >>> @RolesAllowed etc in the security spec (if that spec will actually > >>> happen) > >>> @Startup in the CDI spec itself? > >>> Destroying bean on exception in CDI spec? > >>> > >>> But where should e.g. pooling belong? > >>> > >>> 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. > >> > >> > >> > >> > >> -- > >> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20141117/e34c25f9/attachment-0001.html From rmannibucau at gmail.com Mon Nov 17 16:10:27 2014 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Mon, 17 Nov 2014 22:10:27 +0100 Subject: [cdi-dev] Feedback from Devoxx In-Reply-To: References: <8D99A825-908E-4EB3-A1CA-93CFAD477F6A@sabot-durand.net> Message-ID: Actually it makes sense, we already have @Transactional so only security part is really missing from EJB spec - sorry for the noise. Is there a place with all asked features (JavaSE, @Pooling, easier SPI, config, ...)? then people could maybe vote? Romain Manni-Bucau @rmannibucau http://www.tomitribe.com http://rmannibucau.wordpress.com https://github.com/rmannibucau 2014-11-17 22:04 GMT+01:00 Antonio Goncalves : > Like @dblevins once said "EJB was a super hype spec with all the cool > features... and became blotted throughout the years". If we are not careful, > CDI (the super hype spec at the moment) will become blotted too. > > Context and Dependency Injection should not deal with pooling, scheduling, > security.... but yes, allow the other specs to implement such concerns. I > can easily see most of these concerns implemented with interceptor bindings > or extensions. > > When we talked to Nigel (JMS spec lead) he was really enthousiast to learn > more about CDI and use it to help develop JMS internals. Manfred (JSF / MVC) > who has already implemented most of the JSF stuff with CDI (@ViewScoped and > so on) was really encouraging. > > I think that part of the job this CDI 2.0 expert group has is to evangelize > current specs leads to use CDI in their internals. > > Antonio > > On Mon, Nov 17, 2014 at 9:55 PM, Romain Manni-Bucau > wrote: >> >> 2014-11-17 21:53 GMT+01:00 Antonio Goncalves >> : >> > Would you like to see @Inject in JSR 250 ? I don't think it's a good >> > idea to >> > put everything in Commons Annotations. It makes sense to have @Startup, >> > @Pooling, @Scedule, @Asynchronous where it fits better. >> > >> >> Why not keeping in EJBs (even if it needs to be renamed for historical >> reasons)? ie a spec on top of CDI, not <= CDI. >> >> > Antonio >> > >> > On Mon, Nov 17, 2014 at 5:30 PM, Antoine Sabot-Durand >> > wrote: >> >> >> >> Guys, don?t forget the commons annotation specification since we?re >> >> going >> >> to ask for a MR for it. It could be a convenient solution to share >> >> annotation without having a huge dependency to have it (think of SE). >> >> >> >> Antoine >> >> >> >> >> >> Le 17 nov. 2014 ? 16:53, Antonio Goncalves >> >> a >> >> ?crit : >> >> >> >> @Startup could also make sense in Concurrency in Java EE, like @Pooling >> >> (there's thread pools behind). BTW I was talking to the Oracle guys >> >> and it >> >> looks like the Concurrency spec will be updated in EE 8... I don't know >> >> how >> >> far the update will go. >> >> >> >> As for the JMS stuff, we talked with Nigel and he likes the idea of MDB >> >> replacement going to where it belongs : the JMS spec >> >> >> >> Antonio >> >> >> >> On Mon, Nov 17, 2014 at 4:28 PM, arjan tijms >> >> wrote: >> >>> >> >>> Hi, >> >>> >> >>> On Mon, Nov 17, 2014 at 2:57 PM, Antoine Sabot-Durand >> >>> wrote: >> >>> > Just to give you a small feedback of my Devoxx week regarding CDI >> >>> > and >> >>> > CDI 2.0 (for the rest, what happens in Devoxx stays in Devoxx ;) ) >> >>> > >> >>> > 1) Great expectations: >> >>> > [...] (the question of total EJB replacement came more than once) >> >>> >> >>> I heard this a number of times as well, both before and during Devoxx. >> >>> >> >>> A great number of issues for decoupling EJB features (meaning, >> >>> providing CDI based replacements) have already been created as spec >> >>> issues: >> >>> >> >>> * Decoupling the @Schedule annotation from the EJB component model >> >>> (EJB_SPEC-1) >> >>> * Decoupling the TimerService API from the EJB component model >> >>> (EJB_SPEC-2) >> >>> * Decoupling the @Asynchronous annotation from the EJB component model >> >>> (EJB_SPEC-3) >> >>> * Decoupling the @Lock/@AccessTimeout annotations from the EJB >> >>> component model (EJB_SPEC-4) >> >>> * Decoupling the @Startup/@DependsOn annotations from the EJB >> >>> component model (EJB_SPEC-19) >> >>> * Standardize Pooling and Decouple from EJB Component Model >> >>> (EJB_SPEC-113) >> >>> * Redefine Message Driven Beans as Managed Beans (EJB_SPEC-18) >> >>> * Standardize Abstractions for Common Message Processing Patterns >> >>> (JMS_SPEC-154) >> >>> * Allow Java EE components other than MDBs to consume messages >> >>> asynchronously (JMS_SPEC-100) >> >>> * Bind JMS to CDI events and/or business interfaces (JMS_SPEC-88) >> >>> * Support for "self" injection (CDI-414) >> >>> * Allow access-control related JSR-250 security annotations on managed >> >>> beans (JAVASERVERFACES_SPEC_PUBLIC-495) >> >>> * Support @RolesAllowed on a Servlet (SERVLET_SPEC-29) >> >>> >> >>> >> >>> There are some additional features that may not yet have been covered >> >>> (but maybe I missed them), such as: >> >>> >> >>> * Control over passivation >> >>> * Support for the extended persistence context >> >>> * Destroying a bean whenever an exception occurs (I was just working >> >>> on this the other week) >> >>> * Logging the exception thrown by a bean (yes, trivial, but part of >> >>> EJB) >> >>> * The concept where every method call on a proxy is routed to another >> >>> bean instance, which is then automatically unavailable for other calls >> >>> as long as it doesn't return (related to the "Standardize Pooling" >> >>> issue) >> >>> * Binary remoting without all the explicit mapping that's needed for >> >>> say JAX-RS (yes, thorny issue which we may not wish to support >> >>> anymore?) >> >>> * General support for @RolesAllowed/@RunAs etc (often mentioned, and >> >>> two issues for JSF managed beans resp Servlets were created, but no >> >>> general issue) >> >>> >> >>> The question is perhaps where all this functionality should live. >> >>> >> >>> TimerService and @Asynchronous in the concurrency spec? >> >>> All JMS/messaging listener stuff (aka MDB replacements) in the JMS >> >>> spec? >> >>> @RolesAllowed etc in the security spec (if that spec will actually >> >>> happen) >> >>> @Startup in the CDI spec itself? >> >>> Destroying bean on exception in CDI spec? >> >>> >> >>> But where should e.g. pooling belong? >> >>> >> >>> 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. >> >> >> >> >> >> >> >> >> >> -- >> >> 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 From antonio.goncalves at gmail.com Mon Nov 17 16:15:29 2014 From: antonio.goncalves at gmail.com (Antonio Goncalves) Date: Mon, 17 Nov 2014 22:15:29 +0100 Subject: [cdi-dev] Feedback from Devoxx In-Reply-To: References: <8D99A825-908E-4EB3-A1CA-93CFAD477F6A@sabot-durand.net> Message-ID: That's something that has to be discussed in the EE expert group (@arjan pointed at the JIRAs) because, let's face it, nobody really wants to open up the EJB spec (let's leave it quiet, so let's not bring this to the former EJB expert group... which I'm part of ;o) Antonio On Mon, Nov 17, 2014 at 10:10 PM, Romain Manni-Bucau wrote: > Actually it makes sense, we already have @Transactional so only > security part is really missing from EJB spec - sorry for the noise. > > Is there a place with all asked features (JavaSE, @Pooling, easier > SPI, config, ...)? then people could maybe vote? > > > Romain Manni-Bucau > @rmannibucau > http://www.tomitribe.com > http://rmannibucau.wordpress.com > https://github.com/rmannibucau > > > 2014-11-17 22:04 GMT+01:00 Antonio Goncalves >: > > Like @dblevins once said "EJB was a super hype spec with all the cool > > features... and became blotted throughout the years". If we are not > careful, > > CDI (the super hype spec at the moment) will become blotted too. > > > > Context and Dependency Injection should not deal with pooling, > scheduling, > > security.... but yes, allow the other specs to implement such concerns. I > > can easily see most of these concerns implemented with interceptor > bindings > > or extensions. > > > > When we talked to Nigel (JMS spec lead) he was really enthousiast to > learn > > more about CDI and use it to help develop JMS internals. Manfred (JSF / > MVC) > > who has already implemented most of the JSF stuff with CDI (@ViewScoped > and > > so on) was really encouraging. > > > > I think that part of the job this CDI 2.0 expert group has is to > evangelize > > current specs leads to use CDI in their internals. > > > > Antonio > > > > On Mon, Nov 17, 2014 at 9:55 PM, Romain Manni-Bucau < > rmannibucau at gmail.com> > > wrote: > >> > >> 2014-11-17 21:53 GMT+01:00 Antonio Goncalves > >> : > >> > Would you like to see @Inject in JSR 250 ? I don't think it's a good > >> > idea to > >> > put everything in Commons Annotations. It makes sense to have > @Startup, > >> > @Pooling, @Scedule, @Asynchronous where it fits better. > >> > > >> > >> Why not keeping in EJBs (even if it needs to be renamed for historical > >> reasons)? ie a spec on top of CDI, not <= CDI. > >> > >> > Antonio > >> > > >> > On Mon, Nov 17, 2014 at 5:30 PM, Antoine Sabot-Durand > >> > wrote: > >> >> > >> >> Guys, don?t forget the commons annotation specification since we?re > >> >> going > >> >> to ask for a MR for it. It could be a convenient solution to share > >> >> annotation without having a huge dependency to have it (think of SE). > >> >> > >> >> Antoine > >> >> > >> >> > >> >> Le 17 nov. 2014 ? 16:53, Antonio Goncalves > >> >> a > >> >> ?crit : > >> >> > >> >> @Startup could also make sense in Concurrency in Java EE, like > @Pooling > >> >> (there's thread pools behind). BTW I was talking to the Oracle guys > >> >> and it > >> >> looks like the Concurrency spec will be updated in EE 8... I don't > know > >> >> how > >> >> far the update will go. > >> >> > >> >> As for the JMS stuff, we talked with Nigel and he likes the idea of > MDB > >> >> replacement going to where it belongs : the JMS spec > >> >> > >> >> Antonio > >> >> > >> >> On Mon, Nov 17, 2014 at 4:28 PM, arjan tijms > >> >> wrote: > >> >>> > >> >>> Hi, > >> >>> > >> >>> On Mon, Nov 17, 2014 at 2:57 PM, Antoine Sabot-Durand > >> >>> wrote: > >> >>> > Just to give you a small feedback of my Devoxx week regarding CDI > >> >>> > and > >> >>> > CDI 2.0 (for the rest, what happens in Devoxx stays in Devoxx ;) ) > >> >>> > > >> >>> > 1) Great expectations: > >> >>> > [...] (the question of total EJB replacement came more than once) > >> >>> > >> >>> I heard this a number of times as well, both before and during > Devoxx. > >> >>> > >> >>> A great number of issues for decoupling EJB features (meaning, > >> >>> providing CDI based replacements) have already been created as spec > >> >>> issues: > >> >>> > >> >>> * Decoupling the @Schedule annotation from the EJB component model > >> >>> (EJB_SPEC-1) > >> >>> * Decoupling the TimerService API from the EJB component model > >> >>> (EJB_SPEC-2) > >> >>> * Decoupling the @Asynchronous annotation from the EJB component > model > >> >>> (EJB_SPEC-3) > >> >>> * Decoupling the @Lock/@AccessTimeout annotations from the EJB > >> >>> component model (EJB_SPEC-4) > >> >>> * Decoupling the @Startup/@DependsOn annotations from the EJB > >> >>> component model (EJB_SPEC-19) > >> >>> * Standardize Pooling and Decouple from EJB Component Model > >> >>> (EJB_SPEC-113) > >> >>> * Redefine Message Driven Beans as Managed Beans (EJB_SPEC-18) > >> >>> * Standardize Abstractions for Common Message Processing Patterns > >> >>> (JMS_SPEC-154) > >> >>> * Allow Java EE components other than MDBs to consume messages > >> >>> asynchronously (JMS_SPEC-100) > >> >>> * Bind JMS to CDI events and/or business interfaces (JMS_SPEC-88) > >> >>> * Support for "self" injection (CDI-414) > >> >>> * Allow access-control related JSR-250 security annotations on > managed > >> >>> beans (JAVASERVERFACES_SPEC_PUBLIC-495) > >> >>> * Support @RolesAllowed on a Servlet (SERVLET_SPEC-29) > >> >>> > >> >>> > >> >>> There are some additional features that may not yet have been > covered > >> >>> (but maybe I missed them), such as: > >> >>> > >> >>> * Control over passivation > >> >>> * Support for the extended persistence context > >> >>> * Destroying a bean whenever an exception occurs (I was just working > >> >>> on this the other week) > >> >>> * Logging the exception thrown by a bean (yes, trivial, but part of > >> >>> EJB) > >> >>> * The concept where every method call on a proxy is routed to > another > >> >>> bean instance, which is then automatically unavailable for other > calls > >> >>> as long as it doesn't return (related to the "Standardize Pooling" > >> >>> issue) > >> >>> * Binary remoting without all the explicit mapping that's needed for > >> >>> say JAX-RS (yes, thorny issue which we may not wish to support > >> >>> anymore?) > >> >>> * General support for @RolesAllowed/@RunAs etc (often mentioned, and > >> >>> two issues for JSF managed beans resp Servlets were created, but no > >> >>> general issue) > >> >>> > >> >>> The question is perhaps where all this functionality should live. > >> >>> > >> >>> TimerService and @Asynchronous in the concurrency spec? > >> >>> All JMS/messaging listener stuff (aka MDB replacements) in the JMS > >> >>> spec? > >> >>> @RolesAllowed etc in the security spec (if that spec will actually > >> >>> happen) > >> >>> @Startup in the CDI spec itself? > >> >>> Destroying bean on exception in CDI spec? > >> >>> > >> >>> But where should e.g. pooling belong? > >> >>> > >> >>> 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. > >> >> > >> >> > >> >> > >> >> > >> >> -- > >> >> 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 > -- Antonio Goncalves Software architect, Java Champion and Pluralsight author Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20141117/1988e309/attachment-0001.html From arjan.tijms at gmail.com Mon Nov 17 16:15:53 2014 From: arjan.tijms at gmail.com (arjan tijms) Date: Mon, 17 Nov 2014 22:15:53 +0100 Subject: [cdi-dev] Feedback from Devoxx In-Reply-To: References: <8D99A825-908E-4EB3-A1CA-93CFAD477F6A@sabot-durand.net> Message-ID: Hi, On Mon, Nov 17, 2014 at 9:55 PM, Romain Manni-Bucau wrote: > 2014-11-17 21:53 GMT+01:00 Antonio Goncalves : >> Would you like to see @Inject in JSR 250 ? I don't think it's a good idea to >> put everything in Commons Annotations. It makes sense to have @Startup, >> @Pooling, @Scedule, @Asynchronous where it fits better. >> > > Why not keeping in EJBs (even if it needs to be renamed for historical > reasons)? ie a spec on top of CDI, not <= CDI. It could theoretically be an option to have the EJB spec define many of its key features as CDI based functionality. For the crucial backwards compatibility concern it should not replace its existing implementation by those, but just offer the CDI ones next to the existing EJB-native ones. E.g. just like JSF offers an @ViewScoped for usage with its native managed beans and a second @ViewScoped for use with CDI beans. A counter argument is that EJB has always been about the following concerns: * A component bean model * DI capabilities * Remoting (the initial key EJB feature) * Transactions * Security * Concurrency control * Asynchronous execution * Scheduling * Messaging integration (not messaging itself) DI and the component bean model are now provided in a more universal way by CDI. Remoting is now mostly done by JAX-RS. Transactions was always JTA, EJB just offered an ease of use facility on top of it. The security annotations already are not EJB annotations, they're curiously enough only implemented/supported by EJB at the moment. Concurrency now has its own spec, so my feeling is that concurrency control (i.e. the fact that calls to a single bean instance will be serialized) and asynchronous execution should be in that spec. Scheduling and messaging integration are open questions. Scheduling kinda feels like it may belong with concurrency as well, but messaging integration is more difficult. In the MDB/connector architecture JMS was always just one of many messaging options. JMS was simply the only one that is included with Java EE. Kind regards, Arjan Tijms > >> Antonio >> >> On Mon, Nov 17, 2014 at 5:30 PM, Antoine Sabot-Durand >> wrote: >>> >>> Guys, don?t forget the commons annotation specification since we?re going >>> to ask for a MR for it. It could be a convenient solution to share >>> annotation without having a huge dependency to have it (think of SE). >>> >>> Antoine >>> >>> >>> Le 17 nov. 2014 ? 16:53, Antonio Goncalves a >>> ?crit : >>> >>> @Startup could also make sense in Concurrency in Java EE, like @Pooling >>> (there's thread pools behind). BTW I was talking to the Oracle guys and it >>> looks like the Concurrency spec will be updated in EE 8... I don't know how >>> far the update will go. >>> >>> As for the JMS stuff, we talked with Nigel and he likes the idea of MDB >>> replacement going to where it belongs : the JMS spec >>> >>> Antonio >>> >>> On Mon, Nov 17, 2014 at 4:28 PM, arjan tijms >>> wrote: >>>> >>>> Hi, >>>> >>>> On Mon, Nov 17, 2014 at 2:57 PM, Antoine Sabot-Durand >>>> wrote: >>>> > Just to give you a small feedback of my Devoxx week regarding CDI and >>>> > CDI 2.0 (for the rest, what happens in Devoxx stays in Devoxx ;) ) >>>> > >>>> > 1) Great expectations: >>>> > [...] (the question of total EJB replacement came more than once) >>>> >>>> I heard this a number of times as well, both before and during Devoxx. >>>> >>>> A great number of issues for decoupling EJB features (meaning, >>>> providing CDI based replacements) have already been created as spec >>>> issues: >>>> >>>> * Decoupling the @Schedule annotation from the EJB component model >>>> (EJB_SPEC-1) >>>> * Decoupling the TimerService API from the EJB component model >>>> (EJB_SPEC-2) >>>> * Decoupling the @Asynchronous annotation from the EJB component model >>>> (EJB_SPEC-3) >>>> * Decoupling the @Lock/@AccessTimeout annotations from the EJB >>>> component model (EJB_SPEC-4) >>>> * Decoupling the @Startup/@DependsOn annotations from the EJB >>>> component model (EJB_SPEC-19) >>>> * Standardize Pooling and Decouple from EJB Component Model >>>> (EJB_SPEC-113) >>>> * Redefine Message Driven Beans as Managed Beans (EJB_SPEC-18) >>>> * Standardize Abstractions for Common Message Processing Patterns >>>> (JMS_SPEC-154) >>>> * Allow Java EE components other than MDBs to consume messages >>>> asynchronously (JMS_SPEC-100) >>>> * Bind JMS to CDI events and/or business interfaces (JMS_SPEC-88) >>>> * Support for "self" injection (CDI-414) >>>> * Allow access-control related JSR-250 security annotations on managed >>>> beans (JAVASERVERFACES_SPEC_PUBLIC-495) >>>> * Support @RolesAllowed on a Servlet (SERVLET_SPEC-29) >>>> >>>> >>>> There are some additional features that may not yet have been covered >>>> (but maybe I missed them), such as: >>>> >>>> * Control over passivation >>>> * Support for the extended persistence context >>>> * Destroying a bean whenever an exception occurs (I was just working >>>> on this the other week) >>>> * Logging the exception thrown by a bean (yes, trivial, but part of EJB) >>>> * The concept where every method call on a proxy is routed to another >>>> bean instance, which is then automatically unavailable for other calls >>>> as long as it doesn't return (related to the "Standardize Pooling" >>>> issue) >>>> * Binary remoting without all the explicit mapping that's needed for >>>> say JAX-RS (yes, thorny issue which we may not wish to support >>>> anymore?) >>>> * General support for @RolesAllowed/@RunAs etc (often mentioned, and >>>> two issues for JSF managed beans resp Servlets were created, but no >>>> general issue) >>>> >>>> The question is perhaps where all this functionality should live. >>>> >>>> TimerService and @Asynchronous in the concurrency spec? >>>> All JMS/messaging listener stuff (aka MDB replacements) in the JMS spec? >>>> @RolesAllowed etc in the security spec (if that spec will actually >>>> happen) >>>> @Startup in the CDI spec itself? >>>> Destroying bean on exception in CDI spec? >>>> >>>> But where should e.g. pooling belong? >>>> >>>> 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. >>> >>> >>> >>> >>> -- >>> 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. > > _______________________________________________ > 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 Mon Nov 17 16:23:22 2014 From: arjan.tijms at gmail.com (arjan tijms) Date: Mon, 17 Nov 2014 22:23:22 +0100 Subject: [cdi-dev] Feedback from Devoxx In-Reply-To: References: <8D99A825-908E-4EB3-A1CA-93CFAD477F6A@sabot-durand.net> Message-ID: Hi, On Mon, Nov 17, 2014 at 10:04 PM, Antonio Goncalves wrote: > Like @dblevins once said "EJB was a super hype spec with all the cool > features... and became blotted throughout the years". If we are not careful, > CDI (the super hype spec at the moment) will become blotted too I strongly support that! IMHO as little as possible of these higher level features should be implemented within CDI itself, so that CDI itself can completely focus on being the contextual DI spec on which all other specs can build. I think it's already problematic that CDI 1.1 provided producers for Servlet artifacts, instead of letting the Servlet spec itself define those producers. If/when Servlet starts depending on CDI there will be a rather awkward circular dependency. Kind regards, Arjan From antonio.goncalves at gmail.com Mon Nov 17 16:39:53 2014 From: antonio.goncalves at gmail.com (Antonio Goncalves) Date: Mon, 17 Nov 2014 22:39:53 +0100 Subject: [cdi-dev] Feedback from Devoxx In-Reply-To: References: <8D99A825-908E-4EB3-A1CA-93CFAD477F6A@sabot-durand.net> Message-ID: Yes, we talked about this topic with Manfried and Antoine : CDI should not mention servlet or JSF nor depend on them. I think a little refactoring of the spec would be needed in 2.0 so that CDI doesn't depend on anything (except @Inject) and all the specs would, hopefully, depend on it. On Mon, Nov 17, 2014 at 10:23 PM, arjan tijms wrote: > Hi, > > On Mon, Nov 17, 2014 at 10:04 PM, Antonio Goncalves > wrote: > > Like @dblevins once said "EJB was a super hype spec with all the cool > > features... and became blotted throughout the years". If we are not > careful, > > CDI (the super hype spec at the moment) will become blotted too > > I strongly support that! > > IMHO as little as possible of these higher level features should be > implemented within CDI itself, so that CDI itself can completely focus > on being the contextual DI spec on which all other specs can build. > > I think it's already problematic that CDI 1.1 provided producers for > Servlet artifacts, instead of letting the Servlet spec itself define > those producers. If/when Servlet starts depending on CDI there will be > a rather awkward circular dependency. > > Kind regards, > Arjan > -- Antonio Goncalves Software architect, Java Champion and Pluralsight author Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20141117/bcc95652/attachment.html From antoine at sabot-durand.net Tue Nov 18 05:06:05 2014 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Tue, 18 Nov 2014 11:06:05 +0100 Subject: [cdi-dev] Feedback from Devoxx In-Reply-To: References: <8D99A825-908E-4EB3-A1CA-93CFAD477F6A@sabot-durand.net> Message-ID: <7881C1FE-D656-407E-A055-D8A6F408D997@sabot-durand.net> > Le 17 nov. 2014 ? 21:53, Antonio Goncalves a ?crit : > > Would you like to see @Inject in JSR 250 ? No, but in the end it?s a good thing that it is not in CDI (in a far lighter spec), so it can be used by other DI solution for the sake of end users. > I don't think it's a good idea to put everything in Commons Annotations. It makes sense to have @Startup, @Pooling, @Scedule, @Asynchronous where it fits better. Again, it?s a only Java EE pov, having such dependencies in Java SE can be a real handicap. Take @Startup for instance. Its purpose is to make sure that a bean is instantiated at startup. Why in the hell would I want to drag all the concurrency spec to only have this annotation ? I don?t say that it?s the case for all annotations, but we should really consider having this multiple purpose annotation in light spec. For instance I?m not against having our @Produces moved to AtInject (and perhaps renamed to @Provides to end the mix with JAX-RX Produces) to share this concept with all other implementations. > > Antonio > > On Mon, Nov 17, 2014 at 5:30 PM, Antoine Sabot-Durand > wrote: > Guys, don?t forget the commons annotation specification since we?re going to ask for a MR for it. It could be a convenient solution to share annotation without having a huge dependency to have it (think of SE). > > Antoine > > >> Le 17 nov. 2014 ? 16:53, Antonio Goncalves > a ?crit : >> >> @Startup could also make sense in Concurrency in Java EE, like @Pooling (there's thread pools behind). BTW I was talking to the Oracle guys and it looks like the Concurrency spec will be updated in EE 8... I don't know how far the update will go. >> >> As for the JMS stuff, we talked with Nigel and he likes the idea of MDB replacement going to where it belongs : the JMS spec >> >> Antonio >> >> On Mon, Nov 17, 2014 at 4:28 PM, arjan tijms > wrote: >> Hi, >> >> On Mon, Nov 17, 2014 at 2:57 PM, Antoine Sabot-Durand >> > wrote: >> > Just to give you a small feedback of my Devoxx week regarding CDI and CDI 2.0 (for the rest, what happens in Devoxx stays in Devoxx ;) ) >> > >> > 1) Great expectations: >> > [...] (the question of total EJB replacement came more than once) >> >> I heard this a number of times as well, both before and during Devoxx. >> >> A great number of issues for decoupling EJB features (meaning, >> providing CDI based replacements) have already been created as spec >> issues: >> >> * Decoupling the @Schedule annotation from the EJB component model (EJB_SPEC-1) >> * Decoupling the TimerService API from the EJB component model (EJB_SPEC-2) >> * Decoupling the @Asynchronous annotation from the EJB component model >> (EJB_SPEC-3) >> * Decoupling the @Lock/@AccessTimeout annotations from the EJB >> component model (EJB_SPEC-4) >> * Decoupling the @Startup/@DependsOn annotations from the EJB >> component model (EJB_SPEC-19) >> * Standardize Pooling and Decouple from EJB Component Model (EJB_SPEC-113) >> * Redefine Message Driven Beans as Managed Beans (EJB_SPEC-18) >> * Standardize Abstractions for Common Message Processing Patterns (JMS_SPEC-154) >> * Allow Java EE components other than MDBs to consume messages >> asynchronously (JMS_SPEC-100) >> * Bind JMS to CDI events and/or business interfaces (JMS_SPEC-88) >> * Support for "self" injection (CDI-414) >> * Allow access-control related JSR-250 security annotations on managed >> beans (JAVASERVERFACES_SPEC_PUBLIC-495) >> * Support @RolesAllowed on a Servlet (SERVLET_SPEC-29) >> >> >> There are some additional features that may not yet have been covered >> (but maybe I missed them), such as: >> >> * Control over passivation >> * Support for the extended persistence context >> * Destroying a bean whenever an exception occurs (I was just working >> on this the other week) >> * Logging the exception thrown by a bean (yes, trivial, but part of EJB) >> * The concept where every method call on a proxy is routed to another >> bean instance, which is then automatically unavailable for other calls >> as long as it doesn't return (related to the "Standardize Pooling" >> issue) >> * Binary remoting without all the explicit mapping that's needed for >> say JAX-RS (yes, thorny issue which we may not wish to support >> anymore?) >> * General support for @RolesAllowed/@RunAs etc (often mentioned, and >> two issues for JSF managed beans resp Servlets were created, but no >> general issue) >> >> The question is perhaps where all this functionality should live. >> >> TimerService and @Asynchronous in the concurrency spec? >> All JMS/messaging listener stuff (aka MDB replacements) in the JMS spec? >> @RolesAllowed etc in the security spec (if that spec will actually happen) >> @Startup in the CDI spec itself? >> Destroying bean on exception in CDI spec? >> >> But where should e.g. pooling belong? >> >> 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. >> >> >> >> -- >> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20141118/4d9af550/attachment-0001.html From antonio.goncalves at gmail.com Tue Nov 18 05:07:52 2014 From: antonio.goncalves at gmail.com (Antonio Goncalves) Date: Tue, 18 Nov 2014 11:07:52 +0100 Subject: [cdi-dev] Feedback from Devoxx In-Reply-To: <7881C1FE-D656-407E-A055-D8A6F408D997@sabot-durand.net> References: <8D99A825-908E-4EB3-A1CA-93CFAD477F6A@sabot-durand.net> <7881C1FE-D656-407E-A055-D8A6F408D997@sabot-durand.net> Message-ID: And what if the Concurrency spec is splitted in several parts ? We could @Schedule or @Startup a servlet with just a subset of Concurrency for example. On Tue, Nov 18, 2014 at 11:06 AM, Antoine Sabot-Durand < antoine at sabot-durand.net> wrote: > > Le 17 nov. 2014 ? 21:53, Antonio Goncalves > a ?crit : > > Would you like to see @Inject in JSR 250 ? > > > No, but in the end it?s a good thing that it is not in CDI (in a far > lighter spec), so it can be used by other DI solution for the sake of end > users. > > I don't think it's a good idea to put everything in Commons Annotations. > It makes sense to have @Startup, @Pooling, @Scedule, @Asynchronous where it > fits better. > > > Again, it?s a only Java EE pov, having such dependencies in Java SE can be > a real handicap. Take @Startup for instance. Its purpose is to make sure > that a bean is instantiated at startup. Why in the hell would I want to > drag all the concurrency spec to only have this annotation ? > I don?t say that it?s the case for all annotations, but we should really > consider having this multiple purpose annotation in light spec. For > instance I?m not against having our @Produces moved to AtInject (and > perhaps renamed to @Provides to end the mix with JAX-RX Produces) to share > this concept with all other implementations. > > > Antonio > > On Mon, Nov 17, 2014 at 5:30 PM, Antoine Sabot-Durand < > antoine at sabot-durand.net> wrote: > >> Guys, don?t forget the commons annotation specification since we?re going >> to ask for a MR for it. It could be a convenient solution to share >> annotation without having a huge dependency to have it (think of SE). >> >> Antoine >> >> >> Le 17 nov. 2014 ? 16:53, Antonio Goncalves >> a ?crit : >> >> @Startup could also make sense in Concurrency in Java EE, like @Pooling >> (there's thread pools behind). BTW I was talking to the Oracle guys and >> it looks like the Concurrency spec will be updated in EE 8... I don't know >> how far the update will go. >> >> As for the JMS stuff, we talked with Nigel and he likes the idea of MDB >> replacement going to where it belongs : the JMS spec >> >> Antonio >> >> On Mon, Nov 17, 2014 at 4:28 PM, arjan tijms >> wrote: >> >>> Hi, >>> >>> On Mon, Nov 17, 2014 at 2:57 PM, Antoine Sabot-Durand >>> wrote: >>> > Just to give you a small feedback of my Devoxx week regarding CDI and >>> CDI 2.0 (for the rest, what happens in Devoxx stays in Devoxx ;) ) >>> > >>> > 1) Great expectations: >>> > [...] (the question of total EJB replacement came more than once) >>> >>> I heard this a number of times as well, both before and during Devoxx. >>> >>> A great number of issues for decoupling EJB features (meaning, >>> providing CDI based replacements) have already been created as spec >>> issues: >>> >>> * Decoupling the @Schedule annotation from the EJB component model >>> (EJB_SPEC-1) >>> * Decoupling the TimerService API from the EJB component model >>> (EJB_SPEC-2) >>> * Decoupling the @Asynchronous annotation from the EJB component model >>> (EJB_SPEC-3) >>> * Decoupling the @Lock/@AccessTimeout annotations from the EJB >>> component model (EJB_SPEC-4) >>> * Decoupling the @Startup/@DependsOn annotations from the EJB >>> component model (EJB_SPEC-19) >>> * Standardize Pooling and Decouple from EJB Component Model >>> (EJB_SPEC-113) >>> * Redefine Message Driven Beans as Managed Beans (EJB_SPEC-18) >>> * Standardize Abstractions for Common Message Processing Patterns >>> (JMS_SPEC-154) >>> * Allow Java EE components other than MDBs to consume messages >>> asynchronously (JMS_SPEC-100) >>> * Bind JMS to CDI events and/or business interfaces (JMS_SPEC-88) >>> * Support for "self" injection (CDI-414) >>> * Allow access-control related JSR-250 security annotations on managed >>> beans (JAVASERVERFACES_SPEC_PUBLIC-495) >>> * Support @RolesAllowed on a Servlet (SERVLET_SPEC-29) >>> >>> >>> There are some additional features that may not yet have been covered >>> (but maybe I missed them), such as: >>> >>> * Control over passivation >>> * Support for the extended persistence context >>> * Destroying a bean whenever an exception occurs (I was just working >>> on this the other week) >>> * Logging the exception thrown by a bean (yes, trivial, but part of EJB) >>> * The concept where every method call on a proxy is routed to another >>> bean instance, which is then automatically unavailable for other calls >>> as long as it doesn't return (related to the "Standardize Pooling" >>> issue) >>> * Binary remoting without all the explicit mapping that's needed for >>> say JAX-RS (yes, thorny issue which we may not wish to support >>> anymore?) >>> * General support for @RolesAllowed/@RunAs etc (often mentioned, and >>> two issues for JSF managed beans resp Servlets were created, but no >>> general issue) >>> >>> The question is perhaps where all this functionality should live. >>> >>> TimerService and @Asynchronous in the concurrency spec? >>> All JMS/messaging listener stuff (aka MDB replacements) in the JMS spec? >>> @RolesAllowed etc in the security spec (if that spec will actually >>> happen) >>> @Startup in the CDI spec itself? >>> Destroying bean on exception in CDI spec? >>> >>> But where should e.g. pooling belong? >>> >>> 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. >>> >> >> >> >> -- >> 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 > > > -- Antonio Goncalves Software architect, Java Champion and Pluralsight author Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20141118/9a0ebc84/attachment.html From antoine at sabot-durand.net Tue Nov 18 05:11:35 2014 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Tue, 18 Nov 2014 11:11:35 +0100 Subject: [cdi-dev] Feedback from Devoxx In-Reply-To: References: <8D99A825-908E-4EB3-A1CA-93CFAD477F6A@sabot-durand.net> Message-ID: <513E8F02-4943-4170-B4C1-FF72CF952D12@sabot-durand.net> Arjan, This very topic has been discussed with Ed Burns (Servlet Spec lead) and he agreed to work on moving these feature from CDI to his spec. Ideally CDI shouldn?t have dependency to front specs (servlet, jsf, jax-rs). We?ll try to work in that direction for version 2.0. Antoine > Le 17 nov. 2014 ? 22:23, arjan tijms a ?crit : > > Hi, > > On Mon, Nov 17, 2014 at 10:04 PM, Antonio Goncalves > wrote: >> Like @dblevins once said "EJB was a super hype spec with all the cool >> features... and became blotted throughout the years". If we are not careful, >> CDI (the super hype spec at the moment) will become blotted too > > I strongly support that! > > IMHO as little as possible of these higher level features should be > implemented within CDI itself, so that CDI itself can completely focus > on being the contextual DI spec on which all other specs can build. > > I think it's already problematic that CDI 1.1 provided producers for > Servlet artifacts, instead of letting the Servlet spec itself define > those producers. If/when Servlet starts depending on CDI there will be > a rather awkward circular dependency. > > Kind regards, > Arjan > _______________________________________________ > 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 Tue Nov 18 06:33:15 2014 From: arjan.tijms at gmail.com (arjan tijms) Date: Tue, 18 Nov 2014 12:33:15 +0100 Subject: [cdi-dev] Feedback from Devoxx In-Reply-To: <513E8F02-4943-4170-B4C1-FF72CF952D12@sabot-durand.net> References: <8D99A825-908E-4EB3-A1CA-93CFAD477F6A@sabot-durand.net> <513E8F02-4943-4170-B4C1-FF72CF952D12@sabot-durand.net> Message-ID: On Tue, Nov 18, 2014 at 11:11 AM, Antoine Sabot-Durand wrote: > This very topic has been discussed with Ed Burns (Servlet Spec lead) and he agreed to work on moving these feature from CDI to his spec. Ideally CDI shouldn?t have dependency to front specs (servlet, jsf, jax-rs). We?ll try to work in that direction for version 2.0. That's great to hear really. I brought the subject up at the servlet mailing list (see https://java.net/projects/servlet-spec/lists/users/archive/2014-11/message/11) but there wasn't a follow up there about that discussion. There's btw also a producer for the UserPrincipal, which I think should ideally go to either the new security spec (again if/when it happens) or JASPIC, and a producer for a JTA UserTransaction, which I guess would be best off just being in JTA. Kind regards, Arjan > > Antoine > > >> Le 17 nov. 2014 ? 22:23, arjan tijms a ?crit : >> >> Hi, >> >> On Mon, Nov 17, 2014 at 10:04 PM, Antonio Goncalves >> wrote: >>> Like @dblevins once said "EJB was a super hype spec with all the cool >>> features... and became blotted throughout the years". If we are not careful, >>> CDI (the super hype spec at the moment) will become blotted too >> >> I strongly support that! >> >> IMHO as little as possible of these higher level features should be >> implemented within CDI itself, so that CDI itself can completely focus >> on being the contextual DI spec on which all other specs can build. >> >> I think it's already problematic that CDI 1.1 provided producers for >> Servlet artifacts, instead of letting the Servlet spec itself define >> those producers. If/when Servlet starts depending on CDI there will be >> a rather awkward circular dependency. >> >> Kind regards, >> Arjan >> _______________________________________________ >> 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 Nov 19 11:06:28 2014 From: arjan.tijms at gmail.com (arjan tijms) Date: Wed, 19 Nov 2014 17:06:28 +0100 Subject: [cdi-dev] Getting injection point from Bean#create Message-ID: Hi, In a producer method it's trivial to get access to an InjectionPoint instance representing the point where the value produced by the producer will be injected. When registering a Bean manually from an extension using AfterBeanDiscovery#addBean, this is not immediately obvious. After some fumbling with the CDI APIs I came up with the following code that seems to work on both Weld and OWB (didn't test CanDI yet). It uses a small "dummy" class, which is used to grab an InjectionPoint off: In a Bean: public Object create(CreationalContext creationalContext) { InjectionPoint injectionPoint = (InjectionPoint) beanManager.getInjectableReference( resolve(beanManager, InjectionPointGenerator.class).getInjectionPoints().iterator().next(), creationalContext ); With InjectionPointGenerator being the following class: public class InjectionPointGenerator { @Inject private InjectionPoint injectionPoint; } And resolve being the following method: public static Bean resolve(BeanManager beanManager, Class beanClass) { Set> beans = beanManager.getBeans(beanClass); for (Bean bean : beans) { if (bean.getBeanClass() == beanClass) { return (Bean) beanManager.resolve(Collections.>singleton(bean)); } } return (Bean) beanManager.resolve(beans); } As mentioned, while this seems to work, I wonder if it's the best approach. Kind regards, Arjan From issues at jboss.org Wed Nov 19 13:10:39 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 19 Nov 2014 13:10:39 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-492) Give ownership of servlet specific part to servlet specification In-Reply-To: References: Message-ID: Antoine Sabot-Durand created CDI-492: ---------------------------------------- Summary: Give ownership of servlet specific part to servlet specification Key: CDI-492 URL: https://issues.jboss.org/browse/CDI-492 Project: CDI Specification Issues Issue Type: Feature Request Components: Java EE integration Reporter: Antoine Sabot-Durand [Section 3.8 of the spec|http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#additional_builtin_beans] places some requirements on CDI implementations when running with Servlet. To better suit user desires for modularity these requirements are better met by moving them to the Servlet spec. Specifically, {quote} A servlet container must provide the following built-in beans, all of which have qualifier @Default: * a bean with bean type {{javax.servlet.http.HttpServletRequest}}, allowing injection of a reference to the HttpServletRequest * a bean with bean type {{javax.servlet.http.HttpSession}}, allowing injection of a reference to the HttpSession, * a bean with bean type {{javax.servlet.ServletContext}}, allowing injection of a reference to the ServletContext, These beans are passivation capable dependencies, as defined in Passivation capable dependencies. {quote} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 20 04:41:39 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Thu, 20 Nov 2014 04:41:39 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-270) Allow @WithAnnotations to be applied to other events In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-270: ------------------------------------- Fix Version/s: 2.0 (discussion) (was: TBD) > Allow @WithAnnotations to be applied to other events > ---------------------------------------------------- > > Key: CDI-270 > URL: https://issues.jboss.org/browse/CDI-270 > Project: CDI Specification Issues > Issue Type: Bug > Affects Versions: 1.1.EDR > Reporter: Pete Muir > Labels: with-annotations > Fix For: 2.0 (discussion) > > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 20 04:43:39 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Thu, 20 Nov 2014 04:43:39 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-253) Support for @Nonbinding at annotation level In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021457#comment-13021457 ] Antoine Sabot-Durand commented on CDI-253: ------------------------------------------ I think we should close this feature. It would only bring confusion. > Support for @Nonbinding at annotation level > ------------------------------------------- > > Key: CDI-253 > URL: https://issues.jboss.org/browse/CDI-253 > Project: CDI Specification Issues > Issue Type: Feature Request > Affects Versions: 1.0 > Reporter: Pete Muir > Fix For: TBD > > > Allow putting @Nonbinding at annotation level on qualifiers to apply to entire qualifier -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 20 04:47:39 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Thu, 20 Nov 2014 04:47:39 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-253) Support for @Nonbinding at annotation level In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-253: ------------------------------------- Labels: to-close (was: ) > Support for @Nonbinding at annotation level > ------------------------------------------- > > Key: CDI-253 > URL: https://issues.jboss.org/browse/CDI-253 > Project: CDI Specification Issues > Issue Type: Feature Request > Affects Versions: 1.0 > Reporter: Pete Muir > Labels: to-close > Fix For: TBD > > > Allow putting @Nonbinding at annotation level on qualifiers to apply to entire qualifier -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 20 05:09:39 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Thu, 20 Nov 2014 05:09:39 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-434) AfterTypeDiscovery javadoc outdated In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-434: ------------------------------------- Fix Version/s: 2.0 (discussion) > AfterTypeDiscovery javadoc outdated > ----------------------------------- > > Key: CDI-434 > URL: https://issues.jboss.org/browse/CDI-434 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 1.2.Final > Reporter: Martin Kouba > Assignee: Martin Kouba > Fix For: 2.0 (discussion) > > > {quote} > *getAlternatives()* returns the ordered list of enabled alternatives for the application. Alternatives enabled for a bean archive are not included in the list > {quote} > vs http://docs.jboss.org/cdi/api/1.2/javax/enterprise/inject/spi/AfterTypeDiscovery.html#getAlternatives%28%29 > The same applies to {{getInterceptors()}} and {{getDecorators()}}. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 20 05:10:39 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Thu, 20 Nov 2014 05:10:39 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-437) The container cannot use the final value of AfterTypeDiscovery.getAlternatives() properly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-437: ------------------------------------- Fix Version/s: 2.0 (discussion) > The container cannot use the final value of AfterTypeDiscovery.getAlternatives() properly > ----------------------------------------------------------------------------------------- > > Key: CDI-437 > URL: https://issues.jboss.org/browse/CDI-437 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 1.2.Final > Reporter: Martin Kouba > Fix For: 2.0 (discussion) > > > {quote} > Any observer of this event is permitted to add classes to, or remove classes from, the list of alternatives, list of interceptors or list of decorators. *The container must use the final values of these collections*, after all observers of AfterTypeDiscovery have been called, to determine the order of the enabled alternatives, interceptors, and decorators for application. The initial values of these collections are defined by the @Priority annotation. > {quote} > However, the container cannot use the final value of the alternatives collection properly. The problem occurs if an extension adds an alternative class. > The container can either: > * use the index from the list -> selected alternatives with the same priority will not cause {{AmbiguousResolutionException}} (this contradicts the spec), or > * use the original priority, an alternative added by an extension will be selected for an application but without any priority value (this contradicts the spec) -> an extension would not be able to affect the final ordering > The first option seems to be less harmful. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From struberg at yahoo.de Thu Nov 20 08:47:19 2014 From: struberg at yahoo.de (Mark Struberg) Date: Thu, 20 Nov 2014 13:47:19 +0000 (UTC) Subject: [cdi-dev] [servlet-spec users] [jsr369-experts] [116-CDIRelatedBeansInServletSpec] PROPOSAL In-Reply-To: <21612.56559.530393.47262@gargle.gargle.HOWL> References: <21612.56559.530393.47262@gargle.gargle.HOWL> Message-ID: <142766408.1701891.1416491239656.JavaMail.yahoo@jws11135.mail.ir2.yahoo.com> I'm not quite sure that it's worth it. The @RequestScoped and @SessionScoped are already in the CDI spec package. And as you know we must not split packages between different specs. It would feel quite unnatural to have annotations in the CDI APIs but the description in the servlet spec. Also note that some of those scopes (mostly @RequestScoped) also get used for non-servlet tasks. E.g. java-concurrency-utils threads, @Asynchronous EJBs, JMS invocations, @PostConstruct of @Stateless @Startup beans, etc. What we probably could add (regardless whether on CDI or Servlet side) is kind of a @WebAppScoped. This is really missing atm. But again this must also be active in e.g. JMS invocations which form kind a 'logical app'. LieGrue, strub > On Wednesday, 19 November 2014, 19:40, Edward Burns wrote: > > Hello Volunteers, > > The Servlet spec PDF currently only mentions CDI on two pages (and one > of them is a reference to the other). It appears the normative > declaration of the requirements in Servlet regarding CDI is in our > section 15.5.15 "Contexts and Dependency Injection for Java EE > requirements". > > The CDI spec is trying to trim itself down and part of that effort > requires fobbing off some requirements previously declared in the CDI > spec itself to other related specs. In this case, we have the > following: > > CDI Spec section 3.8 [1] places some requirements on CDI implementations > when running with Servlet. To better suit user desires for modularity > these requirements are better met by moving them to the Servlet > spec. Specifically, > > CDI3.8> A servlet container must provide the following built-in > CDI3.8> beans, all of which have qualifier @Default: > > CDI3.8> a bean with bean type javax.servlet.http.HttpServletRequest, > CDI3.8> allowing injection of a reference to the HttpServletRequest > > CDI3.8> a bean with bean type javax.servlet.http.HttpSession, > CDI3.8> allowing injection of a reference to the HttpSession, > > CDI3.8> a bean with bean type javax.servlet.ServletContext, allowing > CDI3.8> injection of a reference to the ServletContext, > > CDI3.8> These beans are passivation capable dependencies, as defined > CDI3.8> in Passivation capable dependencies. > > To put these items in the Servlet spec, we may have to couch them in > terms similar to, "when running in an environment that also supports > CDI...". > > PROPOSAL: > > Include language in our spec section 15.5.15 which allows the CDI spec > to remove their language while preserving desired existing user > functionality. > > What do you all think? I know several of our constituents do not count > CDI support among their user requirements. Is this going to be a > problem? > > Ed > > [1] http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#additional_builtin_beans > > -- > | edward.burns at oracle.com | office: +1 407 458 0017 > From jharting at redhat.com Thu Nov 20 15:42:19 2014 From: jharting at redhat.com (Jozef Hartinger) Date: Thu, 20 Nov 2014 21:42:19 +0100 Subject: [cdi-dev] Getting injection point from Bean#create In-Reply-To: References: Message-ID: <546E522B.3090509@redhat.com> The simplest thing you can do is: Bean bean = (Bean) manager.resolve(manager.getBeans(InjectionPoint.class)); InjectionPoint ip = (InjectionPoint) manager.getReference(bean, InjectionPoint.class, manager.createCreationalContext(bean)); On 11/19/2014 05:06 PM, arjan tijms wrote: > Hi, > > In a producer method it's trivial to get access to an InjectionPoint > instance representing the point where the value produced by the > producer will be injected. > > When registering a Bean manually from an extension using > AfterBeanDiscovery#addBean, this is not immediately obvious. > > After some fumbling with the CDI APIs I came up with the following > code that seems to work on both Weld and OWB (didn't test CanDI yet). > > It uses a small "dummy" class, which is used to grab an InjectionPoint off: > > In a Bean: > > public Object create(CreationalContext creationalContext) { > > InjectionPoint injectionPoint = (InjectionPoint) > beanManager.getInjectableReference( > resolve(beanManager, > InjectionPointGenerator.class).getInjectionPoints().iterator().next(), > creationalContext > ); > > With InjectionPointGenerator being the following class: > > public class InjectionPointGenerator { > @Inject > private InjectionPoint injectionPoint; > } > > And resolve being the following method: > > public static Bean resolve(BeanManager beanManager, Class beanClass) { > Set> beans = beanManager.getBeans(beanClass); > > for (Bean bean : beans) { > if (bean.getBeanClass() == beanClass) { > return (Bean) > beanManager.resolve(Collections.>singleton(bean)); > } > } > > return (Bean) beanManager.resolve(beans); > } > > As mentioned, while this seems to work, I wonder if it's the best approach. > > Kind regards, > Arjan > _______________________________________________ > 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 Thu Nov 20 16:32:39 2014 From: arjan.tijms at gmail.com (arjan tijms) Date: Thu, 20 Nov 2014 22:32:39 +0100 Subject: [cdi-dev] [servlet-spec users] [jsr369-experts] [116-CDIRelatedBeansInServletSpec] PROPOSAL In-Reply-To: <142766408.1701891.1416491239656.JavaMail.yahoo@jws11135.mail.ir2.yahoo.com> References: <21612.56559.530393.47262@gargle.gargle.HOWL> <142766408.1701891.1416491239656.JavaMail.yahoo@jws11135.mail.ir2.yahoo.com> Message-ID: Hi, On Thu, Nov 20, 2014 at 2:47 PM, Mark Struberg wrote: > I'm not quite sure that it's worth it. The @RequestScoped and @SessionScoped are already in the CDI spec package. And as you know we must not split packages between different specs. > > It would feel quite unnatural to have annotations in the CDI APIs but the description in the servlet spec. I don't think it's about moving those scope annotations, but just about the injection of HttpServletRequest, HttpSession and ServletContext. There's no particular annotation used to inject these, just @Inject. If I'm not mistaken, nothing will change in the API, as the producers for those types are implementation artifacts (build-in Bean instances). >Also note that some of those scopes (mostly @RequestScoped) also get used for non-servlet tasks. E.g. java-concurrency-utils threads, @Asynchronous EJBs, JMS invocations, @PostConstruct of @Stateless @Startup beans, etc. Indeed, @RequestScoped has a very broad definition that covers much more than just an HTTP request. @SessionScoped however has a definition that currently IS strongly tied to the Servlet spec: "The session scope is active: during the service() method of any servlet in the web application, during the doFilter() method of any servlet filter and when the container calls any HttpSessionListener, AsyncListener or ServletRequestListener. The session context is shared between all servlet requests that occur in the same HTTP session. The session context is destroyed when the HTTPSession times out, after all HttpSessionListeners have been called, and at the very end of any request in whichinvalidate() was called, after all filters and ServletRequestListeners have been called." See: https://docs.oracle.com/javaee/7/api/javax/enterprise/context/SessionScoped.html In an ideal world this one would *maybe* have been provided by the Servlet spec as well, but as you mention it's already in the CDI package, so I don't think this one can be easily moved. Kind regards, Arjan > > What we probably could add (regardless whether on CDI or Servlet side) is kind of a @WebAppScoped. This is really missing atm. But again this must also be active in e.g. JMS invocations which form kind a 'logical app'. > > > LieGrue, > strub > > > > >> On Wednesday, 19 November 2014, 19:40, Edward Burns wrote: >> > Hello Volunteers, >> >> The Servlet spec PDF currently only mentions CDI on two pages (and one >> of them is a reference to the other). It appears the normative >> declaration of the requirements in Servlet regarding CDI is in our >> section 15.5.15 "Contexts and Dependency Injection for Java EE >> requirements". >> >> The CDI spec is trying to trim itself down and part of that effort >> requires fobbing off some requirements previously declared in the CDI >> spec itself to other related specs. In this case, we have the >> following: >> >> CDI Spec section 3.8 [1] places some requirements on CDI implementations >> when running with Servlet. To better suit user desires for modularity >> these requirements are better met by moving them to the Servlet >> spec. Specifically, >> >> CDI3.8> A servlet container must provide the following built-in >> CDI3.8> beans, all of which have qualifier @Default: >> >> CDI3.8> a bean with bean type javax.servlet.http.HttpServletRequest, >> CDI3.8> allowing injection of a reference to the HttpServletRequest >> >> CDI3.8> a bean with bean type javax.servlet.http.HttpSession, >> CDI3.8> allowing injection of a reference to the HttpSession, >> >> CDI3.8> a bean with bean type javax.servlet.ServletContext, allowing >> CDI3.8> injection of a reference to the ServletContext, >> >> CDI3.8> These beans are passivation capable dependencies, as defined >> CDI3.8> in Passivation capable dependencies. >> >> To put these items in the Servlet spec, we may have to couch them in >> terms similar to, "when running in an environment that also supports >> CDI...". >> >> PROPOSAL: >> >> Include language in our spec section 15.5.15 which allows the CDI spec >> to remove their language while preserving desired existing user >> functionality. >> >> What do you all think? I know several of our constituents do not count >> CDI support among their user requirements. Is this going to be a >> problem? >> >> Ed >> >> [1] http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#additional_builtin_beans >> >> -- >> | edward.burns at oracle.com | office: +1 407 458 0017 >> > _______________________________________________ > 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 Thu Nov 20 17:01:20 2014 From: arjan.tijms at gmail.com (arjan tijms) Date: Thu, 20 Nov 2014 23:01:20 +0100 Subject: [cdi-dev] Getting injection point from Bean#create In-Reply-To: <546E522B.3090509@redhat.com> References: <546E522B.3090509@redhat.com> Message-ID: Hi, On Thu, Nov 20, 2014 at 9:42 PM, Jozef Hartinger wrote: > The simplest thing you can do is: > > Bean bean = (Bean) > manager.resolve(manager.getBeans(InjectionPoint.class)); > InjectionPoint ip = (InjectionPoint) manager.getReference(bean, > InjectionPoint.class, manager.createCreationalContext(bean)); That's exactly what I initially started with ;) It works perfectly on Weld, but unfortunately doesn't work on OWB (I tried 1.5.0). There's the following exception thrown with that code: java.lang.NullPointerException at org.apache.webbeans.portable.InjectionPointProducer.produce(InjectionPointProducer.java:59) at org.apache.webbeans.portable.InjectionPointProducer.produce(InjectionPointProducer.java:43) at org.apache.webbeans.portable.AbstractProducer.produce(AbstractProducer.java:195) at org.apache.webbeans.component.AbstractOwbBean.create(AbstractOwbBean.java:126) at org.apache.webbeans.context.DependentContext.getInstance(DependentContext.java:68) at org.apache.webbeans.context.AbstractContext.get(AbstractContext.java:124) at org.apache.webbeans.container.BeanManagerImpl.getReference(BeanManagerImpl.java:756) at org.apache.webbeans.container.InjectableBeanManager.getReference(InjectableBeanManager.java:165) It tries to execute the following code, where "first" turns up to be null: // the first injection point on the stack is of type InjectionPoint, so we need the second one CreationalContextImpl creationalContextImpl = (CreationalContextImpl)creationalContext; InjectionPoint first = creationalContextImpl.removeInjectionPoint(); if (!InjectionPoint.class.isAssignableFrom(ClassUtil.getClass(first.getType()))) I tried some variants on the above, like using the existing creationalContext in the manager.getReference call instead of creating a new one via manager.createCreationalContext(bean), but that too didn't work (throws java.lang.IllegalStateException: Inconsistent injection point stack). Kind regards, Arjan Tijms > > > On 11/19/2014 05:06 PM, arjan tijms wrote: >> >> Hi, >> >> In a producer method it's trivial to get access to an InjectionPoint >> instance representing the point where the value produced by the >> producer will be injected. >> >> When registering a Bean manually from an extension using >> AfterBeanDiscovery#addBean, this is not immediately obvious. >> >> After some fumbling with the CDI APIs I came up with the following >> code that seems to work on both Weld and OWB (didn't test CanDI yet). >> >> It uses a small "dummy" class, which is used to grab an InjectionPoint >> off: >> >> In a Bean: >> >> public Object create(CreationalContext creationalContext) { >> >> InjectionPoint injectionPoint = (InjectionPoint) >> beanManager.getInjectableReference( >> resolve(beanManager, >> InjectionPointGenerator.class).getInjectionPoints().iterator().next(), >> creationalContext >> ); >> >> With InjectionPointGenerator being the following class: >> >> public class InjectionPointGenerator { >> @Inject >> private InjectionPoint injectionPoint; >> } >> >> And resolve being the following method: >> >> public static Bean resolve(BeanManager beanManager, Class >> beanClass) { >> Set> beans = beanManager.getBeans(beanClass); >> >> for (Bean bean : beans) { >> if (bean.getBeanClass() == beanClass) { >> return (Bean) >> beanManager.resolve(Collections.>singleton(bean)); >> } >> } >> >> return (Bean) beanManager.resolve(beans); >> } >> >> As mentioned, while this seems to work, I wonder if it's the best >> approach. >> >> Kind regards, >> Arjan >> _______________________________________________ >> 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 Thu Nov 20 17:22:49 2014 From: arjan.tijms at gmail.com (arjan tijms) Date: Thu, 20 Nov 2014 23:22:49 +0100 Subject: [cdi-dev] Getting injection point from Bean#create In-Reply-To: References: <546E522B.3090509@redhat.com> Message-ID: Hi, On Thu, Nov 20, 2014 at 11:07 PM, Romain Manni-Bucau wrote: > Not sure what it means actually. InjectionPoint is highly contextual so > having an exception (not a npe of course) would make sense to me. > > Bean#create is a "you know what you do" from my understanding since > interceptors/decorators are not supported for instance so it shouldnt rely > of things like that, no? Sure, no interceptor/decorators, but the injection point -is- there of course. I can see it being set in OWB as a special property on the creational context if I walk down the stack trace in a debugger when my Bean#create method is being called. An injection point is something that implementations of Bean could always need, for instance to retrieve the name of the field into which injection is taking place. Of course, it being a "you know what you do", it's okay that it's not as simple as having it injected into the Bean, and that some extra code is needed to obtain it. As long as there is at least -a- way to get hold of it. The method I posted in the openings post does in fact work, but it feels slightly hacky. If that's an acceptable way to get the injection point, then so be it. But just wondering if it's not something that works by chance and may break later. Kind regards, Arjan From jharting at redhat.com Fri Nov 21 03:57:44 2014 From: jharting at redhat.com (Jozef Hartinger) Date: Fri, 21 Nov 2014 09:57:44 +0100 Subject: [cdi-dev] Getting injection point from Bean#create In-Reply-To: References: <546E522B.3090509@redhat.com> Message-ID: <546EFE88.9060804@redhat.com> The workaround is very ugly. Instead of going that path OWB should be fixed to support the simple way. On 11/20/2014 11:22 PM, arjan tijms wrote: > Hi, > > On Thu, Nov 20, 2014 at 11:07 PM, Romain Manni-Bucau > wrote: >> Not sure what it means actually. InjectionPoint is highly contextual so >> having an exception (not a npe of course) would make sense to me. >> >> Bean#create is a "you know what you do" from my understanding since >> interceptors/decorators are not supported for instance so it shouldnt rely >> of things like that, no? > Sure, no interceptor/decorators, but the injection point -is- there of > course. I can see it being set in OWB as a special property on the > creational context if I walk down the stack trace in a debugger when > my Bean#create method is being called. An injection point is something > that implementations of Bean could always need, for instance to > retrieve the name of the field into which injection is taking place. > > Of course, it being a "you know what you do", it's okay that it's not > as simple as having it injected into the Bean, and that some extra > code is needed to obtain it. As long as there is at least -a- way to > get hold of it. > > The method I posted in the openings post does in fact work, but it > feels slightly hacky. If that's an acceptable way to get the injection > point, then so be it. But just wondering if it's not something that > works by chance and may break later. > > Kind regards, > Arjan > _______________________________________________ > 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 Fri Nov 21 04:12:16 2014 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Fri, 21 Nov 2014 10:12:16 +0100 Subject: [cdi-dev] Getting injection point from Bean#create In-Reply-To: <546EFE88.9060804@redhat.com> References: <546E522B.3090509@redhat.com> <546EFE88.9060804@redhat.com> Message-ID: @Jozef: InjectionPoint ip = getBean(InjectionPoint.class); doesn't mean anything in the absolute. So why should it be allowed? Romain Manni-Bucau @rmannibucau http://www.tomitribe.com http://rmannibucau.wordpress.com https://github.com/rmannibucau 2014-11-21 9:57 GMT+01:00 Jozef Hartinger : > The workaround is very ugly. Instead of going that path OWB should be fixed > to support the simple way. > > > On 11/20/2014 11:22 PM, arjan tijms wrote: >> >> Hi, >> >> On Thu, Nov 20, 2014 at 11:07 PM, Romain Manni-Bucau >> wrote: >>> >>> Not sure what it means actually. InjectionPoint is highly contextual so >>> having an exception (not a npe of course) would make sense to me. >>> >>> Bean#create is a "you know what you do" from my understanding since >>> interceptors/decorators are not supported for instance so it shouldnt >>> rely >>> of things like that, no? >> >> Sure, no interceptor/decorators, but the injection point -is- there of >> course. I can see it being set in OWB as a special property on the >> creational context if I walk down the stack trace in a debugger when >> my Bean#create method is being called. An injection point is something >> that implementations of Bean could always need, for instance to >> retrieve the name of the field into which injection is taking place. >> >> Of course, it being a "you know what you do", it's okay that it's not >> as simple as having it injected into the Bean, and that some extra >> code is needed to obtain it. As long as there is at least -a- way to >> get hold of it. >> >> The method I posted in the openings post does in fact work, but it >> feels slightly hacky. If that's an acceptable way to get the injection >> point, then so be it. But just wondering if it's not something that >> works by chance and may break later. >> >> Kind regards, >> Arjan >> _______________________________________________ >> 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 jharting at redhat.com Fri Nov 21 04:19:54 2014 From: jharting at redhat.com (Jozef Hartinger) Date: Fri, 21 Nov 2014 10:19:54 +0100 Subject: [cdi-dev] Getting injection point from Bean#create In-Reply-To: References: <546E522B.3090509@redhat.com> <546EFE88.9060804@redhat.com> Message-ID: <546F03BA.2070104@redhat.com> It means "give me an instance of type InjectionPoint and @Default qualifier". In default setup this should be served by the built-in Bean". On 11/21/2014 10:12 AM, Romain Manni-Bucau wrote: > @Jozef: InjectionPoint ip = getBean(InjectionPoint.class); doesn't > mean anything in the absolute. So why should it be allowed? > > > Romain Manni-Bucau > @rmannibucau > http://www.tomitribe.com > http://rmannibucau.wordpress.com > https://github.com/rmannibucau > > > 2014-11-21 9:57 GMT+01:00 Jozef Hartinger : >> The workaround is very ugly. Instead of going that path OWB should be fixed >> to support the simple way. >> >> >> On 11/20/2014 11:22 PM, arjan tijms wrote: >>> Hi, >>> >>> On Thu, Nov 20, 2014 at 11:07 PM, Romain Manni-Bucau >>> wrote: >>>> Not sure what it means actually. InjectionPoint is highly contextual so >>>> having an exception (not a npe of course) would make sense to me. >>>> >>>> Bean#create is a "you know what you do" from my understanding since >>>> interceptors/decorators are not supported for instance so it shouldnt >>>> rely >>>> of things like that, no? >>> Sure, no interceptor/decorators, but the injection point -is- there of >>> course. I can see it being set in OWB as a special property on the >>> creational context if I walk down the stack trace in a debugger when >>> my Bean#create method is being called. An injection point is something >>> that implementations of Bean could always need, for instance to >>> retrieve the name of the field into which injection is taking place. >>> >>> Of course, it being a "you know what you do", it's okay that it's not >>> as simple as having it injected into the Bean, and that some extra >>> code is needed to obtain it. As long as there is at least -a- way to >>> get hold of it. >>> >>> The method I posted in the openings post does in fact work, but it >>> feels slightly hacky. If that's an acceptable way to get the injection >>> point, then so be it. But just wondering if it's not something that >>> works by chance and may break later. >>> >>> Kind regards, >>> Arjan >>> _______________________________________________ >>> 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 Fri Nov 21 04:23:29 2014 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Fri, 21 Nov 2014 10:23:29 +0100 Subject: [cdi-dev] Getting injection point from Bean#create In-Reply-To: <546F03BA.2070104@redhat.com> References: <546E522B.3090509@redhat.com> <546EFE88.9060804@redhat.com> <546F03BA.2070104@redhat.com> Message-ID: yes but what would mean any of the values? Not bound to any injection it doesn't mean anything Romain Manni-Bucau @rmannibucau http://www.tomitribe.com http://rmannibucau.wordpress.com https://github.com/rmannibucau 2014-11-21 10:19 GMT+01:00 Jozef Hartinger : > It means "give me an instance of type InjectionPoint and @Default > qualifier". In default setup this should be served by the built-in > Bean". > > > On 11/21/2014 10:12 AM, Romain Manni-Bucau wrote: >> >> @Jozef: InjectionPoint ip = getBean(InjectionPoint.class); doesn't >> mean anything in the absolute. So why should it be allowed? >> >> >> Romain Manni-Bucau >> @rmannibucau >> http://www.tomitribe.com >> http://rmannibucau.wordpress.com >> https://github.com/rmannibucau >> >> >> 2014-11-21 9:57 GMT+01:00 Jozef Hartinger : >>> >>> The workaround is very ugly. Instead of going that path OWB should be >>> fixed >>> to support the simple way. >>> >>> >>> On 11/20/2014 11:22 PM, arjan tijms wrote: >>>> >>>> Hi, >>>> >>>> On Thu, Nov 20, 2014 at 11:07 PM, Romain Manni-Bucau >>>> wrote: >>>>> >>>>> Not sure what it means actually. InjectionPoint is highly contextual so >>>>> having an exception (not a npe of course) would make sense to me. >>>>> >>>>> Bean#create is a "you know what you do" from my understanding since >>>>> interceptors/decorators are not supported for instance so it shouldnt >>>>> rely >>>>> of things like that, no? >>>> >>>> Sure, no interceptor/decorators, but the injection point -is- there of >>>> course. I can see it being set in OWB as a special property on the >>>> creational context if I walk down the stack trace in a debugger when >>>> my Bean#create method is being called. An injection point is something >>>> that implementations of Bean could always need, for instance to >>>> retrieve the name of the field into which injection is taking place. >>>> >>>> Of course, it being a "you know what you do", it's okay that it's not >>>> as simple as having it injected into the Bean, and that some extra >>>> code is needed to obtain it. As long as there is at least -a- way to >>>> get hold of it. >>>> >>>> The method I posted in the openings post does in fact work, but it >>>> feels slightly hacky. If that's an acceptable way to get the injection >>>> point, then so be it. But just wondering if it's not something that >>>> works by chance and may break later. >>>> >>>> Kind regards, >>>> Arjan >>>> _______________________________________________ >>>> 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 jharting at redhat.com Fri Nov 21 04:31:49 2014 From: jharting at redhat.com (Jozef Hartinger) Date: Fri, 21 Nov 2014 10:31:49 +0100 Subject: [cdi-dev] Getting injection point from Bean#create In-Reply-To: References: <546E522B.3090509@redhat.com> <546EFE88.9060804@redhat.com> <546F03BA.2070104@redhat.com> Message-ID: <546F0685.1050103@redhat.com> We may not be on the same page here. Here is my understanding of Arjan's setup: There is a custom Bean e.g. "FooBean implements Bean" producing instances of Foo. I assume the bean is @Dependent. Then, there is a Bar class e.g. public class Bar { @Inject Foo foo; } If FooBean#create() calls "InjectionPoint ip = getBean(InjectionPoint.class);" it means "I want to see an InjectionPoint representing where I am being injected". In our case this would be InjectionPoint representing Bar.foo field. This is no different from a producer method injecting InjectionPoint directly. On 11/21/2014 10:23 AM, Romain Manni-Bucau wrote: > yes but what would mean any of the values? Not bound to any injection > it doesn't mean anything > > > Romain Manni-Bucau > @rmannibucau > http://www.tomitribe.com > http://rmannibucau.wordpress.com > https://github.com/rmannibucau > > > 2014-11-21 10:19 GMT+01:00 Jozef Hartinger : >> It means "give me an instance of type InjectionPoint and @Default >> qualifier". In default setup this should be served by the built-in >> Bean". >> >> >> On 11/21/2014 10:12 AM, Romain Manni-Bucau wrote: >>> @Jozef: InjectionPoint ip = getBean(InjectionPoint.class); doesn't >>> mean anything in the absolute. So why should it be allowed? >>> >>> >>> Romain Manni-Bucau >>> @rmannibucau >>> http://www.tomitribe.com >>> http://rmannibucau.wordpress.com >>> https://github.com/rmannibucau >>> >>> >>> 2014-11-21 9:57 GMT+01:00 Jozef Hartinger : >>>> The workaround is very ugly. Instead of going that path OWB should be >>>> fixed >>>> to support the simple way. >>>> >>>> >>>> On 11/20/2014 11:22 PM, arjan tijms wrote: >>>>> Hi, >>>>> >>>>> On Thu, Nov 20, 2014 at 11:07 PM, Romain Manni-Bucau >>>>> wrote: >>>>>> Not sure what it means actually. InjectionPoint is highly contextual so >>>>>> having an exception (not a npe of course) would make sense to me. >>>>>> >>>>>> Bean#create is a "you know what you do" from my understanding since >>>>>> interceptors/decorators are not supported for instance so it shouldnt >>>>>> rely >>>>>> of things like that, no? >>>>> Sure, no interceptor/decorators, but the injection point -is- there of >>>>> course. I can see it being set in OWB as a special property on the >>>>> creational context if I walk down the stack trace in a debugger when >>>>> my Bean#create method is being called. An injection point is something >>>>> that implementations of Bean could always need, for instance to >>>>> retrieve the name of the field into which injection is taking place. >>>>> >>>>> Of course, it being a "you know what you do", it's okay that it's not >>>>> as simple as having it injected into the Bean, and that some extra >>>>> code is needed to obtain it. As long as there is at least -a- way to >>>>> get hold of it. >>>>> >>>>> The method I posted in the openings post does in fact work, but it >>>>> feels slightly hacky. If that's an acceptable way to get the injection >>>>> point, then so be it. But just wondering if it's not something that >>>>> works by chance and may break later. >>>>> >>>>> Kind regards, >>>>> Arjan >>>>> _______________________________________________ >>>>> 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 Fri Nov 21 05:17:44 2014 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Fri, 21 Nov 2014 11:17:44 +0100 Subject: [cdi-dev] Getting injection point from Bean#create In-Reply-To: <546F0685.1050103@redhat.com> References: <546E522B.3090509@redhat.com> <546EFE88.9060804@redhat.com> <546F03BA.2070104@redhat.com> <546F0685.1050103@redhat.com> Message-ID: Ok makes sense so it means failing in getBean(Foo.class) is fine right? Another issue is what if there is @inject InjectionPoint ip, in Foo? This should work (validated in TCKs) Romain Manni-Bucau @rmannibucau http://www.tomitribe.com http://rmannibucau.wordpress.com https://github.com/rmannibucau 2014-11-21 10:31 GMT+01:00 Jozef Hartinger : > We may not be on the same page here. Here is my understanding of Arjan's > setup: > > There is a custom Bean e.g. "FooBean implements Bean" producing > instances of Foo. I assume the bean is @Dependent. > > Then, there is a Bar class e.g. > public class Bar { > @Inject Foo foo; > } > > If FooBean#create() calls "InjectionPoint ip = > getBean(InjectionPoint.class);" it means "I want to see an InjectionPoint > representing where I am being injected". In our case this would be > InjectionPoint representing Bar.foo field. > > This is no different from a producer method injecting InjectionPoint > directly. > > > On 11/21/2014 10:23 AM, Romain Manni-Bucau wrote: >> >> yes but what would mean any of the values? Not bound to any injection >> it doesn't mean anything >> >> >> Romain Manni-Bucau >> @rmannibucau >> http://www.tomitribe.com >> http://rmannibucau.wordpress.com >> https://github.com/rmannibucau >> >> >> 2014-11-21 10:19 GMT+01:00 Jozef Hartinger : >>> >>> It means "give me an instance of type InjectionPoint and @Default >>> qualifier". In default setup this should be served by the built-in >>> Bean". >>> >>> >>> On 11/21/2014 10:12 AM, Romain Manni-Bucau wrote: >>>> >>>> @Jozef: InjectionPoint ip = getBean(InjectionPoint.class); doesn't >>>> mean anything in the absolute. So why should it be allowed? >>>> >>>> >>>> Romain Manni-Bucau >>>> @rmannibucau >>>> http://www.tomitribe.com >>>> http://rmannibucau.wordpress.com >>>> https://github.com/rmannibucau >>>> >>>> >>>> 2014-11-21 9:57 GMT+01:00 Jozef Hartinger : >>>>> >>>>> The workaround is very ugly. Instead of going that path OWB should be >>>>> fixed >>>>> to support the simple way. >>>>> >>>>> >>>>> On 11/20/2014 11:22 PM, arjan tijms wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> On Thu, Nov 20, 2014 at 11:07 PM, Romain Manni-Bucau >>>>>> wrote: >>>>>>> >>>>>>> Not sure what it means actually. InjectionPoint is highly contextual >>>>>>> so >>>>>>> having an exception (not a npe of course) would make sense to me. >>>>>>> >>>>>>> Bean#create is a "you know what you do" from my understanding since >>>>>>> interceptors/decorators are not supported for instance so it shouldnt >>>>>>> rely >>>>>>> of things like that, no? >>>>>> >>>>>> Sure, no interceptor/decorators, but the injection point -is- there of >>>>>> course. I can see it being set in OWB as a special property on the >>>>>> creational context if I walk down the stack trace in a debugger when >>>>>> my Bean#create method is being called. An injection point is something >>>>>> that implementations of Bean could always need, for instance to >>>>>> retrieve the name of the field into which injection is taking place. >>>>>> >>>>>> Of course, it being a "you know what you do", it's okay that it's not >>>>>> as simple as having it injected into the Bean, and that some extra >>>>>> code is needed to obtain it. As long as there is at least -a- way to >>>>>> get hold of it. >>>>>> >>>>>> The method I posted in the openings post does in fact work, but it >>>>>> feels slightly hacky. If that's an acceptable way to get the injection >>>>>> point, then so be it. But just wondering if it's not something that >>>>>> works by chance and may break later. >>>>>> >>>>>> Kind regards, >>>>>> Arjan >>>>>> _______________________________________________ >>>>>> 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 Fri Nov 21 05:34:39 2014 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Fri, 21 Nov 2014 11:34:39 +0100 Subject: [cdi-dev] Getting injection point from Bean#create In-Reply-To: References: <546E522B.3090509@redhat.com> <546EFE88.9060804@redhat.com> <546F03BA.2070104@redhat.com> <546F0685.1050103@redhat.com> Message-ID: PS: BTW should work on OWB 1.5.0-SNAPSHOT now Romain Manni-Bucau @rmannibucau http://www.tomitribe.com http://rmannibucau.wordpress.com https://github.com/rmannibucau 2014-11-21 11:17 GMT+01:00 Romain Manni-Bucau : > Ok makes sense so it means failing in getBean(Foo.class) is fine > right? Another issue is what if there is @inject InjectionPoint ip, in > Foo? This should work (validated in TCKs) > > > Romain Manni-Bucau > @rmannibucau > http://www.tomitribe.com > http://rmannibucau.wordpress.com > https://github.com/rmannibucau > > > 2014-11-21 10:31 GMT+01:00 Jozef Hartinger : >> We may not be on the same page here. Here is my understanding of Arjan's >> setup: >> >> There is a custom Bean e.g. "FooBean implements Bean" producing >> instances of Foo. I assume the bean is @Dependent. >> >> Then, there is a Bar class e.g. >> public class Bar { >> @Inject Foo foo; >> } >> >> If FooBean#create() calls "InjectionPoint ip = >> getBean(InjectionPoint.class);" it means "I want to see an InjectionPoint >> representing where I am being injected". In our case this would be >> InjectionPoint representing Bar.foo field. >> >> This is no different from a producer method injecting InjectionPoint >> directly. >> >> >> On 11/21/2014 10:23 AM, Romain Manni-Bucau wrote: >>> >>> yes but what would mean any of the values? Not bound to any injection >>> it doesn't mean anything >>> >>> >>> Romain Manni-Bucau >>> @rmannibucau >>> http://www.tomitribe.com >>> http://rmannibucau.wordpress.com >>> https://github.com/rmannibucau >>> >>> >>> 2014-11-21 10:19 GMT+01:00 Jozef Hartinger : >>>> >>>> It means "give me an instance of type InjectionPoint and @Default >>>> qualifier". In default setup this should be served by the built-in >>>> Bean". >>>> >>>> >>>> On 11/21/2014 10:12 AM, Romain Manni-Bucau wrote: >>>>> >>>>> @Jozef: InjectionPoint ip = getBean(InjectionPoint.class); doesn't >>>>> mean anything in the absolute. So why should it be allowed? >>>>> >>>>> >>>>> Romain Manni-Bucau >>>>> @rmannibucau >>>>> http://www.tomitribe.com >>>>> http://rmannibucau.wordpress.com >>>>> https://github.com/rmannibucau >>>>> >>>>> >>>>> 2014-11-21 9:57 GMT+01:00 Jozef Hartinger : >>>>>> >>>>>> The workaround is very ugly. Instead of going that path OWB should be >>>>>> fixed >>>>>> to support the simple way. >>>>>> >>>>>> >>>>>> On 11/20/2014 11:22 PM, arjan tijms wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> On Thu, Nov 20, 2014 at 11:07 PM, Romain Manni-Bucau >>>>>>> wrote: >>>>>>>> >>>>>>>> Not sure what it means actually. InjectionPoint is highly contextual >>>>>>>> so >>>>>>>> having an exception (not a npe of course) would make sense to me. >>>>>>>> >>>>>>>> Bean#create is a "you know what you do" from my understanding since >>>>>>>> interceptors/decorators are not supported for instance so it shouldnt >>>>>>>> rely >>>>>>>> of things like that, no? >>>>>>> >>>>>>> Sure, no interceptor/decorators, but the injection point -is- there of >>>>>>> course. I can see it being set in OWB as a special property on the >>>>>>> creational context if I walk down the stack trace in a debugger when >>>>>>> my Bean#create method is being called. An injection point is something >>>>>>> that implementations of Bean could always need, for instance to >>>>>>> retrieve the name of the field into which injection is taking place. >>>>>>> >>>>>>> Of course, it being a "you know what you do", it's okay that it's not >>>>>>> as simple as having it injected into the Bean, and that some extra >>>>>>> code is needed to obtain it. As long as there is at least -a- way to >>>>>>> get hold of it. >>>>>>> >>>>>>> The method I posted in the openings post does in fact work, but it >>>>>>> feels slightly hacky. If that's an acceptable way to get the injection >>>>>>> point, then so be it. But just wondering if it's not something that >>>>>>> works by chance and may break later. >>>>>>> >>>>>>> Kind regards, >>>>>>> Arjan >>>>>>> _______________________________________________ >>>>>>> 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 Fri Nov 21 06:58:15 2014 From: arjan.tijms at gmail.com (arjan tijms) Date: Fri, 21 Nov 2014 12:58:15 +0100 Subject: [cdi-dev] Getting injection point from Bean#create In-Reply-To: <546F0685.1050103@redhat.com> References: <546E522B.3090509@redhat.com> <546EFE88.9060804@redhat.com> <546F03BA.2070104@redhat.com> <546F0685.1050103@redhat.com> Message-ID: Hi, On Fri, Nov 21, 2014 at 10:31 AM, Jozef Hartinger wrote: > Here is my understanding of Arjan's > setup: > [...] > > This is no different from a producer method injecting InjectionPoint > directly. That's indeed the exact setup. On Fri, Nov 21, 2014 at 11:34 AM, Romain Manni-Bucau wrote: > PS: BTW should work on OWB 1.5.0-SNAPSHOT now Wow, I'll look at the latest SNAPSHOT of OWB then. Thanks Romain! Kind regards, Arjan > > > On 11/21/2014 10:23 AM, Romain Manni-Bucau wrote: >> >> yes but what would mean any of the values? Not bound to any injection >> it doesn't mean anything >> >> >> Romain Manni-Bucau >> @rmannibucau >> http://www.tomitribe.com >> http://rmannibucau.wordpress.com >> https://github.com/rmannibucau >> >> >> 2014-11-21 10:19 GMT+01:00 Jozef Hartinger : >>> >>> It means "give me an instance of type InjectionPoint and @Default >>> qualifier". In default setup this should be served by the built-in >>> Bean". >>> >>> >>> On 11/21/2014 10:12 AM, Romain Manni-Bucau wrote: >>>> >>>> @Jozef: InjectionPoint ip = getBean(InjectionPoint.class); doesn't >>>> mean anything in the absolute. So why should it be allowed? >>>> >>>> >>>> Romain Manni-Bucau >>>> @rmannibucau >>>> http://www.tomitribe.com >>>> http://rmannibucau.wordpress.com >>>> https://github.com/rmannibucau >>>> >>>> >>>> 2014-11-21 9:57 GMT+01:00 Jozef Hartinger : >>>>> >>>>> The workaround is very ugly. Instead of going that path OWB should be >>>>> fixed >>>>> to support the simple way. >>>>> >>>>> >>>>> On 11/20/2014 11:22 PM, arjan tijms wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> On Thu, Nov 20, 2014 at 11:07 PM, Romain Manni-Bucau >>>>>> wrote: >>>>>>> >>>>>>> Not sure what it means actually. InjectionPoint is highly contextual >>>>>>> so >>>>>>> having an exception (not a npe of course) would make sense to me. >>>>>>> >>>>>>> Bean#create is a "you know what you do" from my understanding since >>>>>>> interceptors/decorators are not supported for instance so it shouldnt >>>>>>> rely >>>>>>> of things like that, no? >>>>>> >>>>>> Sure, no interceptor/decorators, but the injection point -is- there of >>>>>> course. I can see it being set in OWB as a special property on the >>>>>> creational context if I walk down the stack trace in a debugger when >>>>>> my Bean#create method is being called. An injection point is something >>>>>> that implementations of Bean could always need, for instance to >>>>>> retrieve the name of the field into which injection is taking place. >>>>>> >>>>>> Of course, it being a "you know what you do", it's okay that it's not >>>>>> as simple as having it injected into the Bean, and that some extra >>>>>> code is needed to obtain it. As long as there is at least -a- way to >>>>>> get hold of it. >>>>>> >>>>>> The method I posted in the openings post does in fact work, but it >>>>>> feels slightly hacky. If that's an acceptable way to get the injection >>>>>> point, then so be it. But just wondering if it's not something that >>>>>> works by chance and may break later. >>>>>> >>>>>> Kind regards, >>>>>> Arjan >>>>>> _______________________________________________ >>>>>> 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 jharting at redhat.com Fri Nov 21 07:01:20 2014 From: jharting at redhat.com (Jozef Hartinger) Date: Fri, 21 Nov 2014 13:01:20 +0100 Subject: [cdi-dev] Getting injection point from Bean#create In-Reply-To: References: <546E522B.3090509@redhat.com> <546EFE88.9060804@redhat.com> <546F03BA.2070104@redhat.com> <546F0685.1050103@redhat.com> Message-ID: <546F2990.1070004@redhat.com> On 11/21/2014 11:17 AM, Romain Manni-Bucau wrote: > Ok makes sense so it means failing in getBean(Foo.class) is fine > right? Correct, if Foo is not injected into an actual injection point but instead BeanManager.getReference() is used instead, it is OK for Foo to get null as the InjectionPoint > Another issue is what if there is @inject InjectionPoint ip, in > Foo? This should work (validated in TCKs) Yes, same as above. > > > Romain Manni-Bucau > @rmannibucau > http://www.tomitribe.com > http://rmannibucau.wordpress.com > https://github.com/rmannibucau > > > 2014-11-21 10:31 GMT+01:00 Jozef Hartinger : >> We may not be on the same page here. Here is my understanding of Arjan's >> setup: >> >> There is a custom Bean e.g. "FooBean implements Bean" producing >> instances of Foo. I assume the bean is @Dependent. >> >> Then, there is a Bar class e.g. >> public class Bar { >> @Inject Foo foo; >> } >> >> If FooBean#create() calls "InjectionPoint ip = >> getBean(InjectionPoint.class);" it means "I want to see an InjectionPoint >> representing where I am being injected". In our case this would be >> InjectionPoint representing Bar.foo field. >> >> This is no different from a producer method injecting InjectionPoint >> directly. >> >> >> On 11/21/2014 10:23 AM, Romain Manni-Bucau wrote: >>> yes but what would mean any of the values? Not bound to any injection >>> it doesn't mean anything >>> >>> >>> Romain Manni-Bucau >>> @rmannibucau >>> http://www.tomitribe.com >>> http://rmannibucau.wordpress.com >>> https://github.com/rmannibucau >>> >>> >>> 2014-11-21 10:19 GMT+01:00 Jozef Hartinger : >>>> It means "give me an instance of type InjectionPoint and @Default >>>> qualifier". In default setup this should be served by the built-in >>>> Bean". >>>> >>>> >>>> On 11/21/2014 10:12 AM, Romain Manni-Bucau wrote: >>>>> @Jozef: InjectionPoint ip = getBean(InjectionPoint.class); doesn't >>>>> mean anything in the absolute. So why should it be allowed? >>>>> >>>>> >>>>> Romain Manni-Bucau >>>>> @rmannibucau >>>>> http://www.tomitribe.com >>>>> http://rmannibucau.wordpress.com >>>>> https://github.com/rmannibucau >>>>> >>>>> >>>>> 2014-11-21 9:57 GMT+01:00 Jozef Hartinger : >>>>>> The workaround is very ugly. Instead of going that path OWB should be >>>>>> fixed >>>>>> to support the simple way. >>>>>> >>>>>> >>>>>> On 11/20/2014 11:22 PM, arjan tijms wrote: >>>>>>> Hi, >>>>>>> >>>>>>> On Thu, Nov 20, 2014 at 11:07 PM, Romain Manni-Bucau >>>>>>> wrote: >>>>>>>> Not sure what it means actually. InjectionPoint is highly contextual >>>>>>>> so >>>>>>>> having an exception (not a npe of course) would make sense to me. >>>>>>>> >>>>>>>> Bean#create is a "you know what you do" from my understanding since >>>>>>>> interceptors/decorators are not supported for instance so it shouldnt >>>>>>>> rely >>>>>>>> of things like that, no? >>>>>>> Sure, no interceptor/decorators, but the injection point -is- there of >>>>>>> course. I can see it being set in OWB as a special property on the >>>>>>> creational context if I walk down the stack trace in a debugger when >>>>>>> my Bean#create method is being called. An injection point is something >>>>>>> that implementations of Bean could always need, for instance to >>>>>>> retrieve the name of the field into which injection is taking place. >>>>>>> >>>>>>> Of course, it being a "you know what you do", it's okay that it's not >>>>>>> as simple as having it injected into the Bean, and that some extra >>>>>>> code is needed to obtain it. As long as there is at least -a- way to >>>>>>> get hold of it. >>>>>>> >>>>>>> The method I posted in the openings post does in fact work, but it >>>>>>> feels slightly hacky. If that's an acceptable way to get the injection >>>>>>> point, then so be it. But just wondering if it's not something that >>>>>>> works by chance and may break later. >>>>>>> >>>>>>> Kind regards, >>>>>>> Arjan >>>>>>> _______________________________________________ >>>>>>> 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 edward.burns at oracle.com Fri Nov 21 09:14:25 2014 From: edward.burns at oracle.com (Edward Burns) Date: Fri, 21 Nov 2014 06:14:25 -0800 Subject: [cdi-dev] [servlet-spec users] [jsr369-experts] [116-CDIRelatedBeansInServletSpec] PROPOSAL In-Reply-To: <142766408.1701891.1416491239656.JavaMail.yahoo@jws11135.mail.ir2.yahoo.com> References: <21612.56559.530393.47262@gargle.gargle.HOWL> <142766408.1701891.1416491239656.JavaMail.yahoo@jws11135.mail.ir2.yahoo.com> Message-ID: <21615.18625.427842.794819@gargle.gargle.HOWL> Mark added cdi-dev to the recipients list, but I am not subscribed to that (please don't add me, I rely on JJ to keep me up to date!), so this may bounce there. Also, Mark, there is no . The users lists are re-used from JSR to JSR for each technology. Thus, I have put users at servlet-spec.java.net in place of the non-existent list. On Wednesday, 19 November 2014, 19:40, Edward Burns wrote: [...] EB> section 15.5.15 "Contexts and Dependency Injection for Java EE EB> requirements". EB> The CDI spec is trying to trim itself down [...] EB> CDI Spec section 3.8 [1] places some requirements on CDI implementations EB> when running with Servlet. To better suit user desires for modularity EB> these requirements are better met by moving them to the Servlet EB> spec. [...] EB> To put these items in the Servlet spec, we may have to couch them in EB> terms similar to, "when running in an environment that also supports EB> CDI...". EB> PROPOSAL: EB> Include language in our spec section 15.5.15 which allows the CDI spec EB> to remove their language while preserving desired existing user EB> functionality. [...] >>>>> On Thu, 20 Nov 2014 13:47:19 +0000 (UTC), Mark Struberg said: MS> I'm not quite sure that it's worth it. The @RequestScoped and MS> @SessionScoped are already in the CDI spec package. And as you know MS> we must not split packages between different specs. >>>>> On Thu, 20 Nov 2014 22:32:39 +0100, arjan tijms said: AT> I don't think it's about moving those scope annotations, but just AT> about the injection of HttpServletRequest, HttpSession and AT> ServletContext. Granted. The proposal does not touch those. Mark was just questioning if it was worth it. I am skeptical myself, but am responsive to community input. MS> It would feel quite unnatural to have annotations in the CDI APIs MS> but the description in the servlet spec. [...] I'll trust that Antoine Sabot-Durand (ASD) will take your reservations into account when deciding to press on with CDI-492-FobStuffToServlet or not. MS> What we probably could add (regardless whether on CDI or Servlet MS> side) is kind of a @WebAppScoped. This is really missing atm. But MS> again this must also be active in e.g. JMS invocations which form MS> kind a 'logical app'. That's a whole new thing, again for ASD to consider. As you observe, it doesn't belong in Servlet because JMS can also use it. Ed -- | edward.burns at oracle.com | office: +1 407 458 0017 From werner.keil at gmail.com Fri Nov 21 09:30:12 2014 From: werner.keil at gmail.com (Werner Keil) Date: Fri, 21 Nov 2014 15:30:12 +0100 Subject: [cdi-dev] [servlet-spec users] [jsr369-experts] [116-CDIRelatedBeansInServletSpec] PROPOSAL Message-ID: >MS> side) is kind of a @WebAppScoped. This is really missing atm. But >MS> again this must also be active in e.g. JMS invocations which form >MS> kind a 'logical app'. "logical app" what's wrong with @ApplicationScoped especially for JMS? We got e.g. a very distributed Java EE app here at the current client where JMS is a vital part, but it's not just used in the Web tier. Werner On Fri, Nov 21, 2014 at 3:14 PM, 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: Getting injection point from Bean#create (Romain Manni-Bucau) > 2. Re: Getting injection point from Bean#create (Romain Manni-Bucau) > 3. Re: Getting injection point from Bean#create (arjan tijms) > 4. Re: Getting injection point from Bean#create (Jozef Hartinger) > 5. Re: [servlet-spec users] [jsr369-experts] > [116-CDIRelatedBeansInServletSpec] PROPOSAL (Edward Burns) > > > ---------------------------------------------------------------------- > > > Message: 5 > Date: Fri, 21 Nov 2014 06:14:25 -0800 > From: Edward Burns > Subject: Re: [cdi-dev] [servlet-spec users] [jsr369-experts] > [116-CDIRelatedBeansInServletSpec] PROPOSAL > To: Mark Struberg , users at servlet-spec.java.net, > Cdi-dev > Message-ID: <21615.18625.427842.794819 at gargle.gargle.HOWL> > Content-Type: text/plain; charset=us-ascii > > Mark added cdi-dev to the recipients list, but I am not subscribed to > that (please don't add me, I rely on JJ to keep me up to date!), so this > may bounce there. > > Also, Mark, there is no . The users > lists are re-used from JSR to JSR for each technology. Thus, I have put > users at servlet-spec.java.net in place of the non-existent list. > > On Wednesday, 19 November 2014, 19:40, Edward Burns < > edward.burns at oracle.com> wrote: > > [...] > > EB> section 15.5.15 "Contexts and Dependency Injection for Java EE > EB> requirements". > > EB> The CDI spec is trying to trim itself down [...] > > EB> CDI Spec section 3.8 [1] places some requirements on CDI > implementations > EB> when running with Servlet. To better suit user desires for modularity > EB> these requirements are better met by moving them to the Servlet > EB> spec. > > [...] > > EB> To put these items in the Servlet spec, we may have to couch them in > EB> terms similar to, "when running in an environment that also supports > EB> CDI...". > > EB> PROPOSAL: > > EB> Include language in our spec section 15.5.15 which allows the CDI spec > EB> to remove their language while preserving desired existing user > EB> functionality. > > [...] > > >>>>> On Thu, 20 Nov 2014 13:47:19 +0000 (UTC), Mark Struberg < > struberg at yahoo.de> said: > > MS> I'm not quite sure that it's worth it. The @RequestScoped and > MS> @SessionScoped are already in the CDI spec package. And as you know > MS> we must not split packages between different specs. > > >>>>> On Thu, 20 Nov 2014 22:32:39 +0100, arjan tijms < > arjan.tijms at gmail.com> said: > > AT> I don't think it's about moving those scope annotations, but just > AT> about the injection of HttpServletRequest, HttpSession and > AT> ServletContext. > > Granted. The proposal does not touch those. Mark was just questioning > if it was worth it. I am skeptical myself, but am responsive to > community input. > > MS> It would feel quite unnatural to have annotations in the CDI APIs > MS> but the description in the servlet spec. [...] > > I'll trust that Antoine Sabot-Durand (ASD) will take your reservations > into account when deciding to press on with CDI-492-FobStuffToServlet or > not. > > MS> What we probably could add (regardless whether on CDI or Servlet > MS> side) is kind of a @WebAppScoped. This is really missing atm. But > MS> again this must also be active in e.g. JMS invocations which form > MS> kind a 'logical app'. > > That's a whole new thing, again for ASD to consider. As you observe, it > doesn't belong in Servlet because JMS can also use it. > > Ed > > -- > | edward.burns at oracle.com | office: +1 407 458 0017 > > > ------------------------------ > > _______________________________________________ > 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 48, Issue 16 > *************************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20141121/07a97d59/attachment.html From struberg at yahoo.de Fri Nov 21 13:58:22 2014 From: struberg at yahoo.de (Mark Struberg) Date: Fri, 21 Nov 2014 18:58:22 +0000 (UTC) Subject: [cdi-dev] [servlet-spec users] [jsr369-experts] [116-CDIRelatedBeansInServletSpec] PROPOSAL In-Reply-To: References: Message-ID: <712146538.2402112.1416596302496.JavaMail.yahoo@jws11103.mail.ir2.yahoo.com> >"logical app" what's wrong with @ApplicationScoped especially for JMS? We had this discussion quite some time ago. If you like to have fun then read up CDI-129 ;) It basically boils down that the majority of CDI EG members wanted to behave @ApplicationScoped as "1 per EAR", so we miss the "1 per Module/WebApp". But this is needed if you e.g. like to store something which is unique to the webapp. E.g a cache in a JSF app. Would be pretty nasty to share e.g. caches over different WARs... LieGrue, strub On Friday, 21 November 2014, 17:45, Werner Keil wrote: >>MS> side) is kind of a @WebAppScoped. This is really missing atm. But >>MS> again this must also be active in e.g. JMS invocations which form >>MS> kind a 'logical app'. > > >"logical app" what's wrong with @ApplicationScoped especially for JMS? >We got e.g. a very distributed Java EE app here at the current client where JMS is a vital part, but it's not just used in the Web tier. > > >Werner > > > > > >On Fri, Nov 21, 2014 at 3:14 PM, 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: Getting injection point from Bean#create (Romain Manni-Bucau) >> 2. Re: Getting injection point from Bean#create (Romain Manni-Bucau) >> 3. Re: Getting injection point from Bean#create (arjan tijms) >> 4. Re: Getting injection point from Bean#create (Jozef Hartinger) >> 5. Re: [servlet-spec users] [jsr369-experts] >> [116-CDIRelatedBeansInServletSpec] PROPOSAL (Edward Burns) >> >> >>---------------------------------------------------------------------- >> >> >>Message: 5 >>Date: Fri, 21 Nov 2014 06:14:25 -0800 >>From: Edward Burns >>Subject: Re: [cdi-dev] [servlet-spec users] [jsr369-experts] >> [116-CDIRelatedBeansInServletSpec] PROPOSAL >>To: Mark Struberg , users at servlet-spec.java.net, >> Cdi-dev >>Message-ID: <21615.18625.427842.794819 at gargle.gargle.HOWL> >>Content-Type: text/plain; charset=us-ascii >> >>Mark added cdi-dev to the recipients list, but I am not subscribed to >>that (please don't add me, I rely on JJ to keep me up to date!), so this >>may bounce there. >> >>Also, Mark, there is no . The users >>lists are re-used from JSR to JSR for each technology. Thus, I have put >>users at servlet-spec.java.net in place of the non-existent list. >> >>On Wednesday, 19 November 2014, 19:40, Edward Burns wrote: >> >>[...] >> >>EB> section 15.5.15 "Contexts and Dependency Injection for Java EE >>EB> requirements". >> >>EB> The CDI spec is trying to trim itself down [...] >> >>EB> CDI Spec section 3.8 [1] places some requirements on CDI implementations >>EB> when running with Servlet. To better suit user desires for modularity >>EB> these requirements are better met by moving them to the Servlet >>EB> spec. >> >>[...] >> >>EB> To put these items in the Servlet spec, we may have to couch them in >>EB> terms similar to, "when running in an environment that also supports >>EB> CDI...". >> >>EB> PROPOSAL: >> >>EB> Include language in our spec section 15.5.15 which allows the CDI spec >>EB> to remove their language while preserving desired existing user >>EB> functionality. >> >>[...] >> >>>>>>> On Thu, 20 Nov 2014 13:47:19 +0000 (UTC), Mark Struberg said: >> >>MS> I'm not quite sure that it's worth it. The @RequestScoped and >>MS> @SessionScoped are already in the CDI spec package. And as you know >>MS> we must not split packages between different specs. >> >>>>>>> On Thu, 20 Nov 2014 22:32:39 +0100, arjan tijms said: >> >>AT> I don't think it's about moving those scope annotations, but just >>AT> about the injection of HttpServletRequest, HttpSession and >>AT> ServletContext. >> >>Granted. The proposal does not touch those. Mark was just questioning >>if it was worth it. I am skeptical myself, but am responsive to >>community input. >> >>MS> It would feel quite unnatural to have annotations in the CDI APIs >>MS> but the description in the servlet spec. [...] >> >>I'll trust that Antoine Sabot-Durand (ASD) will take your reservations >>into account when deciding to press on with CDI-492-FobStuffToServlet or >>not. >> >>MS> What we probably could add (regardless whether on CDI or Servlet >>MS> side) is kind of a @WebAppScoped. This is really missing atm. But >>MS> again this must also be active in e.g. JMS invocations which form >>MS> kind a 'logical app'. >> >>That's a whole new thing, again for ASD to consider. As you observe, it >>doesn't belong in Servlet because JMS can also use it. >> >>Ed >> >>-- >>| edward.burns at oracle.com | office: +1 407 458 0017 >> >> >>------------------------------ >> >>_______________________________________________ >>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 48, Issue 16 >>*************************************** >> > >_______________________________________________ >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 Fri Nov 21 14:33:03 2014 From: arjan.tijms at gmail.com (arjan tijms) Date: Fri, 21 Nov 2014 20:33:03 +0100 Subject: [cdi-dev] [servlet-spec users] [jsr369-experts] [116-CDIRelatedBeansInServletSpec] PROPOSAL In-Reply-To: <712146538.2402112.1416596302496.JavaMail.yahoo@jws11103.mail.ir2.yahoo.com> References: <712146538.2402112.1416596302496.JavaMail.yahoo@jws11103.mail.ir2.yahoo.com> Message-ID: Hi, On Fri, Nov 21, 2014 at 7:58 PM, Mark Struberg wrote: >>"logical app" what's wrong with @ApplicationScoped especially for JMS? > > We had this discussion quite some time ago. If you like to have fun then read up CDI-129 ;) > It basically boils down that the majority of CDI EG members wanted to behave @ApplicationScoped as "1 per EAR", so we miss the "1 per Module/WebApp". This has indeed been discussed before and remains a problematic issue. Don't want to go too much off-topic here, but the scope of extensions and @Named within an EAR with multiple wars suffers from a similar issue. See e.g. http://balusc.blogspot.com/2013/10/cdi-behaved-unexpectedly-in-ear-so.html Kind regards, Arjan From struberg at yahoo.de Fri Nov 21 16:05:15 2014 From: struberg at yahoo.de (Mark Struberg) Date: Fri, 21 Nov 2014 21:05:15 +0000 (UTC) Subject: [cdi-dev] [servlet-spec users] [jsr369-experts] [116-CDIRelatedBeansInServletSpec] PROPOSAL In-Reply-To: References: Message-ID: <1877815206.2189470.1416603915544.JavaMail.yahoo@jws11116.mail.ir2.yahoo.com> Oh and before I get misinterpreted: it was pretty soon clear to all the EG that we need 2 Scopes. The question was just whether the existing CDI-1.0 @ApplicationScoped annotation should be the 1-per-EAR or the 1-per-Module. LieGrue, strub > On Friday, 21 November 2014, 20:33, arjan tijms wrote: > > Hi, > > > On Fri, Nov 21, 2014 at 7:58 PM, Mark Struberg wrote: >>> "logical app" what's wrong with @ApplicationScoped > especially for JMS? >> >> We had this discussion quite some time ago. If you like to have fun then > read up CDI-129 ;) >> It basically boils down that the majority of CDI EG members wanted to > behave @ApplicationScoped as "1 per EAR", so we miss the "1 per > Module/WebApp". > > This has indeed been discussed before and remains a problematic issue. > Don't want to go too much off-topic here, but the scope of extensions > and @Named within an EAR with multiple wars suffers from a similar > issue. See e.g. > http://balusc.blogspot.com/2013/10/cdi-behaved-unexpectedly-in-ear-so.html > > Kind regards, > Arjan > From issues at jboss.org Fri Nov 21 16:23:39 2014 From: issues at jboss.org (Ed Burns (JIRA)) Date: Fri, 21 Nov 2014 16:23:39 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-492) Give ownership of servlet specific part to servlet specification In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022101#comment-13022101 ] Ed Burns commented on CDI-492: ------------------------------ I brought up this issue in the servlet EG and it was shot down. Here is the reasoning. As spec lead, I do agree with the reasoning so I have provisionally closed the issue unless we can find a way to address the concerns of the servlet EG: {quote} >>>>> On Wed, 19 Nov 2014 15:55:43 -0500 (EST), Stuart Douglas said: [...] SD> I think however there may be some backwards compatibility issues for SD> the standalone servlet container case. SD> Say I have an application that packages Weld (or OWB) that I have SD> deployed on a Servlet 3.1 container, and I now want to move it to a SD> Servlet 4.0 container. The older version of Weld will still provide SD> the HttpServletRequest beans (as it is required to do by spec) and SD> the servlet container will also provide these beans (as we are SD> required to do by spec) and as a result if you try and inject them SD> you will get a bean resolution error as two beans resolve to the SD> injection point. SD> This also works in reverse, if you deploy a new version of CDI to an SD> older servlet container then no beans will be registered, however I SD> think this is less of an issue. SD> For servers that don't actually provide CDI API jars there may also SD> be some linking issues. The producers need to be linked against the SD> CDI API which in this case will be provided by the deployment, so it SD> won't really be possible to just have them as a global library. >>>>> On Fri, 21 Nov 2014 14:06:24 +1100, Greg Wilkins said: [...] GW> I share Stuarts concerns about classloading confusion. More over, GW> I'm concerned that by making CDI to servlet mapping a responsibility GW> of the servlet container, then we are going to have to do a GW> container to CDI adaptation for every CDI implementation out there. GW> The servlet specification already provides servlet container initializers, GW> which have all the power required for CDI implementations to implement GW> these CDI v Servlet cross concerns. Thus I think these things must GW> remain a CDI impl responsibility as they are able to write container GW> portable code that will handle these concerns. The inverse is not true if GW> we make them container concerns. Excellent points. I will use these to push back on CDI-492-FobStuffToServlet. I will provisionally close this issue for now at least. {quote} > Give ownership of servlet specific part to servlet specification > ---------------------------------------------------------------- > > Key: CDI-492 > URL: https://issues.jboss.org/browse/CDI-492 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Java EE integration > Reporter: Antoine Sabot-Durand > > [Section 3.8 of the spec|http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#additional_builtin_beans] places some requirements on CDI implementations when running with Servlet. To better suit user desires for modularity these requirements are better met by moving them to the Servlet spec. Specifically, > {quote} > A servlet container must provide the following built-in beans, all of which have qualifier @Default: > * a bean with bean type {{javax.servlet.http.HttpServletRequest}}, allowing injection of a reference to the HttpServletRequest > * a bean with bean type {{javax.servlet.http.HttpSession}}, allowing injection of a reference to the HttpSession, > * a bean with bean type {{javax.servlet.ServletContext}}, allowing injection of a reference to the ServletContext, > These beans are passivation capable dependencies, as defined in Passivation capable dependencies. > {quote} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From arne.limburg at openknowledge.de Sat Nov 22 05:23:13 2014 From: arne.limburg at openknowledge.de (Arne Limburg) Date: Sat, 22 Nov 2014 10:23:13 +0000 Subject: [cdi-dev] Getting injection point from Bean#create In-Reply-To: Message-ID: Hi Arjan, I?ve verified, that this is a bug in OpenWebBeans. I've created https://issues.apache.org/jira/browse/OWB-1030 and I?m going to fix it. Btw.: You have to use the CreationalContext of the bean (the way OWB currently throws the "Inconsistent injection point stack" exception) Cheers, Arne Am 21.11.14 12:58 schrieb "arjan tijms" unter : >Hi, > >On Fri, Nov 21, 2014 at 10:31 AM, Jozef Hartinger >wrote: >> Here is my understanding of Arjan's >> setup: >> [...] >> >> This is no different from a producer method injecting InjectionPoint >> directly. > >That's indeed the exact setup. > >On Fri, Nov 21, 2014 at 11:34 AM, Romain Manni-Bucau > wrote: >> PS: BTW should work on OWB 1.5.0-SNAPSHOT now > >Wow, I'll look at the latest SNAPSHOT of OWB then. Thanks Romain! > >Kind regards, >Arjan > > > > >> >> >> On 11/21/2014 10:23 AM, Romain Manni-Bucau wrote: >>> >>> yes but what would mean any of the values? Not bound to any injection >>> it doesn't mean anything >>> >>> >>> Romain Manni-Bucau >>> @rmannibucau >>> http://www.tomitribe.com >>> http://rmannibucau.wordpress.com >>> https://github.com/rmannibucau >>> >>> >>> 2014-11-21 10:19 GMT+01:00 Jozef Hartinger : >>>> >>>> It means "give me an instance of type InjectionPoint and @Default >>>> qualifier". In default setup this should be served by the built-in >>>> Bean". >>>> >>>> >>>> On 11/21/2014 10:12 AM, Romain Manni-Bucau wrote: >>>>> >>>>> @Jozef: InjectionPoint ip = getBean(InjectionPoint.class); doesn't >>>>> mean anything in the absolute. So why should it be allowed? >>>>> >>>>> >>>>> Romain Manni-Bucau >>>>> @rmannibucau >>>>> http://www.tomitribe.com >>>>> http://rmannibucau.wordpress.com >>>>> https://github.com/rmannibucau >>>>> >>>>> >>>>> 2014-11-21 9:57 GMT+01:00 Jozef Hartinger : >>>>>> >>>>>> The workaround is very ugly. Instead of going that path OWB should >>>>>>be >>>>>> fixed >>>>>> to support the simple way. >>>>>> >>>>>> >>>>>> On 11/20/2014 11:22 PM, arjan tijms wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> On Thu, Nov 20, 2014 at 11:07 PM, Romain Manni-Bucau >>>>>>> wrote: >>>>>>>> >>>>>>>> Not sure what it means actually. InjectionPoint is highly >>>>>>>>contextual >>>>>>>> so >>>>>>>> having an exception (not a npe of course) would make sense to me. >>>>>>>> >>>>>>>> Bean#create is a "you know what you do" from my understanding >>>>>>>>since >>>>>>>> interceptors/decorators are not supported for instance so it >>>>>>>>shouldnt >>>>>>>> rely >>>>>>>> of things like that, no? >>>>>>> >>>>>>> Sure, no interceptor/decorators, but the injection point -is- >>>>>>>there of >>>>>>> course. I can see it being set in OWB as a special property on the >>>>>>> creational context if I walk down the stack trace in a debugger >>>>>>>when >>>>>>> my Bean#create method is being called. An injection point is >>>>>>>something >>>>>>> that implementations of Bean could always need, for instance to >>>>>>> retrieve the name of the field into which injection is taking >>>>>>>place. >>>>>>> >>>>>>> Of course, it being a "you know what you do", it's okay that it's >>>>>>>not >>>>>>> as simple as having it injected into the Bean, and that some extra >>>>>>> code is needed to obtain it. As long as there is at least -a- way >>>>>>>to >>>>>>> get hold of it. >>>>>>> >>>>>>> The method I posted in the openings post does in fact work, but it >>>>>>> feels slightly hacky. If that's an acceptable way to get the >>>>>>>injection >>>>>>> point, then so be it. But just wondering if it's not something that >>>>>>> works by chance and may break later. >>>>>>> >>>>>>> Kind regards, >>>>>>> Arjan >>>>>>> _______________________________________________ >>>>>>> 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 arjan.tijms at gmail.com Sat Nov 22 09:14:45 2014 From: arjan.tijms at gmail.com (arjan tijms) Date: Sat, 22 Nov 2014 15:14:45 +0100 Subject: [cdi-dev] Getting injection point from Bean#create In-Reply-To: References: Message-ID: Hi On Sat, Nov 22, 2014 at 11:23 AM, Arne Limburg wrote: > I?ve verified, that this is a bug in OpenWebBeans. > I've created > https://issues.apache.org/jira/browse/OWB-1030 > and I?m going to fix it. Cool, thanks! Btw, didn't Romain already fix something? His last reply was: >PS: BTW should work on OWB 1.5.0-SNAPSHOT now > Btw.: You have to use the CreationalContext of the bean (the way OWB > currently throws the "Inconsistent injection point stack" exception) Okay, I tested whether that works on Weld too, and it does. So after your fix the following should work on both Weld and OWB then: public class SomeBean implements Bean { BeanManager beanManager; @Override public Object create(CreationalContext creationalContext) { Bean bean = (Bean) beanManager.resolve(beanManager.getBeans(InjectionPoint.class)); InjectionPoint ip = (InjectionPoint) beanManager.getReference(bean, InjectionPoint.class, creationalContext); // ... } // ctor assigning beanManager and other methods below } Kind regards, Arjan > > Cheers, > Arne > > > Am 21.11.14 12:58 schrieb "arjan tijms" unter : > >>Hi, >> >>On Fri, Nov 21, 2014 at 10:31 AM, Jozef Hartinger >>wrote: >>> Here is my understanding of Arjan's >>> setup: >>> [...] >>> >>> This is no different from a producer method injecting InjectionPoint >>> directly. >> >>That's indeed the exact setup. >> >>On Fri, Nov 21, 2014 at 11:34 AM, Romain Manni-Bucau >> wrote: >>> PS: BTW should work on OWB 1.5.0-SNAPSHOT now >> >>Wow, I'll look at the latest SNAPSHOT of OWB then. Thanks Romain! >> >>Kind regards, >>Arjan >> >> >> >> >>> >>> >>> On 11/21/2014 10:23 AM, Romain Manni-Bucau wrote: >>>> >>>> yes but what would mean any of the values? Not bound to any injection >>>> it doesn't mean anything >>>> >>>> >>>> Romain Manni-Bucau >>>> @rmannibucau >>>> http://www.tomitribe.com >>>> http://rmannibucau.wordpress.com >>>> https://github.com/rmannibucau >>>> >>>> >>>> 2014-11-21 10:19 GMT+01:00 Jozef Hartinger : >>>>> >>>>> It means "give me an instance of type InjectionPoint and @Default >>>>> qualifier". In default setup this should be served by the built-in >>>>> Bean". >>>>> >>>>> >>>>> On 11/21/2014 10:12 AM, Romain Manni-Bucau wrote: >>>>>> >>>>>> @Jozef: InjectionPoint ip = getBean(InjectionPoint.class); doesn't >>>>>> mean anything in the absolute. So why should it be allowed? >>>>>> >>>>>> >>>>>> Romain Manni-Bucau >>>>>> @rmannibucau >>>>>> http://www.tomitribe.com >>>>>> http://rmannibucau.wordpress.com >>>>>> https://github.com/rmannibucau >>>>>> >>>>>> >>>>>> 2014-11-21 9:57 GMT+01:00 Jozef Hartinger : >>>>>>> >>>>>>> The workaround is very ugly. Instead of going that path OWB should >>>>>>>be >>>>>>> fixed >>>>>>> to support the simple way. >>>>>>> >>>>>>> >>>>>>> On 11/20/2014 11:22 PM, arjan tijms wrote: >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> On Thu, Nov 20, 2014 at 11:07 PM, Romain Manni-Bucau >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Not sure what it means actually. InjectionPoint is highly >>>>>>>>>contextual >>>>>>>>> so >>>>>>>>> having an exception (not a npe of course) would make sense to me. >>>>>>>>> >>>>>>>>> Bean#create is a "you know what you do" from my understanding >>>>>>>>>since >>>>>>>>> interceptors/decorators are not supported for instance so it >>>>>>>>>shouldnt >>>>>>>>> rely >>>>>>>>> of things like that, no? >>>>>>>> >>>>>>>> Sure, no interceptor/decorators, but the injection point -is- >>>>>>>>there of >>>>>>>> course. I can see it being set in OWB as a special property on the >>>>>>>> creational context if I walk down the stack trace in a debugger >>>>>>>>when >>>>>>>> my Bean#create method is being called. An injection point is >>>>>>>>something >>>>>>>> that implementations of Bean could always need, for instance to >>>>>>>> retrieve the name of the field into which injection is taking >>>>>>>>place. >>>>>>>> >>>>>>>> Of course, it being a "you know what you do", it's okay that it's >>>>>>>>not >>>>>>>> as simple as having it injected into the Bean, and that some extra >>>>>>>> code is needed to obtain it. As long as there is at least -a- way >>>>>>>>to >>>>>>>> get hold of it. >>>>>>>> >>>>>>>> The method I posted in the openings post does in fact work, but it >>>>>>>> feels slightly hacky. If that's an acceptable way to get the >>>>>>>>injection >>>>>>>> point, then so be it. But just wondering if it's not something that >>>>>>>> works by chance and may break later. >>>>>>>> >>>>>>>> Kind regards, >>>>>>>> Arjan >>>>>>>> _______________________________________________ >>>>>>>> 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 arne.limburg at openknowledge.de Sat Nov 22 10:20:42 2014 From: arne.limburg at openknowledge.de (Arne Limburg) Date: Sat, 22 Nov 2014 15:20:42 +0000 Subject: [cdi-dev] Getting injection point from Bean#create In-Reply-To: Message-ID: Romain did a quick fix and your code will work with that fix as well. So with OWB trunk your code should work. But we are currently discussing how this should be done right in OWB. Cheers, Arne Am 22.11.14 15:14 schrieb "arjan tijms" unter : >Hi > >On Sat, Nov 22, 2014 at 11:23 AM, Arne Limburg > wrote: >> I?ve verified, that this is a bug in OpenWebBeans. >> I've created >> https://issues.apache.org/jira/browse/OWB-1030 >> and I?m going to fix it. > >Cool, thanks! Btw, didn't Romain already fix something? His last reply >was: > >>PS: BTW should work on OWB 1.5.0-SNAPSHOT now > >> Btw.: You have to use the CreationalContext of the bean (the way OWB >> currently throws the "Inconsistent injection point stack" exception) > >Okay, I tested whether that works on Weld too, and it does. So after >your fix the following should work on both Weld and OWB then: > >public class SomeBean implements Bean { > > BeanManager beanManager; > > @Override > public Object create(CreationalContext creationalContext) { > > Bean bean = (Bean) >beanManager.resolve(beanManager.getBeans(InjectionPoint.class)); > InjectionPoint ip = (InjectionPoint) >beanManager.getReference(bean, InjectionPoint.class, >creationalContext); > > // ... > } > > // ctor assigning beanManager and other methods below >} > >Kind regards, >Arjan > > > > >> >> Cheers, >> Arne >> >> >> Am 21.11.14 12:58 schrieb "arjan tijms" unter : >> >>>Hi, >>> >>>On Fri, Nov 21, 2014 at 10:31 AM, Jozef Hartinger >>>wrote: >>>> Here is my understanding of Arjan's >>>> setup: >>>> [...] >>>> >>>> This is no different from a producer method injecting InjectionPoint >>>> directly. >>> >>>That's indeed the exact setup. >>> >>>On Fri, Nov 21, 2014 at 11:34 AM, Romain Manni-Bucau >>> wrote: >>>> PS: BTW should work on OWB 1.5.0-SNAPSHOT now >>> >>>Wow, I'll look at the latest SNAPSHOT of OWB then. Thanks Romain! >>> >>>Kind regards, >>>Arjan >>> >>> >>> >>> >>>> >>>> >>>> On 11/21/2014 10:23 AM, Romain Manni-Bucau wrote: >>>>> >>>>> yes but what would mean any of the values? Not bound to any injection >>>>> it doesn't mean anything >>>>> >>>>> >>>>> Romain Manni-Bucau >>>>> @rmannibucau >>>>> http://www.tomitribe.com >>>>> http://rmannibucau.wordpress.com >>>>> https://github.com/rmannibucau >>>>> >>>>> >>>>> 2014-11-21 10:19 GMT+01:00 Jozef Hartinger : >>>>>> >>>>>> It means "give me an instance of type InjectionPoint and @Default >>>>>> qualifier". In default setup this should be served by the built-in >>>>>> Bean". >>>>>> >>>>>> >>>>>> On 11/21/2014 10:12 AM, Romain Manni-Bucau wrote: >>>>>>> >>>>>>> @Jozef: InjectionPoint ip = getBean(InjectionPoint.class); doesn't >>>>>>> mean anything in the absolute. So why should it be allowed? >>>>>>> >>>>>>> >>>>>>> Romain Manni-Bucau >>>>>>> @rmannibucau >>>>>>> http://www.tomitribe.com >>>>>>> http://rmannibucau.wordpress.com >>>>>>> https://github.com/rmannibucau >>>>>>> >>>>>>> >>>>>>> 2014-11-21 9:57 GMT+01:00 Jozef Hartinger : >>>>>>>> >>>>>>>> The workaround is very ugly. Instead of going that path OWB should >>>>>>>>be >>>>>>>> fixed >>>>>>>> to support the simple way. >>>>>>>> >>>>>>>> >>>>>>>> On 11/20/2014 11:22 PM, arjan tijms wrote: >>>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> On Thu, Nov 20, 2014 at 11:07 PM, Romain Manni-Bucau >>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> Not sure what it means actually. InjectionPoint is highly >>>>>>>>>>contextual >>>>>>>>>> so >>>>>>>>>> having an exception (not a npe of course) would make sense to >>>>>>>>>>me. >>>>>>>>>> >>>>>>>>>> Bean#create is a "you know what you do" from my understanding >>>>>>>>>>since >>>>>>>>>> interceptors/decorators are not supported for instance so it >>>>>>>>>>shouldnt >>>>>>>>>> rely >>>>>>>>>> of things like that, no? >>>>>>>>> >>>>>>>>> Sure, no interceptor/decorators, but the injection point -is- >>>>>>>>>there of >>>>>>>>> course. I can see it being set in OWB as a special property on >>>>>>>>>the >>>>>>>>> creational context if I walk down the stack trace in a debugger >>>>>>>>>when >>>>>>>>> my Bean#create method is being called. An injection point is >>>>>>>>>something >>>>>>>>> that implementations of Bean could always need, for instance to >>>>>>>>> retrieve the name of the field into which injection is taking >>>>>>>>>place. >>>>>>>>> >>>>>>>>> Of course, it being a "you know what you do", it's okay that it's >>>>>>>>>not >>>>>>>>> as simple as having it injected into the Bean, and that some >>>>>>>>>extra >>>>>>>>> code is needed to obtain it. As long as there is at least -a- way >>>>>>>>>to >>>>>>>>> get hold of it. >>>>>>>>> >>>>>>>>> The method I posted in the openings post does in fact work, but >>>>>>>>>it >>>>>>>>> feels slightly hacky. If that's an acceptable way to get the >>>>>>>>>injection >>>>>>>>> point, then so be it. But just wondering if it's not something >>>>>>>>>that >>>>>>>>> works by chance and may break later. >>>>>>>>> >>>>>>>>> Kind regards, >>>>>>>>> Arjan >>>>>>>>> _______________________________________________ >>>>>>>>> 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 issues at jboss.org Mon Nov 24 10:43:39 2014 From: issues at jboss.org (Sven Linstaedt (JIRA)) Date: Mon, 24 Nov 2014 10:43:39 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-493) Allow firiing of generic events from BeanManager In-Reply-To: References: Message-ID: Sven Linstaedt created CDI-493: ---------------------------------- Summary: Allow firiing of generic events from BeanManager Key: CDI-493 URL: https://issues.jboss.org/browse/CDI-493 Project: CDI Specification Issues Issue Type: Feature Request Reporter: Sven Linstaedt Currently we are allowed firiing generic events from {{javax.enterprise.event.Event#fire}} as long as it's type parameter X does not contain a TypeVariable. When it comes to {{javax.enterprise.inject.spi.BeanManager#fireEvent}} and {{javax.enterprise.inject.spi.BeanManager#resolveObserverMethods}} this is unfortunately not possible due to type erasure. Because we lack the relevant generic information that are otherwise explicit stated via {{Event#select}}, we are not able to fire a generic event from {{BeanManager#fireEvent}}. This proposal is about enhancing the API of BeanManager in order to supply the relevant type information, that are otherwise discarded by type erasure. A possible solution would look like adding two new methods to BeanManager {code} BeanManager#fireEvent(Type, Object, Annotation...) BeanManager#resolveObserverMethods(Type, T, Annotation...) {code} which receive the selected event type as 1st parameter, validate that the actual event instance (2nd parameter) is assignable to the selected event type (the selected event type has to resolve all type variables; throwing an IllegalArgumentException otherwise) and fires the event afterwards. The original two methods can delegate their calls to the new ones, having {{java.lang.Object}} as event type. Additionally {{javax.enterprise.inject.spi.EventMetadata#getType()}} will return the resolved parameterized type. With this proposal it would be possible to provide meta-extensions, that enable other extension to handle custom extension lifecycle events like {code} void on(@Observes @BoundWith(InterceptorBinding.class) ProcessBoundedType pbt) { if (pbt.getBoundedType().isAnnotationPresent(Interceptor.class)) { // register interceptor type } else { // register intercepted type } } {code} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 24 10:43:39 2014 From: issues at jboss.org (Sven Linstaedt (JIRA)) Date: Mon, 24 Nov 2014 10:43:39 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-493) Allow firing of generic events from BeanManager In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sven Linstaedt updated CDI-493: ------------------------------- Summary: Allow firing of generic events from BeanManager (was: Allow firiing of generic events from BeanManager) > Allow firing of generic events from BeanManager > ----------------------------------------------- > > Key: CDI-493 > URL: https://issues.jboss.org/browse/CDI-493 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Sven Linstaedt > > Currently we are allowed firiing generic events from {{javax.enterprise.event.Event#fire}} as long as it's type parameter X does not contain a TypeVariable. > When it comes to {{javax.enterprise.inject.spi.BeanManager#fireEvent}} and {{javax.enterprise.inject.spi.BeanManager#resolveObserverMethods}} this is unfortunately not possible due to type erasure. Because we lack the relevant generic information that are otherwise explicit stated via {{Event#select}}, we are not able to fire a generic event from {{BeanManager#fireEvent}}. > This proposal is about enhancing the API of BeanManager in order to supply the relevant type information, that are otherwise discarded by type erasure. A possible solution would look like adding two new methods to BeanManager > {code} > BeanManager#fireEvent(Type, Object, Annotation...) > BeanManager#resolveObserverMethods(Type, T, Annotation...) > {code} > which receive the selected event type as 1st parameter, validate that the actual event instance (2nd parameter) is assignable to the selected event type (the selected event type has to resolve all type variables; throwing an IllegalArgumentException otherwise) and fires the event afterwards. > The original two methods can delegate their calls to the new ones, having {{java.lang.Object}} as event type. > Additionally {{javax.enterprise.inject.spi.EventMetadata#getType()}} will return the resolved parameterized type. > With this proposal it would be possible to provide meta-extensions, that enable other extension to handle custom extension lifecycle events like > {code} > void on(@Observes @BoundWith(InterceptorBinding.class) ProcessBoundedType pbt) { > if (pbt.getBoundedType().isAnnotationPresent(Interceptor.class)) { > // register interceptor type > } else { > // register intercepted type > } > } > {code} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 24 10:44:39 2014 From: issues at jboss.org (Sven Linstaedt (JIRA)) Date: Mon, 24 Nov 2014 10:44:39 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-493) Allow firing of generic events from BeanManager In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sven Linstaedt updated CDI-493: ------------------------------- Description: Currently we are allowed firing generic events from {{javax.enterprise.event.Event#fire}} as long as it's type parameter X does not contain a TypeVariable. When it comes to {{javax.enterprise.inject.spi.BeanManager#fireEvent}} and {{javax.enterprise.inject.spi.BeanManager#resolveObserverMethods}} this is unfortunately not possible due to type erasure. Because we lack the relevant generic information that are otherwise explicit stated via {{Event#select}}, we are not able to fire a generic event from {{BeanManager#fireEvent}}. This proposal is about enhancing the API of BeanManager in order to supply the relevant type information, that are otherwise discarded by type erasure. A possible solution would look like adding two new methods to BeanManager {code} BeanManager#fireEvent(Type, Object, Annotation...) BeanManager#resolveObserverMethods(Type, T, Annotation...) {code} which receive the selected event type as 1st parameter, validate that the actual event instance (2nd parameter) is assignable to the selected event type (the selected event type has to resolve all type variables; throwing an IllegalArgumentException otherwise) and fires the event afterwards. The original two methods can delegate their calls to the new ones, having {{java.lang.Object}} as event type. Additionally {{javax.enterprise.inject.spi.EventMetadata#getType()}} will return the resolved parameterized type. With this proposal it would be possible to provide meta-extensions, that enable other extension to handle custom extension lifecycle events like {code} void on(@Observes @BoundWith(InterceptorBinding.class) ProcessBoundedType pbt) { if (pbt.getBoundedType().isAnnotationPresent(Interceptor.class)) { // register interceptor type } else { // register intercepted type } } {code} was: Currently we are allowed firiing generic events from {{javax.enterprise.event.Event#fire}} as long as it's type parameter X does not contain a TypeVariable. When it comes to {{javax.enterprise.inject.spi.BeanManager#fireEvent}} and {{javax.enterprise.inject.spi.BeanManager#resolveObserverMethods}} this is unfortunately not possible due to type erasure. Because we lack the relevant generic information that are otherwise explicit stated via {{Event#select}}, we are not able to fire a generic event from {{BeanManager#fireEvent}}. This proposal is about enhancing the API of BeanManager in order to supply the relevant type information, that are otherwise discarded by type erasure. A possible solution would look like adding two new methods to BeanManager {code} BeanManager#fireEvent(Type, Object, Annotation...) BeanManager#resolveObserverMethods(Type, T, Annotation...) {code} which receive the selected event type as 1st parameter, validate that the actual event instance (2nd parameter) is assignable to the selected event type (the selected event type has to resolve all type variables; throwing an IllegalArgumentException otherwise) and fires the event afterwards. The original two methods can delegate their calls to the new ones, having {{java.lang.Object}} as event type. Additionally {{javax.enterprise.inject.spi.EventMetadata#getType()}} will return the resolved parameterized type. With this proposal it would be possible to provide meta-extensions, that enable other extension to handle custom extension lifecycle events like {code} void on(@Observes @BoundWith(InterceptorBinding.class) ProcessBoundedType pbt) { if (pbt.getBoundedType().isAnnotationPresent(Interceptor.class)) { // register interceptor type } else { // register intercepted type } } {code} > Allow firing of generic events from BeanManager > ----------------------------------------------- > > Key: CDI-493 > URL: https://issues.jboss.org/browse/CDI-493 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Sven Linstaedt > > Currently we are allowed firing generic events from {{javax.enterprise.event.Event#fire}} as long as it's type parameter X does not contain a TypeVariable. > When it comes to {{javax.enterprise.inject.spi.BeanManager#fireEvent}} and {{javax.enterprise.inject.spi.BeanManager#resolveObserverMethods}} this is unfortunately not possible due to type erasure. Because we lack the relevant generic information that are otherwise explicit stated via {{Event#select}}, we are not able to fire a generic event from {{BeanManager#fireEvent}}. > This proposal is about enhancing the API of BeanManager in order to supply the relevant type information, that are otherwise discarded by type erasure. A possible solution would look like adding two new methods to BeanManager > {code} > BeanManager#fireEvent(Type, Object, Annotation...) > BeanManager#resolveObserverMethods(Type, T, Annotation...) > {code} > which receive the selected event type as 1st parameter, validate that the actual event instance (2nd parameter) is assignable to the selected event type (the selected event type has to resolve all type variables; throwing an IllegalArgumentException otherwise) and fires the event afterwards. > The original two methods can delegate their calls to the new ones, having {{java.lang.Object}} as event type. > Additionally {{javax.enterprise.inject.spi.EventMetadata#getType()}} will return the resolved parameterized type. > With this proposal it would be possible to provide meta-extensions, that enable other extension to handle custom extension lifecycle events like > {code} > void on(@Observes @BoundWith(InterceptorBinding.class) ProcessBoundedType pbt) { > if (pbt.getBoundedType().isAnnotationPresent(Interceptor.class)) { > // register interceptor type > } else { > // register intercepted type > } > } > {code} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 24 10:49:39 2014 From: issues at jboss.org (Sven Linstaedt (JIRA)) Date: Mon, 24 Nov 2014 10:49:39 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-493) Allow firing of generic events from BeanManager In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022413#comment-13022413 ] Sven Linstaedt commented on CDI-493: ------------------------------------ Jozef Hartinger already mentioned something similar in [1], but I guess this was just forgotten. [1] https://issues.jboss.org/browse/CDI-169?focusedCommentId=12637565&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12637565 > Allow firing of generic events from BeanManager > ----------------------------------------------- > > Key: CDI-493 > URL: https://issues.jboss.org/browse/CDI-493 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Sven Linstaedt > > Currently we are allowed firing generic events from {{javax.enterprise.event.Event#fire}} as long as it's type parameter X does not contain a TypeVariable. > When it comes to {{javax.enterprise.inject.spi.BeanManager#fireEvent}} and {{javax.enterprise.inject.spi.BeanManager#resolveObserverMethods}} this is unfortunately not possible due to type erasure. Because we lack the relevant generic information that are otherwise explicit stated via {{Event#select}}, we are not able to fire a generic event from {{BeanManager#fireEvent}}. > This proposal is about enhancing the API of BeanManager in order to supply the relevant type information, that are otherwise discarded by type erasure. A possible solution would look like adding two new methods to BeanManager > {code} > BeanManager#fireEvent(Type, Object, Annotation...) > BeanManager#resolveObserverMethods(Type, T, Annotation...) > {code} > which receive the selected event type as 1st parameter, validate that the actual event instance (2nd parameter) is assignable to the selected event type (the selected event type has to resolve all type variables; throwing an IllegalArgumentException otherwise) and fires the event afterwards. > The original two methods can delegate their calls to the new ones, having {{java.lang.Object}} as event type. > Additionally {{javax.enterprise.inject.spi.EventMetadata#getType()}} will return the resolved parameterized type. > With this proposal it would be possible to provide meta-extensions, that enable other extension to handle custom extension lifecycle events like > {code} > void on(@Observes @BoundWith(InterceptorBinding.class) ProcessBoundedType pbt) { > if (pbt.getBoundedType().isAnnotationPresent(Interceptor.class)) { > // register interceptor type > } else { > // register intercepted type > } > } > {code} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 26 02:36:39 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 26 Nov 2014 02:36:39 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-492) Give ownership of servlet specific part to servlet specification In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022986#comment-13022986 ] Antoine Sabot-Durand commented on CDI-492: ------------------------------------------ [~edburns] I understand those concerns, but I think there are solution for most of them. The points given don't take into account evolutions that could be done in CDI and JSR 330 to make it possible. To take all the points and give first ideas to solve them : *backward compatibility* : introducing a qualifier for these beans (like it's done in Deltaspike to work with CDI 1.0 and 1.1) is a first lead like {{@Servlet}} to tell that these beans are owned by Servlet spec. *Dependency on CDI* ; as you know we're going to work on a new AtInject version. We could imagine having the servlet impl only be dependent on AtInject (which will stay very small : around 10 interfaces / annotations). The only thing that is missing in AtInject today is the concept of {{@Producer}} that could be added to this new version (dagger want to move its {{@Provides}} annotation to AtInject. The integration can off course be done at spec level (the worse case would be to have a dependency on CDI API). So I really don't understand Greg point. For CDI 2.0 our approach is to talk with other specs to see what they need to improve their CDI integration. So let's talk about these needs before deciding it's not doable. > Give ownership of servlet specific part to servlet specification > ---------------------------------------------------------------- > > Key: CDI-492 > URL: https://issues.jboss.org/browse/CDI-492 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Java EE integration > Reporter: Antoine Sabot-Durand > > [Section 3.8 of the spec|http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#additional_builtin_beans] places some requirements on CDI implementations when running with Servlet. To better suit user desires for modularity these requirements are better met by moving them to the Servlet spec. Specifically, > {quote} > A servlet container must provide the following built-in beans, all of which have qualifier @Default: > * a bean with bean type {{javax.servlet.http.HttpServletRequest}}, allowing injection of a reference to the HttpServletRequest > * a bean with bean type {{javax.servlet.http.HttpSession}}, allowing injection of a reference to the HttpSession, > * a bean with bean type {{javax.servlet.ServletContext}}, allowing injection of a reference to the ServletContext, > These beans are passivation capable dependencies, as defined in Passivation capable dependencies. > {quote} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From antoine at sabot-durand.net Wed Nov 26 11:39:08 2014 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Wed, 26 Nov 2014 17:39:08 +0100 Subject: [cdi-dev] Async event API Message-ID: Hi all, As we said I introduced API changes to support scenario 1) of asynchronous event corresponding to ?1 in 4.1.1 (https://docs.google.com/document/d/1lFtgLm6hY-uECdA1r0Sfimq6vkVYThoUZsevPUaSP0E/edit?usp=sharing ) The changes are quite small : https://github.com/cdi-spec/cdi/commit/7a0c1d3aba0c0d2694d56f21867cde939465fb73 Regarding scenario 2) (each event launched in different threads)I think it can be done without having the feature specific to evens. We could discuss the introduction of @Asynchronous calls in CDI and obtain this behaviour by annotating observer method by an @Asynchronous. Wdyt Antoine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20141126/a5b2c61c/attachment.html From antonio.goncalves at gmail.com Thu Nov 27 02:00:42 2014 From: antonio.goncalves at gmail.com (Antonio Goncalves) Date: Thu, 27 Nov 2014 08:00:42 +0100 Subject: [cdi-dev] Feedback from Devoxx In-Reply-To: References: Message-ID: BTW, looks like Bob Lee is active because I can see he is planned to be in the expert group of Java Platform Module System https://jcp.org/en/jsr/detail?id=376 Antonio On Mon, Nov 17, 2014 at 2:57 PM, Antoine Sabot-Durand < antoine at sabot-durand.net> wrote: > Hi all, > > Just to give you a small feedback of my Devoxx week regarding CDI and CDI > 2.0 (for the rest, what happens in Devoxx stays in Devoxx ;) ) > > 1) Great expectations: > I?m not going to state the obvious, but end user and other specs are > watching us and expect a lot from CDI 2.0 (the question of total EJB > replacement came more than once) > > 2) Antonin Stefanutti and myself delivered a very valuable content in our > CDI advanced university. I don?t remember being so proud of a talk material > I released before. I encourage you to give it an eye and use it if you > want. you can watch it on Slideshare [1] or grab the source slides on > Antonin?s Github repo [2] > > 3) Other spec are really willing to have a better integration. > I met JMS, Servlet, JSF and MVC spec leaders, they all are looking for a > better integration with CDI and are ok to take CDI specific part related to > their spec back in their spec (Servlet and JSF mostly). Working with them > will bring a more consistent Java EE and will reduce extra code from the > spec. > > 4) After months of discussion I finally met Jurgen Hoeller (Spring > Framework) and Christian Gruber (Dagger and Guice) and we all agreed on a > new version or MR of AtInject spec. Juergen will probably be the spec lead > and we hope to have the big work done before mid 2015 (cross finger) to met > our various agenda. That will probably add extra work for CDI 2.0 but will > bring clarity and a good signal to the community. Thanks to Antonio who > helped me on this. > For those who remember the history of JSR 330 and JSR 299 the following > picture will be nearly an historical one ;) [3] > > > Antoine > > [1] http://www.slideshare.net/antoinesd/going-further-with-cdi-41411812 > [2] https://github.com/astefanutti/further-cdi > [3] http://twitter.com/antoine_sd/status/533710069255667712/photo/1 > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20141127/1438ac37/attachment-0001.html From werner.keil at gmail.com Thu Nov 27 08:51:44 2014 From: werner.keil at gmail.com (Werner Keil) Date: Thu, 27 Nov 2014 14:51:44 +0100 Subject: [cdi-dev] Feedback from Devoxx Message-ID: > BTW, looks like Bob Lee is active because I can see he is planned to be in >the expert group of Java Platform Module System Just because he's listed to support it means nothing. AFAIK he was in one of the prior JSRs like Jigsaw that went dormant eventually. And he officially was in the EG of JSR 354 because he used to work for Square and they seemed interested in financial services, but he never contributed anything (Anatole also considered re-allocating him to Observer due to that) Werner Keil | JCP Executive Committee Member, JSR 363 Co Spec Lead | Eclipse UOMo Lead, Babel Language Champion | Apache Committer | DWX 15 Advisory Board Member Twitter @wernerkeil | @UnitAPI | @JSR354 | #EclipseUOMo | #Java_Social | #DevOps Skype werner.keil | Google+ gplus.to/wernerkeil On Thu, Nov 27, 2014 at 8:01 AM, 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. [JBoss JIRA] (CDI-493) Allow firing of generic events from > BeanManager (Sven Linstaedt (JIRA)) > 2. [JBoss JIRA] (CDI-493) Allow firing of generic events from > BeanManager (Sven Linstaedt (JIRA)) > 3. [JBoss JIRA] (CDI-493) Allow firing of generic events from > BeanManager (Sven Linstaedt (JIRA)) > 4. [JBoss JIRA] (CDI-492) Give ownership of servlet specific > part to servlet specification (Antoine Sabot-Durand (JIRA)) > 5. Async event API (Antoine Sabot-Durand) > 6. Re: Feedback from Devoxx (Antonio Goncalves) > > > ---------------------------------------------------------------------- > > > Message: 6 > Date: Thu, 27 Nov 2014 08:00:42 +0100 > From: Antonio Goncalves > Subject: Re: [cdi-dev] Feedback from Devoxx > To: Antoine Sabot-Durand > Cc: cdi-dev > Message-ID: > ukyYk-nqUUXCOJDzL+7Q6FA at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > BTW, looks like Bob Lee is active because I can see he is planned to be in > the expert group of Java Platform Module System > > https://jcp.org/en/jsr/detail?id=376 > > Antonio > > On Mon, Nov 17, 2014 at 2:57 PM, Antoine Sabot-Durand < > antoine at sabot-durand.net> wrote: > > > Hi all, > > > > Just to give you a small feedback of my Devoxx week regarding CDI and CDI > > 2.0 (for the rest, what happens in Devoxx stays in Devoxx ;) ) > > > > 1) Great expectations: > > I?m not going to state the obvious, but end user and other specs are > > watching us and expect a lot from CDI 2.0 (the question of total EJB > > replacement came more than once) > > > > 2) Antonin Stefanutti and myself delivered a very valuable content in our > > CDI advanced university. I don?t remember being so proud of a talk > material > > I released before. I encourage you to give it an eye and use it if you > > want. you can watch it on Slideshare [1] or grab the source slides on > > Antonin?s Github repo [2] > > > > 3) Other spec are really willing to have a better integration. > > I met JMS, Servlet, JSF and MVC spec leaders, they all are looking for a > > better integration with CDI and are ok to take CDI specific part related > to > > their spec back in their spec (Servlet and JSF mostly). Working with them > > will bring a more consistent Java EE and will reduce extra code from the > > spec. > > > > 4) After months of discussion I finally met Jurgen Hoeller (Spring > > Framework) and Christian Gruber (Dagger and Guice) and we all agreed on a > > new version or MR of AtInject spec. Juergen will probably be the spec > lead > > and we hope to have the big work done before mid 2015 (cross finger) to > met > > our various agenda. That will probably add extra work for CDI 2.0 but > will > > bring clarity and a good signal to the community. Thanks to Antonio who > > helped me on this. > > For those who remember the history of JSR 330 and JSR 299 the following > > picture will be nearly an historical one ;) [3] > > > > > > Antoine > > > > [1] http://www.slideshare.net/antoinesd/going-further-with-cdi-41411812 > > [2] https://github.com/astefanutti/further-cdi > > [3] http://twitter.com/antoine_sd/status/533710069255667712/photo/1 > > _______________________________________________ > > 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 < > http://www.linkedin.com/in/agoncal> | > Pluralsight > | > Paris > JUG | Devoxx France > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://lists.jboss.org/pipermail/cdi-dev/attachments/20141127/1438ac37/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 48, Issue 19 > *************************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20141127/3fd0e7f0/attachment.html From antonio.goncalves at gmail.com Thu Nov 27 16:36:15 2014 From: antonio.goncalves at gmail.com (Antonio Goncalves) Date: Thu, 27 Nov 2014 22:36:15 +0100 Subject: [cdi-dev] CDI in the new Java EE Security spec Message-ID: Hi, Today was announced the new Java EE Security spec ( https://jcp.org/en/jsr/detail?id=375). When you read it it's written : "Additionally, we are considering supporting standardized CDI Events as part of the access decision I hope that it's more than juts a "consideration" ;o) We might get in touch with the Expert Group to make sure we can help them in integrating CDI. -- Antonio Goncalves Software architect, Java Champion and Pluralsight author Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20141127/08b9d0ea/attachment.html From arjan.tijms at gmail.com Thu Nov 27 18:38:12 2014 From: arjan.tijms at gmail.com (arjan tijms) Date: Fri, 28 Nov 2014 00:38:12 +0100 Subject: [cdi-dev] CDI in the new Java EE Security spec In-Reply-To: References: Message-ID: Hi, On Thu, Nov 27, 2014 at 10:36 PM, Antonio Goncalves wrote: > I hope that it's more than juts a "consideration" ;o) We might get in touch > with the Expert Group to make sure we can help them in integrating CDI. I think CDI is indeed very important in making a more modern security system. A couple of random ideas where CDI can be leveraged: * Auth modules using CDI to locate an appropriate user provided authenticator as described here: http://arjan-tijms.omnifaces.org/2014/11/header-based-stateless-token.html * The @RolesAllowed annotation re-implemented as CDI interceptor. There are many examples, I implemented one here (using BV actually, but that's an interceptor as well): https://github.com/omnifaces/omnisecurity/blob/master/src/main/java/org/omnifaces/security/constraints/RolesAllowedValidator.java * Events that are fired at several moments of the authentication dialog, with possibly the ability to abort the dialog from the event handler. Examples of events are mentioned here: https://java.net/jira/browse/JASPIC_SPEC-21 Discussion about events in security: https://java.net/projects/javaee-spec/lists/users/archive/2014-11/message/17 A *crucial* aspect is that CDI is activated early during request processing. Currently CDI is often activated via a servlet request listener. Now the problem is that at some containers request listeners run BEFORE authentication are executed (and see the HttpServletRequest object), while on some other contains those request listeners execute AFTER authentication modules execute. Kind regards, Arjan Tijms > > > -- > 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 Tue Nov 11 07:31:58 2014 From: antonio.goncalves at gmail.com (Antonio Goncalves) Date: Tue, 11 Nov 2014 12:31:58 -0000 Subject: [cdi-dev] PermGen with JBoss add-on Message-ID: Hi all, The other day on #IRC I mentioned having PermGen issues with the JBossAS add-on. It's confirmed. During the HoL there are plenty of people who had the same issue : install the JBoss add-on, start wildfly 8.1, build the app, deploy it, go to the index.html page (fine), click on an Entity, bang ! PermGen Alexis Hassler investigated it during the lab (see below). Basically, no matter what PermGen you set, it's not taken into account. Again, I really think this add-on should be looked after carefully, it's very unstable. Antonio ---------- Forwarded message ---------- From: Alexis Hassler Date: Tue, Nov 11, 2014 at 11:37 AM Subject: Re: Forge + Wildfly VM arguments To: Antonio Goncalves Pas de changement avec as-setup --server wildfly8 --installDir /opt/java/wildfly-8.1.0.Final/ --jvmargs "-Xmx512m -XX:MaxPermSize=256m" Alexis http://www.jtips.info, http://blog.alexis-hassler.com, http://www.lyonjug.org 2014-11-11 11:22 GMT+01:00 Alexis Hassler : > Avec un wf externe, d?marr? avec as-start. > > > > ? > Pour info, en d?marrant un wf 8.1 en ligne de commande "normale" : > -D[Standalone] -Xms64m -Xmx512m -XX:MaxPermSize=256m > -Djava.net.preferIPv4Stack=true > -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true > -Dorg.jboss.boot.log.file=/opt/java/wildfly-8.1.0.Final/standalone/log/server.log > -Dlogging.configuration=file:/opt/java/wildfly-8.1.0.Final/standalone/configuration/logging.properties > > Alexis > http://www.jtips.info, http://blog.alexis-hassler.com, > http://www.lyonjug.org > > -- Antonio Goncalves Software architect, Java Champion and Pluralsight author Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20141111/eeee209b/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: forge-wf-jconsole.png Type: image/png Size: 414948 bytes Desc: not available Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20141111/eeee209b/attachment-0001.png