From issues at jboss.org Sat Jun 2 06:07:00 2018 From: issues at jboss.org (arjan tijms (JIRA)) Date: Sat, 2 Jun 2018 06:07:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-492) Give ownership of servlet specific part to servlet specification In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13585866#comment-13585866 ] arjan tijms commented on CDI-492: --------------------------------- Coming back to this and reading this again, I'm not sure why everyone understands Greg's concerns. His concerns mostly seem to be about things that are not being asked: >More over, >GW> I'm concerned that by making CDI to servlet mapping a responsibility >GW> of the servlet container Greg seems to be concerned he has to initialise CD implementations, but that's not what's being asked here. > then we are going to have to do a >GW> container to CDI adaptation for every CDI implementation out there. This is just not the case here. It's a complete non-concern. What's being asked is a built-in bean/producer for the HttpServletRequest and other types, which can be done by a portable extension. >GW> The servlet specification already provides servlet container initializers, GW> which have all the power required for CDI implementations to implement GW> these CDI v Servlet cross concerns. This clearly shows the mismatch of what Greg seems to think is being asked and what's actually being asked. A Servlet container initialiser of course has nothing to do with a built-in bean/producer for a certain type. > Give ownership of servlet specific part to servlet specification > ---------------------------------------------------------------- > > Key: CDI-492 > URL: https://issues.jboss.org/browse/CDI-492 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Java EE integration > Reporter: Antoine Sabot-Durand > Fix For: 2.1 (Discussion) > > > [Section 3.8 of the spec|http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#additional_builtin_beans] places some requirements on CDI implementations when running with Servlet. To better suit user desires for modularity these requirements are better met by moving them to the Servlet spec. Specifically, > {quote} > A servlet container must provide the following built-in beans, all of which have qualifier @Default: > * a bean with bean type {{javax.servlet.http.HttpServletRequest}}, allowing injection of a reference to the HttpServletRequest > * a bean with bean type {{javax.servlet.http.HttpSession}}, allowing injection of a reference to the HttpSession, > * a bean with bean type {{javax.servlet.ServletContext}}, allowing injection of a reference to the ServletContext, > These beans are passivation capable dependencies, as defined in Passivation capable dependencies. > {quote} -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Sat Jun 2 06:11:00 2018 From: issues at jboss.org (arjan tijms (JIRA)) Date: Sat, 2 Jun 2018 06:11:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-709) Should injecting the HttpServletRequest consider all used wrappers? In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13585867#comment-13585867 ] arjan tijms commented on CDI-709: --------------------------------- This is indeed a very real problem and would be great if a solution could be found. Relates to CDI-492 The issue is perhaps that using public Servlet APIs a CDI implementation can not guarantee it gets the last wrapped request. Only the Servlet container itself has this information. Also consider the case where the request is being injected into a bean called from a Servlet filter. > Should injecting the HttpServletRequest consider all used wrappers? > ------------------------------------------------------------------- > > Key: CDI-709 > URL: https://issues.jboss.org/browse/CDI-709 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Java EE integration > Affects Versions: 2.0 .Final > Reporter: Marcel Witte > > For example see this bug report of rewrite: https://github.com/ocpsoft/rewrite/issues/235 > If you inject the HttpServletRequest: > {code:java} > @Inject > private HttpServletRequest request > {code} > then you do not get the latest created HttpServletRequestWrapper. > If the wrapper is modifying the request (like adding parameters), these changes would not be visible to the application code using this injected request. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Sat Jun 2 06:13:00 2018 From: issues at jboss.org (arjan tijms (JIRA)) Date: Sat, 2 Jun 2018 06:13:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-492) Give ownership of servlet specific part to servlet specification In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13585868#comment-13585868 ] arjan tijms commented on CDI-492: --------------------------------- See CDI-709 for another more practical reason why the producers should live in the Servlet spec. > Give ownership of servlet specific part to servlet specification > ---------------------------------------------------------------- > > Key: CDI-492 > URL: https://issues.jboss.org/browse/CDI-492 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Java EE integration > Reporter: Antoine Sabot-Durand > Fix For: 2.1 (Discussion) > > > [Section 3.8 of the spec|http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#additional_builtin_beans] places some requirements on CDI implementations when running with Servlet. To better suit user desires for modularity these requirements are better met by moving them to the Servlet spec. Specifically, > {quote} > A servlet container must provide the following built-in beans, all of which have qualifier @Default: > * a bean with bean type {{javax.servlet.http.HttpServletRequest}}, allowing injection of a reference to the HttpServletRequest > * a bean with bean type {{javax.servlet.http.HttpSession}}, allowing injection of a reference to the HttpSession, > * a bean with bean type {{javax.servlet.ServletContext}}, allowing injection of a reference to the ServletContext, > These beans are passivation capable dependencies, as defined in Passivation capable dependencies. > {quote} -- This message was sent by Atlassian JIRA (v7.5.0#75005) From emijiang6 at googlemail.com Sun Jun 3 18:56:42 2018 From: emijiang6 at googlemail.com (Emily Jiang) Date: Sun, 3 Jun 2018 23:56:42 +0100 Subject: [cdi-dev] [JBoss JIRA] (CDI-726) Deprecate before dropping CDI.setCDIProvider In-Reply-To: References: Message-ID: OSGi runtime integator uses this. Romain, as explained by Martin, it is not designed by lib usage. Can you elaborate your use case here so that we can discuss further? Thanks Emily On Tue, May 29, 2018 at 4:24 PM, Martin Kouba (JIRA) wrote: > > [ https://issues.jboss.org/browse/CDI-726?page=com. > atlassian.jira.plugin.system.issuetabpanels:comment- > tabpanel&focusedCommentId=13583731#comment-13583731 ] > > Martin Kouba commented on CDI-726: > ---------------------------------- > > Hm, in CDI 1.2 it was only possible to set the provider once and I > remember there was some legal use case for this method (OSGi or something > like that). You're right that in CDI 2.0 anyone can set it anytime. The > logic seems to be modified in this commit: https://github.com/cdi-spec/ > cdi/commit/14cd36abb4d039212cf21521a46755b15f4e0a1c#diff- > 03e83766e93415c9ba16a9dfb42a5ac5. [~antoinesabot-durand] Do you remember > the details? > > > Deprecate before dropping CDI.setCDIProvider > > -------------------------------------------- > > > > Key: CDI-726 > > URL: https://issues.jboss.org/browse/CDI-726 > > Project: CDI Specification Issues > > Issue Type: Feature Request > > Components: Java SE Integration > > Affects Versions: 2.0 .Final > > Reporter: Romain Manni-Bucau > > Priority: Blocker > > > > CDI.setCDIProvider allows to switch the cdi provider at *any* time by > *anyone*. This lead to issues integrating multiple libraries doing it + is > not a real user facing API, it is actually a server internal. > > Proposal is to deprecate the method, remove its implementation (always > throw an IllegalStateException or just do a noop) and finally drop the > method after one or two releases since it can't really be used except for > very simple apps. > > > > -- > This message was sent by Atlassian JIRA > (v7.5.0#75005) > _______________________________________________ > 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. > -- Thanks Emily ================= Emily Jiang ejiang at apache.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20180603/56e81d2a/attachment.html From issues at jboss.org Sun Jun 3 18:58:00 2018 From: issues at jboss.org (Emily Jiang (JIRA)) Date: Sun, 3 Jun 2018 18:58:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-726) Deprecate before dropping CDI.setCDIProvider In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13585889#comment-13585889 ] Emily Jiang commented on CDI-726: --------------------------------- OSGi runtime integator uses this. Romain, as explained by Martin, it is not designed by lib usage. Can you elaborate your use case here so that we can discuss further? Thanks Emily On Tue, May 29, 2018 at 4:24 PM, Martin Kouba (JIRA) -- Thanks Emily ================= Emily Jiang ejiang at apache.org > Deprecate before dropping CDI.setCDIProvider > -------------------------------------------- > > Key: CDI-726 > URL: https://issues.jboss.org/browse/CDI-726 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Java SE Integration > Affects Versions: 2.0 .Final > Reporter: Romain Manni-Bucau > Priority: Blocker > > CDI.setCDIProvider allows to switch the cdi provider at *any* time by *anyone*. This lead to issues integrating multiple libraries doing it + is not a real user facing API, it is actually a server internal. > Proposal is to deprecate the method, remove its implementation (always throw an IllegalStateException or just do a noop) and finally drop the method after one or two releases since it can't really be used except for very simple apps. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jun 4 00:38:00 2018 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Mon, 4 Jun 2018 00:38:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-726) Deprecate before dropping CDI.setCDIProvider In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13585909#comment-13585909 ] Romain Manni-Bucau commented on CDI-726: ---------------------------------------- Please Emily stop saying these methods are for OSGi, this is just not true, technically you have at least 2 trivial alternatives to not pollute the spec with unsafe methods and still work in OSGi (once again geronimo and was did it for years so you can xheck not that far ;)). Maybe openliberty got lazy and used that bit it is an openliberty implementation leak in specs which is a very big concern if true. Concretely this method is a user method (since it is in the spec and whatever any javadoc could state) and is not thread safe and worse, it just doesnt work in general if the user, a framework or a 2nd container calls it after a first one. > Deprecate before dropping CDI.setCDIProvider > -------------------------------------------- > > Key: CDI-726 > URL: https://issues.jboss.org/browse/CDI-726 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Java SE Integration > Affects Versions: 2.0 .Final > Reporter: Romain Manni-Bucau > Priority: Blocker > > CDI.setCDIProvider allows to switch the cdi provider at *any* time by *anyone*. This lead to issues integrating multiple libraries doing it + is not a real user facing API, it is actually a server internal. > Proposal is to deprecate the method, remove its implementation (always throw an IllegalStateException or just do a noop) and finally drop the method after one or two releases since it can't really be used except for very simple apps. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jun 4 00:39:00 2018 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Mon, 4 Jun 2018 00:39:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-726) Deprecate before dropping CDI.setCDIProvider In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13585909#comment-13585909 ] Romain Manni-Bucau edited comment on CDI-726 at 6/4/18 12:38 AM: ----------------------------------------------------------------- Please Emily stop saying these methods are for OSGi, this is just not true, technically you have at least 2 trivial alternatives to not pollute the spec with unsafe methods and still work in OSGi (once again geronimo did it for years so you can check not that far ;)). Maybe openliberty got lazy and used that but iit is an openliberty implementation leak in specs which is a very big concern if true. Concretely this method is a user method (since it is in the spec and whatever any javadoc could state) and is not thread safe and worse, it just doesnt work in general if the user, a framework or a 2nd container calls it after a first one. was (Author: rmannibucau): Please Emily stop saying these methods are for OSGi, this is just not true, technically you have at least 2 trivial alternatives to not pollute the spec with unsafe methods and still work in OSGi (once again geronimo and was did it for years so you can xheck not that far ;)). Maybe openliberty got lazy and used that bit it is an openliberty implementation leak in specs which is a very big concern if true. Concretely this method is a user method (since it is in the spec and whatever any javadoc could state) and is not thread safe and worse, it just doesnt work in general if the user, a framework or a 2nd container calls it after a first one. > Deprecate before dropping CDI.setCDIProvider > -------------------------------------------- > > Key: CDI-726 > URL: https://issues.jboss.org/browse/CDI-726 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Java SE Integration > Affects Versions: 2.0 .Final > Reporter: Romain Manni-Bucau > Priority: Blocker > > CDI.setCDIProvider allows to switch the cdi provider at *any* time by *anyone*. This lead to issues integrating multiple libraries doing it + is not a real user facing API, it is actually a server internal. > Proposal is to deprecate the method, remove its implementation (always throw an IllegalStateException or just do a noop) and finally drop the method after one or two releases since it can't really be used except for very simple apps. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From asd at redhat.com Wed Jun 6 08:20:05 2018 From: asd at redhat.com (Antoine Sabot-Durand) Date: Wed, 6 Jun 2018 14:20:05 +0200 Subject: [cdi-dev] CDI Issues with security manager Message-ID: Hi All, Recent issue with AnnotationLiteral and security manager [1] require our immediate attention as it impact Weld and (probably OpenWebBeans) limiting security option. After internal discussion at Red Hat we are proposing to create a fix for CDI 2.0 API to fix this issue and the other one related to security manager [2]. We propose to discuss this point in the coming days in the EG and propose a PR to discuss the nature of the fix. If you have concern regarding this security fix let us know. Without negative feedback from you, we'd like to propose, review and merge these fixes in the coming 2 weeks. Thanks Antoine [1]https://issues.jboss.org/browse/CDI-699 [2]https://issues.jboss.org/browse/CDI-486 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20180606/05882c33/attachment-0001.html From issues at jboss.org Thu Jun 7 13:58:00 2018 From: issues at jboss.org (Jan Kalina (JIRA)) Date: Thu, 7 Jun 2018 13:58:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-727) CDI.current() should use privileged block In-Reply-To: References: Message-ID: Jan Kalina created CDI-727: ------------------------------ Summary: CDI.current() should use privileged block Key: CDI-727 URL: https://issues.jboss.org/browse/CDI-727 Project: CDI Specification Issues Issue Type: Bug Components: Javadoc and API Affects Versions: 2.0 .Final Reporter: Jan Kalina When deployment in container with security manager enabled try to use {{CDI.current()}} call, {{CDI}} class directly access JAR of CDI provider, because of which security manager requires from the deployment to have permission to read the JAR. *{{CDI.findAllProviders}} method should read the JAR in privileged block.* {code} java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.io.FilePermission" "/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-secman/1cfa62fc/jboss-eap-7.2/modules/system/layers/base/org/jboss/as/weld/main/wildfly-weld-7.2.0.CD12-redhat-2.jar" "read")" in code source "(vfs:/content/test.war/WEB-INF/classes )" of "ModuleClassLoader for Module "deployment.test.war" from Service Module Loader") at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:295) at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:192) at java.lang.SecurityManager.checkRead(SecurityManager.java:888) at org.wildfly.security.manager.WildFlySecurityManager.checkRead(WildFlySecurityManager.java:360) at sun.net.www.protocol.jar.JarFileFactory.getCachedJarFile(JarFileFactory.java:137) at sun.net.www.protocol.jar.JarFileFactory.get(JarFileFactory.java:81) at sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:122) at sun.net.www.protocol.jar.JarURLConnection.getInputStream(JarURLConnection.java:152) at java.net.URL.openStream(URL.java:1045) at javax.enterprise.inject.spi.CDI.findAllProviders(CDI.java:109) at javax.enterprise.inject.spi.CDI.current(CDI.java:53) at org.jboss.as.test.integration.ee.injection.support.jpa.beanManager.TestEntityListener.obtainFooViaCdiCurrent(TestEntityListener.java:97) {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Jun 7 13:59:00 2018 From: issues at jboss.org (Jan Kalina (JIRA)) Date: Thu, 7 Jun 2018 13:59:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-727) CDI.current() should use privileged block In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Kalina updated CDI-727: --------------------------- Description: When deployment in container with security manager enabled try to use {{CDI.current()}} call, {{CDI}} class directly access JAR of CDI provider, because of which security manager requires from the deployment to have permission to read the JAR. *{{CDI.findAllProviders}} method should read the JAR in privileged block.* (as discussed in WFLY-10125) {code} java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.io.FilePermission" "/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-secman/1cfa62fc/jboss-eap-7.2/modules/system/layers/base/org/jboss/as/weld/main/wildfly-weld-7.2.0.CD12-redhat-2.jar" "read")" in code source "(vfs:/content/test.war/WEB-INF/classes )" of "ModuleClassLoader for Module "deployment.test.war" from Service Module Loader") at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:295) at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:192) at java.lang.SecurityManager.checkRead(SecurityManager.java:888) at org.wildfly.security.manager.WildFlySecurityManager.checkRead(WildFlySecurityManager.java:360) at sun.net.www.protocol.jar.JarFileFactory.getCachedJarFile(JarFileFactory.java:137) at sun.net.www.protocol.jar.JarFileFactory.get(JarFileFactory.java:81) at sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:122) at sun.net.www.protocol.jar.JarURLConnection.getInputStream(JarURLConnection.java:152) at java.net.URL.openStream(URL.java:1045) at javax.enterprise.inject.spi.CDI.findAllProviders(CDI.java:109) at javax.enterprise.inject.spi.CDI.current(CDI.java:53) at org.jboss.as.test.integration.ee.injection.support.jpa.beanManager.TestEntityListener.obtainFooViaCdiCurrent(TestEntityListener.java:97) {code} was: When deployment in container with security manager enabled try to use {{CDI.current()}} call, {{CDI}} class directly access JAR of CDI provider, because of which security manager requires from the deployment to have permission to read the JAR. *{{CDI.findAllProviders}} method should read the JAR in privileged block.* {code} java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.io.FilePermission" "/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-secman/1cfa62fc/jboss-eap-7.2/modules/system/layers/base/org/jboss/as/weld/main/wildfly-weld-7.2.0.CD12-redhat-2.jar" "read")" in code source "(vfs:/content/test.war/WEB-INF/classes )" of "ModuleClassLoader for Module "deployment.test.war" from Service Module Loader") at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:295) at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:192) at java.lang.SecurityManager.checkRead(SecurityManager.java:888) at org.wildfly.security.manager.WildFlySecurityManager.checkRead(WildFlySecurityManager.java:360) at sun.net.www.protocol.jar.JarFileFactory.getCachedJarFile(JarFileFactory.java:137) at sun.net.www.protocol.jar.JarFileFactory.get(JarFileFactory.java:81) at sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:122) at sun.net.www.protocol.jar.JarURLConnection.getInputStream(JarURLConnection.java:152) at java.net.URL.openStream(URL.java:1045) at javax.enterprise.inject.spi.CDI.findAllProviders(CDI.java:109) at javax.enterprise.inject.spi.CDI.current(CDI.java:53) at org.jboss.as.test.integration.ee.injection.support.jpa.beanManager.TestEntityListener.obtainFooViaCdiCurrent(TestEntityListener.java:97) {code} > CDI.current() should use privileged block > ----------------------------------------- > > Key: CDI-727 > URL: https://issues.jboss.org/browse/CDI-727 > Project: CDI Specification Issues > Issue Type: Bug > Components: Javadoc and API > Affects Versions: 2.0 .Final > Reporter: Jan Kalina > > When deployment in container with security manager enabled try to use {{CDI.current()}} call, {{CDI}} class directly access JAR of CDI provider, because of which security manager requires from the deployment to have permission to read the JAR. > *{{CDI.findAllProviders}} method should read the JAR in privileged block.* > (as discussed in WFLY-10125) > {code} > java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.io.FilePermission" "/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-secman/1cfa62fc/jboss-eap-7.2/modules/system/layers/base/org/jboss/as/weld/main/wildfly-weld-7.2.0.CD12-redhat-2.jar" "read")" in code source "(vfs:/content/test.war/WEB-INF/classes )" of "ModuleClassLoader for Module "deployment.test.war" from Service Module Loader") > at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:295) > at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:192) > at java.lang.SecurityManager.checkRead(SecurityManager.java:888) > at org.wildfly.security.manager.WildFlySecurityManager.checkRead(WildFlySecurityManager.java:360) > at sun.net.www.protocol.jar.JarFileFactory.getCachedJarFile(JarFileFactory.java:137) > at sun.net.www.protocol.jar.JarFileFactory.get(JarFileFactory.java:81) > at sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:122) > at sun.net.www.protocol.jar.JarURLConnection.getInputStream(JarURLConnection.java:152) > at java.net.URL.openStream(URL.java:1045) > at javax.enterprise.inject.spi.CDI.findAllProviders(CDI.java:109) > at javax.enterprise.inject.spi.CDI.current(CDI.java:53) > at org.jboss.as.test.integration.ee.injection.support.jpa.beanManager.TestEntityListener.obtainFooViaCdiCurrent(TestEntityListener.java:97) > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Fri Jun 8 16:14:00 2018 From: issues at jboss.org (Sanne Grinovero (JIRA)) Date: Fri, 8 Jun 2018 16:14:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-728) The CDI specification javadoc is setting lang=french in the headers In-Reply-To: References: Message-ID: Sanne Grinovero created CDI-728: ----------------------------------- Summary: The CDI specification javadoc is setting lang=french in the headers Key: CDI-728 URL: https://issues.jboss.org/browse/CDI-728 Project: CDI Specification Issues Issue Type: Clarification Components: Javadoc and API Affects Versions: 2.0 .Final Reporter: Sanne Grinovero Priority: Trivial The page http://docs.jboss.org/cdi/api/2.0/ is setting {noformat} {noformat} However the content seems to be in English. It's a bit annoying as each time I open it my browser kicks in with a popup to ask if I want it to translate for me. I guess there are too many native French speakers on the team to have noticed ;) Thanks -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Fri Jun 8 16:19:00 2018 From: issues at jboss.org (Emmanuel Bernard (JIRA)) Date: Fri, 8 Jun 2018 16:19:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-728) The CDI specification javadoc is setting lang=french in the headers In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13588893#comment-13588893 ] Emmanuel Bernard commented on CDI-728: -------------------------------------- The proper approach to fix this bug is to translate it to French. Everything else would be a lazy hack. > The CDI specification javadoc is setting lang=french in the headers > ------------------------------------------------------------------- > > Key: CDI-728 > URL: https://issues.jboss.org/browse/CDI-728 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Javadoc and API > Affects Versions: 2.0 .Final > Reporter: Sanne Grinovero > Priority: Trivial > > The page http://docs.jboss.org/cdi/api/2.0/ is setting > {noformat} > > {noformat} > However the content seems to be in English. > It's a bit annoying as each time I open it my browser kicks in with a popup to ask if I want it to translate for me. > I guess there are too many native French speakers on the team to have noticed ;) > Thanks -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Wed Jun 13 03:54:00 2018 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Wed, 13 Jun 2018 03:54:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-728) The CDI specification javadoc is setting lang=french in the headers In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13590588#comment-13590588 ] Martin Kouba commented on CDI-728: ---------------------------------- bq. I guess there are too many native French speakers on the team to have noticed... [~sannegrinovero] Well, I know a word or two but I rarely read the javadoc in the browser and also my browser does not bother me with such popups ;-) [~epbernard] Should we only translate the javadoc or the whole spec? > The CDI specification javadoc is setting lang=french in the headers > ------------------------------------------------------------------- > > Key: CDI-728 > URL: https://issues.jboss.org/browse/CDI-728 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Javadoc and API > Affects Versions: 2.0 .Final > Reporter: Sanne Grinovero > Priority: Trivial > > The page http://docs.jboss.org/cdi/api/2.0/ is setting > {noformat} > > {noformat} > However the content seems to be in English. > It's a bit annoying as each time I open it my browser kicks in with a popup to ask if I want it to translate for me. > I guess there are too many native French speakers on the team to have noticed ;) > Thanks -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Wed Jun 13 10:16:00 2018 From: issues at jboss.org (Emmanuel Bernard (JIRA)) Date: Wed, 13 Jun 2018 10:16:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-728) The CDI specification javadoc is setting lang=french in the headers In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13590988#comment-13590988 ] Emmanuel Bernard commented on CDI-728: -------------------------------------- [~mkouba] you are raising a good point. If we truly want world domination, translating the spec is necessary. It will fix any inconsistencies anyway ahahahahah. > The CDI specification javadoc is setting lang=french in the headers > ------------------------------------------------------------------- > > Key: CDI-728 > URL: https://issues.jboss.org/browse/CDI-728 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Javadoc and API > Affects Versions: 2.0 .Final > Reporter: Sanne Grinovero > Priority: Trivial > > The page http://docs.jboss.org/cdi/api/2.0/ is setting > {noformat} > > {noformat} > However the content seems to be in English. > It's a bit annoying as each time I open it my browser kicks in with a popup to ask if I want it to translate for me. > I guess there are too many native French speakers on the team to have noticed ;) > Thanks -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jun 18 05:22:00 2018 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Mon, 18 Jun 2018 05:22:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-729) Async event not CompletionStage friendly In-Reply-To: References: Message-ID: Romain Manni-Bucau created CDI-729: -------------------------------------- Summary: Async event not CompletionStage friendly Key: CDI-729 URL: https://issues.jboss.org/browse/CDI-729 Project: CDI Specification Issues Issue Type: Feature Request Reporter: Romain Manni-Bucau The goal of this ticket is to enable user to get injected the completion future instead of the raw event and return another completion stage (generic type ignored) to enable the "chain" to be synched. Here is a sample: 1. fireAsync(persistEvent) 2. observer implementation does: return future.thenCompose(db::doAsyncPersist) 3. when the user gets back the result of the fireAsync the doAsyncPersist is completed. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jun 18 05:34:00 2018 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Mon, 18 Jun 2018 05:34:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-729) Async event not CompletionStage friendly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13592523#comment-13592523 ] Martin Kouba commented on CDI-729: ---------------------------------- Pls provide a more concrete example. I don't understand the description. > Async event not CompletionStage friendly > ---------------------------------------- > > Key: CDI-729 > URL: https://issues.jboss.org/browse/CDI-729 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Romain Manni-Bucau > > The goal of this ticket is to enable user to get injected the completion future instead of the raw event and return another completion stage (generic type ignored) to enable the "chain" to be synched. > Here is a sample: > 1. fireAsync(persistEvent) > 2. observer implementation does: return future.thenCompose(db::doAsyncPersist) > 3. when the user gets back the result of the fireAsync the doAsyncPersist is completed. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jun 18 08:30:00 2018 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Mon, 18 Jun 2018 08:30:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-729) Async event not CompletionStage friendly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13592649#comment-13592649 ] Romain Manni-Bucau commented on CDI-729: ---------------------------------------- If the observer execute some reactive code returning a CompletionStage there is no way in current spec to chain the CompletionStage of the processing to the event firing to ensure it is executed before returning. This makes the whole API quite useless and requires to define another way to fire event and compose them. {code} public CompletionStage save(Entity e); {code} {code} fireAsync(new Persist(entity)) {code} How do you compose both? What you want is: {code} CompletionStage onPersist(@ObserveAsync CompletionStage persist) { return persist.thenCompose(event -> repo.save(event.getEntity()); } {code} This way the fireAsync ensures the persistence is done: {code} event.fireAsync(new Persist(entity)) .thenApply(event -> log.info("{} persisted", event.getEntity())); {code} > Async event not CompletionStage friendly > ---------------------------------------- > > Key: CDI-729 > URL: https://issues.jboss.org/browse/CDI-729 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Romain Manni-Bucau > > The goal of this ticket is to enable user to get injected the completion future instead of the raw event and return another completion stage (generic type ignored) to enable the "chain" to be synched. > Here is a sample: > 1. fireAsync(persistEvent) > 2. observer implementation does: return future.thenCompose(db::doAsyncPersist) > 3. when the user gets back the result of the fireAsync the doAsyncPersist is completed. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jun 18 08:42:00 2018 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Mon, 18 Jun 2018 08:42:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-729) Async event not CompletionStage friendly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13592659#comment-13592659 ] Matej Novotny commented on CDI-729: ----------------------------------- [~rmannibucau] and what if you have multiple observers? How does the chain proceed there? Who goes first, who second? What if both observers expect to go first. > Async event not CompletionStage friendly > ---------------------------------------- > > Key: CDI-729 > URL: https://issues.jboss.org/browse/CDI-729 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Romain Manni-Bucau > > The goal of this ticket is to enable user to get injected the completion future instead of the raw event and return another completion stage (generic type ignored) to enable the "chain" to be synched. > Here is a sample: > 1. fireAsync(persistEvent) > 2. observer implementation does: return future.thenCompose(db::doAsyncPersist) > 3. when the user gets back the result of the fireAsync the doAsyncPersist is completed. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jun 18 08:47:00 2018 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Mon, 18 Jun 2018 08:47:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-729) Async event not CompletionStage friendly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13592664#comment-13592664 ] Romain Manni-Bucau commented on CDI-729: ---------------------------------------- You do the same for all, note that the proposal still returns the compltionstage with the event and not with the transformed payload, it is all about chaining, not transforming which is not possible with a loosely coupled chain. Issue I hit today in a modern app is that I can't use that mecanism natively because i return way before actual completion :(. > Async event not CompletionStage friendly > ---------------------------------------- > > Key: CDI-729 > URL: https://issues.jboss.org/browse/CDI-729 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Romain Manni-Bucau > > The goal of this ticket is to enable user to get injected the completion future instead of the raw event and return another completion stage (generic type ignored) to enable the "chain" to be synched. > Here is a sample: > 1. fireAsync(persistEvent) > 2. observer implementation does: return future.thenCompose(db::doAsyncPersist) > 3. when the user gets back the result of the fireAsync the doAsyncPersist is completed. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jun 18 08:56:00 2018 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Mon, 18 Jun 2018 08:56:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-729) Async event not CompletionStage friendly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13592677#comment-13592677 ] Martin Kouba commented on CDI-729: ---------------------------------- Well, observers are not designed to return anything. If you return some object it is just ignored. The reason is that observers were designed for decoupled communication. Ideally, observers should NOT depend on each other and emitters should NOT depend on observers either. In your example, the observer which saves the entity could throw an exception if something goes wrong so that the {{CompletionStage}} returned from {{fire()}} would end up exceptionally. Of course, if you need to perform the save action asynchronously you'd probably have to fire another async event when it's done and declare another async observer for this particular event. > Async event not CompletionStage friendly > ---------------------------------------- > > Key: CDI-729 > URL: https://issues.jboss.org/browse/CDI-729 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Romain Manni-Bucau > > The goal of this ticket is to enable user to get injected the completion future instead of the raw event and return another completion stage (generic type ignored) to enable the "chain" to be synched. > Here is a sample: > 1. fireAsync(persistEvent) > 2. observer implementation does: return future.thenCompose(db::doAsyncPersist) > 3. when the user gets back the result of the fireAsync the doAsyncPersist is completed. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jun 18 09:04:01 2018 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Mon, 18 Jun 2018 09:04:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-729) Async event not CompletionStage friendly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13592688#comment-13592688 ] Matej Novotny commented on CDI-729: ----------------------------------- Chaining can be done from the event-firing side, but the loose coupling is intentional. Observers often don't know about other observers as they may come from different bean archives. What you are trying to do could be done, for instance, with interceptors which seem a good match for logging after certain action was performed. But I suppose you are mainly trying events because they can be asynchronous. If that's the case, what Martin says is probably the go-to way and can be achieved 'natively'. > Async event not CompletionStage friendly > ---------------------------------------- > > Key: CDI-729 > URL: https://issues.jboss.org/browse/CDI-729 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Romain Manni-Bucau > > The goal of this ticket is to enable user to get injected the completion future instead of the raw event and return another completion stage (generic type ignored) to enable the "chain" to be synched. > Here is a sample: > 1. fireAsync(persistEvent) > 2. observer implementation does: return future.thenCompose(db::doAsyncPersist) > 3. when the user gets back the result of the fireAsync the doAsyncPersist is completed. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jun 18 09:11:01 2018 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Mon, 18 Jun 2018 09:11:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-729) Async event not CompletionStage friendly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13592701#comment-13592701 ] Romain Manni-Bucau commented on CDI-729: ---------------------------------------- I'm using events because I don't know the impl I will use (it is a library which is integrated with some 3rd party backend). The event is very handy on both side since it doesn't couple strongly both maintainers. The only blocking point is to have what CDI provides in synchronous mode: return when done. For completionstage it is providing a way to register another stage in the event chain. I can't put the chaining in the caller (because I don't know it) I can't throw an exception in the observer because the processing is done through a completionstage in another thread so it is missed and likely happen after the caller already returned anyway (timing issue). This is also why fire() (not async) doesn't work. I'm not sure I got your solution but sounds like registering a task to delay the completion of the returned stage is not a big deal (clearly not in impl side) and would help to be reactive in apps. > Async event not CompletionStage friendly > ---------------------------------------- > > Key: CDI-729 > URL: https://issues.jboss.org/browse/CDI-729 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Romain Manni-Bucau > > The goal of this ticket is to enable user to get injected the completion future instead of the raw event and return another completion stage (generic type ignored) to enable the "chain" to be synched. > Here is a sample: > 1. fireAsync(persistEvent) > 2. observer implementation does: return future.thenCompose(db::doAsyncPersist) > 3. when the user gets back the result of the fireAsync the doAsyncPersist is completed. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Tue Jun 19 08:20:00 2018 From: issues at jboss.org (Gordon Hutchison (JIRA)) Date: Tue, 19 Jun 2018 08:20:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-729) Async event not CompletionStage friendly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13593764#comment-13593764 ] Gordon Hutchison commented on CDI-729: -------------------------------------- This sort of approach could prove very useful in tryin to 'plug-together' a stream of CDI events from some other reactive stream. > Async event not CompletionStage friendly > ---------------------------------------- > > Key: CDI-729 > URL: https://issues.jboss.org/browse/CDI-729 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Romain Manni-Bucau > > The goal of this ticket is to enable user to get injected the completion future instead of the raw event and return another completion stage (generic type ignored) to enable the "chain" to be synched. > Here is a sample: > 1. fireAsync(persistEvent) > 2. observer implementation does: return future.thenCompose(db::doAsyncPersist) > 3. when the user gets back the result of the fireAsync the doAsyncPersist is completed. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Tue Jun 19 08:20:00 2018 From: issues at jboss.org (Gordon Hutchison (JIRA)) Date: Tue, 19 Jun 2018 08:20:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-729) Async event not CompletionStage friendly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13593764#comment-13593764 ] Gordon Hutchison edited comment on CDI-729 at 6/19/18 8:19 AM: --------------------------------------------------------------- This sort of approach could prove very useful in trying to 'plug-together' a stream of CDI events from some other reactive stream. was (Author: hutchig): This sort of approach could prove very useful in tryin to 'plug-together' a stream of CDI events from some other reactive stream. > Async event not CompletionStage friendly > ---------------------------------------- > > Key: CDI-729 > URL: https://issues.jboss.org/browse/CDI-729 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Romain Manni-Bucau > > The goal of this ticket is to enable user to get injected the completion future instead of the raw event and return another completion stage (generic type ignored) to enable the "chain" to be synched. > Here is a sample: > 1. fireAsync(persistEvent) > 2. observer implementation does: return future.thenCompose(db::doAsyncPersist) > 3. when the user gets back the result of the fireAsync the doAsyncPersist is completed. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Tue Jun 19 08:33:00 2018 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Tue, 19 Jun 2018 08:33:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-699) AnnotationLiteral should use privileged actions for reflective operations In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Kouba updated CDI-699: ----------------------------- Labels: security-manager (was: ) > 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 > Labels: security-manager > 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.5.0#75005) From issues at jboss.org Tue Jun 19 08:34:00 2018 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Tue, 19 Jun 2018 08:34:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-727) CDI.current() should use privileged block In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Kouba updated CDI-727: ----------------------------- Labels: security-manager (was: ) > CDI.current() should use privileged block > ----------------------------------------- > > Key: CDI-727 > URL: https://issues.jboss.org/browse/CDI-727 > Project: CDI Specification Issues > Issue Type: Bug > Components: Javadoc and API > Affects Versions: 2.0 .Final > Reporter: Jan Kalina > Labels: security-manager > > When deployment in container with security manager enabled try to use {{CDI.current()}} call, {{CDI}} class directly access JAR of CDI provider, because of which security manager requires from the deployment to have permission to read the JAR. > *{{CDI.findAllProviders}} method should read the JAR in privileged block.* > (as discussed in WFLY-10125) > {code} > java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.io.FilePermission" "/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-secman/1cfa62fc/jboss-eap-7.2/modules/system/layers/base/org/jboss/as/weld/main/wildfly-weld-7.2.0.CD12-redhat-2.jar" "read")" in code source "(vfs:/content/test.war/WEB-INF/classes )" of "ModuleClassLoader for Module "deployment.test.war" from Service Module Loader") > at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:295) > at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:192) > at java.lang.SecurityManager.checkRead(SecurityManager.java:888) > at org.wildfly.security.manager.WildFlySecurityManager.checkRead(WildFlySecurityManager.java:360) > at sun.net.www.protocol.jar.JarFileFactory.getCachedJarFile(JarFileFactory.java:137) > at sun.net.www.protocol.jar.JarFileFactory.get(JarFileFactory.java:81) > at sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:122) > at sun.net.www.protocol.jar.JarURLConnection.getInputStream(JarURLConnection.java:152) > at java.net.URL.openStream(URL.java:1045) > at javax.enterprise.inject.spi.CDI.findAllProviders(CDI.java:109) > at javax.enterprise.inject.spi.CDI.current(CDI.java:53) > at org.jboss.as.test.integration.ee.injection.support.jpa.beanManager.TestEntityListener.obtainFooViaCdiCurrent(TestEntityListener.java:97) > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Tue Jun 19 10:36:02 2018 From: issues at jboss.org (James Roper (JIRA)) Date: Tue, 19 Jun 2018 10:36:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-729) Async event not CompletionStage friendly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13593930#comment-13593930 ] James Roper commented on CDI-729: --------------------------------- The problem is that while it is possible for event publishers to fire an event asynchronously, that is, fire it and then continue processing immediately, and then asynchronously be notified when the event has been successfully observed by all the observers, there is no way for event observers to handle the event asynchronously, that is, they can't trigger some asynchronous IO, then return immediately from the method, and then asynchronously let the publisher know that they event was handled successfully. The only thing they can do is block. So, imagine I wanted to do a REST call using an asynchronous HTTP client, this REST call is done using the following method: {code:java} public CompletionStage makeRequest(Request request); {code} Now, if I implement an observer: {code:java} public void handleEvent(@ObservesAsync MyEvent event) { CompletionStage response = makeRequest(convertEventToRequest(event)); // Now what do I do? } {code} The problem with the above is that {{handleEvent}} is going to return before the REST request has been made, and so neither the status, nor backpressure, can be propagated back to the event publisher, unless of course I block on the {{CompletionStage}}, in which case, I'm no longer asynchronous. In order to support asynchronous propagation of backpressure and success signalling, CDI needs to support observer methods that return {{CompletionStage}} so that the methods can indicate when they are done handling the event, eg: {code:java} public CompletionStage handleEvent(@ObservesAsync MyEvent event) { CompletionStage response = makeRequest(convertEventToRequest(event)); return response; } {code} What the impact here is is when I publish the event using the following code: {code:java} CompletionStage fireEventResult = event.fireAsync(myEvent); {code} The {{fireEventResult}} completion stage won't be redeemed until after the {{CompletionStage}} returned by {{handleEvent}} is redeemed. This ensures that something publishing events asynchronously doesn't overwhelm the event handlers, by ensuring backpressure gets propagated, and also ensures that if there's an error that's asynchronously encountered, that the publisher can be aware of that. We're looking at integrating the MicroProfile messaging spec with CDI asynchronous events, and the ability to propagate backpressure asynchronously through event publishing is necessary before we can do that, otherwise an incoming message stream from a message broker could easily overwhelm a server. Our issue for tracking that feature is here: https://github.com/eclipse/microprofile-reactive/issues/30 > Async event not CompletionStage friendly > ---------------------------------------- > > Key: CDI-729 > URL: https://issues.jboss.org/browse/CDI-729 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Romain Manni-Bucau > > The goal of this ticket is to enable user to get injected the completion future instead of the raw event and return another completion stage (generic type ignored) to enable the "chain" to be synched. > Here is a sample: > 1. fireAsync(persistEvent) > 2. observer implementation does: return future.thenCompose(db::doAsyncPersist) > 3. when the user gets back the result of the fireAsync the doAsyncPersist is completed. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Tue Jun 19 10:50:00 2018 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Tue, 19 Jun 2018 10:50:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-729) Async event not CompletionStage friendly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13593943#comment-13593943 ] Romain Manni-Bucau commented on CDI-729: ---------------------------------------- Not sure what you mean. From the point you can return a CompletionStage and cdi container append it to the "waited" CompletionStage then you are good and can introduce the error handling you want in all layers (either the nested one for internal error handling and backpressure to the fireAsync caller or directly in the caller layer to get a default error handling. Indeed you can stack a lot of promises but it is what you intend with this pattern and if you care (means you dont trust observers) then you combine it with timeouts. In terms of implementations it is really <5mn with tests on cdi impl side. > Async event not CompletionStage friendly > ---------------------------------------- > > Key: CDI-729 > URL: https://issues.jboss.org/browse/CDI-729 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Romain Manni-Bucau > > The goal of this ticket is to enable user to get injected the completion future instead of the raw event and return another completion stage (generic type ignored) to enable the "chain" to be synched. > Here is a sample: > 1. fireAsync(persistEvent) > 2. observer implementation does: return future.thenCompose(db::doAsyncPersist) > 3. when the user gets back the result of the fireAsync the doAsyncPersist is completed. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Tue Jun 19 11:32:00 2018 From: issues at jboss.org (James Roper (JIRA)) Date: Tue, 19 Jun 2018 11:32:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-729) Async event not CompletionStage friendly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13593983#comment-13593983 ] James Roper commented on CDI-729: --------------------------------- Not sure that I understand, are you saying that what I described above is already supported today? Because, at least according to the Weld documentation, the only thing an observer can return today is {{void}}. And for back pressure, sure, the CDI implementation might be fast, but if an event handler is doing an operation on a database or remote service, and that is overloaded and taking 10 seconds to respond, how can that backpressure be propagated back to the thing that fired the event so that it doesn't continue firing events and increase the load on the already overloaded slow component? Currently, the only way is for the consumer to block the thread it's running on, that's not asynchronous. > Async event not CompletionStage friendly > ---------------------------------------- > > Key: CDI-729 > URL: https://issues.jboss.org/browse/CDI-729 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Romain Manni-Bucau > > The goal of this ticket is to enable user to get injected the completion future instead of the raw event and return another completion stage (generic type ignored) to enable the "chain" to be synched. > Here is a sample: > 1. fireAsync(persistEvent) > 2. observer implementation does: return future.thenCompose(db::doAsyncPersist) > 3. when the user gets back the result of the fireAsync the doAsyncPersist is completed. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Tue Jun 19 12:51:01 2018 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Tue, 19 Jun 2018 12:51:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-729) Async event not CompletionStage friendly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13594023#comment-13594023 ] Romain Manni-Bucau commented on CDI-729: ---------------------------------------- What I'm saying is that supporting to inject the completionstage event and use the returned completion stage (which can include a database call) for the "wait completion" logic on cdi side is trivial to impl and enable a lot of cases in user land so it does worth it a lot. Exception are a simple impl of backpressure with CompletionStage, even using bulkhead (different pool) works. This is clearly out of cdi (which is good) and already handled in the jre for the basic stuff. Advanced impl will use rx, hystrix or other impl and the link to CompletionStage. > Async event not CompletionStage friendly > ---------------------------------------- > > Key: CDI-729 > URL: https://issues.jboss.org/browse/CDI-729 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Romain Manni-Bucau > > The goal of this ticket is to enable user to get injected the completion future instead of the raw event and return another completion stage (generic type ignored) to enable the "chain" to be synched. > Here is a sample: > 1. fireAsync(persistEvent) > 2. observer implementation does: return future.thenCompose(db::doAsyncPersist) > 3. when the user gets back the result of the fireAsync the doAsyncPersist is completed. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Tue Jun 19 12:52:00 2018 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Tue, 19 Jun 2018 12:52:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-729) Async event not CompletionStage friendly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13594023#comment-13594023 ] Romain Manni-Bucau edited comment on CDI-729 at 6/19/18 12:51 PM: ------------------------------------------------------------------ What I'm saying is that supporting to inject the completionstage event and use the returned completion stage (which can include a database call) for the "wait completion" logic on cdi side is trivial to impl and enable a lot of cases in user land so it does worth it a lot. Exception are a simple impl of backpressure with CompletionStage, even using bulkhead (different pool) works. This is clearly out of cdi (which is good) and already handled in the jre for the basic stuff. Advanced impl will use rx, hystrix or other impl and the link to CompletionStage. Side note: you don't block the caller thread anyway ;) and if you want to append your db call you expect to block the async thread and this is the whole goal of that ticket. In practise I expect to use NIO at the end (remote http service in my case). was (Author: rmannibucau): What I'm saying is that supporting to inject the completionstage event and use the returned completion stage (which can include a database call) for the "wait completion" logic on cdi side is trivial to impl and enable a lot of cases in user land so it does worth it a lot. Exception are a simple impl of backpressure with CompletionStage, even using bulkhead (different pool) works. This is clearly out of cdi (which is good) and already handled in the jre for the basic stuff. Advanced impl will use rx, hystrix or other impl and the link to CompletionStage. > Async event not CompletionStage friendly > ---------------------------------------- > > Key: CDI-729 > URL: https://issues.jboss.org/browse/CDI-729 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Romain Manni-Bucau > > The goal of this ticket is to enable user to get injected the completion future instead of the raw event and return another completion stage (generic type ignored) to enable the "chain" to be synched. > Here is a sample: > 1. fireAsync(persistEvent) > 2. observer implementation does: return future.thenCompose(db::doAsyncPersist) > 3. when the user gets back the result of the fireAsync the doAsyncPersist is completed. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Tue Jun 19 13:17:00 2018 From: issues at jboss.org (James Roper (JIRA)) Date: Tue, 19 Jun 2018 13:17:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-729) Async event not CompletionStage friendly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13594037#comment-13594037 ] James Roper commented on CDI-729: --------------------------------- Ah, sorry I misunderstood. Why is a {{CompletionStage}} of the event needed to be passed to the method? To use it, the first thing that will need to be done is to attach a {{thenCompose}} to the completion stage. Why not have CDI do a {{thenCompose}} first, and then just invoke the method directly with the actual event? I don't see what value is gained by passing in a {{CompletionStage}}, an event when published is always available immediately, {{CompletionStage}} is for values that aren't available yet. > Async event not CompletionStage friendly > ---------------------------------------- > > Key: CDI-729 > URL: https://issues.jboss.org/browse/CDI-729 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Romain Manni-Bucau > > The goal of this ticket is to enable user to get injected the completion future instead of the raw event and return another completion stage (generic type ignored) to enable the "chain" to be synched. > Here is a sample: > 1. fireAsync(persistEvent) > 2. observer implementation does: return future.thenCompose(db::doAsyncPersist) > 3. when the user gets back the result of the fireAsync the doAsyncPersist is completed. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Tue Jun 19 13:20:00 2018 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Tue, 19 Jun 2018 13:20:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-729) Async event not CompletionStage friendly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13594038#comment-13594038 ] Romain Manni-Bucau commented on CDI-729: ---------------------------------------- To enable exceptionally and friends ;) > Async event not CompletionStage friendly > ---------------------------------------- > > Key: CDI-729 > URL: https://issues.jboss.org/browse/CDI-729 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Romain Manni-Bucau > > The goal of this ticket is to enable user to get injected the completion future instead of the raw event and return another completion stage (generic type ignored) to enable the "chain" to be synched. > Here is a sample: > 1. fireAsync(persistEvent) > 2. observer implementation does: return future.thenCompose(db::doAsyncPersist) > 3. when the user gets back the result of the fireAsync the doAsyncPersist is completed. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Wed Jun 20 04:18:00 2018 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Wed, 20 Jun 2018 04:18:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-729) Async event not CompletionStage friendly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13594267#comment-13594267 ] Martin Kouba commented on CDI-729: ---------------------------------- bq. To enable exceptionally and friends... [~rmannibucau] I still don't get it. What does the {{CompletionStage}} param represent and why is it needed? IMHO an observer should not care about what happened before/after its notification. Also note that async observers can be notified in parallel. I can see a lot of misunderstanding in the comments which indicates that this topic is difficult. But otherwise it's a good discussion. Keep going ;-). > Async event not CompletionStage friendly > ---------------------------------------- > > Key: CDI-729 > URL: https://issues.jboss.org/browse/CDI-729 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Romain Manni-Bucau > > The goal of this ticket is to enable user to get injected the completion future instead of the raw event and return another completion stage (generic type ignored) to enable the "chain" to be synched. > Here is a sample: > 1. fireAsync(persistEvent) > 2. observer implementation does: return future.thenCompose(db::doAsyncPersist) > 3. when the user gets back the result of the fireAsync the doAsyncPersist is completed. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Wed Jun 20 04:33:00 2018 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Wed, 20 Jun 2018 04:33:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-729) Async event not CompletionStage friendly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13594279#comment-13594279 ] Romain Manni-Bucau commented on CDI-729: ---------------------------------------- [~mkouba] how do you embrace the rich semantic without the stage as a param? If you drop it then it means you just use thenCompose which is a very small portion of the API. No acceptEither etc... If they are notified in parallel you get N stages and can replace the "submitted" stage by the returned one to notify the completion to the caller. This is the goal of the returned instance. In summary: param = rich compose API with fallback support etc, returned type = enrichment of the "wait" logic of the returned instance to the caller to give caller the guarantee all is execpted (= same guarantee than in sync mode but reactive style) > Async event not CompletionStage friendly > ---------------------------------------- > > Key: CDI-729 > URL: https://issues.jboss.org/browse/CDI-729 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Romain Manni-Bucau > > The goal of this ticket is to enable user to get injected the completion future instead of the raw event and return another completion stage (generic type ignored) to enable the "chain" to be synched. > Here is a sample: > 1. fireAsync(persistEvent) > 2. observer implementation does: return future.thenCompose(db::doAsyncPersist) > 3. when the user gets back the result of the fireAsync the doAsyncPersist is completed. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Wed Jun 20 04:34:00 2018 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Wed, 20 Jun 2018 04:34:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-729) Async event not CompletionStage friendly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13594279#comment-13594279 ] Romain Manni-Bucau edited comment on CDI-729 at 6/20/18 4:33 AM: ----------------------------------------------------------------- [~mkouba] how do you embrace the rich semantic without the stage as a param? If you drop it then it means you just use thenCompose which is a very small portion of the API. No acceptEither etc... If they are notified in parallel you get N stages and can replace the "submitted" stage by the returned one to notify the completion to the caller. This is the goal of the returned instance. In summary: param = rich compose API with fallback support etc, returned type = enrichment of the "wait" logic of the returned instance to the caller to give caller the guarantee all is done (= same guarantee than in sync mode but reactive style) was (Author: rmannibucau): [~mkouba] how do you embrace the rich semantic without the stage as a param? If you drop it then it means you just use thenCompose which is a very small portion of the API. No acceptEither etc... If they are notified in parallel you get N stages and can replace the "submitted" stage by the returned one to notify the completion to the caller. This is the goal of the returned instance. In summary: param = rich compose API with fallback support etc, returned type = enrichment of the "wait" logic of the returned instance to the caller to give caller the guarantee all is execpted (= same guarantee than in sync mode but reactive style) > Async event not CompletionStage friendly > ---------------------------------------- > > Key: CDI-729 > URL: https://issues.jboss.org/browse/CDI-729 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Romain Manni-Bucau > > The goal of this ticket is to enable user to get injected the completion future instead of the raw event and return another completion stage (generic type ignored) to enable the "chain" to be synched. > Here is a sample: > 1. fireAsync(persistEvent) > 2. observer implementation does: return future.thenCompose(db::doAsyncPersist) > 3. when the user gets back the result of the fireAsync the doAsyncPersist is completed. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Wed Jun 20 04:53:00 2018 From: issues at jboss.org (Benjamin Confino (JIRA)) Date: Wed, 20 Jun 2018 04:53:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-730) The order in which contexts are destroyed is undefined. In-Reply-To: References: Message-ID: Benjamin Confino created CDI-730: ------------------------------------ Summary: The order in which contexts are destroyed is undefined. Key: CDI-730 URL: https://issues.jboss.org/browse/CDI-730 Project: CDI Specification Issues Issue Type: Clarification Affects Versions: 2.0 .Final, 1.2.Final, 2.Future Reporter: Benjamin Confino Priority: Minor The order in which contexts are destroyed is not defined in the spec, I believe this should be made explicit. At present weld destroys conversation, request, then session context in that order. I think this should become the standard and written into the spec. For background there is this email by Martin Kouba: http://lists.jboss.org/pipermail/weld-dev/2018-June/003694.html -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Jun 21 06:58:00 2018 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Thu, 21 Jun 2018 06:58:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-699) AnnotationLiteral should use privileged actions for reflective operations In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-699: ------------------------------------- Fix Version/s: 2.0.SP1 (was: 2.1 (Discussion)) > 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 > Labels: security-manager > Fix For: 2.0.SP1 > > > 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.5.0#75005) From issues at jboss.org Thu Jun 21 06:58:00 2018 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Thu, 21 Jun 2018 06:58:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-727) CDI.current() should use privileged block In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-727: ------------------------------------- Fix Version/s: 2.0.SP1 > CDI.current() should use privileged block > ----------------------------------------- > > Key: CDI-727 > URL: https://issues.jboss.org/browse/CDI-727 > Project: CDI Specification Issues > Issue Type: Bug > Components: Javadoc and API > Affects Versions: 2.0 .Final > Reporter: Jan Kalina > Labels: security-manager > Fix For: 2.0.SP1 > > > When deployment in container with security manager enabled try to use {{CDI.current()}} call, {{CDI}} class directly access JAR of CDI provider, because of which security manager requires from the deployment to have permission to read the JAR. > *{{CDI.findAllProviders}} method should read the JAR in privileged block.* > (as discussed in WFLY-10125) > {code} > java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.io.FilePermission" "/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-secman/1cfa62fc/jboss-eap-7.2/modules/system/layers/base/org/jboss/as/weld/main/wildfly-weld-7.2.0.CD12-redhat-2.jar" "read")" in code source "(vfs:/content/test.war/WEB-INF/classes )" of "ModuleClassLoader for Module "deployment.test.war" from Service Module Loader") > at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:295) > at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:192) > at java.lang.SecurityManager.checkRead(SecurityManager.java:888) > at org.wildfly.security.manager.WildFlySecurityManager.checkRead(WildFlySecurityManager.java:360) > at sun.net.www.protocol.jar.JarFileFactory.getCachedJarFile(JarFileFactory.java:137) > at sun.net.www.protocol.jar.JarFileFactory.get(JarFileFactory.java:81) > at sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:122) > at sun.net.www.protocol.jar.JarURLConnection.getInputStream(JarURLConnection.java:152) > at java.net.URL.openStream(URL.java:1045) > at javax.enterprise.inject.spi.CDI.findAllProviders(CDI.java:109) > at javax.enterprise.inject.spi.CDI.current(CDI.java:53) > at org.jboss.as.test.integration.ee.injection.support.jpa.beanManager.TestEntityListener.obtainFooViaCdiCurrent(TestEntityListener.java:97) > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Jun 21 07:00:00 2018 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Thu, 21 Jun 2018 07:00:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-727) CDI.current() should use privileged block In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand reassigned CDI-727: ---------------------------------------- Assignee: Antoine Sabot-Durand > CDI.current() should use privileged block > ----------------------------------------- > > Key: CDI-727 > URL: https://issues.jboss.org/browse/CDI-727 > Project: CDI Specification Issues > Issue Type: Bug > Components: Javadoc and API > Affects Versions: 2.0 .Final > Reporter: Jan Kalina > Assignee: Antoine Sabot-Durand > Labels: security-manager > Fix For: 2.0.SP1 > > > When deployment in container with security manager enabled try to use {{CDI.current()}} call, {{CDI}} class directly access JAR of CDI provider, because of which security manager requires from the deployment to have permission to read the JAR. > *{{CDI.findAllProviders}} method should read the JAR in privileged block.* > (as discussed in WFLY-10125) > {code} > java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.io.FilePermission" "/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-secman/1cfa62fc/jboss-eap-7.2/modules/system/layers/base/org/jboss/as/weld/main/wildfly-weld-7.2.0.CD12-redhat-2.jar" "read")" in code source "(vfs:/content/test.war/WEB-INF/classes )" of "ModuleClassLoader for Module "deployment.test.war" from Service Module Loader") > at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:295) > at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:192) > at java.lang.SecurityManager.checkRead(SecurityManager.java:888) > at org.wildfly.security.manager.WildFlySecurityManager.checkRead(WildFlySecurityManager.java:360) > at sun.net.www.protocol.jar.JarFileFactory.getCachedJarFile(JarFileFactory.java:137) > at sun.net.www.protocol.jar.JarFileFactory.get(JarFileFactory.java:81) > at sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:122) > at sun.net.www.protocol.jar.JarURLConnection.getInputStream(JarURLConnection.java:152) > at java.net.URL.openStream(URL.java:1045) > at javax.enterprise.inject.spi.CDI.findAllProviders(CDI.java:109) > at javax.enterprise.inject.spi.CDI.current(CDI.java:53) > at org.jboss.as.test.integration.ee.injection.support.jpa.beanManager.TestEntityListener.obtainFooViaCdiCurrent(TestEntityListener.java:97) > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Jun 21 07:00:01 2018 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Thu, 21 Jun 2018 07:00:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-699) AnnotationLiteral should use privileged actions for reflective operations In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand reassigned CDI-699: ---------------------------------------- Assignee: Antoine Sabot-Durand > 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 > Assignee: Antoine Sabot-Durand > Labels: security-manager > Fix For: 2.0.SP1 > > > 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.5.0#75005) From issues at jboss.org Thu Jun 21 07:01:00 2018 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Thu, 21 Jun 2018 07:01:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-699) AnnotationLiteral should use privileged actions for reflective operations In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CDI-699 started by Antoine Sabot-Durand. ------------------------------------------------ > 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 > Assignee: Antoine Sabot-Durand > Labels: security-manager > Fix For: 2.0.SP1 > > > 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.5.0#75005) From arjan.tijms at gmail.com Sun Jun 24 07:54:17 2018 From: arjan.tijms at gmail.com (arjan tijms) Date: Sun, 24 Jun 2018 12:54:17 +0100 Subject: [cdi-dev] CDI 2.1 Message-ID: Hi there, Just wondering, is there any time planned for when to officially start the CDI 2.1 effort? Kind regards, Arjan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20180624/d36d9b3e/attachment.html From issues at jboss.org Mon Jun 25 07:28:00 2018 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 25 Jun 2018 07:28:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-727) CDI.current() should use privileged block In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CDI-727 started by Antoine Sabot-Durand. ------------------------------------------------ > CDI.current() should use privileged block > ----------------------------------------- > > Key: CDI-727 > URL: https://issues.jboss.org/browse/CDI-727 > Project: CDI Specification Issues > Issue Type: Bug > Components: Javadoc and API > Affects Versions: 2.0 .Final > Reporter: Jan Kalina > Assignee: Antoine Sabot-Durand > Labels: security-manager > Fix For: 2.0.SP1 > > > When deployment in container with security manager enabled try to use {{CDI.current()}} call, {{CDI}} class directly access JAR of CDI provider, because of which security manager requires from the deployment to have permission to read the JAR. > *{{CDI.findAllProviders}} method should read the JAR in privileged block.* > (as discussed in WFLY-10125) > {code} > java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.io.FilePermission" "/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-secman/1cfa62fc/jboss-eap-7.2/modules/system/layers/base/org/jboss/as/weld/main/wildfly-weld-7.2.0.CD12-redhat-2.jar" "read")" in code source "(vfs:/content/test.war/WEB-INF/classes )" of "ModuleClassLoader for Module "deployment.test.war" from Service Module Loader") > at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:295) > at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:192) > at java.lang.SecurityManager.checkRead(SecurityManager.java:888) > at org.wildfly.security.manager.WildFlySecurityManager.checkRead(WildFlySecurityManager.java:360) > at sun.net.www.protocol.jar.JarFileFactory.getCachedJarFile(JarFileFactory.java:137) > at sun.net.www.protocol.jar.JarFileFactory.get(JarFileFactory.java:81) > at sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:122) > at sun.net.www.protocol.jar.JarURLConnection.getInputStream(JarURLConnection.java:152) > at java.net.URL.openStream(URL.java:1045) > at javax.enterprise.inject.spi.CDI.findAllProviders(CDI.java:109) > at javax.enterprise.inject.spi.CDI.current(CDI.java:53) > at org.jboss.as.test.integration.ee.injection.support.jpa.beanManager.TestEntityListener.obtainFooViaCdiCurrent(TestEntityListener.java:97) > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jun 25 07:29:00 2018 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 25 Jun 2018 07:29:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-727) CDI.current() should use privileged block In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CDI-727 stopped by Antoine Sabot-Durand. ------------------------------------------------ > CDI.current() should use privileged block > ----------------------------------------- > > Key: CDI-727 > URL: https://issues.jboss.org/browse/CDI-727 > Project: CDI Specification Issues > Issue Type: Bug > Components: Javadoc and API > Affects Versions: 2.0 .Final > Reporter: Jan Kalina > Assignee: Antoine Sabot-Durand > Labels: security-manager > Fix For: 2.0.SP1 > > > When deployment in container with security manager enabled try to use {{CDI.current()}} call, {{CDI}} class directly access JAR of CDI provider, because of which security manager requires from the deployment to have permission to read the JAR. > *{{CDI.findAllProviders}} method should read the JAR in privileged block.* > (as discussed in WFLY-10125) > {code} > java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.io.FilePermission" "/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-secman/1cfa62fc/jboss-eap-7.2/modules/system/layers/base/org/jboss/as/weld/main/wildfly-weld-7.2.0.CD12-redhat-2.jar" "read")" in code source "(vfs:/content/test.war/WEB-INF/classes )" of "ModuleClassLoader for Module "deployment.test.war" from Service Module Loader") > at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:295) > at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:192) > at java.lang.SecurityManager.checkRead(SecurityManager.java:888) > at org.wildfly.security.manager.WildFlySecurityManager.checkRead(WildFlySecurityManager.java:360) > at sun.net.www.protocol.jar.JarFileFactory.getCachedJarFile(JarFileFactory.java:137) > at sun.net.www.protocol.jar.JarFileFactory.get(JarFileFactory.java:81) > at sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:122) > at sun.net.www.protocol.jar.JarURLConnection.getInputStream(JarURLConnection.java:152) > at java.net.URL.openStream(URL.java:1045) > at javax.enterprise.inject.spi.CDI.findAllProviders(CDI.java:109) > at javax.enterprise.inject.spi.CDI.current(CDI.java:53) > at org.jboss.as.test.integration.ee.injection.support.jpa.beanManager.TestEntityListener.obtainFooViaCdiCurrent(TestEntityListener.java:97) > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Tue Jun 26 06:11:00 2018 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 26 Jun 2018 06:11:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-727) CDI.current() should use privileged block In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CDI-727 started by Antoine Sabot-Durand. ------------------------------------------------ > CDI.current() should use privileged block > ----------------------------------------- > > Key: CDI-727 > URL: https://issues.jboss.org/browse/CDI-727 > Project: CDI Specification Issues > Issue Type: Bug > Components: Javadoc and API > Affects Versions: 2.0 .Final > Reporter: Jan Kalina > Assignee: Antoine Sabot-Durand > Labels: security-manager > Fix For: 2.0.SP1 > > > When deployment in container with security manager enabled try to use {{CDI.current()}} call, {{CDI}} class directly access JAR of CDI provider, because of which security manager requires from the deployment to have permission to read the JAR. > *{{CDI.findAllProviders}} method should read the JAR in privileged block.* > (as discussed in WFLY-10125) > {code} > java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.io.FilePermission" "/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-secman/1cfa62fc/jboss-eap-7.2/modules/system/layers/base/org/jboss/as/weld/main/wildfly-weld-7.2.0.CD12-redhat-2.jar" "read")" in code source "(vfs:/content/test.war/WEB-INF/classes )" of "ModuleClassLoader for Module "deployment.test.war" from Service Module Loader") > at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:295) > at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:192) > at java.lang.SecurityManager.checkRead(SecurityManager.java:888) > at org.wildfly.security.manager.WildFlySecurityManager.checkRead(WildFlySecurityManager.java:360) > at sun.net.www.protocol.jar.JarFileFactory.getCachedJarFile(JarFileFactory.java:137) > at sun.net.www.protocol.jar.JarFileFactory.get(JarFileFactory.java:81) > at sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:122) > at sun.net.www.protocol.jar.JarURLConnection.getInputStream(JarURLConnection.java:152) > at java.net.URL.openStream(URL.java:1045) > at javax.enterprise.inject.spi.CDI.findAllProviders(CDI.java:109) > at javax.enterprise.inject.spi.CDI.current(CDI.java:53) > at org.jboss.as.test.integration.ee.injection.support.jpa.beanManager.TestEntityListener.obtainFooViaCdiCurrent(TestEntityListener.java:97) > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Wed Jun 27 04:02:00 2018 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Wed, 27 Jun 2018 04:02:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-727) CDI.current() should use privileged block In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13597453#comment-13597453 ] Martin Kouba commented on CDI-727: ---------------------------------- For the record - this applies to CDI 1.2 API and not 2.0 API. Compare https://github.com/cdi-spec/cdi/blob/1.2/api/src/main/java/javax/enterprise/inject/spi/CDI.java#L109 and https://github.com/cdi-spec/cdi/blob/2.0/api/sc/main/java/javax/enterprise/inject/spi/CDI.java#L109. [~honza889] Pls could you verify whether this is a problem for CDI 2.0 too? > CDI.current() should use privileged block > ----------------------------------------- > > Key: CDI-727 > URL: https://issues.jboss.org/browse/CDI-727 > Project: CDI Specification Issues > Issue Type: Bug > Components: Javadoc and API > Affects Versions: 2.0 .Final > Reporter: Jan Kalina > Assignee: Antoine Sabot-Durand > Labels: security-manager > Fix For: 2.0.SP1 > > > When deployment in container with security manager enabled try to use {{CDI.current()}} call, {{CDI}} class directly access JAR of CDI provider, because of which security manager requires from the deployment to have permission to read the JAR. > *{{CDI.findAllProviders}} method should read the JAR in privileged block.* > (as discussed in WFLY-10125) > {code} > java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.io.FilePermission" "/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-secman/1cfa62fc/jboss-eap-7.2/modules/system/layers/base/org/jboss/as/weld/main/wildfly-weld-7.2.0.CD12-redhat-2.jar" "read")" in code source "(vfs:/content/test.war/WEB-INF/classes )" of "ModuleClassLoader for Module "deployment.test.war" from Service Module Loader") > at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:295) > at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:192) > at java.lang.SecurityManager.checkRead(SecurityManager.java:888) > at org.wildfly.security.manager.WildFlySecurityManager.checkRead(WildFlySecurityManager.java:360) > at sun.net.www.protocol.jar.JarFileFactory.getCachedJarFile(JarFileFactory.java:137) > at sun.net.www.protocol.jar.JarFileFactory.get(JarFileFactory.java:81) > at sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:122) > at sun.net.www.protocol.jar.JarURLConnection.getInputStream(JarURLConnection.java:152) > at java.net.URL.openStream(URL.java:1045) > at javax.enterprise.inject.spi.CDI.findAllProviders(CDI.java:109) > at javax.enterprise.inject.spi.CDI.current(CDI.java:53) > at org.jboss.as.test.integration.ee.injection.support.jpa.beanManager.TestEntityListener.obtainFooViaCdiCurrent(TestEntityListener.java:97) > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Wed Jun 27 04:36:00 2018 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Wed, 27 Jun 2018 04:36:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-727) CDI.current() should use privileged block In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13597453#comment-13597453 ] Martin Kouba edited comment on CDI-727 at 6/27/18 4:35 AM: ----------------------------------------------------------- For the record - this applies to CDI 1.2 API and not 2.0 API. Compare https://github.com/cdi-spec/cdi/blob/1.2/api/src/main/java/javax/enterprise/inject/spi/CDI.java#L109 and https://github.com/cdi-spec/cdi/blob/2.0/api/src/main/java/javax/enterprise/inject/spi/CDI.java#L109. [~honza889] Pls could you verify whether this is a problem for CDI 2.0 too? was (Author: mkouba): For the record - this applies to CDI 1.2 API and not 2.0 API. Compare https://github.com/cdi-spec/cdi/blob/1.2/api/src/main/java/javax/enterprise/inject/spi/CDI.java#L109 and https://github.com/cdi-spec/cdi/blob/2.0/api/sc/main/java/javax/enterprise/inject/spi/CDI.java#L109. [~honza889] Pls could you verify whether this is a problem for CDI 2.0 too? > CDI.current() should use privileged block > ----------------------------------------- > > Key: CDI-727 > URL: https://issues.jboss.org/browse/CDI-727 > Project: CDI Specification Issues > Issue Type: Bug > Components: Javadoc and API > Affects Versions: 2.0 .Final > Reporter: Jan Kalina > Assignee: Antoine Sabot-Durand > Labels: security-manager > Fix For: 2.0.SP1 > > > When deployment in container with security manager enabled try to use {{CDI.current()}} call, {{CDI}} class directly access JAR of CDI provider, because of which security manager requires from the deployment to have permission to read the JAR. > *{{CDI.findAllProviders}} method should read the JAR in privileged block.* > (as discussed in WFLY-10125) > {code} > java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.io.FilePermission" "/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-secman/1cfa62fc/jboss-eap-7.2/modules/system/layers/base/org/jboss/as/weld/main/wildfly-weld-7.2.0.CD12-redhat-2.jar" "read")" in code source "(vfs:/content/test.war/WEB-INF/classes )" of "ModuleClassLoader for Module "deployment.test.war" from Service Module Loader") > at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:295) > at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:192) > at java.lang.SecurityManager.checkRead(SecurityManager.java:888) > at org.wildfly.security.manager.WildFlySecurityManager.checkRead(WildFlySecurityManager.java:360) > at sun.net.www.protocol.jar.JarFileFactory.getCachedJarFile(JarFileFactory.java:137) > at sun.net.www.protocol.jar.JarFileFactory.get(JarFileFactory.java:81) > at sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:122) > at sun.net.www.protocol.jar.JarURLConnection.getInputStream(JarURLConnection.java:152) > at java.net.URL.openStream(URL.java:1045) > at javax.enterprise.inject.spi.CDI.findAllProviders(CDI.java:109) > at javax.enterprise.inject.spi.CDI.current(CDI.java:53) > at org.jboss.as.test.integration.ee.injection.support.jpa.beanManager.TestEntityListener.obtainFooViaCdiCurrent(TestEntityListener.java:97) > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005) From arjan.tijms at gmail.com Wed Jun 27 04:40:43 2018 From: arjan.tijms at gmail.com (arjan tijms) Date: Wed, 27 Jun 2018 09:40:43 +0100 Subject: [cdi-dev] CDI 2.1 In-Reply-To: References: Message-ID: Any plans to unofficially start CDI 2.1? On Sun, Jun 24, 2018 at 12:54 PM arjan tijms wrote: > Hi there, > > Just wondering, is there any time planned for when to officially start the > CDI 2.1 effort? > > Kind regards, > Arjan > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20180627/bec19a3a/attachment-0001.html From manovotn at redhat.com Wed Jun 27 05:48:56 2018 From: manovotn at redhat.com (Matej Novotny) Date: Wed, 27 Jun 2018 05:48:56 -0400 (EDT) Subject: [cdi-dev] CDI 2.1 In-Reply-To: References: Message-ID: <1540293493.46296644.1530092936550.JavaMail.zimbra@redhat.com> While this is for Antoine to answer, I would say that unofficial start would be to just go and create some pull requests ;-) Matej ----- Original Message ----- > From: "arjan tijms" > To: cdi-dev at lists.jboss.org > Sent: Wednesday, June 27, 2018 10:40:43 AM > Subject: Re: [cdi-dev] CDI 2.1 > > Any plans to unofficially start CDI 2.1? > > On Sun, Jun 24, 2018 at 12:54 PM arjan tijms < arjan.tijms at gmail.com > wrote: > > > > Hi there, > > Just wondering, is there any time planned for when to officially start the > CDI 2.1 effort? > > Kind regards, > Arjan > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code > under the Apache License, Version 2 > (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other intellectual > property rights inherent in such information. From issues at jboss.org Wed Jun 27 07:02:00 2018 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 27 Jun 2018 07:02:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-731) Defaut methods in Annoted hierarchy should use privileged block In-Reply-To: References: Message-ID: Antoine Sabot-Durand created CDI-731: ---------------------------------------- Summary: Defaut methods in Annoted hierarchy should use privileged block Key: CDI-731 URL: https://issues.jboss.org/browse/CDI-731 Project: CDI Specification Issues Issue Type: Bug Components: Javadoc and API Affects Versions: 2.0 .Final Reporter: Antoine Sabot-Durand To deal with reporting annotation (see CDI-471), CDI 2.0 introduced default method {{getAnnotations}} , in the following interfaces: * {{AnnotatedConstructor}} * {{AnnotatedField}} * {{AnnotatedMethod}} * {{AnnotatedParameter}} * {{AnnotatedType}} These methods make use of reflection and thus should use privileged blocs when used with a security manager -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Wed Jun 27 07:02:00 2018 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 27 Jun 2018 07:02:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-731) Defaut methods in Annoted hierarchy should use privileged block In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-731: ------------------------------------- Fix Version/s: 2.0.SP1 > Defaut methods in Annoted hierarchy should use privileged block > --------------------------------------------------------------- > > Key: CDI-731 > URL: https://issues.jboss.org/browse/CDI-731 > Project: CDI Specification Issues > Issue Type: Bug > Components: Javadoc and API > Affects Versions: 2.0 .Final > Reporter: Antoine Sabot-Durand > Fix For: 2.0.SP1 > > > To deal with reporting annotation (see CDI-471), CDI 2.0 introduced default method {{getAnnotations}} , in the following interfaces: > * {{AnnotatedConstructor}} > * {{AnnotatedField}} > * {{AnnotatedMethod}} > * {{AnnotatedParameter}} > * {{AnnotatedType}} > These methods make use of reflection and thus should use privileged blocs when used with a security manager -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Wed Jun 27 07:02:00 2018 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 27 Jun 2018 07:02:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-731) Defaut methods in Annoted hierarchy should use privileged block In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand reassigned CDI-731: ---------------------------------------- Assignee: Antoine Sabot-Durand > Defaut methods in Annoted hierarchy should use privileged block > --------------------------------------------------------------- > > Key: CDI-731 > URL: https://issues.jboss.org/browse/CDI-731 > Project: CDI Specification Issues > Issue Type: Bug > Components: Javadoc and API > Affects Versions: 2.0 .Final > Reporter: Antoine Sabot-Durand > Assignee: Antoine Sabot-Durand > Fix For: 2.0.SP1 > > > To deal with reporting annotation (see CDI-471), CDI 2.0 introduced default method {{getAnnotations}} , in the following interfaces: > * {{AnnotatedConstructor}} > * {{AnnotatedField}} > * {{AnnotatedMethod}} > * {{AnnotatedParameter}} > * {{AnnotatedType}} > These methods make use of reflection and thus should use privileged blocs when used with a security manager -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Wed Jun 27 07:03:00 2018 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 27 Jun 2018 07:03:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-731) Defaut methods in Annoted hierarchy should use privileged block In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-731: ------------------------------------- Description: To deal with repearting annotatiosn (see CDI-471), CDI 2.0 introduced default method {{getAnnotations}}, in the following interfaces: * {{AnnotatedConstructor}} * {{AnnotatedField}} * {{AnnotatedMethod}} * {{AnnotatedParameter}} * {{AnnotatedType}} These methods make use of reflection and thus should use privileged blocs when used with a security manager was: To deal with reporting annotation (see CDI-471), CDI 2.0 introduced default method {{getAnnotations}} , in the following interfaces: * {{AnnotatedConstructor}} * {{AnnotatedField}} * {{AnnotatedMethod}} * {{AnnotatedParameter}} * {{AnnotatedType}} These methods make use of reflection and thus should use privileged blocs when used with a security manager > Defaut methods in Annoted hierarchy should use privileged block > --------------------------------------------------------------- > > Key: CDI-731 > URL: https://issues.jboss.org/browse/CDI-731 > Project: CDI Specification Issues > Issue Type: Bug > Components: Javadoc and API > Affects Versions: 2.0 .Final > Reporter: Antoine Sabot-Durand > Assignee: Antoine Sabot-Durand > Fix For: 2.0.SP1 > > > To deal with repearting annotatiosn (see CDI-471), CDI 2.0 introduced default method {{getAnnotations}}, in the following interfaces: > * {{AnnotatedConstructor}} > * {{AnnotatedField}} > * {{AnnotatedMethod}} > * {{AnnotatedParameter}} > * {{AnnotatedType}} > These methods make use of reflection and thus should use privileged blocs when used with a security manager -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Wed Jun 27 07:05:00 2018 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 27 Jun 2018 07:05:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-731) Default methods in {{Annotated}} hierarchy should use privileged blocs In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-731: ------------------------------------- Summary: Default methods in {{Annotated}} hierarchy should use privileged blocs (was: Defaut methods in Annoted hierarchy should use privileged block) > Default methods in {{Annotated}} hierarchy should use privileged blocs > ---------------------------------------------------------------------- > > Key: CDI-731 > URL: https://issues.jboss.org/browse/CDI-731 > Project: CDI Specification Issues > Issue Type: Bug > Components: Javadoc and API > Affects Versions: 2.0 .Final > Reporter: Antoine Sabot-Durand > Assignee: Antoine Sabot-Durand > Fix For: 2.0.SP1 > > > To deal with repearting annotatiosn (see CDI-471), CDI 2.0 introduced default method {{getAnnotations}}, in the following interfaces: > * {{AnnotatedConstructor}} > * {{AnnotatedField}} > * {{AnnotatedMethod}} > * {{AnnotatedParameter}} > * {{AnnotatedType}} > These methods make use of reflection and thus should use privileged blocs when used with a security manager -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Wed Jun 27 07:05:00 2018 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 27 Jun 2018 07:05:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-731) Default methods in Annotated hierarchy should use privileged blocs In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-731: ------------------------------------- Summary: Default methods in Annotated hierarchy should use privileged blocs (was: Default methods in {{Annotated}} hierarchy should use privileged blocs) > Default methods in Annotated hierarchy should use privileged blocs > ------------------------------------------------------------------ > > Key: CDI-731 > URL: https://issues.jboss.org/browse/CDI-731 > Project: CDI Specification Issues > Issue Type: Bug > Components: Javadoc and API > Affects Versions: 2.0 .Final > Reporter: Antoine Sabot-Durand > Assignee: Antoine Sabot-Durand > Fix For: 2.0.SP1 > > > To deal with repearting annotatiosn (see CDI-471), CDI 2.0 introduced default method {{getAnnotations}}, in the following interfaces: > * {{AnnotatedConstructor}} > * {{AnnotatedField}} > * {{AnnotatedMethod}} > * {{AnnotatedParameter}} > * {{AnnotatedType}} > These methods make use of reflection and thus should use privileged blocs when used with a security manager -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Wed Jun 27 07:09:00 2018 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Wed, 27 Jun 2018 07:09:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-731) Default methods in Annotated hierarchy should use privileged blocs In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13597614#comment-13597614 ] Martin Kouba commented on CDI-731: ---------------------------------- I don't think {{java.lang.reflect.AnnotatedElement.getAnnotationsByType()}} throws {{SecurityException}}. > Default methods in Annotated hierarchy should use privileged blocs > ------------------------------------------------------------------ > > Key: CDI-731 > URL: https://issues.jboss.org/browse/CDI-731 > Project: CDI Specification Issues > Issue Type: Bug > Components: Javadoc and API > Affects Versions: 2.0 .Final > Reporter: Antoine Sabot-Durand > Assignee: Antoine Sabot-Durand > Fix For: 2.0.SP1 > > > To deal with repearting annotatiosn (see CDI-471), CDI 2.0 introduced default method {{getAnnotations}}, in the following interfaces: > * {{AnnotatedConstructor}} > * {{AnnotatedField}} > * {{AnnotatedMethod}} > * {{AnnotatedParameter}} > * {{AnnotatedType}} > These methods make use of reflection and thus should use privileged blocs when used with a security manager -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Wed Jun 27 07:09:00 2018 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Wed, 27 Jun 2018 07:09:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-731) Default methods in Annotated hierarchy should use privileged blocs In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13597614#comment-13597614 ] Martin Kouba edited comment on CDI-731 at 6/27/18 7:08 AM: ----------------------------------------------------------- I don't think that {{java.lang.reflect.AnnotatedElement.getAnnotationsByType()}} (used in those default methods) throws {{SecurityException}}. was (Author: mkouba): I don't think {{java.lang.reflect.AnnotatedElement.getAnnotationsByType()}} throws {{SecurityException}}. > Default methods in Annotated hierarchy should use privileged blocs > ------------------------------------------------------------------ > > Key: CDI-731 > URL: https://issues.jboss.org/browse/CDI-731 > Project: CDI Specification Issues > Issue Type: Bug > Components: Javadoc and API > Affects Versions: 2.0 .Final > Reporter: Antoine Sabot-Durand > Assignee: Antoine Sabot-Durand > Fix For: 2.0.SP1 > > > To deal with repearting annotatiosn (see CDI-471), CDI 2.0 introduced default method {{getAnnotations}}, in the following interfaces: > * {{AnnotatedConstructor}} > * {{AnnotatedField}} > * {{AnnotatedMethod}} > * {{AnnotatedParameter}} > * {{AnnotatedType}} > These methods make use of reflection and thus should use privileged blocs when used with a security manager -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Wed Jun 27 08:51:00 2018 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 27 Jun 2018 08:51:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-731) Default methods in Annotated hierarchy should use privileged blocs In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13597711#comment-13597711 ] Antoine Sabot-Durand commented on CDI-731: ------------------------------------------ When I launch test in https://github.com/antoinesd/cdi-spec/tree/master/api/src/test/java/org/jboss/cdi/api/test/annotated with security manager I have ACE stack traces on the tests related to the interface above. They're like: {code:console} java.security.AccessControlException: access denied ("java.lang.reflect.ReflectPermission" "suppressAccessChecks") at java.security.AccessControlContext.checkPermission(AccessControlContext.java:472) at java.security.AccessController.checkPermission(AccessController.java:884) at java.lang.SecurityManager.checkPermission(SecurityManager.java:549) at javax.enterprise.inject.spi.AnnotatedMethod.getAnnotations(AnnotatedMethod.java:49) at org.jboss.cdi.api.test.annotated.AbstractAnnotatedTest.shouldFindAnnotationsOnAnnotated(AbstractAnnotatedTest.java:36) ... Removed 34 stack frames {code} > Default methods in Annotated hierarchy should use privileged blocs > ------------------------------------------------------------------ > > Key: CDI-731 > URL: https://issues.jboss.org/browse/CDI-731 > Project: CDI Specification Issues > Issue Type: Bug > Components: Javadoc and API > Affects Versions: 2.0 .Final > Reporter: Antoine Sabot-Durand > Assignee: Antoine Sabot-Durand > Fix For: 2.0.SP1 > > > To deal with repearting annotatiosn (see CDI-471), CDI 2.0 introduced default method {{getAnnotations}}, in the following interfaces: > * {{AnnotatedConstructor}} > * {{AnnotatedField}} > * {{AnnotatedMethod}} > * {{AnnotatedParameter}} > * {{AnnotatedType}} > These methods make use of reflection and thus should use privileged blocs when used with a security manager -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Wed Jun 27 08:56:01 2018 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 27 Jun 2018 08:56:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-731) Default methods in Annotated hierarchy should use privileged blocs In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13597711#comment-13597711 ] Antoine Sabot-Durand edited comment on CDI-731 at 6/27/18 8:55 AM: ------------------------------------------------------------------- When I launch tests in https://github.com/antoinesd/cdi-spec/tree/master/api/src/test/java/org/jboss/cdi/api/test/annotated with security manager I have ACE stack traces on the tests related to the interfaces above. They look like: {code:console} java.security.AccessControlException: access denied ("java.lang.reflect.ReflectPermission" "suppressAccessChecks") at java.security.AccessControlContext.checkPermission(AccessControlContext.java:472) at java.security.AccessController.checkPermission(AccessController.java:884) at java.lang.SecurityManager.checkPermission(SecurityManager.java:549) at javax.enterprise.inject.spi.AnnotatedMethod.getAnnotations(AnnotatedMethod.java:49) at org.jboss.cdi.api.test.annotated.AbstractAnnotatedTest.shouldFindAnnotationsOnAnnotated(AbstractAnnotatedTest.java:36) ... Removed 34 stack frames {code} was (Author: antoinesabot-durand): When I launch test in https://github.com/antoinesd/cdi-spec/tree/master/api/src/test/java/org/jboss/cdi/api/test/annotated with security manager I have ACE stack traces on the tests related to the interface above. They're like: {code:console} java.security.AccessControlException: access denied ("java.lang.reflect.ReflectPermission" "suppressAccessChecks") at java.security.AccessControlContext.checkPermission(AccessControlContext.java:472) at java.security.AccessController.checkPermission(AccessController.java:884) at java.lang.SecurityManager.checkPermission(SecurityManager.java:549) at javax.enterprise.inject.spi.AnnotatedMethod.getAnnotations(AnnotatedMethod.java:49) at org.jboss.cdi.api.test.annotated.AbstractAnnotatedTest.shouldFindAnnotationsOnAnnotated(AbstractAnnotatedTest.java:36) ... Removed 34 stack frames {code} > Default methods in Annotated hierarchy should use privileged blocs > ------------------------------------------------------------------ > > Key: CDI-731 > URL: https://issues.jboss.org/browse/CDI-731 > Project: CDI Specification Issues > Issue Type: Bug > Components: Javadoc and API > Affects Versions: 2.0 .Final > Reporter: Antoine Sabot-Durand > Assignee: Antoine Sabot-Durand > Fix For: 2.0.SP1 > > > To deal with repearting annotatiosn (see CDI-471), CDI 2.0 introduced default method {{getAnnotations}}, in the following interfaces: > * {{AnnotatedConstructor}} > * {{AnnotatedField}} > * {{AnnotatedMethod}} > * {{AnnotatedParameter}} > * {{AnnotatedType}} > These methods make use of reflection and thus should use privileged blocs when used with a security manager -- This message was sent by Atlassian JIRA (v7.5.0#75005) From asd at redhat.com Wed Jun 27 08:59:34 2018 From: asd at redhat.com (Antoine Sabot-Durand) Date: Wed, 27 Jun 2018 14:59:34 +0200 Subject: [cdi-dev] CDI 2.1 In-Reply-To: <1540293493.46296644.1530092936550.JavaMail.zimbra@redhat.com> References: <1540293493.46296644.1530092936550.JavaMail.zimbra@redhat.com> Message-ID: There's no official start, but as Matej said, we can discuss of future features. The only thing that is certain is that there will be a CDI 2.1. Antoine On Wed, Jun 27, 2018 at 11:51 AM Matej Novotny wrote: > While this is for Antoine to answer, I would say that unofficial start > would be to just go and create some pull requests ;-) > > Matej > > ----- Original Message ----- > > From: "arjan tijms" > > To: cdi-dev at lists.jboss.org > > Sent: Wednesday, June 27, 2018 10:40:43 AM > > Subject: Re: [cdi-dev] CDI 2.1 > > > > Any plans to unofficially start CDI 2.1? > > > > On Sun, Jun 24, 2018 at 12:54 PM arjan tijms < arjan.tijms at gmail.com > > wrote: > > > > > > > > Hi there, > > > > Just wondering, is there any time planned for when to officially start > the > > CDI 2.1 effort? > > > > Kind regards, > > Arjan > > > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > Note that for all code provided on this list, the provider licenses the > code > > under the Apache License, Version 2 > > (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > > provided on this list, the provider waives all patent and other > intellectual > > property rights inherent in such information. > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20180627/44174063/attachment.html From issues at jboss.org Wed Jun 27 09:27:00 2018 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Wed, 27 Jun 2018 09:27:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-731) Default methods in Annotated hierarchy should use privileged blocs In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13597752#comment-13597752 ] Martin Kouba commented on CDI-731: ---------------------------------- The problem is that our tests use mock implementations of these interfaces. So for example to test the {{AnnotatedMethod}} default method we do call {{java.lang.Class.getMethod()}} which is a subject to access control: https://github.com/antoinesd/cdi-spec/blob/master/api/src/test/java/org/jboss/cdi/api/test/annotated/AnnotatedMethodTest.java#L30 That's why we see "access denied ("java.lang.reflect.ReflectPermission" "suppressAccessChecks")" in the stack. > Default methods in Annotated hierarchy should use privileged blocs > ------------------------------------------------------------------ > > Key: CDI-731 > URL: https://issues.jboss.org/browse/CDI-731 > Project: CDI Specification Issues > Issue Type: Bug > Components: Javadoc and API > Affects Versions: 2.0 .Final > Reporter: Antoine Sabot-Durand > Assignee: Antoine Sabot-Durand > Fix For: 2.0.SP1 > > > To deal with repearting annotatiosn (see CDI-471), CDI 2.0 introduced default method {{getAnnotations}}, in the following interfaces: > * {{AnnotatedConstructor}} > * {{AnnotatedField}} > * {{AnnotatedMethod}} > * {{AnnotatedParameter}} > * {{AnnotatedType}} > These methods make use of reflection and thus should use privileged blocs when used with a security manager -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Wed Jun 27 09:38:00 2018 From: issues at jboss.org (Jan Kalina (JIRA)) Date: Wed, 27 Jun 2018 09:38:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-727) CDI.current() should use privileged block In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13597763#comment-13597763 ] Jan Kalina commented on CDI-727: -------------------------------- [~mkouba] Confirmed: problem affects latest master of CDI (9f5eaa/2.1-SNAPSHOT) and patch in https://github.com/cdi-spec/cdi/pull/391 (508a47) resolves it successfully. For testing it is need to revert WFLY-10125 workaround, to enable given CDI and to run {{EntityListenerBeanManagerInjectionTestCase}} with {{-Dsecurity.manager}}. > CDI.current() should use privileged block > ----------------------------------------- > > Key: CDI-727 > URL: https://issues.jboss.org/browse/CDI-727 > Project: CDI Specification Issues > Issue Type: Bug > Components: Javadoc and API > Affects Versions: 2.0 .Final > Reporter: Jan Kalina > Assignee: Antoine Sabot-Durand > Labels: security-manager > Fix For: 2.0.SP1 > > > When deployment in container with security manager enabled try to use {{CDI.current()}} call, {{CDI}} class directly access JAR of CDI provider, because of which security manager requires from the deployment to have permission to read the JAR. > *{{CDI.findAllProviders}} method should read the JAR in privileged block.* > (as discussed in WFLY-10125) > {code} > java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.io.FilePermission" "/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-secman/1cfa62fc/jboss-eap-7.2/modules/system/layers/base/org/jboss/as/weld/main/wildfly-weld-7.2.0.CD12-redhat-2.jar" "read")" in code source "(vfs:/content/test.war/WEB-INF/classes )" of "ModuleClassLoader for Module "deployment.test.war" from Service Module Loader") > at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:295) > at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:192) > at java.lang.SecurityManager.checkRead(SecurityManager.java:888) > at org.wildfly.security.manager.WildFlySecurityManager.checkRead(WildFlySecurityManager.java:360) > at sun.net.www.protocol.jar.JarFileFactory.getCachedJarFile(JarFileFactory.java:137) > at sun.net.www.protocol.jar.JarFileFactory.get(JarFileFactory.java:81) > at sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:122) > at sun.net.www.protocol.jar.JarURLConnection.getInputStream(JarURLConnection.java:152) > at java.net.URL.openStream(URL.java:1045) > at javax.enterprise.inject.spi.CDI.findAllProviders(CDI.java:109) > at javax.enterprise.inject.spi.CDI.current(CDI.java:53) > at org.jboss.as.test.integration.ee.injection.support.jpa.beanManager.TestEntityListener.obtainFooViaCdiCurrent(TestEntityListener.java:97) > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Wed Jun 27 09:43:00 2018 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 27 Jun 2018 09:43:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-731) Default methods in Annotated hierarchy should use privileged blocs In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13597773#comment-13597773 ] Antoine Sabot-Durand commented on CDI-731: ------------------------------------------ Ok. got it. I close the ticket > Default methods in Annotated hierarchy should use privileged blocs > ------------------------------------------------------------------ > > Key: CDI-731 > URL: https://issues.jboss.org/browse/CDI-731 > Project: CDI Specification Issues > Issue Type: Bug > Components: Javadoc and API > Affects Versions: 2.0 .Final > Reporter: Antoine Sabot-Durand > Assignee: Antoine Sabot-Durand > Fix For: 2.0.SP1 > > > To deal with repearting annotatiosn (see CDI-471), CDI 2.0 introduced default method {{getAnnotations}}, in the following interfaces: > * {{AnnotatedConstructor}} > * {{AnnotatedField}} > * {{AnnotatedMethod}} > * {{AnnotatedParameter}} > * {{AnnotatedType}} > These methods make use of reflection and thus should use privileged blocs when used with a security manager -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Wed Jun 27 09:50:00 2018 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Wed, 27 Jun 2018 09:50:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-727) CDI.current() should use privileged block In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13597783#comment-13597783 ] Martin Kouba commented on CDI-727: ---------------------------------- [~honza889] Ok, thanks. I suppose the problematic method is {{java.util.ServiceLoader.parse(Class, URL)}} where {{java.net.URL.openStream()}} is used. > CDI.current() should use privileged block > ----------------------------------------- > > Key: CDI-727 > URL: https://issues.jboss.org/browse/CDI-727 > Project: CDI Specification Issues > Issue Type: Bug > Components: Javadoc and API > Affects Versions: 2.0 .Final > Reporter: Jan Kalina > Assignee: Antoine Sabot-Durand > Labels: security-manager > Fix For: 2.0.SP1 > > > When deployment in container with security manager enabled try to use {{CDI.current()}} call, {{CDI}} class directly access JAR of CDI provider, because of which security manager requires from the deployment to have permission to read the JAR. > *{{CDI.findAllProviders}} method should read the JAR in privileged block.* > (as discussed in WFLY-10125) > {code} > java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.io.FilePermission" "/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-secman/1cfa62fc/jboss-eap-7.2/modules/system/layers/base/org/jboss/as/weld/main/wildfly-weld-7.2.0.CD12-redhat-2.jar" "read")" in code source "(vfs:/content/test.war/WEB-INF/classes )" of "ModuleClassLoader for Module "deployment.test.war" from Service Module Loader") > at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:295) > at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:192) > at java.lang.SecurityManager.checkRead(SecurityManager.java:888) > at org.wildfly.security.manager.WildFlySecurityManager.checkRead(WildFlySecurityManager.java:360) > at sun.net.www.protocol.jar.JarFileFactory.getCachedJarFile(JarFileFactory.java:137) > at sun.net.www.protocol.jar.JarFileFactory.get(JarFileFactory.java:81) > at sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:122) > at sun.net.www.protocol.jar.JarURLConnection.getInputStream(JarURLConnection.java:152) > at java.net.URL.openStream(URL.java:1045) > at javax.enterprise.inject.spi.CDI.findAllProviders(CDI.java:109) > at javax.enterprise.inject.spi.CDI.current(CDI.java:53) > at org.jboss.as.test.integration.ee.injection.support.jpa.beanManager.TestEntityListener.obtainFooViaCdiCurrent(TestEntityListener.java:97) > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Wed Jun 27 10:24:00 2018 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 27 Jun 2018 10:24:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-731) Default methods in Annotated hierarchy should use privileged blocs In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand closed CDI-731. ------------------------------------ Resolution: Explained > Default methods in Annotated hierarchy should use privileged blocs > ------------------------------------------------------------------ > > Key: CDI-731 > URL: https://issues.jboss.org/browse/CDI-731 > Project: CDI Specification Issues > Issue Type: Bug > Components: Javadoc and API > Affects Versions: 2.0 .Final > Reporter: Antoine Sabot-Durand > Assignee: Antoine Sabot-Durand > Fix For: 2.0.SP1 > > > To deal with repearting annotatiosn (see CDI-471), CDI 2.0 introduced default method {{getAnnotations}}, in the following interfaces: > * {{AnnotatedConstructor}} > * {{AnnotatedField}} > * {{AnnotatedMethod}} > * {{AnnotatedParameter}} > * {{AnnotatedType}} > These methods make use of reflection and thus should use privileged blocs when used with a security manager -- This message was sent by Atlassian JIRA (v7.5.0#75005)