From issues at jboss.org Wed Mar 1 05:40:00 2017 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 1 Mar 2017 05:40:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-684) Should portable extension support static observer method In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-684: ------------------------------------- Fix Version/s: 2.0 .Final > Should portable extension support static observer method > -------------------------------------------------------- > > Key: CDI-684 > URL: https://issues.jboss.org/browse/CDI-684 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Portable Extensions > Reporter: Antoine Sabot-Durand > Fix For: 2.0 .Final > > > Error reported in WELD-2331 brings the question of clarification of this point. > Should we forbid usage of static observer in extension class or not ? -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 1 05:41:00 2017 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 1 Mar 2017 05:41:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-684) Should portable extension support static observer method In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13370742#comment-13370742 ] Antoine Sabot-Durand commented on CDI-684: ------------------------------------------ EG agreed to explicitly make this feature non-portable > Should portable extension support static observer method > -------------------------------------------------------- > > Key: CDI-684 > URL: https://issues.jboss.org/browse/CDI-684 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Portable Extensions > Reporter: Antoine Sabot-Durand > Fix For: 2.0 .Final > > > Error reported in WELD-2331 brings the question of clarification of this point. > Should we forbid usage of static observer in extension class or not ? -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 1 05:41:00 2017 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 1 Mar 2017 05:41:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-684) Should portable extension support static observer method In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand reassigned CDI-684: ---------------------------------------- Assignee: Antoine Sabot-Durand > Should portable extension support static observer method > -------------------------------------------------------- > > Key: CDI-684 > URL: https://issues.jboss.org/browse/CDI-684 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Portable Extensions > Reporter: Antoine Sabot-Durand > Assignee: Antoine Sabot-Durand > Fix For: 2.0 .Final > > > Error reported in WELD-2331 brings the question of clarification of this point. > Should we forbid usage of static observer in extension class or not ? -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 1 12:07:00 2017 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 1 Mar 2017 12:07:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-684) Should portable extension support static observer method In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CDI-684 started by Antoine Sabot-Durand. ------------------------------------------------ > Should portable extension support static observer method > -------------------------------------------------------- > > Key: CDI-684 > URL: https://issues.jboss.org/browse/CDI-684 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Portable Extensions > Reporter: Antoine Sabot-Durand > Assignee: Antoine Sabot-Durand > Fix For: 2.0 .Final > > > Error reported in WELD-2331 brings the question of clarification of this point. > Should we forbid usage of static observer in extension class or not ? -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 1 12:22:00 2017 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 1 Mar 2017 12:22:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-686) Could InterceptionFactory accept an interface as type parameter In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand reassigned CDI-686: ---------------------------------------- Assignee: Antoine Sabot-Durand > Could InterceptionFactory accept an interface as type parameter > --------------------------------------------------------------- > > Key: CDI-686 > URL: https://issues.jboss.org/browse/CDI-686 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 2.0 .Final > Reporter: Antoine Sabot-Durand > Assignee: Antoine Sabot-Durand > > If you take this code: > {code:java} > @Produces > public List produceList(InterceptionFactory> interceptionFactory) { > interceptionFactory.ignoreFinalMethods().configure().filterMethods((m) -> { > if (m.getJavaMember().getName().equals("add") > && m.getJavaMember().getParameterCount() == 1) { > return true; > } > return false; > }).findFirst().get().add(Monitor.Literal.INSTANCE); > return interceptionFactory.createInterceptedInstance(new ArrayList<>()); > } > {code} > Parameterized type for injected {{InterceptionFactory}} is an interface {{List}}, so when calling {{configure()}}, user will work with an {{AnnotatedTypeConfigurator>}} to apply interceptor binding. > In a standard interceptor usage, interceptor binding on interface are ignored (even if they have {{@Inherited}} annotation), so doing it with {{InterceptionFactory}} could be confusing for some user. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From hiromi_18_takahashi at mufg.jp Thu Mar 2 03:41:11 2017 From: hiromi_18_takahashi at mufg.jp (hiromi_18_takahashi at mufg.jp) Date: Thu, 2 Mar 2017 08:41:11 +0000 Subject: [cdi-dev] JSR365(CDI2.0)Public Review Comment Message-ID: CDI developer all Hi, I'm Hiromi Takahashi. I work for Mitsubishi UFJ Information Technology. Our company is in charge of Mitsubishi UFJ financial group system development, operation and maintenance. And then , I'm in charge of in-house Java framework. Our Java framework depends heavily on Java SE and Java EE technologies. I reviewed JSR365 (CDI2.0) Public Review . I think it's great. On the other hand, to make things even better, I would like to suggest the following: ?About CDI's goal in Java SE What I think is great about CDI is its ability to inject to Java object "transparently". However, with the current spec of CDI, it requires some coding each time to get the injected objects. For example, in getNewInstance() method, I think it would be great if CDI could judge if there was an injected field or not (ie. if there is an injected field then CDI injects, and if not CDI just makes a new instance.) How we code would be even simpler and more beautiful. This way, users can always generate instances in such standard method. Also, it could be even better if CDI could act like below when using "new" descriptor: - If the class has injected field, then get the injected instances - If the class has no injected field, then just simply get a new instance In Java EE, these functions are the container's role and CDI may not have to be in charge of them. However, considering CDI may be used in Java SE, I think CDI needs to act like above in the future. Best regards. ############################################################## Mitsubishi UFJ Information Technology,Ltd. ?Management Information Systems Platforms Department. Hiromi Takahashi tel?+81-3-5859-1525 mail?hiromi_18_takahashi at mufg.jp ############################################################## -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170302/34ff2a9a/attachment.html From issues at jboss.org Thu Mar 2 03:43:00 2017 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Thu, 2 Mar 2017 03:43:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-686) Could InterceptionFactory accept an interface as type parameter In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CDI-686 started by Antoine Sabot-Durand. ------------------------------------------------ > Could InterceptionFactory accept an interface as type parameter > --------------------------------------------------------------- > > Key: CDI-686 > URL: https://issues.jboss.org/browse/CDI-686 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 2.0 .Final > Reporter: Antoine Sabot-Durand > Assignee: Antoine Sabot-Durand > > If you take this code: > {code:java} > @Produces > public List produceList(InterceptionFactory> interceptionFactory) { > interceptionFactory.ignoreFinalMethods().configure().filterMethods((m) -> { > if (m.getJavaMember().getName().equals("add") > && m.getJavaMember().getParameterCount() == 1) { > return true; > } > return false; > }).findFirst().get().add(Monitor.Literal.INSTANCE); > return interceptionFactory.createInterceptedInstance(new ArrayList<>()); > } > {code} > Parameterized type for injected {{InterceptionFactory}} is an interface {{List}}, so when calling {{configure()}}, user will work with an {{AnnotatedTypeConfigurator>}} to apply interceptor binding. > In a standard interceptor usage, interceptor binding on interface are ignored (even if they have {{@Inherited}} annotation), so doing it with {{InterceptionFactory}} could be confusing for some user. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 2 04:30:00 2017 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Thu, 2 Mar 2017 04:30:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-686) Could InterceptionFactory accept an interface as type parameter In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-686: ------------------------------------- Fix Version/s: 2.0 .Final > Could InterceptionFactory accept an interface as type parameter > --------------------------------------------------------------- > > Key: CDI-686 > URL: https://issues.jboss.org/browse/CDI-686 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 2.0 .Final > Reporter: Antoine Sabot-Durand > Assignee: Antoine Sabot-Durand > Fix For: 2.0 .Final > > > If you take this code: > {code:java} > @Produces > public List produceList(InterceptionFactory> interceptionFactory) { > interceptionFactory.ignoreFinalMethods().configure().filterMethods((m) -> { > if (m.getJavaMember().getName().equals("add") > && m.getJavaMember().getParameterCount() == 1) { > return true; > } > return false; > }).findFirst().get().add(Monitor.Literal.INSTANCE); > return interceptionFactory.createInterceptedInstance(new ArrayList<>()); > } > {code} > Parameterized type for injected {{InterceptionFactory}} is an interface {{List}}, so when calling {{configure()}}, user will work with an {{AnnotatedTypeConfigurator>}} to apply interceptor binding. > In a standard interceptor usage, interceptor binding on interface are ignored (even if they have {{@Inherited}} annotation), so doing it with {{InterceptionFactory}} could be confusing for some user. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From antoine at sabot-durand.net Thu Mar 2 06:09:04 2017 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Thu, 02 Mar 2017 11:09:04 +0000 Subject: [cdi-dev] JSR365(CDI2.0)Public Review Comment In-Reply-To: References: Message-ID: Hi Hiromi, And thanks for your feedback. Regarding your suggestion I'm not sure to understand everything, so giving us code example could help. Anyway, I'll try to answer on the points I understood, we won't go on too much magic in CDI: injecting automatically in field if they are not annotated with @Inject. This could be confusing and would bring more problem than solution I think. But if you need this on your project you can rather easily create a portable extension to implement this feature. Regarding hooking on the "new" java keyword, I also think it's a bad idea: user would be never be sure if their variable contains a pojo instance or a contextual instance with a lifecycle they don't own. I may have misunderstood your suggestion, so feel free to correct me. Antoine Sabot-Durand On Thu, Mar 2, 2017 at 9:41 AM wrote: > CDI developer all > > Hi, I'm Hiromi Takahashi. > > I work for Mitsubishi UFJ Information Technology. > Our company is in charge of Mitsubishi UFJ financial group system > development, operation and maintenance. > And then , I'm in charge of in-house Java framework. > Our Java framework depends heavily on Java SE and Java EE technologies. > > I reviewed JSR365 (CDI2.0) Public Review . > I think it's great. > > On the other hand, to make things even better, I would like to suggest > the following: > > ?About CDI's goal in Java SE > > What I think is great about CDI is its ability to inject to Java object > "transparently". > However, with the current spec of CDI, it requires some coding each time > to get the injected objects. > > For example, in getNewInstance() method, I think it would be great if CDI > could judge if there was an injected field or not > (ie. if there is an injected field then CDI injects, and if not CDI just > makes a new instance.) > How we code would be even simpler and more beautiful. > This way, users can always generate instances in such standard method. > > Also, it could be even better if CDI could act like below when using "new" > descriptor: > - If the class has injected field, then get the injected instances > - If the class has no injected field, then just simply get a new instance > > In Java EE, these functions are the container's role and CDI may not have > to be in charge of them. > However, considering CDI may be used in Java SE, I think CDI needs to act > like above in the future. > > Best regards. > > ############################################################## > Mitsubishi UFJ Information Technology,Ltd. > Management Information Systems Platforms Department. > Hiromi Takahashi > tel?+81-3-5859-1525 <+81%203-5859-1525> > mail?hiromi_18_takahashi at mufg.jp > ############################################################## > > > _______________________________________________ > 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/20170302/b088c59d/attachment-0001.html From john.ament at spartasystems.com Sun Mar 5 13:20:54 2017 From: john.ament at spartasystems.com (John Ament) Date: Sun, 5 Mar 2017 18:20:54 +0000 Subject: [cdi-dev] Is InterceptionFactory a built in bean? Message-ID: All, I don't see it explicitly called out in the spec, but should I be able to do this? CDI.current().select(InterceptionFactory.class).get() - e.g. is it a a bean, or can I only access it as a producer method or via BeanManager.createInterceptionFactory() ? Also, I found in the 2.0 beta 1 spec the following: public interface InterceptionFactory { InterceptionProxyFactory ignoreFinalMethods(); I believe InterceptionProxyFactory should be replaced with InterceptionFactory, if we haven't already fixed this. John ________________________________ NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170305/e3751fdf/attachment.html From issues at jboss.org Sun Mar 5 13:54:00 2017 From: issues at jboss.org (John Ament (JIRA)) Date: Sun, 5 Mar 2017 13:54:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-687) Programmatic activation of an existing conversation by conversation id In-Reply-To: References: Message-ID: John Ament created CDI-687: ------------------------------ Summary: Programmatic activation of an existing conversation by conversation id Key: CDI-687 URL: https://issues.jboss.org/browse/CDI-687 Project: CDI Specification Issues Issue Type: Feature Request Reporter: John Ament Currently, conversation activation can only work if you have an HTTP request with cid query param passed in. We should expand this to allow any arbitrary lookup of conversation by id. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Sun Mar 5 13:56:00 2017 From: issues at jboss.org (John Ament (JIRA)) Date: Sun, 5 Mar 2017 13:56:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-688) Contextual bean stores In-Reply-To: References: Message-ID: John Ament created CDI-688: ------------------------------ Summary: Contextual bean stores Key: CDI-688 URL: https://issues.jboss.org/browse/CDI-688 Project: CDI Specification Issues Issue Type: Feature Request Reporter: John Ament Right now, the notion of how beans are stored are ambiguous. The implementations back them by maps. This may work well, but there's some amount of plugability required to make passivation capable beans work right. A single request makes sense to store in a map. Sessions are stored in the HTTPSession. We should allow these bean stores to be more pluggable, allowing users or implementations to override how their beans are stored. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Sun Mar 5 19:32:00 2017 From: issues at jboss.org (John Ament (JIRA)) Date: Sun, 5 Mar 2017 19:32:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-689) Typo or unclear message in 24.1.2 In-Reply-To: References: Message-ID: John Ament created CDI-689: ------------------------------ Summary: Typo or unclear message in 24.1.2 Key: CDI-689 URL: https://issues.jboss.org/browse/CDI-689 Project: CDI Specification Issues Issue Type: Feature Request Reporter: John Ament Section 24.1.2 includes the following text: {quote} When Running in Java EE, the container must extend the rules defined in Observer method invocation context and must also ensure that All kinds of observers are called in the same client security context as the invocation of Event.fire() or Event.fireAsync() or BeanManager.fireEvent(). {code} The break after "that" in the first line seems weird, its not clear if its supposed to continue into the second line, or if the sentence is intended to continue. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Sun Mar 5 19:32:00 2017 From: issues at jboss.org (John Ament (JIRA)) Date: Sun, 5 Mar 2017 19:32:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-689) Typo or unclear message in 24.1.2 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Ament updated CDI-689: --------------------------- Issue Type: Bug (was: Feature Request) > Typo or unclear message in 24.1.2 > --------------------------------- > > Key: CDI-689 > URL: https://issues.jboss.org/browse/CDI-689 > Project: CDI Specification Issues > Issue Type: Bug > Reporter: John Ament > > Section 24.1.2 includes the following text: > {quote} > When Running in Java EE, the container must extend the rules defined in Observer method invocation context and must also ensure that > All kinds of observers are called in the same client security context as the invocation of Event.fire() or Event.fireAsync() or BeanManager.fireEvent(). > {quote} > The break after "that" in the first line seems weird, its not clear if its supposed to continue into the second line, or if the sentence is intended to continue. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Sun Mar 5 19:32:00 2017 From: issues at jboss.org (John Ament (JIRA)) Date: Sun, 5 Mar 2017 19:32:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-689) Typo or unclear message in 24.1.2 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Ament updated CDI-689: --------------------------- Priority: Minor (was: Major) > Typo or unclear message in 24.1.2 > --------------------------------- > > Key: CDI-689 > URL: https://issues.jboss.org/browse/CDI-689 > Project: CDI Specification Issues > Issue Type: Bug > Reporter: John Ament > Priority: Minor > > Section 24.1.2 includes the following text: > {quote} > When Running in Java EE, the container must extend the rules defined in Observer method invocation context and must also ensure that > All kinds of observers are called in the same client security context as the invocation of Event.fire() or Event.fireAsync() or BeanManager.fireEvent(). > {quote} > The break after "that" in the first line seems weird, its not clear if its supposed to continue into the second line, or if the sentence is intended to continue. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Sun Mar 5 19:32:00 2017 From: issues at jboss.org (John Ament (JIRA)) Date: Sun, 5 Mar 2017 19:32:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-689) Typo or unclear message in 24.1.2 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Ament updated CDI-689: --------------------------- Description: Section 24.1.2 includes the following text: {quote} When Running in Java EE, the container must extend the rules defined in Observer method invocation context and must also ensure that All kinds of observers are called in the same client security context as the invocation of Event.fire() or Event.fireAsync() or BeanManager.fireEvent(). {quote} The break after "that" in the first line seems weird, its not clear if its supposed to continue into the second line, or if the sentence is intended to continue. was: Section 24.1.2 includes the following text: {quote} When Running in Java EE, the container must extend the rules defined in Observer method invocation context and must also ensure that All kinds of observers are called in the same client security context as the invocation of Event.fire() or Event.fireAsync() or BeanManager.fireEvent(). {code} The break after "that" in the first line seems weird, its not clear if its supposed to continue into the second line, or if the sentence is intended to continue. > Typo or unclear message in 24.1.2 > --------------------------------- > > Key: CDI-689 > URL: https://issues.jboss.org/browse/CDI-689 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: John Ament > > Section 24.1.2 includes the following text: > {quote} > When Running in Java EE, the container must extend the rules defined in Observer method invocation context and must also ensure that > All kinds of observers are called in the same client security context as the invocation of Event.fire() or Event.fireAsync() or BeanManager.fireEvent(). > {quote} > The break after "that" in the first line seems weird, its not clear if its supposed to continue into the second line, or if the sentence is intended to continue. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From john.ament at spartasystems.com Sun Mar 5 19:42:09 2017 From: john.ament at spartasystems.com (John Ament) Date: Mon, 6 Mar 2017 00:42:09 +0000 Subject: [cdi-dev] Can an observer be both async and sync? Message-ID: Section 10.4.4 has the following section which got me thinking public void refreshOnDocumentUpdate(@Observes(notifyObserver=IF_EXISTS) @Updated Document doc) { ... } public void asyncRefreshOnDocumentUpdate(@ObservesAsync(notifyObserver=IF_EXISTS) @Updated Document doc) { ... } I'm wondering, is it OK to have an observer method defined like this? public void asyncRefreshOnDocumentUpdate(@Observes(notifyObserver=IF_EXISTS) @ObservesAsync(notifyObserver=IF_EXISTS) @Updated Document doc) { ... } I don't see anything against this in the spec, but I suspect most people are going to think this shouldn't work. So I'm asking the question - should it work? John ________________________________ NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170306/32b3861a/attachment-0001.html From issues at jboss.org Sun Mar 5 20:06:00 2017 From: issues at jboss.org (John Ament (JIRA)) Date: Sun, 5 Mar 2017 20:06:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-690) Automatically start a request context for async observer methods In-Reply-To: References: Message-ID: John Ament created CDI-690: ------------------------------ Summary: Automatically start a request context for async observer methods Key: CDI-690 URL: https://issues.jboss.org/browse/CDI-690 Project: CDI Specification Issues Issue Type: Feature Request Reporter: John Ament In many other places we start an implicit request context for method invocations (post constructs for instance). We should have an implicit request context for async observer methods. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Sun Mar 5 20:39:00 2017 From: issues at jboss.org (John Ament (JIRA)) Date: Sun, 5 Mar 2017 20:39:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-691) Fire initialized/destroyed for conversation and session scoped In-Reply-To: References: Message-ID: John Ament created CDI-691: ------------------------------ Summary: Fire initialized/destroyed for conversation and session scoped Key: CDI-691 URL: https://issues.jboss.org/browse/CDI-691 Project: CDI Specification Issues Issue Type: Feature Request Reporter: John Ament Section 6.7 indicates that initialized/destroyed are called for request and application scopes. need to also fire for conversation and session. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From john.ament at spartasystems.com Sun Mar 5 20:45:30 2017 From: john.ament at spartasystems.com (John Ament) Date: Mon, 6 Mar 2017 01:45:30 +0000 Subject: [cdi-dev] [JBoss JIRA] (CDI-690) Automatically start a request context for async observer methods In-Reply-To: References: , Message-ID: Hey guys So I filed this, however I then tested against the RI and noticed that the RI was already doing this. Is that expected? John ________________________________ From: cdi-dev-bounces at lists.jboss.org on behalf of John Ament (JIRA) Sent: Sunday, March 5, 2017 8:06 PM To: cdi-dev at lists.jboss.org Subject: [cdi-dev] [JBoss JIRA] (CDI-690) Automatically start a request context for async observer methods John Ament created CDI-690: ------------------------------ Summary: Automatically start a request context for async observer methods Key: CDI-690 URL: https://issues.jboss.org/browse/CDI-690 Project: CDI Specification Issues Issue Type: Feature Request Reporter: John Ament In many other places we start an implicit request context for method invocations (post constructs for instance). We should have an implicit request context for async observer methods. -- This message was sent by Atlassian JIRA (v7.2.3#72005) _______________________________________________ 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. ________________________________ NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170306/d6851301/attachment.html From issues at jboss.org Sun Mar 5 21:06:00 2017 From: issues at jboss.org (John Ament (JIRA)) Date: Sun, 5 Mar 2017 21:06:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-692) isResolvable missing from 5.6.1 In-Reply-To: References: Message-ID: John Ament created CDI-692: ------------------------------ Summary: isResolvable missing from 5.6.1 Key: CDI-692 URL: https://issues.jboss.org/browse/CDI-692 Project: CDI Specification Issues Issue Type: Bug Reporter: John Ament Section 5.6.1 is missing the new isResolvable method http://docs.jboss.org/cdi/spec/2.0.Beta1/cdi-spec.html#dynamic_lookup -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Sun Mar 5 22:20:00 2017 From: issues at jboss.org (John Ament (JIRA)) Date: Sun, 5 Mar 2017 22:20:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-693) Introduce a Instance#ifResolved(Consumer) method In-Reply-To: References: Message-ID: John Ament created CDI-693: ------------------------------ Summary: Introduce a Instance#ifResolved(Consumer) method Key: CDI-693 URL: https://issues.jboss.org/browse/CDI-693 Project: CDI Specification Issues Issue Type: Feature Request Reporter: John Ament in many cases, the logic around isResolvable/isUnsatisfied/isAmbiguous could be replaced by a consumer of the resolved instance. It would be good to introduce a ifResolved(Consumer) method that consumes the resolved instance, not invoking the consumer if the instance was not resolvable. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From tremes at redhat.com Mon Mar 6 01:55:39 2017 From: tremes at redhat.com (Tomas Remes) Date: Mon, 6 Mar 2017 01:55:39 -0500 (EST) Subject: [cdi-dev] Can an observer be both async and sync? In-Reply-To: References: Message-ID: <1390289376.28215507.1488783339118.JavaMail.zimbra@redhat.com> Hi John, No it shouldn't. The problematic and confusing case would be when there is some other param (injection point) in this observer method and this param resolves to let's say @SessionScoped bean. How does it work then? Once it fails (since there's no context propagation for async event), once it works (sync event)? Therefore this was forbidden. Tom ----- Original Message ----- From: "John Ament" To: "cdi-dev" Sent: Monday, March 6, 2017 1:42:09 AM Subject: [cdi-dev] Can an observer be both async and sync? Section 10.4.4 has the following section which got me thinking public void refreshOnDocumentUpdate(@Observes(notifyObserver=IF_EXISTS) @Updated Document doc) { ... } public void asyncRefreshOnDocumentUpdate(@ObservesAsync(notifyObserver=IF_EXISTS) @Updated Document doc) { ... } I'm wondering, is it OK to have an observer method defined like this? public void asyncRefreshOnDocumentUpdate( @Observes(notifyObserver=IF_EXISTS) @ObservesAsync(notifyObserver=IF_EXISTS) @Updated Document doc) { ... } I don't see anything against this in the spec, but I suspect most people are going to think this shouldn't work. So I'm asking the question - should it work? John NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you. _______________________________________________ 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. -- Tomas Remes From issues at jboss.org Mon Mar 6 02:12:00 2017 From: issues at jboss.org (Tomas Remes (JIRA)) Date: Mon, 6 Mar 2017 02:12:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-692) isResolvable missing from 5.6.1 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13372766#comment-13372766 ] Tomas Remes commented on CDI-692: --------------------------------- John please use latest version of the cdi spec http://docs.jboss.org/cdi/spec/2.0-PFD/cdi-spec.html#dynamic_lookup. I know it's still not updated on the website - [~antoinesabot-durand] > isResolvable missing from 5.6.1 > ------------------------------- > > Key: CDI-692 > URL: https://issues.jboss.org/browse/CDI-692 > Project: CDI Specification Issues > Issue Type: Bug > Reporter: John Ament > > Section 5.6.1 is missing the new isResolvable method http://docs.jboss.org/cdi/spec/2.0.Beta1/cdi-spec.html#dynamic_lookup -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 6 02:15:00 2017 From: issues at jboss.org (Tomas Remes (JIRA)) Date: Mon, 6 Mar 2017 02:15:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-691) Fire initialized/destroyed for conversation and session scoped In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13372767#comment-13372767 ] Tomas Remes commented on CDI-691: --------------------------------- Isn't this in the EE part of the spec http://docs.jboss.org/cdi/spec/2.0-PFD/cdi-spec.html#session_context_ee ? > Fire initialized/destroyed for conversation and session scoped > -------------------------------------------------------------- > > Key: CDI-691 > URL: https://issues.jboss.org/browse/CDI-691 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: John Ament > > Section 6.7 indicates that initialized/destroyed are called for request and application scopes. need to also fire for conversation and session. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 6 02:21:00 2017 From: issues at jboss.org (Tomas Remes (JIRA)) Date: Mon, 6 Mar 2017 02:21:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-690) Automatically start a request context for async observer methods In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13372770#comment-13372770 ] Tomas Remes commented on CDI-690: --------------------------------- http://docs.jboss.org/cdi/spec/2.0-PFD/cdi-spec.html#request_context_ee - the third indent in the list. THe request context is active which basically means is automatically started IIUC. > Automatically start a request context for async observer methods > ---------------------------------------------------------------- > > Key: CDI-690 > URL: https://issues.jboss.org/browse/CDI-690 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: John Ament > > In many other places we start an implicit request context for method invocations (post constructs for instance). We should have an implicit request context for async observer methods. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 6 03:25:01 2017 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Mon, 6 Mar 2017 03:25:01 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-690) Automatically start a request context for async observer methods In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13372790#comment-13372790 ] Martin Kouba commented on CDI-690: ---------------------------------- [~tremes] You're right but what about Java SE? It should work there as well (and I believe it does in Weld). Also info about async observers is missing in the "The request context is destroyed:..." part. > Automatically start a request context for async observer methods > ---------------------------------------------------------------- > > Key: CDI-690 > URL: https://issues.jboss.org/browse/CDI-690 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: John Ament > > In many other places we start an implicit request context for method invocations (post constructs for instance). We should have an implicit request context for async observer methods. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From mkouba at redhat.com Mon Mar 6 03:28:52 2017 From: mkouba at redhat.com (Martin Kouba) Date: Mon, 6 Mar 2017 09:28:52 +0100 Subject: [cdi-dev] Is InterceptionFactory a built in bean? In-Reply-To: References: Message-ID: Dne 5.3.2017 v 19:20 John Ament napsal(a): > All, > > > I don't see it explicitly called out in the spec, but should I be able > to do this? CDI.current().select(InterceptionFactory.class).get() - > e.g. is it a a bean, or can I only access it as a producer method or via > BeanManager.createInterceptionFactory() ? There is a built-in bean of type InterceptionFactory (as defined in 11.7. The InterceptionFactory interface), but you can only inject it in a param of a producer method: "If an injection point of type InterceptionFactory and qualifier @Default exists and is not a parameter of a producer method, the container automatically detects the problem and treats it as a definition error." > > > Also, I found in the 2.0 beta 1 spec the following: > > > public interface InterceptionFactory { > InterceptionProxyFactory ignoreFinalMethods(); > > I believe InterceptionProxyFactory should be replaced > with InterceptionFactory, if we haven't already fixed this. > > > John > > > ------------------------------------------------------------------------ > NOTICE: This e-mail message and any attachments may contain > confidential, proprietary, and/or privileged information which should be > treated accordingly. If you are not the intended recipient, please > notify the sender immediately by return e-mail, delete this message, and > destroy all physical and electronic copies. Thank you. > > > _______________________________________________ > 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. > -- Martin Kouba Senior Software Engineer Red Hat, Czech Republic From issues at jboss.org Mon Mar 6 03:32:00 2017 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Mon, 6 Mar 2017 03:32:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-691) Fire initialized/destroyed for conversation and session scoped In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13372796#comment-13372796 ] Martin Kouba commented on CDI-691: ---------------------------------- Tomas is right, {{@ConversationScoped}} and {{@SessionScoped}} are not defined for Java SE. > Fire initialized/destroyed for conversation and session scoped > -------------------------------------------------------------- > > Key: CDI-691 > URL: https://issues.jboss.org/browse/CDI-691 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: John Ament > > Section 6.7 indicates that initialized/destroyed are called for request and application scopes. need to also fire for conversation and session. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 6 03:46:01 2017 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Mon, 6 Mar 2017 03:46:01 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-688) Contextual bean stores In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13372805#comment-13372805 ] Martin Kouba commented on CDI-688: ---------------------------------- Right now, this is undefined, i.e. it's completely up to the implementations (assuming the requirements for normal scopes are met: "6.3. Normal scopes and pseudo-scopes"). What kind of pluggability do you have in mind? > Contextual bean stores > ---------------------- > > Key: CDI-688 > URL: https://issues.jboss.org/browse/CDI-688 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: John Ament > > Right now, the notion of how beans are stored are ambiguous. The implementations back them by maps. This may work well, but there's some amount of plugability required to make passivation capable beans work right. A single request makes sense to store in a map. Sessions are stored in the HTTPSession. We should allow these bean stores to be more pluggable, allowing users or implementations to override how their beans are stored. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 6 03:54:00 2017 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Mon, 6 Mar 2017 03:54:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-693) Introduce a Instance#ifResolved(Consumer) method In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Kouba updated CDI-693: ----------------------------- Fix Version/s: 2.1 (Discussion) > Introduce a Instance#ifResolved(Consumer) method > --------------------------------------------------- > > Key: CDI-693 > URL: https://issues.jboss.org/browse/CDI-693 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: John Ament > Fix For: 2.1 (Discussion) > > > in many cases, the logic around isResolvable/isUnsatisfied/isAmbiguous could be replaced by a consumer of the resolved instance. It would be good to introduce a ifResolved(Consumer) method that consumes the resolved instance, not invoking the consumer if the instance was not resolvable. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From mkouba at redhat.com Mon Mar 6 04:15:13 2017 From: mkouba at redhat.com (Martin Kouba) Date: Mon, 6 Mar 2017 10:15:13 +0100 Subject: [cdi-dev] Can an observer be both async and sync? In-Reply-To: <1390289376.28215507.1488783339118.JavaMail.zimbra@redhat.com> References: <1390289376.28215507.1488783339118.JavaMail.zimbra@redhat.com> Message-ID: <51e06a60-f9c9-d69f-26ad-8bdeac18396d@redhat.com> Well, it's not 100% clear but I believe it should be forbidden. The spec only states: "An observer method may be declared by annotating a parameter @javax.enterprise.event.Observes OR @javax.enterprise.event.ObservesAsync of a default-access, public, protected or private method. That parameter is the event parameter." I think it wouldn't hurt to add: "If an event parameter is annotated with both @Observes and @ObservesAsync, the container automatically detects the problem and treats it as a definition error." Weld throws a DefinitionException. Martin Dne 6.3.2017 v 07:55 Tomas Remes napsal(a): > > Hi John, > > No it shouldn't. The problematic and confusing case would be when there is some other param (injection point) in this observer method and this param resolves to let's say @SessionScoped bean. How does it work then? Once it fails (since there's no context propagation for async event), once it works (sync event)? Therefore this was forbidden. > > Tom > > ----- Original Message ----- > From: "John Ament" > To: "cdi-dev" > Sent: Monday, March 6, 2017 1:42:09 AM > Subject: [cdi-dev] Can an observer be both async and sync? > > > > Section 10.4.4 has the following section which got me thinking > > > > > > public void refreshOnDocumentUpdate(@Observes(notifyObserver=IF_EXISTS) @Updated Document doc) { ... } > > public void asyncRefreshOnDocumentUpdate(@ObservesAsync(notifyObserver=IF_EXISTS) @Updated Document doc) { ... } > > > > > > I'm wondering, is it OK to have an observer method defined like this? > > > > > > public void asyncRefreshOnDocumentUpdate( @Observes(notifyObserver=IF_EXISTS) @ObservesAsync(notifyObserver=IF_EXISTS) @Updated Document doc) { ... } > > > > > > I don't see anything against this in the spec, but I suspect most people are going to think this shouldn't work. So I'm asking the question - should it work? > > > > > John > > > > > > > > > > NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you. > > _______________________________________________ > 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. > -- Martin Kouba Senior Software Engineer Red Hat, Czech Republic From issues at jboss.org Mon Mar 6 04:27:00 2017 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Mon, 6 Mar 2017 04:27:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-687) Programmatic activation of an existing conversation by conversation id In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13372842#comment-13372842 ] Martin Kouba commented on CDI-687: ---------------------------------- Do you mean to allow to change the way a long-running conversation id is extracted from an HTTP request (e.g. to use an HTTP request header) or to "detach" the long-running conversations from a ServletRequest? > Programmatic activation of an existing conversation by conversation id > ---------------------------------------------------------------------- > > Key: CDI-687 > URL: https://issues.jboss.org/browse/CDI-687 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: John Ament > > Currently, conversation activation can only work if you have an HTTP request with cid query param passed in. We should expand this to allow any arbitrary lookup of conversation by id. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 6 04:47:00 2017 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 6 Mar 2017 04:47:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-688) Contextual bean stores In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13372872#comment-13372872 ] Antoine Sabot-Durand commented on CDI-688: ------------------------------------------ +1 to [~mkouba] comment. Right now, nothing prevents you to create a custom scope with your own store. > Contextual bean stores > ---------------------- > > Key: CDI-688 > URL: https://issues.jboss.org/browse/CDI-688 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: John Ament > > Right now, the notion of how beans are stored are ambiguous. The implementations back them by maps. This may work well, but there's some amount of plugability required to make passivation capable beans work right. A single request makes sense to store in a map. Sessions are stored in the HTTPSession. We should allow these bean stores to be more pluggable, allowing users or implementations to override how their beans are stored. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 6 04:49:00 2017 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 6 Mar 2017 04:49:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-689) Typo or unclear message in 24.1.2 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-689: ------------------------------------- Fix Version/s: 2.0 .Final > Typo or unclear message in 24.1.2 > --------------------------------- > > Key: CDI-689 > URL: https://issues.jboss.org/browse/CDI-689 > Project: CDI Specification Issues > Issue Type: Bug > Reporter: John Ament > Priority: Minor > Fix For: 2.0 .Final > > > Section 24.1.2 includes the following text: > {quote} > When Running in Java EE, the container must extend the rules defined in Observer method invocation context and must also ensure that > All kinds of observers are called in the same client security context as the invocation of Event.fire() or Event.fireAsync() or BeanManager.fireEvent(). > {quote} > The break after "that" in the first line seems weird, its not clear if its supposed to continue into the second line, or if the sentence is intended to continue. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 6 05:43:00 2017 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 6 Mar 2017 05:43:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-692) isResolvable missing from 5.6.1 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13372928#comment-13372928 ] Antoine Sabot-Durand commented on CDI-692: ------------------------------------------ Sorry for that, bad regression. It's now ok. Note that the correct URL is http://docs.jboss.org/cdi/spec/2.0-PRD/cdi-spec.html since we are in public review. > isResolvable missing from 5.6.1 > ------------------------------- > > Key: CDI-692 > URL: https://issues.jboss.org/browse/CDI-692 > Project: CDI Specification Issues > Issue Type: Bug > Reporter: John Ament > > Section 5.6.1 is missing the new isResolvable method http://docs.jboss.org/cdi/spec/2.0.Beta1/cdi-spec.html#dynamic_lookup -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 6 06:34:00 2017 From: issues at jboss.org (John Ament (JIRA)) Date: Mon, 6 Mar 2017 06:34:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-692) isResolvable missing from 5.6.1 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13372989#comment-13372989 ] John Ament commented on CDI-692: -------------------------------- Did you point me to PRD because the line is supposed to be there? Or some other reason? > isResolvable missing from 5.6.1 > ------------------------------- > > Key: CDI-692 > URL: https://issues.jboss.org/browse/CDI-692 > Project: CDI Specification Issues > Issue Type: Bug > Reporter: John Ament > > Section 5.6.1 is missing the new isResolvable method http://docs.jboss.org/cdi/spec/2.0.Beta1/cdi-spec.html#dynamic_lookup -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 6 06:39:00 2017 From: issues at jboss.org (John Ament (JIRA)) Date: Mon, 6 Mar 2017 06:39:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-690) Automatically start a request context for async observer methods In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13372993#comment-13372993 ] John Ament commented on CDI-690: -------------------------------- Yes, I raised this for the SE use case. Martin is correct, this already happens in the RI for SE. > Automatically start a request context for async observer methods > ---------------------------------------------------------------- > > Key: CDI-690 > URL: https://issues.jboss.org/browse/CDI-690 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: John Ament > > In many other places we start an implicit request context for method invocations (post constructs for instance). We should have an implicit request context for async observer methods. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From john.ament at spartasystems.com Mon Mar 6 06:40:33 2017 From: john.ament at spartasystems.com (John Ament) Date: Mon, 6 Mar 2017 11:40:33 +0000 Subject: [cdi-dev] Is InterceptionFactory a built in bean? In-Reply-To: References: , Message-ID: Gotcha, makes sense. ________________________________ From: Martin Kouba Sent: Monday, March 6, 2017 3:28 AM To: John Ament; cdi-dev Subject: Re: [cdi-dev] Is InterceptionFactory a built in bean? Dne 5.3.2017 v 19:20 John Ament napsal(a): > All, > > > I don't see it explicitly called out in the spec, but should I be able > to do this? CDI.current().select(InterceptionFactory.class).get() - > e.g. is it a a bean, or can I only access it as a producer method or via > BeanManager.createInterceptionFactory() ? There is a built-in bean of type InterceptionFactory (as defined in 11.7. The InterceptionFactory interface), but you can only inject it in a param of a producer method: "If an injection point of type InterceptionFactory and qualifier @Default exists and is not a parameter of a producer method, the container automatically detects the problem and treats it as a definition error." > > > Also, I found in the 2.0 beta 1 spec the following: > > > public interface InterceptionFactory { > InterceptionProxyFactory ignoreFinalMethods(); > > I believe InterceptionProxyFactory should be replaced > with InterceptionFactory, if we haven't already fixed this. > > > John > > > ------------------------------------------------------------------------ > NOTICE: This e-mail message and any attachments may contain > confidential, proprietary, and/or privileged information which should be > treated accordingly. If you are not the intended recipient, please > notify the sender immediately by return e-mail, delete this message, and > destroy all physical and electronic copies. Thank you. > > > _______________________________________________ > 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. > -- Martin Kouba Senior Software Engineer Red Hat, Czech Republic ________________________________ NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170306/65b1ac26/attachment.html From issues at jboss.org Mon Mar 6 06:42:03 2017 From: issues at jboss.org (John Ament (JIRA)) Date: Mon, 6 Mar 2017 06:42:03 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-691) Fire initialized/destroyed for conversation and session scoped In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13372996#comment-13372996 ] John Ament commented on CDI-691: -------------------------------- In the case of conversation at least, there is nothing stopping you from starting one in SE, is there? > Fire initialized/destroyed for conversation and session scoped > -------------------------------------------------------------- > > Key: CDI-691 > URL: https://issues.jboss.org/browse/CDI-691 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: John Ament > > Section 6.7 indicates that initialized/destroyed are called for request and application scopes. need to also fire for conversation and session. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 6 06:49:00 2017 From: issues at jboss.org (John Ament (JIRA)) Date: Mon, 6 Mar 2017 06:49:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-687) Programmatic activation of an existing conversation by conversation id In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13373006#comment-13373006 ] John Ament commented on CDI-687: -------------------------------- Either/both. > Programmatic activation of an existing conversation by conversation id > ---------------------------------------------------------------------- > > Key: CDI-687 > URL: https://issues.jboss.org/browse/CDI-687 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: John Ament > > Currently, conversation activation can only work if you have an HTTP request with cid query param passed in. We should expand this to allow any arbitrary lookup of conversation by id. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From john.ament at spartasystems.com Mon Mar 6 06:49:32 2017 From: john.ament at spartasystems.com (John Ament) Date: Mon, 6 Mar 2017 11:49:32 +0000 Subject: [cdi-dev] Can an observer be both async and sync? In-Reply-To: <51e06a60-f9c9-d69f-26ad-8bdeac18396d@redhat.com> References: <1390289376.28215507.1488783339118.JavaMail.zimbra@redhat.com>, <51e06a60-f9c9-d69f-26ad-8bdeac18396d@redhat.com> Message-ID: I'll put in a ticket to update the spec. I agree that it was intended to be forbidden, but I couldn't find anything saying it was. John ________________________________ From: Martin Kouba Sent: Monday, March 6, 2017 4:15 AM To: Tomas Remes; John Ament Cc: cdi-dev Subject: Re: [cdi-dev] Can an observer be both async and sync? Well, it's not 100% clear but I believe it should be forbidden. The spec only states: "An observer method may be declared by annotating a parameter @javax.enterprise.event.Observes OR @javax.enterprise.event.ObservesAsync of a default-access, public, protected or private method. That parameter is the event parameter." I think it wouldn't hurt to add: "If an event parameter is annotated with both @Observes and @ObservesAsync, the container automatically detects the problem and treats it as a definition error." Weld throws a DefinitionException. Martin Dne 6.3.2017 v 07:55 Tomas Remes napsal(a): > > Hi John, > > No it shouldn't. The problematic and confusing case would be when there is some other param (injection point) in this observer method and this param resolves to let's say @SessionScoped bean. How does it work then? Once it fails (since there's no context propagation for async event), once it works (sync event)? Therefore this was forbidden. > > Tom > > ----- Original Message ----- > From: "John Ament" > To: "cdi-dev" > Sent: Monday, March 6, 2017 1:42:09 AM > Subject: [cdi-dev] Can an observer be both async and sync? > > > > Section 10.4.4 has the following section which got me thinking > > > > > > public void refreshOnDocumentUpdate(@Observes(notifyObserver=IF_EXISTS) @Updated Document doc) { ... } > > public void asyncRefreshOnDocumentUpdate(@ObservesAsync(notifyObserver=IF_EXISTS) @Updated Document doc) { ... } > > > > > > I'm wondering, is it OK to have an observer method defined like this? > > > > > > public void asyncRefreshOnDocumentUpdate( @Observes(notifyObserver=IF_EXISTS) @ObservesAsync(notifyObserver=IF_EXISTS) @Updated Document doc) { ... } > > > > > > I don't see anything against this in the spec, but I suspect most people are going to think this shouldn't work. So I'm asking the question - should it work? > > > > > John > > > > > > > > > > NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you. > > _______________________________________________ > 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. > -- Martin Kouba Senior Software Engineer Red Hat, Czech Republic ________________________________ NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170306/05dea314/attachment-0001.html From issues at jboss.org Mon Mar 6 06:51:01 2017 From: issues at jboss.org (John Ament (JIRA)) Date: Mon, 6 Mar 2017 06:51:01 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-694) Make an observer that uses both @Observes and @ObservesAsync forbidden In-Reply-To: References: Message-ID: John Ament created CDI-694: ------------------------------ Summary: Make an observer that uses both @Observes and @ObservesAsync forbidden Key: CDI-694 URL: https://issues.jboss.org/browse/CDI-694 Project: CDI Specification Issues Issue Type: Bug Reporter: John Ament Not explicitly called out in the spec text, we should make an observer that has both annotations forbidden. RI presently throws a DefinitionException. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 6 06:53:00 2017 From: issues at jboss.org (John Ament (JIRA)) Date: Mon, 6 Mar 2017 06:53:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-691) Fire initialized/destroyed for conversation and session scoped In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13373014#comment-13373014 ] John Ament commented on CDI-691: -------------------------------- We can consider this a bug then I guess. The issue is that 6.9.1 doesn't mention it - http://docs.jboss.org/cdi/spec/2.0-PFD/cdi-spec.html#builtin_contexts > Fire initialized/destroyed for conversation and session scoped > -------------------------------------------------------------- > > Key: CDI-691 > URL: https://issues.jboss.org/browse/CDI-691 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: John Ament > > Section 6.7 indicates that initialized/destroyed are called for request and application scopes. need to also fire for conversation and session. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 6 06:53:00 2017 From: issues at jboss.org (John Ament (JIRA)) Date: Mon, 6 Mar 2017 06:53:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-691) Fire initialized/destroyed for conversation and session scoped In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Ament updated CDI-691: --------------------------- Issue Type: Bug (was: Feature Request) > Fire initialized/destroyed for conversation and session scoped > -------------------------------------------------------------- > > Key: CDI-691 > URL: https://issues.jboss.org/browse/CDI-691 > Project: CDI Specification Issues > Issue Type: Bug > Reporter: John Ament > > Section 6.7 indicates that initialized/destroyed are called for request and application scopes. need to also fire for conversation and session. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 6 06:57:00 2017 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Mon, 6 Mar 2017 06:57:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-691) Fire initialized/destroyed for conversation and session scoped In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13373020#comment-13373020 ] Martin Kouba commented on CDI-691: ---------------------------------- Of course not, but then you would have to use either an impl-specific API or a custom context. In both cases, it's a non-portable functionality. Also note that extensions are encouraged to synchronously fire these events. > Fire initialized/destroyed for conversation and session scoped > -------------------------------------------------------------- > > Key: CDI-691 > URL: https://issues.jboss.org/browse/CDI-691 > Project: CDI Specification Issues > Issue Type: Bug > Reporter: John Ament > > Section 6.7 indicates that initialized/destroyed are called for request and application scopes. need to also fire for conversation and session. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 6 08:27:00 2017 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 6 Mar 2017 08:27:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-692) isResolvable missing from 5.6.1 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13373125#comment-13373125 ] Antoine Sabot-Durand commented on CDI-692: ------------------------------------------ [~meetoblivion] I was just answering [~tremes] remark. Your point is valid: {{isResolvable()}} is missing in all spec versions ;). > isResolvable missing from 5.6.1 > ------------------------------- > > Key: CDI-692 > URL: https://issues.jboss.org/browse/CDI-692 > Project: CDI Specification Issues > Issue Type: Bug > Reporter: John Ament > Fix For: 2.0 .Final > > > Section 5.6.1 is missing the new isResolvable method http://docs.jboss.org/cdi/spec/2.0.Beta1/cdi-spec.html#dynamic_lookup -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 6 08:27:00 2017 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 6 Mar 2017 08:27:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-692) isResolvable missing from 5.6.1 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-692: ------------------------------------- Fix Version/s: 2.0 .Final > isResolvable missing from 5.6.1 > ------------------------------- > > Key: CDI-692 > URL: https://issues.jboss.org/browse/CDI-692 > Project: CDI Specification Issues > Issue Type: Bug > Reporter: John Ament > Fix For: 2.0 .Final > > > Section 5.6.1 is missing the new isResolvable method http://docs.jboss.org/cdi/spec/2.0.Beta1/cdi-spec.html#dynamic_lookup -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 6 08:32:00 2017 From: issues at jboss.org (Tomas Remes (JIRA)) Date: Mon, 6 Mar 2017 08:32:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-692) isResolvable missing from 5.6.1 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13373132#comment-13373132 ] Tomas Remes commented on CDI-692: --------------------------------- In the link I posted above is {{isResolvable}} method mentioned. > isResolvable missing from 5.6.1 > ------------------------------- > > Key: CDI-692 > URL: https://issues.jboss.org/browse/CDI-692 > Project: CDI Specification Issues > Issue Type: Bug > Reporter: John Ament > Fix For: 2.0 .Final > > > Section 5.6.1 is missing the new isResolvable method http://docs.jboss.org/cdi/spec/2.0.Beta1/cdi-spec.html#dynamic_lookup -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 6 08:43:01 2017 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Mon, 6 Mar 2017 08:43:01 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-692) isResolvable missing from 5.6.1 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13373152#comment-13373152 ] Martin Kouba commented on CDI-692: ---------------------------------- bq. Your point is valid: isResolvable() is missing in all spec versions. It's definitely not. See also "5.6.1. The Instance interface": bq. The methods isUnsatisfied(), isAmbiguous() and isResolvable() must: ... > isResolvable missing from 5.6.1 > ------------------------------- > > Key: CDI-692 > URL: https://issues.jboss.org/browse/CDI-692 > Project: CDI Specification Issues > Issue Type: Bug > Reporter: John Ament > Fix For: 2.0 .Final > > > Section 5.6.1 is missing the new isResolvable method http://docs.jboss.org/cdi/spec/2.0.Beta1/cdi-spec.html#dynamic_lookup -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 6 08:54:00 2017 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 6 Mar 2017 08:54:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-692) isResolvable missing from 5.6.1 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13373166#comment-13373166 ] Antoine Sabot-Durand commented on CDI-692: ------------------------------------------ We're both right: it is mentioned in the spec text, but not in the code bloc for {{Instance}} interface at the beginning of 5.6.1. > isResolvable missing from 5.6.1 > ------------------------------- > > Key: CDI-692 > URL: https://issues.jboss.org/browse/CDI-692 > Project: CDI Specification Issues > Issue Type: Bug > Reporter: John Ament > Fix For: 2.0 .Final > > > Section 5.6.1 is missing the new isResolvable method http://docs.jboss.org/cdi/spec/2.0.Beta1/cdi-spec.html#dynamic_lookup -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 6 10:15:01 2017 From: issues at jboss.org (John Ament (JIRA)) Date: Mon, 6 Mar 2017 10:15:01 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-695) Allow stereotypes to include priority annotations In-Reply-To: References: Message-ID: John Ament created CDI-695: ------------------------------ Summary: Allow stereotypes to include priority annotations Key: CDI-695 URL: https://issues.jboss.org/browse/CDI-695 Project: CDI Specification Issues Issue Type: Feature Request Reporter: John Ament Stereotypes can include things like Alternative. However, there is no mention as to whether or not Priority can be included in the stereotype definition. I feel it would be useful to be included. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From john.ament at spartasystems.com Mon Mar 6 22:16:39 2017 From: john.ament at spartasystems.com (John Ament) Date: Tue, 7 Mar 2017 03:16:39 +0000 Subject: [cdi-dev] Behavior of CDI fireAsync when using CompletionStage.whenCompleteAsync Message-ID: Run into an interesting issue. Not sure if its an RI problem, or something else. Actually not even sure if its a problem just surprised me. I have two very simple main methods here: try(SeContainer container = SeContainerInitializer.newInstance() .addPackages(Pojo.class) .disableDiscovery() .initialize()) { Event event = container.getBeanManager().getEvent(); FixedThreadPoolExecutorServices executorServices = new FixedThreadPoolExecutorServices(2); CompletionStage completionStage = event.fireAsync(new Pojo("this is asynchronous"), NotificationOptions.ofExecutor(executorServices.getTaskExecutor())); completionStage.whenCompleteAsync((pojo, throwable) -> event.fire(new Pojo(pojo.showName() + ", and now this is synchronous"))); Thread.sleep(500L); } public static void main(String...args) throws Exception{ try(SeContainer container = SeContainerInitializer.newInstance() .addPackages(Pojo.class) .disableDiscovery() .initialize()) { Event event = container.getBeanManager().getEvent(); CompletionStage completionStage = event.fireAsync(new Pojo("this is asynchronous")); completionStage.whenCompleteAsync((pojo, throwable) -> event.fire(new Pojo(pojo.showName() + ", and now this is synchronous"))); Thread.sleep(500L); } } In the first, I'm using a custom executor (a 2 thread pool executor) and the latter just using the default unspecified version, which weld seems to use a fork-join pool. In both of these examples, I use the whenCompleteAsync method. in the first method, I always see the fired event being handled in a different thread than what handled the first event. In the second method, I always see the fired events both being handled in the same thread. Is that just the behavior of fork-join? Or something special happening? John ________________________________ NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170307/5a96c528/attachment-0001.html From mkouba at redhat.com Tue Mar 7 03:12:50 2017 From: mkouba at redhat.com (Martin Kouba) Date: Tue, 7 Mar 2017 09:12:50 +0100 Subject: [cdi-dev] Behavior of CDI fireAsync when using CompletionStage.whenCompleteAsync In-Reply-To: References: Message-ID: Hi John, I don't think it's a problem. I believe users should not care about these implementation details at all. The only thing which is guaranteed is that async observers and eventual async callbacks are executed asynchronously and do not block the thread from where the event was fired. For completeness - Weld SE is using fork-join pool by default (and this could be changed by means of org.jboss.weld.executor.threadPoolType). See also http://docs.jboss.org/weld/reference/latest-master/en-US/html/configure.html#_thread_pool_configuration. Martin Dne 7.3.2017 v 04:16 John Ament napsal(a): > Run into an interesting issue. Not sure if its an RI problem, or > something else. Actually not even sure if its a problem just surprised me. > > > I have two very simple main methods here: > > > try(SeContainer container = SeContainerInitializer.newInstance() > .addPackages(Pojo.class) > .disableDiscovery() > .initialize()) { > Event event = container.getBeanManager().getEvent(); > FixedThreadPoolExecutorServices executorServices = new > FixedThreadPoolExecutorServices(2); > CompletionStage completionStage = event.fireAsync(new Pojo("this > is asynchronous"), > NotificationOptions.ofExecutor(executorServices.getTaskExecutor())); > completionStage.whenCompleteAsync((pojo, throwable) -> event.fire(new > Pojo(pojo.showName() + ", and now this is synchronous"))); > Thread.sleep(500L); > } > > public static void main(String...args) throws Exception{ > try(SeContainer container = SeContainerInitializer.newInstance() > .addPackages(Pojo.class) > .disableDiscovery() > .initialize()) { > Event event = container.getBeanManager().getEvent(); > CompletionStage completionStage = event.fireAsync(new Pojo("this > is asynchronous")); > completionStage.whenCompleteAsync((pojo, throwable) -> event.fire(new > Pojo(pojo.showName() + ", and now this is synchronous"))); > Thread.sleep(500L); > } > } > > > In the first, I'm using a custom executor (a 2 thread pool executor) and > the latter just using the default unspecified version, which weld seems > to use a fork-join pool. In both of these examples, I use the > whenCompleteAsync method. in the first method, I always see the fired > event being handled in a different thread than what handled the first > event. In the second method, I always see the fired events both being > handled in the same thread. Is that just the behavior of fork-join? Or > something special happening? > > > John > > ------------------------------------------------------------------------ > NOTICE: This e-mail message and any attachments may contain > confidential, proprietary, and/or privileged information which should be > treated accordingly. If you are not the intended recipient, please > notify the sender immediately by return e-mail, delete this message, and > destroy all physical and electronic copies. Thank you. > > > _______________________________________________ > 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. > -- Martin Kouba Senior Software Engineer Red Hat, Czech Republic From issues at jboss.org Tue Mar 7 05:10:00 2017 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 7 Mar 2017 05:10:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-694) Make an observer that uses both @Observes and @ObservesAsync forbidden In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13373815#comment-13373815 ] Antoine Sabot-Durand commented on CDI-694: ------------------------------------------ Well, section [10.4.2|http://docs.jboss.org/cdi/spec/2.0-PRD/cdi-spec.html#observes] start with the following mention: {quote}An observer method may be declared by annotating a parameter {{@javax.enterprise.event.Observes}} *or* {{@javax.enterprise.event.ObservesAsync}} of a default-access{quote} But we could add a mention to say when and how the container should handle such a conflict. > Make an observer that uses both @Observes and @ObservesAsync forbidden > ---------------------------------------------------------------------- > > Key: CDI-694 > URL: https://issues.jboss.org/browse/CDI-694 > Project: CDI Specification Issues > Issue Type: Bug > Reporter: John Ament > Fix For: 2.0 .Final > > > Not explicitly called out in the spec text, we should make an observer that has both annotations forbidden. > RI presently throws a DefinitionException. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 05:10:00 2017 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 7 Mar 2017 05:10:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-694) Make an observer that uses both @Observes and @ObservesAsync forbidden In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-694: ------------------------------------- Fix Version/s: 2.0 .Final > Make an observer that uses both @Observes and @ObservesAsync forbidden > ---------------------------------------------------------------------- > > Key: CDI-694 > URL: https://issues.jboss.org/browse/CDI-694 > Project: CDI Specification Issues > Issue Type: Bug > Reporter: John Ament > Fix For: 2.0 .Final > > > Not explicitly called out in the spec text, we should make an observer that has both annotations forbidden. > RI presently throws a DefinitionException. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 05:18:00 2017 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 7 Mar 2017 05:18:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-695) Allow stereotypes to include priority annotations In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13373820#comment-13373820 ] Antoine Sabot-Durand commented on CDI-695: ------------------------------------------ IMO, I think it would bring more confusion than useful: * A Stereotype is usually created to be used on many elements. What would be the interest to apply same priority in different places? * {{@Priority}} is used and activate Interceptors and Alternatives and not having this info directly on the element can be source of confusion IMO. Could you give a use case where it could be interesting to have this? > Allow stereotypes to include priority annotations > ------------------------------------------------- > > Key: CDI-695 > URL: https://issues.jboss.org/browse/CDI-695 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: John Ament > > Stereotypes can include things like Alternative. However, there is no mention as to whether or not Priority can be included in the stereotype definition. I feel it would be useful to be included. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 05:18:00 2017 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Tue, 7 Mar 2017 05:18:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-694) Make an observer that uses both @Observes and @ObservesAsync forbidden In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13373821#comment-13373821 ] Martin Kouba commented on CDI-694: ---------------------------------- It's always better to say what happens if a rule is violated. > Make an observer that uses both @Observes and @ObservesAsync forbidden > ---------------------------------------------------------------------- > > Key: CDI-694 > URL: https://issues.jboss.org/browse/CDI-694 > Project: CDI Specification Issues > Issue Type: Bug > Reporter: John Ament > Fix For: 2.0 .Final > > > Not explicitly called out in the spec text, we should make an observer that has both annotations forbidden. > RI presently throws a DefinitionException. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 7 05:25:00 2017 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 7 Mar 2017 05:25:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-694) Make an observer that uses both @Observes and @ObservesAsync forbidden In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13373827#comment-13373827 ] Antoine Sabot-Durand commented on CDI-694: ------------------------------------------ Totally agree with you [~mkouba] > Make an observer that uses both @Observes and @ObservesAsync forbidden > ---------------------------------------------------------------------- > > Key: CDI-694 > URL: https://issues.jboss.org/browse/CDI-694 > Project: CDI Specification Issues > Issue Type: Bug > Reporter: John Ament > Fix For: 2.0 .Final > > > Not explicitly called out in the spec text, we should make an observer that has both annotations forbidden. > RI presently throws a DefinitionException. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From ljnelson at gmail.com Tue Mar 7 11:57:29 2017 From: ljnelson at gmail.com (Laird Nelson) Date: Tue, 07 Mar 2017 16:57:29 +0000 Subject: [cdi-dev] Behavior of CDI fireAsync when using CompletionStage.whenCompleteAsync In-Reply-To: References: Message-ID: On Tue, Mar 7, 2017 at 12:15 AM Martin Kouba wrote: > The only thing which is guaranteed > is that async observers and eventual async callbacks are executed > asynchronously and do not block the thread from where the event was fired. > What about: event.fireAsync(someEvent, NotificationOptions.ofExecutor(someSynchronousExecutor)) ?? I know that's contrived but?? Best, Laird -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170307/bbed4cc5/attachment.html From issues at jboss.org Fri Mar 10 04:17:00 2017 From: issues at jboss.org (Alexandr Sokolov (JIRA)) Date: Fri, 10 Mar 2017 04:17:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-696) Decorator for MDB is not used In-Reply-To: References: Message-ID: Alexandr Sokolov created CDI-696: ------------------------------------ Summary: Decorator for MDB is not used Key: CDI-696 URL: https://issues.jboss.org/browse/CDI-696 Project: CDI Specification Issues Issue Type: Bug Components: Decorators, Java EE integration Reporter: Alexandr Sokolov Guys, I'm using Wildfly 8.2.1.Final Here is MDB bean: {code:java} @MessageDriven(activationConfig = { @ActivationConfigProperty(propertyName = "destinationLookup", propertyValue = "topic/dse"), @ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Topic") }) public class JobChangedSubscriber implements MessageListener { ... @Override public void onMessage(final Message message) { ... } } {code} And decorator: {code:java} @Decorator public class RetroplannerSubscriber implements MessageListener { @Inject @Delegate @Any JobChangedSubscriber jobChangedSubscriber; @Override public void onMessage(Message message) { jobChangedSubscriber.onMessage(message); //custom code } } {code} During deployment, all mistakes about decorator definition are shown. They were fixed. I was sure it would work. But now, only JobChangedSubscriber.onMessage() is invoked. As a user I want to decorate MDB as an usual CDI bean. What am I doing wrong? -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 05:41:00 2017 From: issues at jboss.org (Tomas Remes (JIRA)) Date: Fri, 10 Mar 2017 05:41:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-696) Decorator for MDB is not used In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13375900#comment-13375900 ] Tomas Remes commented on CDI-696: --------------------------------- Hi [~avsokolov], I don't think your question is adequate as a CDI issue. This sounds more like question on forum. Anyway do you define your {{RetroplannerSubscriber}} in beans.xml as a decorator? I am going to verify this behaviour with WildFly 10.1.0.Final. Not really sure but I think it could work since interception works. > Decorator for MDB is not used > ----------------------------- > > Key: CDI-696 > URL: https://issues.jboss.org/browse/CDI-696 > Project: CDI Specification Issues > Issue Type: Bug > Components: Decorators, Java EE integration > Reporter: Alexandr Sokolov > > Guys, I'm using Wildfly 8.2.1.Final > Here is MDB bean: > {code:java} > @MessageDriven(activationConfig = { > @ActivationConfigProperty(propertyName = "destinationLookup", > propertyValue = "topic/dse"), > @ActivationConfigProperty(propertyName = "destinationType", > propertyValue = "javax.jms.Topic") > }) > public class JobChangedSubscriber implements MessageListener { > ... > @Override > public void onMessage(final Message message) { > ... > } > } > {code} > And decorator: > {code:java} > @Decorator > public class RetroplannerSubscriber implements MessageListener { > @Inject > @Delegate > @Any > JobChangedSubscriber jobChangedSubscriber; > @Override > public void onMessage(Message message) { > jobChangedSubscriber.onMessage(message); > //custom code > } > } > {code} > During deployment, all mistakes about decorator definition are shown. They were fixed. I was sure it would work. But now, only JobChangedSubscriber.onMessage() is invoked. > As a user I want to decorate MDB as an usual CDI bean. What am I doing wrong? -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 06:04:00 2017 From: issues at jboss.org (Tomas Remes (JIRA)) Date: Fri, 10 Mar 2017 06:04:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-696) Decorator for MDB is not used In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13375920#comment-13375920 ] Tomas Remes commented on CDI-696: --------------------------------- OK so it doesn't seem to work. So the question is whether it should. I cannot find such evidence in specifications. EJB 3.2 spec defines only support for interceptors in {{5.4.10 Message Listener Interceptor Methods for Message-Driven Beans}} AFAIK. > Decorator for MDB is not used > ----------------------------- > > Key: CDI-696 > URL: https://issues.jboss.org/browse/CDI-696 > Project: CDI Specification Issues > Issue Type: Bug > Components: Decorators, Java EE integration > Reporter: Alexandr Sokolov > > Guys, I'm using Wildfly 8.2.1.Final > Here is MDB bean: > {code:java} > @MessageDriven(activationConfig = { > @ActivationConfigProperty(propertyName = "destinationLookup", > propertyValue = "topic/dse"), > @ActivationConfigProperty(propertyName = "destinationType", > propertyValue = "javax.jms.Topic") > }) > public class JobChangedSubscriber implements MessageListener { > ... > @Override > public void onMessage(final Message message) { > ... > } > } > {code} > And decorator: > {code:java} > @Decorator > public class RetroplannerSubscriber implements MessageListener { > @Inject > @Delegate > @Any > JobChangedSubscriber jobChangedSubscriber; > @Override > public void onMessage(Message message) { > jobChangedSubscriber.onMessage(message); > //custom code > } > } > {code} > During deployment, all mistakes about decorator definition are shown. They were fixed. I was sure it would work. But now, only JobChangedSubscriber.onMessage() is invoked. > As a user I want to decorate MDB as an usual CDI bean. What am I doing wrong? -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 07:20:00 2017 From: issues at jboss.org (John Ament (JIRA)) Date: Fri, 10 Mar 2017 07:20:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-696) Decorator for MDB is not used In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13375985#comment-13375985 ] John Ament commented on CDI-696: -------------------------------- Most specs are pretty ambiguous in this area, however the root of the problem is that most of these EE objects are not actually managed beans. If you look at message listeners, servlets, filters, they all support injection, but themselves are not managed by CDI as a runtime. The containers will delegate down to CDI to provide injection support into those classes. > Decorator for MDB is not used > ----------------------------- > > Key: CDI-696 > URL: https://issues.jboss.org/browse/CDI-696 > Project: CDI Specification Issues > Issue Type: Bug > Components: Decorators, Java EE integration > Reporter: Alexandr Sokolov > > Guys, I'm using Wildfly 8.2.1.Final > Here is MDB bean: > {code:java} > @MessageDriven(activationConfig = { > @ActivationConfigProperty(propertyName = "destinationLookup", > propertyValue = "topic/dse"), > @ActivationConfigProperty(propertyName = "destinationType", > propertyValue = "javax.jms.Topic") > }) > public class JobChangedSubscriber implements MessageListener { > ... > @Override > public void onMessage(final Message message) { > ... > } > } > {code} > And decorator: > {code:java} > @Decorator > public class RetroplannerSubscriber implements MessageListener { > @Inject > @Delegate > @Any > JobChangedSubscriber jobChangedSubscriber; > @Override > public void onMessage(Message message) { > jobChangedSubscriber.onMessage(message); > //custom code > } > } > {code} > During deployment, all mistakes about decorator definition are shown. They were fixed. I was sure it would work. But now, only JobChangedSubscriber.onMessage() is invoked. > As a user I want to decorate MDB as an usual CDI bean. What am I doing wrong? -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 07:32:00 2017 From: issues at jboss.org (Alexandr Sokolov (JIRA)) Date: Fri, 10 Mar 2017 07:32:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-696) Decorator for MDB is not used In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13375993#comment-13375993 ] Alexandr Sokolov commented on CDI-696: -------------------------------------- John, if MDB would no be actually managed bean, I would not be able to inject beans in to it. And I'd have to think about life cycle of this bean. It seems that some functionality works with MDB, like with usual managed beans. But exact decorators - no. > Decorator for MDB is not used > ----------------------------- > > Key: CDI-696 > URL: https://issues.jboss.org/browse/CDI-696 > Project: CDI Specification Issues > Issue Type: Bug > Components: Decorators, Java EE integration > Reporter: Alexandr Sokolov > > Guys, I'm using Wildfly 8.2.1.Final > Here is MDB bean: > {code:java} > @MessageDriven(activationConfig = { > @ActivationConfigProperty(propertyName = "destinationLookup", > propertyValue = "topic/dse"), > @ActivationConfigProperty(propertyName = "destinationType", > propertyValue = "javax.jms.Topic") > }) > public class JobChangedSubscriber implements MessageListener { > ... > @Override > public void onMessage(final Message message) { > ... > } > } > {code} > And decorator: > {code:java} > @Decorator > public class RetroplannerSubscriber implements MessageListener { > @Inject > @Delegate > @Any > JobChangedSubscriber jobChangedSubscriber; > @Override > public void onMessage(Message message) { > jobChangedSubscriber.onMessage(message); > //custom code > } > } > {code} > During deployment, all mistakes about decorator definition are shown. They were fixed. I was sure it would work. But now, only JobChangedSubscriber.onMessage() is invoked. > As a user I want to decorate MDB as an usual CDI bean. What am I doing wrong? -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Mar 10 07:58:00 2017 From: issues at jboss.org (John Ament (JIRA)) Date: Fri, 10 Mar 2017 07:58:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-696) Decorator for MDB is not used In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13376004#comment-13376004 ] John Ament commented on CDI-696: -------------------------------- [~avsokolov] that's incorrect. We expose an SPI that does that, for instance how DeltaSpike uses {{InjectionTarget.inject}} - https://github.com/apache/deltaspike/blob/master/deltaspike/core/api/src/main/java/org/apache/deltaspike/core/api/provider/BeanProvider.java#L461 > Decorator for MDB is not used > ----------------------------- > > Key: CDI-696 > URL: https://issues.jboss.org/browse/CDI-696 > Project: CDI Specification Issues > Issue Type: Bug > Components: Decorators, Java EE integration > Reporter: Alexandr Sokolov > > Guys, I'm using Wildfly 8.2.1.Final > Here is MDB bean: > {code:java} > @MessageDriven(activationConfig = { > @ActivationConfigProperty(propertyName = "destinationLookup", > propertyValue = "topic/dse"), > @ActivationConfigProperty(propertyName = "destinationType", > propertyValue = "javax.jms.Topic") > }) > public class JobChangedSubscriber implements MessageListener { > ... > @Override > public void onMessage(final Message message) { > ... > } > } > {code} > And decorator: > {code:java} > @Decorator > public class RetroplannerSubscriber implements MessageListener { > @Inject > @Delegate > @Any > JobChangedSubscriber jobChangedSubscriber; > @Override > public void onMessage(Message message) { > jobChangedSubscriber.onMessage(message); > //custom code > } > } > {code} > During deployment, all mistakes about decorator definition are shown. They were fixed. I was sure it would work. But now, only JobChangedSubscriber.onMessage() is invoked. > As a user I want to decorate MDB as an usual CDI bean. What am I doing wrong? -- This message was sent by Atlassian JIRA (v7.2.3#72005) From donatas.ciuksys at gmail.com Fri Mar 10 08:56:31 2017 From: donatas.ciuksys at gmail.com (Donatas) Date: Fri, 10 Mar 2017 06:56:31 -0700 (MST) Subject: [cdi-dev] Review comment: Either allow or explicity disallow EXTENDED @PersistenceContext Message-ID: <1489154191774-5714559.post@n5.nabble.com> Section "18.7.1. Declaring a resource" mentions only: @PersistenceContext(unitName="CustomerDatabase") but doesn't tell whether injection of EXTENDED and/or UNSYNCHRONIZED PersistenceContext is allowed, dis-allowed or not-portable. Please consider covering all the possible attributes of annotation @PersistenceContext: type and synchronization. Donatas -- View this message in context: http://cdi-development-mailing-list.1064426.n5.nabble.com/Review-comment-Either-allow-or-explicity-disallow-EXTENDED-PersistenceContext-tp5714559.html Sent from the CDI Development mailing list mailing list archive at Nabble.com. From donatas.ciuksys at gmail.com Fri Mar 10 09:05:04 2017 From: donatas.ciuksys at gmail.com (Donatas) Date: Fri, 10 Mar 2017 07:05:04 -0700 (MST) Subject: [cdi-dev] Review comment: consider allowing NormalScoped EntityManager producers Message-ID: <1489154704846-5714560.post@n5.nabble.com> Section "18.7. Resources" contains: /The container is not required to support resources with scope other than @Dependent. Portable applications should not define resources with any scope other than @Dependent./ Yet the CDI spec itself has examples like the one in section "3.4.2. Declaring a disposer method": @Produces *@ConversationScoped* @UserDatabase public *EntityManager* create(EntityManagerFactory emf) { return emf.createEntityManager(); } Most best practices recommend @RequestScoped EntityManager producer (e.g.: DeltaSpike JPA module: http://deltaspike.apache.org/documentation/jpa.html ). Thus please consider explicitly allowing NormalScoped EntityManager producers. Donatas -- View this message in context: http://cdi-development-mailing-list.1064426.n5.nabble.com/Review-comment-consider-allowing-NormalScoped-EntityManager-producers-tp5714560.html Sent from the CDI Development mailing list mailing list archive at Nabble.com. From john.ament at spartasystems.com Fri Mar 10 09:08:40 2017 From: john.ament at spartasystems.com (John Ament) Date: Fri, 10 Mar 2017 14:08:40 +0000 Subject: [cdi-dev] Review comment: consider allowing NormalScoped EntityManager producers In-Reply-To: <1489154704846-5714560.post@n5.nabble.com> References: <1489154704846-5714560.post@n5.nabble.com> Message-ID: Donatas, There's nothing stopping request scoped entity managers, from a spec level. The spec is referring to the inject of resources via @Resource and similar annotations (e.g. PersistenceContext). John ________________________________ From: cdi-dev-bounces at lists.jboss.org on behalf of Donatas Sent: Friday, March 10, 2017 9:05 AM To: cdi-dev at lists.jboss.org Subject: [cdi-dev] Review comment: consider allowing NormalScoped EntityManager producers Section "18.7. Resources" contains: /The container is not required to support resources with scope other than @Dependent. Portable applications should not define resources with any scope other than @Dependent./ Yet the CDI spec itself has examples like the one in section "3.4.2. Declaring a disposer method": @Produces *@ConversationScoped* @UserDatabase public *EntityManager* create(EntityManagerFactory emf) { return emf.createEntityManager(); } Most best practices recommend @RequestScoped EntityManager producer (e.g.: DeltaSpike JPA module: http://deltaspike.apache.org/documentation/jpa.html ). Thus please consider explicitly allowing NormalScoped EntityManager producers. Donatas -- View this message in context: http://cdi-development-mailing-list.1064426.n5.nabble.com/Review-comment-consider-allowing-NormalScoped-EntityManager-producers-tp5714560.html Sent from the CDI Development mailing list mailing list archive at Nabble.com. _______________________________________________ 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. ________________________________ NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170310/a593b0e7/attachment-0001.html From issues at jboss.org Fri Mar 10 09:11:00 2017 From: issues at jboss.org (Alexandr Sokolov (JIRA)) Date: Fri, 10 Mar 2017 09:11:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-696) Decorator for MDB is not used In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13376047#comment-13376047 ] Alexandr Sokolov commented on CDI-696: -------------------------------------- Ok. I think I'm as a client expect more than I should and my understanding of managed beans can be wrong. > Decorator for MDB is not used > ----------------------------- > > Key: CDI-696 > URL: https://issues.jboss.org/browse/CDI-696 > Project: CDI Specification Issues > Issue Type: Bug > Components: Decorators, Java EE integration > Reporter: Alexandr Sokolov > > Guys, I'm using Wildfly 8.2.1.Final > Here is MDB bean: > {code:java} > @MessageDriven(activationConfig = { > @ActivationConfigProperty(propertyName = "destinationLookup", > propertyValue = "topic/dse"), > @ActivationConfigProperty(propertyName = "destinationType", > propertyValue = "javax.jms.Topic") > }) > public class JobChangedSubscriber implements MessageListener { > ... > @Override > public void onMessage(final Message message) { > ... > } > } > {code} > And decorator: > {code:java} > @Decorator > public class RetroplannerSubscriber implements MessageListener { > @Inject > @Delegate > @Any > JobChangedSubscriber jobChangedSubscriber; > @Override > public void onMessage(Message message) { > jobChangedSubscriber.onMessage(message); > //custom code > } > } > {code} > During deployment, all mistakes about decorator definition are shown. They were fixed. I was sure it would work. But now, only JobChangedSubscriber.onMessage() is invoked. > As a user I want to decorate MDB as an usual CDI bean. What am I doing wrong? -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Sat Mar 11 04:35:00 2017 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Sat, 11 Mar 2017 04:35:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-696) Decorator for MDB is not used In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13376353#comment-13376353 ] Martin Kouba commented on CDI-696: ---------------------------------- See also "1.2.2. Relationship to EJB": bq. Message-driven and entity beans are by nature non-contextual objects and may not be injected into other objects. And "3.6. Java EE components": bq. Most Java EE components support injection and interception, as defined in the Java Platform, Enterprise Edition Specification 7, table EE.5-1, but are not considered beans (as defined by this specification). EJBs, as defined in Session beans are an exception. > Decorator for MDB is not used > ----------------------------- > > Key: CDI-696 > URL: https://issues.jboss.org/browse/CDI-696 > Project: CDI Specification Issues > Issue Type: Bug > Components: Decorators, Java EE integration > Reporter: Alexandr Sokolov > > Guys, I'm using Wildfly 8.2.1.Final > Here is MDB bean: > {code:java} > @MessageDriven(activationConfig = { > @ActivationConfigProperty(propertyName = "destinationLookup", > propertyValue = "topic/dse"), > @ActivationConfigProperty(propertyName = "destinationType", > propertyValue = "javax.jms.Topic") > }) > public class JobChangedSubscriber implements MessageListener { > ... > @Override > public void onMessage(final Message message) { > ... > } > } > {code} > And decorator: > {code:java} > @Decorator > public class RetroplannerSubscriber implements MessageListener { > @Inject > @Delegate > @Any > JobChangedSubscriber jobChangedSubscriber; > @Override > public void onMessage(Message message) { > jobChangedSubscriber.onMessage(message); > //custom code > } > } > {code} > During deployment, all mistakes about decorator definition are shown. They were fixed. I was sure it would work. But now, only JobChangedSubscriber.onMessage() is invoked. > As a user I want to decorate MDB as an usual CDI bean. What am I doing wrong? -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 05:13:00 2017 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Thu, 16 Mar 2017 05:13:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-689) Typo or unclear message in 24.1.2 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CDI-689 started by Antoine Sabot-Durand. ------------------------------------------------ > Typo or unclear message in 24.1.2 > --------------------------------- > > Key: CDI-689 > URL: https://issues.jboss.org/browse/CDI-689 > Project: CDI Specification Issues > Issue Type: Bug > Reporter: John Ament > Assignee: Antoine Sabot-Durand > Priority: Minor > Fix For: 2.0 .Final > > > Section 24.1.2 includes the following text: > {quote} > When Running in Java EE, the container must extend the rules defined in Observer method invocation context and must also ensure that > All kinds of observers are called in the same client security context as the invocation of Event.fire() or Event.fireAsync() or BeanManager.fireEvent(). > {quote} > The break after "that" in the first line seems weird, its not clear if its supposed to continue into the second line, or if the sentence is intended to continue. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 05:18:00 2017 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Thu, 16 Mar 2017 05:18:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-692) isResolvable missing from 5.6.1 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CDI-692 started by Antoine Sabot-Durand. ------------------------------------------------ > isResolvable missing from 5.6.1 > ------------------------------- > > Key: CDI-692 > URL: https://issues.jboss.org/browse/CDI-692 > Project: CDI Specification Issues > Issue Type: Bug > Reporter: John Ament > Assignee: Antoine Sabot-Durand > Fix For: 2.0 .Final > > > Section 5.6.1 is missing the new isResolvable method http://docs.jboss.org/cdi/spec/2.0.Beta1/cdi-spec.html#dynamic_lookup -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 16 05:48:00 2017 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Thu, 16 Mar 2017 05:48:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-694) Make an observer that uses both @Observes and @ObservesAsync forbidden In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CDI-694 started by Antoine Sabot-Durand. ------------------------------------------------ > Make an observer that uses both @Observes and @ObservesAsync forbidden > ---------------------------------------------------------------------- > > Key: CDI-694 > URL: https://issues.jboss.org/browse/CDI-694 > Project: CDI Specification Issues > Issue Type: Bug > Reporter: John Ament > Assignee: Antoine Sabot-Durand > Fix For: 2.0 .Final > > > Not explicitly called out in the spec text, we should make an observer that has both annotations forbidden. > RI presently throws a DefinitionException. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From antoine at sabot-durand.net Thu Mar 16 11:08:18 2017 From: antoine at sabot-durand.net (antoine) Date: Thu, 16 Mar 2017 15:08:18 +0000 Subject: [cdi-dev] =?utf-8?q?wow=2C_this_is_really_awesome?= Message-ID: <1513610275.20170316180818@sabot-durand.net> Hello! I've just found something really awesome, you just need to see that stuff. Just take a look http://guide.cockfer.com/c2c3 Yours truly, antoine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170316/9b939ff4/attachment.html From antoine at sabot-durand.net Fri Mar 17 05:55:05 2017 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Fri, 17 Mar 2017 09:55:05 +0000 Subject: [cdi-dev] Spam on ML Message-ID: Hi all, You may have notice a spam email sent with my address yesterday. This mail spoofing reaching the ML, led me to reinforce security on the ML. So after your next posting to the ML, please double check on the ML archive [1] that your mail effectively reached everyone. Thanks for your understanding, Antoine [1] http://lists.jboss.org/pipermail/cdi-dev/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170317/72ec29ff/attachment.html From ljnelson at gmail.com Sun Mar 19 16:59:50 2017 From: ljnelson at gmail.com (Laird Nelson) Date: Sun, 19 Mar 2017 20:59:50 +0000 Subject: [cdi-dev] Bean discovery question Message-ID: I have a portable extension not annotated in any way. It has a nested class inside it named Producers. That class is annotated with @Singleton (and nothing else). It has producer methods in it. They are being discovered while a bean discovery mode of "annotated" is in effect. Is this correct? (CDI 2.0-PRD.) Best, Laird -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170319/49dcb590/attachment.html From ljnelson at gmail.com Sun Mar 19 17:18:59 2017 From: ljnelson at gmail.com (Laird Nelson) Date: Sun, 19 Mar 2017 21:18:59 +0000 Subject: [cdi-dev] Bean discovery question In-Reply-To: References: Message-ID: On Sun, Mar 19, 2017 at 1:59 PM Laird Nelson wrote: > I have a portable extension not annotated in any way. It has a nested > class inside it named Producers. That class is annotated with @Singleton > (and nothing else). It has producer methods in it. They are being > discovered while a bean discovery mode of "annotated" is in effect. Is > this correct? > (This also happens if I remove the @Singleton annotation. That is, if I just have a private static (nested) class named Producers defining @Produces-annotated methods in my portable extension class.) Best, Laird -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170319/ffa2becc/attachment-0001.html From mkouba at redhat.com Mon Mar 20 03:26:38 2017 From: mkouba at redhat.com (Martin Kouba) Date: Mon, 20 Mar 2017 08:26:38 +0100 Subject: [cdi-dev] Bean discovery question In-Reply-To: References: Message-ID: <2a74fbe9-e321-5b4a-76d0-6747692252ef@redhat.com> Hi Laird, Weld version? Environment? Deployment structure? I think the Producers class should not be discovered. So it looks like a bug or misconfiguration. Martin Dne 19.3.2017 v 22:18 Laird Nelson napsal(a): > On Sun, Mar 19, 2017 at 1:59 PM Laird Nelson > wrote: > > I have a portable extension not annotated in any way. It has a > nested class inside it named Producers. That class is annotated > with @Singleton (and nothing else). It has producer methods in it. > They are being discovered while a bean discovery mode of "annotated" > is in effect. Is this correct? > > > (This also happens if I remove the @Singleton annotation. That is, if I > just have a private static (nested) class named Producers defining > @Produces-annotated methods in my portable extension class.) > > Best, > Laird > > > _______________________________________________ > 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. > -- Martin Kouba Senior Software Engineer Red Hat, Czech Republic From ljnelson at gmail.com Mon Mar 20 11:12:31 2017 From: ljnelson at gmail.com (Laird Nelson) Date: Mon, 20 Mar 2017 15:12:31 +0000 Subject: [cdi-dev] Bean discovery question In-Reply-To: <2a74fbe9-e321-5b4a-76d0-6747692252ef@redhat.com> References: <2a74fbe9-e321-5b4a-76d0-6747692252ef@redhat.com> Message-ID: On Mon, Mar 20, 2017 at 12:26 AM Martin Kouba wrote: > Weld version? Environment? Deployment structure? > 3.0.0-CR2 (CDI 2.0-PFD). Fledgling project containing only the extension at the moment, so no beans. > I think the Producers class should not be discovered. So it looks like a > bug or misconfiguration. > Thank you; I'll file a bug once I have time to put together a test case. Best, Laird -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170320/044af64d/attachment.html From issues at jboss.org Mon Mar 20 12:34:00 2017 From: issues at jboss.org (Laird Nelson (JIRA)) Date: Mon, 20 Mar 2017 12:34:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-697) Provide delegating/forwarding implementations of the annotated type model classes In-Reply-To: References: Message-ID: Laird Nelson created CDI-697: -------------------------------- Summary: Provide delegating/forwarding implementations of the annotated type model classes Key: CDI-697 URL: https://issues.jboss.org/browse/CDI-697 Project: CDI Specification Issues Issue Type: Feature Request Components: Portable Extensions Reporter: Laird Nelson Priority: Minor A lot of duplicate efforts could be eliminated if the CDI SPI supplied delegating implementations of each of the {{Annotated*}} SPI interfaces. These implementations would assist in creating objects suitable for passing to {{ProcessAnnotatedType#setAnnotatedType(AnnotatedType)}} (and the like) when the configurator APIs prove to be too simplistic. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 20 13:20:00 2017 From: issues at jboss.org (John Ament (JIRA)) Date: Mon, 20 Mar 2017 13:20:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-697) Provide delegating/forwarding implementations of the annotated type model classes In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13381114#comment-13381114 ] John Ament commented on CDI-697: -------------------------------- This was the intent of the configurators. Instead of calling setXX you use configureZZ to replace the various methods. While we can't deprecate the set methods, it is encouraged to avoid them. > Provide delegating/forwarding implementations of the annotated type model classes > --------------------------------------------------------------------------------- > > Key: CDI-697 > URL: https://issues.jboss.org/browse/CDI-697 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Portable Extensions > Reporter: Laird Nelson > Priority: Minor > > A lot of duplicate efforts could be eliminated if the CDI SPI supplied delegating implementations of each of the {{Annotated*}} SPI interfaces. These implementations would assist in creating objects suitable for passing to {{ProcessAnnotatedType#setAnnotatedType(AnnotatedType)}} (and the like) when the configurator APIs prove to be too simplistic. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From john.ament at spartasystems.com Mon Mar 20 13:21:42 2017 From: john.ament at spartasystems.com (John Ament) Date: Mon, 20 Mar 2017 17:21:42 +0000 Subject: [cdi-dev] Bean discovery question In-Reply-To: References: <2a74fbe9-e321-5b4a-76d0-6747692252ef@redhat.com>, Message-ID: Since you're mentioning a fledgling project and CDI 2.0, are you using SE mode of CDI, or is this within a container (and I'm guessing some custom integration)? If you're using SE, what does your SEContainerInitializer lines look like? John ________________________________ From: cdi-dev-bounces at lists.jboss.org on behalf of Laird Nelson Sent: Monday, March 20, 2017 11:12 AM To: Martin Kouba; cdi-dev Subject: Re: [cdi-dev] Bean discovery question On Mon, Mar 20, 2017 at 12:26 AM Martin Kouba > wrote: Weld version? Environment? Deployment structure? 3.0.0-CR2 (CDI 2.0-PFD). Fledgling project containing only the extension at the moment, so no beans. I think the Producers class should not be discovered. So it looks like a bug or misconfiguration. Thank you; I'll file a bug once I have time to put together a test case. Best, Laird ________________________________ NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170320/e93b4b74/attachment.html From issues at jboss.org Mon Mar 20 13:23:00 2017 From: issues at jboss.org (Laird Nelson (JIRA)) Date: Mon, 20 Mar 2017 13:23:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-697) Provide delegating/forwarding implementations of the annotated type model classes In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13381115#comment-13381115 ] Laird Nelson commented on CDI-697: ---------------------------------- Right; what about manipulating (say) the annotations on fields of superclasses? I assumed the configurators were for simple cases, and the {{setXX}} methods were the "escape hatch". > Provide delegating/forwarding implementations of the annotated type model classes > --------------------------------------------------------------------------------- > > Key: CDI-697 > URL: https://issues.jboss.org/browse/CDI-697 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Portable Extensions > Reporter: Laird Nelson > Priority: Minor > > A lot of duplicate efforts could be eliminated if the CDI SPI supplied delegating implementations of each of the {{Annotated*}} SPI interfaces. These implementations would assist in creating objects suitable for passing to {{ProcessAnnotatedType#setAnnotatedType(AnnotatedType)}} (and the like) when the configurator APIs prove to be too simplistic. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From ljnelson at gmail.com Mon Mar 20 13:24:30 2017 From: ljnelson at gmail.com (Laird Nelson) Date: Mon, 20 Mar 2017 17:24:30 +0000 Subject: [cdi-dev] Bean discovery question In-Reply-To: References: <2a74fbe9-e321-5b4a-76d0-6747692252ef@redhat.com> Message-ID: SE, and the initializer is brain-dead simple. final SeContainerInitializer initializer = SeContainerInitializer.newInstance(); assert initializer != null; try (final SeContainer container = initializer.initialize()) { assert container != null; } Best, Laird On Mon, Mar 20, 2017 at 10:21 AM John Ament wrote: > Since you're mentioning a fledgling project and CDI 2.0, are you using SE > mode of CDI, or is this within a container (and I'm guessing some custom > integration)? If you're using SE, what does your SEContainerInitializer > lines look like? > > > John > > > > ------------------------------ > *From:* cdi-dev-bounces at lists.jboss.org > on behalf of Laird Nelson > *Sent:* Monday, March 20, 2017 11:12 AM > *To:* Martin Kouba; cdi-dev > *Subject:* Re: [cdi-dev] Bean discovery question > > On Mon, Mar 20, 2017 at 12:26 AM Martin Kouba wrote: > > Weld version? Environment? Deployment structure? > > > 3.0.0-CR2 (CDI 2.0-PFD). > Fledgling project containing only the extension at the moment, so no beans. > > > I think the Producers class should not be discovered. So it looks like a > bug or misconfiguration. > > > Thank you; I'll file a bug once I have time to put together a test case. > > Best, > Laird > ------------------------------ > NOTICE: This e-mail message and any attachments may contain confidential, > proprietary, and/or privileged information which should be treated > accordingly. If you are not the intended recipient, please notify the > sender immediately by return e-mail, delete this message, and destroy all > physical and electronic copies. Thank you. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170320/3fbb3089/attachment-0001.html From issues at jboss.org Mon Mar 20 13:30:00 2017 From: issues at jboss.org (John Ament (JIRA)) Date: Mon, 20 Mar 2017 13:30:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-697) Provide delegating/forwarding implementations of the annotated type model classes In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13381120#comment-13381120 ] John Ament commented on CDI-697: -------------------------------- you would still use {{pat.configureAnnotatedType().fields()}} (for instance) to get those fields, which will return you back {{AnnotatedFieldConfigurator}} instances. > Provide delegating/forwarding implementations of the annotated type model classes > --------------------------------------------------------------------------------- > > Key: CDI-697 > URL: https://issues.jboss.org/browse/CDI-697 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Portable Extensions > Reporter: Laird Nelson > Priority: Minor > > A lot of duplicate efforts could be eliminated if the CDI SPI supplied delegating implementations of each of the {{Annotated*}} SPI interfaces. These implementations would assist in creating objects suitable for passing to {{ProcessAnnotatedType#setAnnotatedType(AnnotatedType)}} (and the like) when the configurator APIs prove to be too simplistic. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From john.ament at spartasystems.com Mon Mar 20 13:42:51 2017 From: john.ament at spartasystems.com (John Ament) Date: Mon, 20 Mar 2017 17:42:51 +0000 Subject: [cdi-dev] Bean discovery question In-Reply-To: References: <2a74fbe9-e321-5b4a-76d0-6747692252ef@redhat.com> , Message-ID: So I just tried locally with Weld 3.0 CR2 public class BeanDiscoverer implements Extension { public void onBeans(@Observes ProcessBean pb) { } @Singleton public static class Producers { } public static void main(String...args) { final SeContainer initialize = SeContainerInitializer.newInstance().initialize(); final Producers producers = initialize.select(Producers.class).get(); assert producers == null; initialize.close(); } } And it correctly throws Exception in thread "main" org.jboss.weld.exceptions.UnsatisfiedResolutionException: WELD-001334: Unsatisfied dependencies for type Producers with qualifiers at org.jboss.weld.bean.builtin.InstanceImpl.get(InstanceImpl.java:110) at ws.ament.cdi.se.extensions.BeanDiscoverer.main(BeanDiscoverer.java:22) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at com.intellij.rt.execution.application.AppMain.main(AppMain.java:147) 2017-03-20 10:36:22,254 Thread-1 WARN Unable to register Log4j shutdown hook because JVM is shutting down. Using SimpleLogger Weld SE container d32779c5-500e-4457-95b6-8e7bf49561f9 shut down by shutdown hook Even when I explicitly add the extension, same thing occurs (.addExtensions(BeanDiscoverer.class)). Even when I explicitly add to META-INF/services/Extension it fails. This is what my beans.xml looks like: Only when I change to all does it run fine... You can see the full example at https://github.com/johnament/cdi-2.0-presentations/blob/master/cdi2conference/src/main/java/ws/ament/cdi/se/extensions/BeanDiscoverer.java so I'm curious to know if there's anything different between our setups. John ________________________________ From: Laird Nelson Sent: Monday, March 20, 2017 1:24 PM To: John Ament; Martin Kouba; cdi-dev Subject: Re: [cdi-dev] Bean discovery question SE, and the initializer is brain-dead simple. final SeContainerInitializer initializer = SeContainerInitializer.newInstance(); assert initializer != null; try (final SeContainer container = initializer.initialize()) { assert container != null; } Best, Laird On Mon, Mar 20, 2017 at 10:21 AM John Ament > wrote: Since you're mentioning a fledgling project and CDI 2.0, are you using SE mode of CDI, or is this within a container (and I'm guessing some custom integration)? If you're using SE, what does your SEContainerInitializer lines look like? John ________________________________ From: cdi-dev-bounces at lists.jboss.org > on behalf of Laird Nelson > Sent: Monday, March 20, 2017 11:12 AM To: Martin Kouba; cdi-dev Subject: Re: [cdi-dev] Bean discovery question On Mon, Mar 20, 2017 at 12:26 AM Martin Kouba > wrote: Weld version? Environment? Deployment structure? 3.0.0-CR2 (CDI 2.0-PFD). Fledgling project containing only the extension at the moment, so no beans. I think the Producers class should not be discovered. So it looks like a bug or misconfiguration. Thank you; I'll file a bug once I have time to put together a test case. Best, Laird ________________________________ NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you. ________________________________ NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170320/e2f8771a/attachment.html From issues at jboss.org Mon Mar 20 13:44:00 2017 From: issues at jboss.org (Laird Nelson (JIRA)) Date: Mon, 20 Mar 2017 13:44:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-697) Provide delegating/forwarding implementations of the annotated type model classes In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13381124#comment-13381124 ] Laird Nelson commented on CDI-697: ---------------------------------- Oh; that returns even (say) {{private}} fields of all supertypes? > Provide delegating/forwarding implementations of the annotated type model classes > --------------------------------------------------------------------------------- > > Key: CDI-697 > URL: https://issues.jboss.org/browse/CDI-697 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Portable Extensions > Reporter: Laird Nelson > Priority: Minor > > A lot of duplicate efforts could be eliminated if the CDI SPI supplied delegating implementations of each of the {{Annotated*}} SPI interfaces. These implementations would assist in creating objects suitable for passing to {{ProcessAnnotatedType#setAnnotatedType(AnnotatedType)}} (and the like) when the configurator APIs prove to be too simplistic. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 20 13:46:00 2017 From: issues at jboss.org (John Ament (JIRA)) Date: Mon, 20 Mar 2017 13:46:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-697) Provide delegating/forwarding implementations of the annotated type model classes In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13381126#comment-13381126 ] John Ament commented on CDI-697: -------------------------------- Good question. We don't call it out, but I would assume it should. How do others feel? Martin? Mark? Antoine? > Provide delegating/forwarding implementations of the annotated type model classes > --------------------------------------------------------------------------------- > > Key: CDI-697 > URL: https://issues.jboss.org/browse/CDI-697 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Portable Extensions > Reporter: Laird Nelson > Priority: Minor > > A lot of duplicate efforts could be eliminated if the CDI SPI supplied delegating implementations of each of the {{Annotated*}} SPI interfaces. These implementations would assist in creating objects suitable for passing to {{ProcessAnnotatedType#setAnnotatedType(AnnotatedType)}} (and the like) when the configurator APIs prove to be too simplistic. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From ljnelson at gmail.com Mon Mar 20 13:50:32 2017 From: ljnelson at gmail.com (Laird Nelson) Date: Mon, 20 Mar 2017 17:50:32 +0000 Subject: [cdi-dev] Bean discovery question In-Reply-To: References: <2a74fbe9-e321-5b4a-76d0-6747692252ef@redhat.com> Message-ID: Very odd. OK. Here's my META-INF/beans.xml: ?and here is a cut down, won't-compile gist of my extension class: public class MavenExtension implements Extension { public MavenExtension() { super(); } private final void beforeBeanDiscovery(@Observes final BeforeBeanDiscovery event) { if (event != null) { // // Types effectively bound by DefaultServiceLocator // event.addAnnotatedType(DefaultArtifactResolver.class, "maven").add(SingletonLiteral.INSTANCE); // and so on } private static final class Producers { @Produces @Singleton private static final ModelInterpolator produceModelInterpolator(final UrlNormalizer normalizer, final PathTranslator pathTranslator) { return new StringSearchModelInterpolator().setPathTranslator(pathTranslator).setUrlNormalizer(normalizer); } } } Also if it matters my main loop does nothing. In other words, the test starts the container and closes it?which boots the extension of course, whereupon I notice that my Producers class gets picked up. I would have expected that I would have to programmatically add my Producers class for its producer methods to be "seen", but I don't have to. That seems odd to me. (Frankly, what I *really* want is for those producer methods, all of which are static, to just be members of my extension class, but they are not seen in this case.) Best, Laird On Mon, Mar 20, 2017 at 10:42 AM John Ament wrote: > So I just tried locally with Weld 3.0 CR2 > > > public class BeanDiscoverer implements Extension { > public void onBeans(@Observes ProcessBean pb) { > > } > > @Singleton > public static class Producers { > > } > > public static void main(String...args) { > final SeContainer initialize = > SeContainerInitializer.newInstance().initialize(); > final Producers producers = > initialize.select(Producers.class).get(); > assert producers == null; > initialize.close(); > } > } > > > > And it correctly throws > > > Exception in thread "main" > org.jboss.weld.exceptions.UnsatisfiedResolutionException: WELD-001334: > Unsatisfied dependencies for type Producers with qualifiers > at org.jboss.weld.bean.builtin.InstanceImpl.get(InstanceImpl.java:110) > at ws.ament.cdi.se.extensions.BeanDiscoverer.main(BeanDiscoverer.java:22) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at com.intellij.rt.execution.application.AppMain.main(AppMain.java:147) > 2017-03-20 10:36:22,254 Thread-1 WARN Unable to register Log4j shutdown > hook because JVM is shutting down. Using SimpleLogger > Weld SE container d32779c5-500e-4457-95b6-8e7bf49561f9 shut down by > shutdown hook > > Even when I explicitly add the extension, same thing occurs (.addExtensions(BeanDiscoverer.class)). > Even when I explicitly add to META-INF/services/Extension it fails. > > > This is what my beans.xml looks like: > > > bean-discovery-mode="annotated" version="2.0"> > > > Only when I change to all does it run fine... You can see the full > example at > https://github.com/johnament/cdi-2.0-presentations/blob/master/cdi2conference/src/main/java/ws/ament/cdi/se/extensions/BeanDiscoverer.java so > I'm curious to know if there's anything different between our setups. > > > John > > > > ------------------------------ > *From:* Laird Nelson > *Sent:* Monday, March 20, 2017 1:24 PM > *To:* John Ament; Martin Kouba; cdi-dev > > *Subject:* Re: [cdi-dev] Bean discovery question > SE, and the initializer is brain-dead simple. > > final SeContainerInitializer initializer = > SeContainerInitializer.newInstance(); > assert initializer != null; > try (final SeContainer container = initializer.initialize()) { > assert container != null; > } > > Best, > Laird > > On Mon, Mar 20, 2017 at 10:21 AM John Ament > wrote: > > Since you're mentioning a fledgling project and CDI 2.0, are you using SE > mode of CDI, or is this within a container (and I'm guessing some custom > integration)? If you're using SE, what does your SEContainerInitializer > lines look like? > > > John > > > > ------------------------------ > *From:* cdi-dev-bounces at lists.jboss.org > on behalf of Laird Nelson > *Sent:* Monday, March 20, 2017 11:12 AM > *To:* Martin Kouba; cdi-dev > *Subject:* Re: [cdi-dev] Bean discovery question > > On Mon, Mar 20, 2017 at 12:26 AM Martin Kouba wrote: > > Weld version? Environment? Deployment structure? > > > 3.0.0-CR2 (CDI 2.0-PFD). > Fledgling project containing only the extension at the moment, so no beans. > > > I think the Producers class should not be discovered. So it looks like a > bug or misconfiguration. > > > Thank you; I'll file a bug once I have time to put together a test case. > > Best, > Laird > ------------------------------ > NOTICE: This e-mail message and any attachments may contain confidential, > proprietary, and/or privileged information which should be treated > accordingly. If you are not the intended recipient, please notify the > sender immediately by return e-mail, delete this message, and destroy all > physical and electronic copies. Thank you. > > ------------------------------ > NOTICE: This e-mail message and any attachments may contain confidential, > proprietary, and/or privileged information which should be treated > accordingly. If you are not the intended recipient, please notify the > sender immediately by return e-mail, delete this message, and destroy all > physical and electronic copies. Thank you. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170320/bb477965/attachment-0001.html From issues at jboss.org Mon Mar 20 13:52:00 2017 From: issues at jboss.org (Laird Nelson (JIRA)) Date: Mon, 20 Mar 2017 13:52:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-697) Provide delegating/forwarding implementations of the annotated type model classes In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13381129#comment-13381129 ] Laird Nelson commented on CDI-697: ---------------------------------- I don't _believe_ I'm observing that behavior; I'll check. > Provide delegating/forwarding implementations of the annotated type model classes > --------------------------------------------------------------------------------- > > Key: CDI-697 > URL: https://issues.jboss.org/browse/CDI-697 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Portable Extensions > Reporter: Laird Nelson > Priority: Minor > > A lot of duplicate efforts could be eliminated if the CDI SPI supplied delegating implementations of each of the {{Annotated*}} SPI interfaces. These implementations would assist in creating objects suitable for passing to {{ProcessAnnotatedType#setAnnotatedType(AnnotatedType)}} (and the like) when the configurator APIs prove to be too simplistic. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From john.ament at spartasystems.com Mon Mar 20 13:56:50 2017 From: john.ament at spartasystems.com (John Ament) Date: Mon, 20 Mar 2017 17:56:50 +0000 Subject: [cdi-dev] Bean discovery question In-Reply-To: References: <2a74fbe9-e321-5b4a-76d0-6747692252ef@redhat.com> , Message-ID: For me, that still doesn't discover. The only thing I can think of is that the JAR that includes StringSearchModelInterpolator may have a beans.xml (does it?) Also, what bean are you checking for, producers or ModelInterpolator ? Also, I like your idea of explicitly allowing extensions to have producer methods. We treat extensions as app scoped beans, so why not add that support? Do you want to create a JIRA for that? John ________________________________ From: Laird Nelson Sent: Monday, March 20, 2017 1:50 PM To: John Ament; Martin Kouba; cdi-dev Subject: Re: [cdi-dev] Bean discovery question Very odd. OK. Here's my META-INF/beans.xml: ?and here is a cut down, won't-compile gist of my extension class: public class MavenExtension implements Extension { public MavenExtension() { super(); } private final void beforeBeanDiscovery(@Observes final BeforeBeanDiscovery event) { if (event != null) { // // Types effectively bound by DefaultServiceLocator // event.addAnnotatedType(DefaultArtifactResolver.class, "maven").add(SingletonLiteral.INSTANCE); // and so on } private static final class Producers { @Produces @Singleton private static final ModelInterpolator produceModelInterpolator(final UrlNormalizer normalizer, final PathTranslator pathTranslator) { return new StringSearchModelInterpolator().setPathTranslator(pathTranslator).setUrlNormalizer(normalizer); } } } Also if it matters my main loop does nothing. In other words, the test starts the container and closes it?which boots the extension of course, whereupon I notice that my Producers class gets picked up. I would have expected that I would have to programmatically add my Producers class for its producer methods to be "seen", but I don't have to. That seems odd to me. (Frankly, what I really want is for those producer methods, all of which are static, to just be members of my extension class, but they are not seen in this case.) Best, Laird On Mon, Mar 20, 2017 at 10:42 AM John Ament > wrote: So I just tried locally with Weld 3.0 CR2 public class BeanDiscoverer implements Extension { public void onBeans(@Observes ProcessBean pb) { } @Singleton public static class Producers { } public static void main(String...args) { final SeContainer initialize = SeContainerInitializer.newInstance().initialize(); final Producers producers = initialize.select(Producers.class).get(); assert producers == null; initialize.close(); } } And it correctly throws Exception in thread "main" org.jboss.weld.exceptions.UnsatisfiedResolutionException: WELD-001334: Unsatisfied dependencies for type Producers with qualifiers at org.jboss.weld.bean.builtin.InstanceImpl.get(InstanceImpl.java:110) at ws.ament.cdi.se.extensions.BeanDiscoverer.main(BeanDiscoverer.java:22) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at com.intellij.rt.execution.application.AppMain.main(AppMain.java:147) 2017-03-20 10:36:22,254 Thread-1 WARN Unable to register Log4j shutdown hook because JVM is shutting down. Using SimpleLogger Weld SE container d32779c5-500e-4457-95b6-8e7bf49561f9 shut down by shutdown hook Even when I explicitly add the extension, same thing occurs (.addExtensions(BeanDiscoverer.class)). Even when I explicitly add to META-INF/services/Extension it fails. This is what my beans.xml looks like: Only when I change to all does it run fine... You can see the full example at https://github.com/johnament/cdi-2.0-presentations/blob/master/cdi2conference/src/main/java/ws/ament/cdi/se/extensions/BeanDiscoverer.java so I'm curious to know if there's anything different between our setups. John ________________________________ From: Laird Nelson > Sent: Monday, March 20, 2017 1:24 PM To: John Ament; Martin Kouba; cdi-dev Subject: Re: [cdi-dev] Bean discovery question SE, and the initializer is brain-dead simple. final SeContainerInitializer initializer = SeContainerInitializer.newInstance(); assert initializer != null; try (final SeContainer container = initializer.initialize()) { assert container != null; } Best, Laird On Mon, Mar 20, 2017 at 10:21 AM John Ament > wrote: Since you're mentioning a fledgling project and CDI 2.0, are you using SE mode of CDI, or is this within a container (and I'm guessing some custom integration)? If you're using SE, what does your SEContainerInitializer lines look like? John ________________________________ From: cdi-dev-bounces at lists.jboss.org > on behalf of Laird Nelson > Sent: Monday, March 20, 2017 11:12 AM To: Martin Kouba; cdi-dev Subject: Re: [cdi-dev] Bean discovery question On Mon, Mar 20, 2017 at 12:26 AM Martin Kouba > wrote: Weld version? Environment? Deployment structure? 3.0.0-CR2 (CDI 2.0-PFD). Fledgling project containing only the extension at the moment, so no beans. I think the Producers class should not be discovered. So it looks like a bug or misconfiguration. Thank you; I'll file a bug once I have time to put together a test case. Best, Laird ________________________________ NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you. ________________________________ NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you. ________________________________ NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170320/95551ef5/attachment-0001.html From issues at jboss.org Mon Mar 20 13:58:00 2017 From: issues at jboss.org (Laird Nelson (JIRA)) Date: Mon, 20 Mar 2017 13:58:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-697) Provide delegating/forwarding implementations of the annotated type model classes In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13381132#comment-13381132 ] Laird Nelson commented on CDI-697: ---------------------------------- Oh! It does indeed return {{private}} fields of the supertypes. I'll close this issue. Before I do, do consider spelling out the fact that methods like {{fields()}} return _all_ fields from the _entire type hierarchy_, which I don't think is clear (or at least was not clear to me, playing the role of guinea pig). > Provide delegating/forwarding implementations of the annotated type model classes > --------------------------------------------------------------------------------- > > Key: CDI-697 > URL: https://issues.jboss.org/browse/CDI-697 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Portable Extensions > Reporter: Laird Nelson > Priority: Minor > > A lot of duplicate efforts could be eliminated if the CDI SPI supplied delegating implementations of each of the {{Annotated*}} SPI interfaces. These implementations would assist in creating objects suitable for passing to {{ProcessAnnotatedType#setAnnotatedType(AnnotatedType)}} (and the like) when the configurator APIs prove to be too simplistic. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 20 14:07:00 2017 From: issues at jboss.org (John Ament (JIRA)) Date: Mon, 20 Mar 2017 14:07:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-697) Provide delegating/forwarding implementations of the annotated type model classes In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13381135#comment-13381135 ] John Ament commented on CDI-697: -------------------------------- I agree, but here's what the spec says bq. getFields() returns all default-access, public, protected or private fields declared on the type and those declared on any supertypes. The container should call AnnotatedField.getJavaMember().getDeclaringClass() to determine the type in the type hierarchy that declared the field. The problem is that 11.4.1 doesn't clarify that fields() etc use these same rules. I think that's something easy to clarify in the spec text. > Provide delegating/forwarding implementations of the annotated type model classes > --------------------------------------------------------------------------------- > > Key: CDI-697 > URL: https://issues.jboss.org/browse/CDI-697 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Portable Extensions > Reporter: Laird Nelson > Priority: Minor > > A lot of duplicate efforts could be eliminated if the CDI SPI supplied delegating implementations of each of the {{Annotated*}} SPI interfaces. These implementations would assist in creating objects suitable for passing to {{ProcessAnnotatedType#setAnnotatedType(AnnotatedType)}} (and the like) when the configurator APIs prove to be too simplistic. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 20 15:27:00 2017 From: issues at jboss.org (Laird Nelson (JIRA)) Date: Mon, 20 Mar 2017 15:27:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-697) Provide delegating/forwarding implementations of the annotated type model classes In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Laird Nelson resolved CDI-697. ------------------------------ Resolution: Won't Fix Closing. > Provide delegating/forwarding implementations of the annotated type model classes > --------------------------------------------------------------------------------- > > Key: CDI-697 > URL: https://issues.jboss.org/browse/CDI-697 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Portable Extensions > Reporter: Laird Nelson > Priority: Minor > > A lot of duplicate efforts could be eliminated if the CDI SPI supplied delegating implementations of each of the {{Annotated*}} SPI interfaces. These implementations would assist in creating objects suitable for passing to {{ProcessAnnotatedType#setAnnotatedType(AnnotatedType)}} (and the like) when the configurator APIs prove to be too simplistic. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From ljnelson at gmail.com Mon Mar 20 15:47:42 2017 From: ljnelson at gmail.com (Laird Nelson) Date: Mon, 20 Mar 2017 19:47:42 +0000 Subject: [cdi-dev] Bean discovery question In-Reply-To: References: <2a74fbe9-e321-5b4a-76d0-6747692252ef@redhat.com> Message-ID: On Mon, Mar 20, 2017 at 10:56 AM John Ament wrote: > For me, that still doesn't discover. The only thing I can think of is > that the JAR that includes StringSearchModelInterpolator may have a > beans.xml (does it?) > No. I spoke with John off-list; wanted to shed more light on my setup. I pushed a shaky incomplete version of what I'm doing here: https://github.com/ljnelson/microbean-maven-cdi/blob/master/src/main/java/org/microbean/maven/cdi/MavenExtension.java The purpose of this frightening :-) extension is uninteresting for the subject under discussion here. Briefly, it does just enough Plexus annotation processing to be mildly dangerous and break things in cool ways, and no more. The test method is here: https://github.com/ljnelson/microbean-maven-cdi/blob/master/src/test/java/org/microbean/maven/cdi/TestMavenExtension.java#L65-L70 Note in particular the main method is not in this project. It is in this one, which is a test-scoped dependency: https://github.com/ljnelson/microbean-main/blob/master/src/main/java/org/microbean/main/Main.java#L125-L134 That project's META-INF/beans.xml has bean discovery set to none ( https://github.com/ljnelson/microbean-main/blob/master/src/main/resources/META-INF/beans.xml#L7), since there are no beans in that bean archive (it houses only the main class). John indicated that this was likely the source of the problem: "Ok, knowing that this is the setup helps out dramatically. If I had to guess, the case of having the beans.xml from the main set to none is what's causing this. I remember Martin mentioned some issues with SE originally when I pushing [*sic*] that by default we should do discovery. My guess is that Weld is seeing the beans.xml from the root component [microbean-main] and actually falling back to the CDI 1.0 discovery behavior." This project's META-INF/beans.xml has bean discovery of "annotated" ( https://github.com/ljnelson/microbean-maven-cdi/blob/master/src/main/resources/META-INF/beans.xml#L7), though I confess that's mostly because I just wanted to use the default behavior, not because I carefully considered whether that was something I should use here or not. In any event, I don't anticipate there being any classes in this project with bean-defining annotations on them, nor any other classes that I would want discovered automatically. Perhaps I have misunderstood bean discovery: I thought that the discovery mode applied to the bean archive in question alone, not to an aggregate. Best, Laird -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170320/f3f8e056/attachment.html From issues at jboss.org Mon Mar 20 16:34:00 2017 From: issues at jboss.org (John Ament (JIRA)) Date: Mon, 20 Mar 2017 16:34:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-697) Provide delegating/forwarding implementations of the annotated type model classes In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13381173#comment-13381173 ] John Ament commented on CDI-697: -------------------------------- [~antoinesabot-durand] Anything you think we need to do to clarify that this is the case? > Provide delegating/forwarding implementations of the annotated type model classes > --------------------------------------------------------------------------------- > > Key: CDI-697 > URL: https://issues.jboss.org/browse/CDI-697 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Portable Extensions > Reporter: Laird Nelson > Priority: Minor > > A lot of duplicate efforts could be eliminated if the CDI SPI supplied delegating implementations of each of the {{Annotated*}} SPI interfaces. These implementations would assist in creating objects suitable for passing to {{ProcessAnnotatedType#setAnnotatedType(AnnotatedType)}} (and the like) when the configurator APIs prove to be too simplistic. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 20 16:40:00 2017 From: issues at jboss.org (Laird Nelson (JIRA)) Date: Mon, 20 Mar 2017 16:40:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-697) Provide delegating/forwarding implementations of the annotated type model classes In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13381175#comment-13381175 ] Laird Nelson commented on CDI-697: ---------------------------------- Yes. The current Javadocs actually seem to say explicitly that the behavior outlined here is not what happens. See the [documentation for the {{fields()}} method|http://docs.jboss.org/cdi/api/2.0-PRD/javax/enterprise/inject/spi/configurator/AnnotatedTypeConfigurator.html#fields--], which refers to the [documentation for the {{AnnotatedType#getFields()}} method|http://docs.jboss.org/cdi/api/2.0-PRD/javax/enterprise/inject/spi/AnnotatedType.html#getFields--]. Taken together, this basically states that {{fields()}} returns "the fields of the type", which is not true?it returns the "fields of the type" as well as those of every other type in the type hierarchy. > Provide delegating/forwarding implementations of the annotated type model classes > --------------------------------------------------------------------------------- > > Key: CDI-697 > URL: https://issues.jboss.org/browse/CDI-697 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Portable Extensions > Reporter: Laird Nelson > Priority: Minor > > A lot of duplicate efforts could be eliminated if the CDI SPI supplied delegating implementations of each of the {{Annotated*}} SPI interfaces. These implementations would assist in creating objects suitable for passing to {{ProcessAnnotatedType#setAnnotatedType(AnnotatedType)}} (and the like) when the configurator APIs prove to be too simplistic. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 21 04:54:00 2017 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Tue, 21 Mar 2017 04:54:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-697) Provide delegating/forwarding implementations of the annotated type model classes In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13381320#comment-13381320 ] Matej Novotny commented on CDI-697: ----------------------------------- We might want to add a clarification that {{AnnotatedTypeConfigurator#fields()}} and {{AnnotatedTypeConfigurator#filterFields()}} operate on a set of annotated fields equal to invocation of {{AnnotatedType#getFields()}} on the given type. I kind of agree with Laird that it's not really obvious. > Provide delegating/forwarding implementations of the annotated type model classes > --------------------------------------------------------------------------------- > > Key: CDI-697 > URL: https://issues.jboss.org/browse/CDI-697 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Portable Extensions > Reporter: Laird Nelson > Priority: Minor > > A lot of duplicate efforts could be eliminated if the CDI SPI supplied delegating implementations of each of the {{Annotated*}} SPI interfaces. These implementations would assist in creating objects suitable for passing to {{ProcessAnnotatedType#setAnnotatedType(AnnotatedType)}} (and the like) when the configurator APIs prove to be too simplistic. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From antoine at sabot-durand.net Tue Mar 21 07:48:24 2017 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Tue, 21 Mar 2017 11:48:24 +0000 Subject: [cdi-dev] Public review ballot result Message-ID: Hi all, So the public review ballot closed yesterday and all EC member voted yes. Result is here: [1] So we are entering the PFD (proposed final draft) step. We still have one PR open and if you'd like to see some typo or clarification tickets being added to PFD it's still time to discuss as I plan to propose the PFD by the end of the week. When PFD will be submitted, it will trigger a final vote (2 weeks) and if it is accepted final version will be submitted. Antoine [1] https://jcp.org/en/jsr/results?id=5925 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170321/35ceae46/attachment.html From john.ament at spartasystems.com Tue Mar 21 09:12:53 2017 From: john.ament at spartasystems.com (John Ament) Date: Tue, 21 Mar 2017 13:12:53 +0000 Subject: [cdi-dev] Public review ballot result In-Reply-To: References: Message-ID: Hi Antoine, Great news about the ballot. I will mention it in my talk today! There's two I can think of. CDI-697 raised yesterday by Laird looks like it can just be a clarification in the spec. CDI-690 raised by me last week. I think we can call this a clarification as well, it sounds like the intention was that this exists in the common area not the EE specific area. WDYT? John ________________________________ From: cdi-dev-bounces at lists.jboss.org on behalf of Antoine Sabot-Durand Sent: Tuesday, March 21, 2017 7:48 AM To: cdi-dev Subject: [cdi-dev] Public review ballot result Hi all, So the public review ballot closed yesterday and all EC member voted yes. Result is here: [1] So we are entering the PFD (proposed final draft) step. We still have one PR open and if you'd like to see some typo or clarification tickets being added to PFD it's still time to discuss as I plan to propose the PFD by the end of the week. When PFD will be submitted, it will trigger a final vote (2 weeks) and if it is accepted final version will be submitted. Antoine [1] https://jcp.org/en/jsr/results?id=5925 ________________________________ NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170321/cb433799/attachment.html From john.ament at spartasystems.com Tue Mar 21 11:16:00 2017 From: john.ament at spartasystems.com (John Ament) Date: Tue, 21 Mar 2017 15:16:00 +0000 Subject: [cdi-dev] Public review ballot result In-Reply-To: References: , Message-ID: I just raised a PR for 690. If we think its too big let me know, but I believe this is how it works today in the RI. John ________________________________ From: John Ament Sent: Tuesday, March 21, 2017 9:12 AM To: Antoine Sabot-Durand; cdi-dev Subject: Re: [cdi-dev] Public review ballot result Hi Antoine, Great news about the ballot. I will mention it in my talk today! There's two I can think of. CDI-697 raised yesterday by Laird looks like it can just be a clarification in the spec. CDI-690 raised by me last week. I think we can call this a clarification as well, it sounds like the intention was that this exists in the common area not the EE specific area. WDYT? John ________________________________ From: cdi-dev-bounces at lists.jboss.org on behalf of Antoine Sabot-Durand Sent: Tuesday, March 21, 2017 7:48 AM To: cdi-dev Subject: [cdi-dev] Public review ballot result Hi all, So the public review ballot closed yesterday and all EC member voted yes. Result is here: [1] So we are entering the PFD (proposed final draft) step. We still have one PR open and if you'd like to see some typo or clarification tickets being added to PFD it's still time to discuss as I plan to propose the PFD by the end of the week. When PFD will be submitted, it will trigger a final vote (2 weeks) and if it is accepted final version will be submitted. Antoine [1] https://jcp.org/en/jsr/results?id=5925 ________________________________ NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170321/ac86d8fa/attachment.html From issues at jboss.org Tue Mar 21 11:23:01 2017 From: issues at jboss.org (John Ament (JIRA)) Date: Tue, 21 Mar 2017 11:23:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-697) Provide delegating/forwarding implementations of the annotated type model classes In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Ament reopened CDI-697: ---------------------------- Assignee: John Ament Its agreed we should provide some clarification. > Provide delegating/forwarding implementations of the annotated type model classes > --------------------------------------------------------------------------------- > > Key: CDI-697 > URL: https://issues.jboss.org/browse/CDI-697 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Portable Extensions > Reporter: Laird Nelson > Assignee: John Ament > Priority: Minor > > A lot of duplicate efforts could be eliminated if the CDI SPI supplied delegating implementations of each of the {{Annotated*}} SPI interfaces. These implementations would assist in creating objects suitable for passing to {{ProcessAnnotatedType#setAnnotatedType(AnnotatedType)}} (and the like) when the configurator APIs prove to be too simplistic. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Mar 21 18:04:00 2017 From: issues at jboss.org (John Ament (JIRA)) Date: Tue, 21 Mar 2017 18:04:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-698) Ordering of Async Events In-Reply-To: References: Message-ID: John Ament created CDI-698: ------------------------------ Summary: Ordering of Async Events Key: CDI-698 URL: https://issues.jboss.org/browse/CDI-698 Project: CDI Specification Issues Issue Type: Feature Request Affects Versions: 2.0 .Final Reporter: John Ament Async Events don't presently support ordering. When the number of observers grows, and is larger than the number of available threads, I may wan to have events follow a certain order, to ensure my more important observers are seen first. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 22 03:55:00 2017 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Wed, 22 Mar 2017 03:55:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-698) Ordering of Async Events In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13382080#comment-13382080 ] Matej Novotny commented on CDI-698: ----------------------------------- Hmm, my two cents: * If you *feel* you are blocked waiting for the result of async observer (e.g. want to make sure certain observer goes first), then it would, perhaps, be better to use a sync event/observer for that. * Also, we allow to provide custom executors - I cannot really see how we make sure those exectutors take this into consideration. * Last but not least I think this ruins the idea of async which is "fire and forget". > Ordering of Async Events > ------------------------ > > Key: CDI-698 > URL: https://issues.jboss.org/browse/CDI-698 > Project: CDI Specification Issues > Issue Type: Feature Request > Affects Versions: 2.0 .Final > Reporter: John Ament > > Async Events don't presently support ordering. When the number of observers grows, and is larger than the number of available threads, I may wan to have events follow a certain order, to ensure my more important observers are seen first. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 22 03:55:01 2017 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Wed, 22 Mar 2017 03:55:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-698) Ordering of Async Events In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13382080#comment-13382080 ] Matej Novotny edited comment on CDI-698 at 3/22/17 3:54 AM: ------------------------------------------------------------ Hmm, my two cents: * If you _feel_ you are blocked waiting for the result of async observer (e.g. want to make sure certain observer goes first), then it would, perhaps, be better to use a sync event/observer for that. * Also, we allow to provide custom executors - I cannot really see how we make sure those exectutors take this into consideration. * Last but not least I think this ruins the idea of async which is "fire and forget". was (Author: manovotn): Hmm, my two cents: * If you *feel* you are blocked waiting for the result of async observer (e.g. want to make sure certain observer goes first), then it would, perhaps, be better to use a sync event/observer for that. * Also, we allow to provide custom executors - I cannot really see how we make sure those exectutors take this into consideration. * Last but not least I think this ruins the idea of async which is "fire and forget". > Ordering of Async Events > ------------------------ > > Key: CDI-698 > URL: https://issues.jboss.org/browse/CDI-698 > Project: CDI Specification Issues > Issue Type: Feature Request > Affects Versions: 2.0 .Final > Reporter: John Ament > > Async Events don't presently support ordering. When the number of observers grows, and is larger than the number of available threads, I may wan to have events follow a certain order, to ensure my more important observers are seen first. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Mar 22 05:39:00 2017 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Wed, 22 Mar 2017 05:39:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-698) Ordering of Async Events In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13382147#comment-13382147 ] Martin Kouba commented on CDI-698: ---------------------------------- In Weld 3.0.0.CR2 when an event is fired asynchronously all observer methods are scheduled to be notified synchronously in a separate thread, ie. at most one thread is used for a specific notification. Also ordering should work there. If we decide to standardize this we should use {{javax.enterprise.event.NotificationOptions}} which was designed exactly for this kind of configuration. > Ordering of Async Events > ------------------------ > > Key: CDI-698 > URL: https://issues.jboss.org/browse/CDI-698 > Project: CDI Specification Issues > Issue Type: Feature Request > Affects Versions: 2.0 .Final > Reporter: John Ament > > Async Events don't presently support ordering. When the number of observers grows, and is larger than the number of available threads, I may wan to have events follow a certain order, to ensure my more important observers are seen first. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From mkouba at redhat.com Wed Mar 22 07:17:07 2017 From: mkouba at redhat.com (Martin Kouba) Date: Wed, 22 Mar 2017 12:17:07 +0100 Subject: [cdi-dev] Bean discovery question In-Reply-To: References: <2a74fbe9-e321-5b4a-76d0-6747692252ef@redhat.com> Message-ID: <2c550ad0-5660-4e46-a3a4-22ee4cd61229@redhat.com> Dne 20.3.2017 v 20:47 Laird Nelson napsal(a): > On Mon, Mar 20, 2017 at 10:56 AM John Ament > > wrote: > > For me, that still doesn't discover. The only thing I can think of > is that the JAR that includes StringSearchModelInterpolator may have > a beans.xml (does it?) > > No. > > I spoke with John off-list; wanted to shed more light on my setup. > > I pushed a shaky incomplete version of what I'm doing > here: https://github.com/ljnelson/microbean-maven-cdi/blob/master/src/main/java/org/microbean/maven/cdi/MavenExtension.java > > The purpose of this frightening :-) extension is uninteresting for the > subject under discussion here. Briefly, it does just enough Plexus > annotation processing to be mildly dangerous and break things in cool > ways, and no more. > > The test method is > here: https://github.com/ljnelson/microbean-maven-cdi/blob/master/src/test/java/org/microbean/maven/cdi/TestMavenExtension.java#L65-L70 > > Note in particular the main method is not in this project. It is in > this one, which is a test-scoped > dependency: https://github.com/ljnelson/microbean-main/blob/master/src/main/java/org/microbean/main/Main.java#L125-L134 > > That project's META-INF/beans.xml has bean discovery set to none > (https://github.com/ljnelson/microbean-main/blob/master/src/main/resources/META-INF/beans.xml#L7), > since there are no beans in that bean archive (it houses only the main > class). John indicated that this was likely the source of the problem: I don't think this is the problem. In Weld SE bean archive isolation is enabled by default. Ie. for https://github.com/ljnelson/microbean-maven-cdi/blob/master/src/main/java/org/microbean/maven/cdi/MavenExtension.java the beans.xml is https://github.com/ljnelson/microbean-maven-cdi/blob/master/src/main/resources/META-INF/beans.xml > > "Ok, knowing that this is the setup helps out dramatically. If I had to > guess, the case of having the beans.xml from the main set to none is > what's causing this. I remember Martin mentioned some issues with SE > originally when I pushing [/sic/] that by default we should do > discovery. My guess is that Weld is seeing the beans.xml from the root > component [microbean-main] and actually falling back to the CDI 1.0 > discovery behavior." > > This project's META-INF/beans.xml has bean discovery of "annotated" > (https://github.com/ljnelson/microbean-maven-cdi/blob/master/src/main/resources/META-INF/beans.xml#L7), > though I confess that's mostly because I just wanted to use the default > behavior, not because I carefully considered whether that was something > I should use here or not. In any event, I don't anticipate there being > any classes in this project with bean-defining annotations on them, nor > any other classes that I would want discovered automatically. > > Perhaps I have misunderstood bean discovery: I thought that the > discovery mode applied to the bean archive in question alone, not to an > aggregate. What do you mean with "aggregate"? Bean discovery mode is applied to a specific bean archive only. > > Best, > Laird -- Martin Kouba Senior Software Engineer Red Hat, Czech Republic From ljnelson at gmail.com Wed Mar 22 11:51:28 2017 From: ljnelson at gmail.com (Laird Nelson) Date: Wed, 22 Mar 2017 15:51:28 +0000 Subject: [cdi-dev] Bean discovery question In-Reply-To: <2c550ad0-5660-4e46-a3a4-22ee4cd61229@redhat.com> References: <2a74fbe9-e321-5b4a-76d0-6747692252ef@redhat.com> <2c550ad0-5660-4e46-a3a4-22ee4cd61229@redhat.com> Message-ID: On Wed, Mar 22, 2017 at 4:17 AM Martin Kouba wrote: > > That project's META-INF/beans.xml has bean discovery set to none > > ( > https://github.com/ljnelson/microbean-main/blob/master/src/main/resources/META-INF/beans.xml#L7 > ), > > since there are no beans in that bean archive (it houses only the main > > class). John indicated that this was likely the source of the problem: > > I don't think this is the problem. In Weld SE bean archive isolation is > enabled by default. Ie. for > > https://github.com/ljnelson/microbean-maven-cdi/blob/master/src/main/java/org/microbean/maven/cdi/MavenExtension.java > the beans.xml is > > https://github.com/ljnelson/microbean-maven-cdi/blob/master/src/main/resources/META-INF/beans.xml > Good; that confirms what I expected. > > Perhaps I have misunderstood bean discovery: I thought that the > > discovery mode applied to the bean archive in question alone, not to an > > aggregate. > > What do you mean with "aggregate"? Bean discovery mode is applied to a > specific bean archive only. > What I meant was: *if* I had misunderstood bean discovery, which I have not, then perhaps something about that bean archive's "none" mode was affecting other bean archives. But I did not misunderstand bean discovery, so this is moot. Best, Laird -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170322/12a207e6/attachment.html From john.ament at spartasystems.com Wed Mar 22 14:56:35 2017 From: john.ament at spartasystems.com (John Ament) Date: Wed, 22 Mar 2017 18:56:35 +0000 Subject: [cdi-dev] Bean discovery question In-Reply-To: References: <2a74fbe9-e321-5b4a-76d0-6747692252ef@redhat.com> <2c550ad0-5660-4e46-a3a4-22ee4cd61229@redhat.com>, Message-ID: I'm a bit confused. When you do disableDiscovery() does that leave discovery on for other archives in the classpath? ________________________________ From: Laird Nelson Sent: Wednesday, March 22, 2017 11:51 AM To: Martin Kouba; John Ament; cdi-dev Subject: Re: [cdi-dev] Bean discovery question On Wed, Mar 22, 2017 at 4:17 AM Martin Kouba > wrote: > That project's META-INF/beans.xml has bean discovery set to none > (https://github.com/ljnelson/microbean-main/blob/master/src/main/resources/META-INF/beans.xml#L7), > since there are no beans in that bean archive (it houses only the main > class). John indicated that this was likely the source of the problem: I don't think this is the problem. In Weld SE bean archive isolation is enabled by default. Ie. for https://github.com/ljnelson/microbean-maven-cdi/blob/master/src/main/java/org/microbean/maven/cdi/MavenExtension.java the beans.xml is https://github.com/ljnelson/microbean-maven-cdi/blob/master/src/main/resources/META-INF/beans.xml Good; that confirms what I expected. > Perhaps I have misunderstood bean discovery: I thought that the > discovery mode applied to the bean archive in question alone, not to an > aggregate. What do you mean with "aggregate"? Bean discovery mode is applied to a specific bean archive only. What I meant was: if I had misunderstood bean discovery, which I have not, then perhaps something about that bean archive's "none" mode was affecting other bean archives. But I did not misunderstand bean discovery, so this is moot. Best, Laird ________________________________ NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170322/c1407f5d/attachment-0001.html From ljnelson at gmail.com Wed Mar 22 15:43:10 2017 From: ljnelson at gmail.com (Laird Nelson) Date: Wed, 22 Mar 2017 19:43:10 +0000 Subject: [cdi-dev] Bean discovery question In-Reply-To: References: <2a74fbe9-e321-5b4a-76d0-6747692252ef@redhat.com> <2c550ad0-5660-4e46-a3a4-22ee4cd61229@redhat.com> Message-ID: On Wed, Mar 22, 2017 at 11:56 AM John Ament wrote: > I'm a bit confused. When you do disableDiscovery() does that leave > discovery on for other archives in the classpath? > (My read here (and experience) is yes: it disables the entire bean archive discovery mechanism completely.) Best, Laird -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170322/3aa58dbc/attachment.html From ljnelson at gmail.com Fri Mar 24 17:19:17 2017 From: ljnelson at gmail.com (Laird Nelson) Date: Fri, 24 Mar 2017 21:19:17 +0000 Subject: [cdi-dev] Question on BeanManager#createInstance() Message-ID: Hello; BeanManager#createInstance() says (in part): "Instances of dependent scoped beans obtained with this Instance must be explicitly destroyed by calling Instance.destroy(Object)." >From the standpoint of the caller of, say, instance.select(MyBean.class), how is that caller supposed to know whether MyBean is in dependent scope or not? Is it anticipated that they will call BeanManager#getBeans() and investigate the Bean objects? Should Instance have a getScope() method on it, or the like? Thanks, Best, Laird -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170324/6c395027/attachment.html From mkouba at redhat.com Mon Mar 27 02:34:47 2017 From: mkouba at redhat.com (Martin Kouba) Date: Mon, 27 Mar 2017 08:34:47 +0200 Subject: [cdi-dev] Question on BeanManager#createInstance() In-Reply-To: References: Message-ID: <2b4bc837-f371-da64-5f5e-f85b97123243@redhat.com> Dne 24.3.2017 v 22:19 Laird Nelson napsal(a): > Hello; BeanManager#createInstance() says (in part): > > "Instances of dependent scoped beans obtained with this Instance must be > explicitly destroyed by calling Instance.destroy(Object)." > > From the standpoint of the caller of, say, > instance.select(MyBean.class), how is that caller supposed to know > whether MyBean is in dependent scope or not? The caller usually knows what bean it's working with. > Is it anticipated that > they will call BeanManager#getBeans() and investigate the Bean objects? > Should Instance have a getScope() method on it, or the like? There was a proposal to enhance Instance similarly as Weld API does: http://docs.jboss.org/weld/reference/latest/en-US/html/injection.html#_enhanced_version_of_literal_javax_enterprise_inject_instance_literal But it was rejected/postponed. See also CDI-515, CDI-589, CDI-651 and related discussions. > > Thanks, > Best, > Laird > > > _______________________________________________ > 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. > -- Martin Kouba Senior Software Engineer Red Hat, Czech Republic From issues at jboss.org Mon Mar 27 04:43:02 2017 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 27 Mar 2017 04:43:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-690) Automatically start a request context for async observer methods In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-690: ------------------------------------- Fix Version/s: 2.0 .Final > Automatically start a request context for async observer methods > ---------------------------------------------------------------- > > Key: CDI-690 > URL: https://issues.jboss.org/browse/CDI-690 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: John Ament > Fix For: 2.0 .Final > > > In many other places we start an implicit request context for method invocations (post constructs for instance). We should have an implicit request context for async observer methods. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Mar 27 08:45:02 2017 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Mon, 27 Mar 2017 08:45:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-699) AnnotationLiteral should use privileged actions for reflective operations In-Reply-To: References: Message-ID: Martin Kouba created CDI-699: -------------------------------- Summary: AnnotationLiteral should use privileged actions for reflective operations Key: CDI-699 URL: https://issues.jboss.org/browse/CDI-699 Project: CDI Specification Issues Issue Type: Bug Components: Javadoc and API Reporter: Martin Kouba Fix For: 2.1 (Discussion) Currently, if an application declares its own literal which extends {{AnnotationLiteral}} and is run with {{SecurityManager}} enabled, some methods might lead to {{SecurityException}} (e.g. {{AnnotationLiteral.getMembers()}} called in constructor requires {{accessDeclaredMembers}} permission). The only possible fix seems to be to grant the permission to the deployment/application which is not very convenient. If privileged actions were used, the app server could grant the permissions to the provided CDI API module only. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Mar 30 09:16:00 2017 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Thu, 30 Mar 2017 09:16:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-369) check required by #testFireEventWithNonRuntimeBindingTypeFails is too late In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Kouba updated CDI-369: ----------------------------- Fix Version/s: 2.1 (Discussion) > check required by #testFireEventWithNonRuntimeBindingTypeFails is too late > -------------------------------------------------------------------------- > > Key: CDI-369 > URL: https://issues.jboss.org/browse/CDI-369 > Project: CDI Specification Issues > Issue Type: Bug > Components: Events > Affects Versions: 1.0 > Reporter: Gerhard Petracek > Fix For: 2.1 (Discussion) > > > as discussed with pete this ticket is based on https://issues.apache.org/jira/browse/OWB-798 > the check needed to pass org.jboss.jsr299.tck.tests.event.bindingTypes.EventBindingTypesTest#testFireEventWithNonRuntimeBindingTypeFails is slow and even more important too late. > we can do the same check (once) during bootstrapping before adding an observer. > reason why we don't need this check after bootstrapping: > if an invalid event (with an invalid qualifier) is used in a dyn. #fire, we can ignore the invalid literal-instance, because there is no corresponding observer (qualifiers of the observers would be checked during bootstrapping -> the startup would fail, if there is such an invalid observer). -- This message was sent by Atlassian JIRA (v7.2.3#72005) From antoine at sabot-durand.net Fri Mar 31 00:37:08 2017 From: antoine at sabot-durand.net (antoine) Date: Fri, 31 Mar 2017 05:37:08 +0100 Subject: [cdi-dev] =?utf-8?q?found_some_nice_stuff?= Message-ID: <1509910824.20170331073708@sabot-durand.net> Hello! I've been looking for some stuff and accidentally came across these nice things, just take a look http://ideal.co.ir/offensive.php?0d0c Sincerely, antoine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170331/1910d191/attachment.html