December 2016 - cdi-dev - Jboss List Archives

[JBoss JIRA] (CDI-232) Relax requirements for built-in Instance

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-232?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-232: ------------------------------------- Fix Version/s: 2.0 .Final (was: 2.1 (Discussion)) > Relax requirements for built-in Instance > ---------------------------------------- > > Key: CDI-232 > URL: https://issues.jboss.org/browse/CDI-232 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 1.1.EDR > Reporter: Martin Kouba > Priority: Minor > Labels: F2F2016 > Fix For: 2.0 .Final > > > 5.6.2. The built-in Instance > {quote} > The container must provide a built-in bean with: > * Instance<X> and Provider<X> for every legal bean type X in its set of bean types, > * every qualifier type in its set of qualifier types, > {quote} > This type/qualifier requirements seem to be too strict. Maybe we should omit these and instead force implementation to satisfy every injection point for every legal bean type and corresponding qualifiers found in application... or something like that. I'm not sure about the wording. > By the way Weld (2.0.0.Alpha2) does not fulfil these requirements at the moment. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years

1
0
0 / 0

[JBoss JIRA] (CDI-232) Relax requirements for built-in Instance

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-232?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-232: ------------------------------------- Fix Version/s: 2.1 (Discussion) (was: 2.0 .Final) > Relax requirements for built-in Instance > ---------------------------------------- > > Key: CDI-232 > URL: https://issues.jboss.org/browse/CDI-232 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 1.1.EDR > Reporter: Martin Kouba > Priority: Minor > Labels: F2F2016 > Fix For: 2.1 (Discussion) > > > 5.6.2. The built-in Instance > {quote} > The container must provide a built-in bean with: > * Instance<X> and Provider<X> for every legal bean type X in its set of bean types, > * every qualifier type in its set of qualifier types, > {quote} > This type/qualifier requirements seem to be too strict. Maybe we should omit these and instead force implementation to satisfy every injection point for every legal bean type and corresponding qualifiers found in application... or something like that. I'm not sure about the wording. > By the way Weld (2.0.0.Alpha2) does not fulfil these requirements at the moment. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years

1
0
0 / 0

[JBoss JIRA] (CDI-486) Define security constraints for using CDI SPI

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-486?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-486: ------------------------------------- Fix Version/s: 2.1 (Discussion) (was: 2.0 .Final) > Define security constraints for using CDI SPI > --------------------------------------------- > > Key: CDI-486 > URL: https://issues.jboss.org/browse/CDI-486 > Project: CDI Specification Issues > Issue Type: Feature Request > Affects Versions: 1.2.Final > Reporter: Jozef Hartinger > Priority: Critical > Fix For: 2.1 (Discussion) > > > Currently, the specification does not require any security checks to be performed when CDI SPI is used. It is not clear how this should be implemented. > Note that since a CDI implementation is required to support bypassing platform securiy checks (e.g. when invoking aprivate observer method), total absence of security checks on CDI SPI level could result in privilege escalation. Here's an example: > Suppose the application server bundles a sensitive method: > {code:JAVA} > public class ApplicationServer { > static boolean explode() { > // ... > } > } > {code} > The method is package-private and thus cannot be by an application. If the application would be to invoke this method using reflection, it would need to first obtain the Method handle for the explode method. Obtaining a Method handle requires the "accessDeclaredMembers" runtime permission which the application does not have. It can however use the CDI SPI: > {code:JAVA} > Method method = null; > for (AnnotatedMethod<?> annotatedMethod : manager.createAnnotatedType(ApplicationServer.class).getMethods()) { > if (annotatedMethod.getJavaMember().equals("explode")) { > method = annotatedMethod.getJavaMember(); > break; > } > } > {code} > Now the application has the Method handle without having the "accessDeclaredMembers" permission. > The application still cannot invoke the method as it needs to bypass security checks on access to the method first. This cannot be done without the "suppressAccessChecks" runtime permission. > Again, remember that CDI implementations are supposed to be capable of invoking inaccessible methods and this capability is exposed through the SPI. Therefore, the application call: > {code:JAVA} > Producer<?> producer = manager.getProducerFactory(annotatedMethod, null).createProducer(null); > {code} > Now, calling producer.produce() will cause the sensitive method to be invoked even though the application was not granted "accessDeclaredMembers" neither "suppressAccessChecks" permission. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years

1
0
0 / 0

[JBoss JIRA] (CDI-659) Introduce a provider in-specific servlet listener

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-659?page=com.atlassian.jira.plugin.sy... ] Martin Kouba edited comment on CDI-659 at 12/5/16 9:00 AM: ----------------------------------------------------------- [~meetoblivion] Sure, why not. I'm all for any ideas that will make CDI/Servlet integration easier. By the way, the other thing missing is dependency injection into servlet components (servlers, listeners, etc.). Right now, there is no Servlet SPI which would allow the CDI container to hook into the component lifecycle and Servlet impls are not required to perform injection (I'm not sure about Servlet 4.0). And so CDI impls must depend on non-portable (often very unstable) SPIs. CDI-492 is also related. was (Author: mkouba): Sure, why not. I'm all for any ideas that will make CDI/Servlet integration easier. By the way, the other thing missing is dependency injection into servlet components (servlers, listeners, etc.). Right now, there is no Servlet SPI which would allow the CDI container to hook into the component lifecycle and Servlet impls are not required to perform injection (I'm not sure about Servlet 4.0). And so CDI impls must depend on non-portable (often very unstable) SPIs. CDI-492 is also related. > Introduce a provider in-specific servlet listener > ------------------------------------------------- > > Key: CDI-659 > URL: https://issues.jboss.org/browse/CDI-659 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Java EE integration > Reporter: John Ament > Fix For: 2.1 (Discussion) > > > Currently, each provider (OWB, Weld) provides a servlet listener for registering CDI in a plain servlet container. Looking at other specs, e.g. JAX-RS, references to an implementation in-specific way to register your services are provided. We should do the same for CDI, allowing a user to register a servlet listener without needing to leverage provider-specific classes. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years

1
0
0 / 0

[JBoss JIRA] (CDI-659) Introduce a provider in-specific servlet listener

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-659?page=com.atlassian.jira.plugin.sy... ] Martin Kouba commented on CDI-659: ---------------------------------- Sure, why not. I'm all for any ideas that will make CDI/Servlet integration easier. By the way, the other thing missing is dependency injection into servlet components (servlers, listeners, etc.). Right now, there is no Servlet SPI which would allow the CDI container to hook into the component lifecycle and Servlet impls are not required to perform injection (I'm not sure about Servlet 4.0). And so CDI impls must depend on non-portable (often very unstable) SPIs. CDI-492 is also related. > Introduce a provider in-specific servlet listener > ------------------------------------------------- > > Key: CDI-659 > URL: https://issues.jboss.org/browse/CDI-659 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Java EE integration > Reporter: John Ament > Fix For: 2.1 (Discussion) > > > Currently, each provider (OWB, Weld) provides a servlet listener for registering CDI in a plain servlet container. Looking at other specs, e.g. JAX-RS, references to an implementation in-specific way to register your services are provided. We should do the same for CDI, allowing a user to register a servlet listener without needing to leverage provider-specific classes. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years

1
0
0 / 0

[JBoss JIRA] (CDI-659) Introduce a provider in-specific servlet listener

by Romain Manni-Bucau (JIRA)

[ https://issues.jboss.org/browse/CDI-659?page=com.atlassian.jira.plugin.sy... ] Romain Manni-Bucau commented on CDI-659: ---------------------------------------- +1 for ServletContainerInitializer, would it makes sense to have a scanning mode relying on this as well and avoiding CDI to scan anything (@HandleTypes)? > Introduce a provider in-specific servlet listener > ------------------------------------------------- > > Key: CDI-659 > URL: https://issues.jboss.org/browse/CDI-659 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Java EE integration > Reporter: John Ament > Fix For: 2.1 (Discussion) > > > Currently, each provider (OWB, Weld) provides a servlet listener for registering CDI in a plain servlet container. Looking at other specs, e.g. JAX-RS, references to an implementation in-specific way to register your services are provided. We should do the same for CDI, allowing a user to register a servlet listener without needing to leverage provider-specific classes. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years

1
0
0 / 0

[JBoss JIRA] (CDI-659) Introduce a provider in-specific servlet listener

by John Ament (JIRA)

[ https://issues.jboss.org/browse/CDI-659?page=com.atlassian.jira.plugin.sy... ] John Ament commented on CDI-659: -------------------------------- Would it make sense to leverage this ticket as the intro to specifying servlet container support? > Introduce a provider in-specific servlet listener > ------------------------------------------------- > > Key: CDI-659 > URL: https://issues.jboss.org/browse/CDI-659 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Java EE integration > Reporter: John Ament > Fix For: 2.1 (Discussion) > > > Currently, each provider (OWB, Weld) provides a servlet listener for registering CDI in a plain servlet container. Looking at other specs, e.g. JAX-RS, references to an implementation in-specific way to register your services are provided. We should do the same for CDI, allowing a user to register a servlet listener without needing to leverage provider-specific classes. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years

1
0
0 / 0

[JBoss JIRA] (CDI-659) Introduce a provider in-specific servlet listener

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-659?page=com.atlassian.jira.plugin.sy... ] Martin Kouba commented on CDI-659: ---------------------------------- Tomas is right. We would have to specify the Servlet container support first as there are other problems we would have to deal with (e.g. read-only JNDI). By the way, an impl. may leverage {{javax.servlet.ServletContainerInitializer}} API to initialize the CDI container (this should work on most recent versions of Tomcat, Jetty, etc.). > Introduce a provider in-specific servlet listener > ------------------------------------------------- > > Key: CDI-659 > URL: https://issues.jboss.org/browse/CDI-659 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Java EE integration > Reporter: John Ament > Fix For: 2.1 (Discussion) > > > Currently, each provider (OWB, Weld) provides a servlet listener for registering CDI in a plain servlet container. Looking at other specs, e.g. JAX-RS, references to an implementation in-specific way to register your services are provided. We should do the same for CDI, allowing a user to register a servlet listener without needing to leverage provider-specific classes. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years

1
0
0 / 0

[JBoss JIRA] (CDI-660) Registration of custom Producer

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-660?page=com.atlassian.jira.plugin.sy... ] Martin Kouba commented on CDI-660: ---------------------------------- If I understand the description correctly this applies to *@Dependent producers only*. Because normal scoped beans are not bound to a single injection point. In Weld, the manual lookup of the injection point metadata is supported, see also https://github.com/weld/core/blob/master/tests-arquillian/src/test/java/o.... I think we should clarify the usage of {{InjectionPoint}} metadata for custom beans and probably extend {{CreationalContext}} to return metadata for {{@Dependent}} beans. > Registration of custom Producer > ------------------------------- > > Key: CDI-660 > URL: https://issues.jboss.org/browse/CDI-660 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans, Portable Extensions > Reporter: John Ament > Fix For: 2.1 (Discussion) > > > Introduce a feature that would allow a developer to register a custom producer, probably in a portable extension as a lifecycle method, separate from a custom bean implementation. > The producer would have optional access to the underlying injection point (which bean does not provide) but probably needs to still track: > - Qualifiers > - Scope -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years

1
0
0 / 0

[JBoss JIRA] (CDI-593) Mention javax.enterprise.inject.spi.Prioritized in spec text and improve its javadoc

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-593?page=com.atlassian.jira.plugin.sy... ] Martin Kouba commented on CDI-593: ---------------------------------- Yes, plus custom interceptors and decorators and also {{ObserverMethod}}. > Mention javax.enterprise.inject.spi.Prioritized in spec text and improve its javadoc > ------------------------------------------------------------------------------------ > > Key: CDI-593 > URL: https://issues.jboss.org/browse/CDI-593 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Martin Kouba > Assignee: Antoine Sabot-Durand > Fix For: 2.0 .Final > > > * javadoc would definitely deserve some more info > * the spec text should mention this interface as well and describe basic use cases (e.g. an interceptor passed to {{AfterBeanDiscovery.addBean()}} and implementing this interface is globally enabled) -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev December 2016