October 2016 - cdi-dev - Jboss List Archives

[JBoss JIRA] (CDI-259) Add conversation begin and conversation end events

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-259?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-259: ------------------------------------- Priority: Optional (was: Major) > Add conversation begin and conversation end events > -------------------------------------------------- > > Key: CDI-259 > URL: https://issues.jboss.org/browse/CDI-259 > Project: CDI Specification Issues > Issue Type: Feature Request > Affects Versions: 1.1.EDR > Reporter: Pete Muir > Priority: Optional > Fix For: TBD > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (CDI-259) Add conversation begin and conversation end events

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-259?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-259: ------------------------------------- Fix Version/s: TBD (was: 2.0 (discussion)) > Add conversation begin and conversation end events > -------------------------------------------------- > > Key: CDI-259 > URL: https://issues.jboss.org/browse/CDI-259 > Project: CDI Specification Issues > Issue Type: Feature Request > Affects Versions: 1.1.EDR > Reporter: Pete Muir > Priority: Optional > Fix For: TBD > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (CDI-468) Extend javax.interceptor.InvocationContext

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-468?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-468: ------------------------------------- Fix Version/s: 2.1 (Discussion) (was: 2.0 (discussion)) > Extend javax.interceptor.InvocationContext > ------------------------------------------ > > Key: CDI-468 > URL: https://issues.jboss.org/browse/CDI-468 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Arne Limburg > Fix For: 2.1 (Discussion) > > > Currently there is no easy way to obtain the interceptor binding annotation for an interceptor call. The interceptor binding annotation is needed to access @Nonbinding attributes and behave accordingly. > I propose to extend the javax.interceptor.InvocationContext interface with a method > public Annotation getInterceptorBinding() or > public <A extends Annotation> A getInterceptorBinding(Class<A> type) > The @AroundInvoke method of CDI Interceptors may use this extended interface as parameter instead of the original one to obtain the interceptor binding annotation. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (CDI-473) Standardize eager initialisation of ApplicationScoped bean

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-473?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-473: ------------------------------------- Fix Version/s: 2.0 .Final (was: 2.0 (discussion)) > Standardize eager initialisation of ApplicationScoped bean > ---------------------------------------------------------- > > Key: CDI-473 > URL: https://issues.jboss.org/browse/CDI-473 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Contexts > Reporter: Antonin Stefanutti > Fix For: 2.0 .Final > > > Given the proxying strategy documented in the CDI specification, normal scoped beans get initialize when an injected proxy reference is first called. > While that's perfectly fine in the vast majority of use cases, that proves inconvenient when dealing with {{ApplicationScoped}} beans that capture application singletons which we want to bound to the application lifecycle with a {{postConstruct}} callback. As this callback is only called when a proxy is invoked, it is frequent to see the application developers using a CDI extension to meet that need, e.g.: > {code} > void forceInitialization(@Observes AfterDeploymentValidation adv, BeanManager manager) { > for (AnnotatedType<?> type : eagerBeans) > // Calling toString is necessary to force the initialization of normal-scoped beans > BeanManagerHelper.getReferencesByType(manager, type.getBaseType(), AnyLiteral.INSTANCE).toString(); > } > {code} > There should be a concise way to declare that intent which would then be address by the CDI container, for example: > {code} > @ApplicationScoped(eager = true} > class EagerApplicationScopedBean { > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (CDI-478) Interceptor and Decorator EPIC for CDI 2.0

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-478?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-478: ------------------------------------- Fix Version/s: 2.0 .Final (was: 2.0 (discussion)) > Interceptor and Decorator EPIC for CDI 2.0 > ------------------------------------------ > > Key: CDI-478 > URL: https://issues.jboss.org/browse/CDI-478 > Project: CDI Specification Issues > Issue Type: Epic > Reporter: Antoine Sabot-Durand > Fix For: 2.0 .Final > > > This Epic ticket gathers all work and documents about interceptor and decorator in CDI 2.0 > Draft document is here : https://docs.google.com/document/d/10iexiDfMT9tYaUPa2cGiw4P68VG_bryDIS0DK... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (CDI-477) Update outdated package-info.java in javax.enterprise.inject package

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-477?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-477: ------------------------------------- Fix Version/s: 2.0 .Final (was: 2.0 (discussion)) > Update outdated package-info.java in javax.enterprise.inject package > -------------------------------------------------------------------- > > Key: CDI-477 > URL: https://issues.jboss.org/browse/CDI-477 > Project: CDI Specification Issues > Issue Type: Bug > Components: Javadoc and API > Affects Versions: 1.2.Final > Reporter: Martin Kouba > Fix For: 2.0 .Final > > > Update or remove this javadoc. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (CDI-482) Overloaded version of ObserverMethod.notify()

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-482?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand resolved CDI-482. -------------------------------------- Resolution: Duplicate Issue > Overloaded version of ObserverMethod.notify() > --------------------------------------------- > > Key: CDI-482 > URL: https://issues.jboss.org/browse/CDI-482 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Events, Portable Extensions > Affects Versions: 1.2.Final > Reporter: Jozef Hartinger > Fix For: 2.0 (discussion) > > > Resurrecting the old proposal (CDI-36) that was rejected due to backward compatibility (CDI-281). In the meantime, alternative approach of obtaining event qualifiers (doing a programmatic lookup for EventMetadata) became available. > Now that default methods are available in Java, we should consider making EventMetadata easier to use by making it part of the SPI directly: > {code:JAVA} > ObserverMethod.notify(T event, EventMetadata metadata) > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (CDI-484) Provide forwarding implementations of SPI interfaces

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-484?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand resolved CDI-484. -------------------------------------- Resolution: Duplicate Issue CDI-558 answers to most use cases link to this ticket > Provide forwarding implementations of SPI interfaces > ---------------------------------------------------- > > Key: CDI-484 > URL: https://issues.jboss.org/browse/CDI-484 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Portable Extensions > Affects Versions: 1.2.Final > Reporter: Jozef Hartinger > Fix For: 2.0 (discussion) > > > The decorator design pattern is commonly used in CDI extensions to modify existing metadata by wrapping it with a wrapper implementation that overrides certain method. This can be done in the following callbacks: ProcessAnnotatedType, ProcessProducer, ProcessInjectionTarget, ProcessInjectionPoint and ProcessBeanAttributes. > In order to do this it is often very convenient to have a forwarding implementation available, e.g.: > {code:JAVA} > void wrap(@Observes ProcessAnnotatedType<Foo> event) { > final AnnotatedType<Foo> delegate = event.getAnnotatedType(); > event.setAnnotatedType(new ForwardingAnnotatedType<Foo>(delegate) { > @Override > public <A extends Annotation> A getAnnotation(Class<A> annotationType) { > return null; > } > @Override > public Set<Annotation> getAnnotations() { > return Collections.emptySet(); > } > @Override > public boolean isAnnotationPresent(Class<? extends Annotation> annotationType) { > return false; > } > } > {code} > We should consider providing these utility forwarding implementations as part of the CDI API. This is similar to e.g. Servlet specification doing this for their decorable APIs (http://tomcat.apache.org/tomcat-5.5-doc/servletapi/javax/servlet/http/Htt...) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 7 months

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.0 .Final (was: 2.0 (discussion)) > 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.0 .Final > > > 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 (v6.4.11#64026)

7 years, 7 months

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 commented on CDI-486: ------------------------------------------ We really need to consult a security expert on this point. > 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.0 .Final > > > 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 (v6.4.11#64026)

7 years, 7 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev October 2016