[JBoss JIRA] (CDI-728) The CDI specification javadoc is setting lang=french in the headers
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-728?page=com.atlassian.jira.plugin.sy... ]
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}
> <html lang="fr">
> {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)
6 years, 6 months
[JBoss JIRA] (CDI-728) The CDI specification javadoc is setting lang=french in the headers
by Sanne Grinovero (JIRA)
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}
<html lang="fr">
{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)
6 years, 6 months
[JBoss JIRA] (CDI-727) CDI.current() should use privileged block
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/CDI-727?page=com.atlassian.jira.plugin.sy... ]
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 <no signer certificates>)" 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 <no signer certificates>)" 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 <no signer certificates>)" 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)
6 years, 6 months
[JBoss JIRA] (CDI-727) CDI.current() should use privileged block
by Jan Kalina (JIRA)
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 <no signer certificates>)" 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)
6 years, 6 months
CDI Issues with security manager
by Antoine Sabot-Durand
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
6 years, 6 months
[JBoss JIRA] (CDI-726) Deprecate before dropping CDI.setCDIProvider
by Romain Manni-Bucau (JIRA)
[ https://issues.jboss.org/browse/CDI-726?page=com.atlassian.jira.plugin.sy... ]
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)
6 years, 6 months
[JBoss JIRA] (CDI-726) Deprecate before dropping CDI.setCDIProvider
by Romain Manni-Bucau (JIRA)
[ https://issues.jboss.org/browse/CDI-726?page=com.atlassian.jira.plugin.sy... ]
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)
6 years, 6 months
[JBoss JIRA] (CDI-726) Deprecate before dropping CDI.setCDIProvider
by Emily Jiang (JIRA)
[ https://issues.jboss.org/browse/CDI-726?page=com.atlassian.jira.plugin.sy... ]
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) <issues(a)jboss.org>
--
Thanks
Emily
=================
Emily Jiang
ejiang(a)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)
6 years, 6 months
[JBoss JIRA] (CDI-726) Deprecate before dropping CDI.setCDIProvider
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-726?page=com.atlassian.jira.plugin.sy... ]
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/14cd36abb4d039212cf21521a46755b15f.... [~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)
6 years, 6 months
