November 2014 - cdi-dev - Jboss List Archives

[JBoss JIRA] (CDI-491) Clarify what happens when an interceptor doesn't have any @AroundInvoke or lifecycle annotation

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-491?page=com.atlassian.jira.plugin.sy... ] 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)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (CDI-491) Clarify what happens when an interceptor doesn't have any @AroundInvoke or lifecycle annotation

by Antonio Goncalves (JIRA)

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)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (CDI-490) Clarify what happens when an interceptor/decorator is enabled using both @Priority and beans.xml

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-490?page=com.atlassian.jira.plugin.sy... ] 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} <interceptors> <class>com.acme.myfwk.TransactionInterceptor</class> <class>com.acme.myfwk.LoggingInterceptor</class> </interceptors> {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)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (CDI-490) Clarify what happens when an interceptor/decorator is enabled using both @Priority and beans.xml

by Jozef Hartinger (JIRA)

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)

10 years, 1 month

1
0
0 / 0

Devoxx BE

by Antonio Goncalves

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 <http://www.antoniogoncalves.org> | Twitter <http://twitter.com/agoncal> | LinkedIn <http://www.linkedin.com/in/agoncal> | Pluralsight <http://pluralsight.com/training/Authors/Details/antonio-goncalves> | Paris JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr>

10 years, 1 month

1
0
0 / 0

Re: [cdi-dev] More CDI integration on JSF 2.3

by Werner Keil

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, <cdi-dev-request(a)lists.jboss.org> wrote: > Send cdi-dev mailing list submissions to > cdi-dev(a)lists.jboss.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.jboss.org/mailman/listinfo/cdi-dev > or, via email, send a message with subject or body 'help' to > cdi-dev-request(a)lists.jboss.org > > You can reach the person managing the list at > cdi-dev-owner(a)lists.jboss.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of cdi-dev digest..." > > > Today's Topics: > > 1. 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 <antoine(a)sabot-durand.net> > Subject: Re: [cdi-dev] More CDI integration on JSF 2.3 > To: Antonio Goncalves <antonio.goncalves(a)gmail.com> > Cc: cdi-dev <cdi-dev(a)lists.jboss.org> > Message-ID: <E3C773E0-F298-487D-A1FB-7E68E1686426(a)sabot-durand.net> > 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 <antonio.goncalves(a)gmail.com> > 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-u... > < > https://weblogs.java.net/blog/mriem/archive/2014/10/29/jsf-23-injecting-u... > > > > > https://weblogs.java.net/blog/mriem/archive/2014/10/27/jsf-23-allow-cdi-h... > < > https://weblogs.java.net/blog/mriem/archive/2014/10/27/jsf-23-allow-cdi-h... > > > > 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-a... > < > https://weblogs.java.net/blog/mriem/archive/2014/10/15/jsf-23-injecting-a... > > > > > https://weblogs.java.net/blog/mriem/archive/2014/10/13/jsf-23-inject-exte... > < > https://weblogs.java.net/blog/mriem/archive/2014/10/13/jsf-23-inject-exte... > > > > > https://weblogs.java.net/blog/mriem/archive/2014/10/10/jsf-23-inject-face... > < > https://weblogs.java.net/blog/mriem/archive/2014/10/10/jsf-23-inject-face... > > > > 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 <http://www.antoniogoncalves.org/> | Twitter < > http://twitter.com/agoncal> | LinkedIn <http://www.linkedin.com/in/agoncal> > | Pluralsight < > http://pluralsight.com/training/Authors/Details/antonio-goncalves> | > Paris JUG <http://www.parisjug.org/> | Devoxx France < > http://www.devoxx.fr/> > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://lists.jboss.org/pipermail/cdi-dev/attachments/20141103/13f44ebc/at... > > ------------------------------ > > _______________________________________________ > cdi-dev mailing list > cdi-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > > End of cdi-dev Digest, Vol 48, Issue 1 > ************************************** >

10 years, 1 month

1
0
0 / 0

More CDI integration on JSF 2.3

by Antonio Goncalves

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-u... - https://weblogs.java.net/blog/mriem/archive/2014/10/27/jsf-23-allow-cdi-h... - 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-a... - https://weblogs.java.net/blog/mriem/archive/2014/10/13/jsf-23-inject-exte... - https://weblogs.java.net/blog/mriem/archive/2014/10/10/jsf-23-inject-face... 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 <http://www.antoniogoncalves.org> | Twitter <http://twitter.com/agoncal> | LinkedIn <http://www.linkedin.com/in/agoncal> | Pluralsight <http://pluralsight.com/training/Authors/Details/antonio-goncalves> | Paris JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr>

10 years, 1 month

2
2
0 / 0

Meeting time slot and daylight saving

by Antoine Sabot-Durand

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

10 years, 1 month

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev November 2014