October 2014 - cdi-dev - Jboss List Archives

Updated Invitation: CDI weekly meeting @ Weekly from 18:00 to 19:00 on Wednesday except Wed 1 Oct 18:00 or Wed 15 Oct 18:00 (ASD Perso)

by antoine＠sabot-durand.net

This event has been changed. Title: CDI weekly meeting View your event at https://www.google.com/calendar/event?action=VIEW&eid=YmdhdXVtcDdnNjhlM3B.... View your event at https://www.google.com/calendar/event?action=VIEW&eid=YmdhdXVtcDdnNjhlM3B.... View your event at https://www.google.com/calendar/event?action=VIEW&eid=YmdhdXVtcDdnNjhlM3B.... When: Weekly from 18:00 to 19:00 on Wednesday except Wed 1 Oct 18:00 or Wed 15 Oct 18:00 Paris (changed) Where: IRC #cdi-dev channel on freenode Calendar: ASD Perso Who: * Antoine Sabot-Durand- organiser * cdi-dev(a)lists.jboss.org Event details: https://www.google.com/calendar/event?action=VIEW&eid=YmdhdXVtcDdnNjhlM3B... Invitation from Google Calendar: https://www.google.com/calendar/ You are receiving this courtesy email at the account cdi-dev(a)lists.jboss.org because you are an attendee of this event. To stop receiving future notifications for this event, decline this event. Alternatively, you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar.

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (CDI-488) InjectionPoint SPI should expose whether an injection point is @TransientReference

by Jozef Hartinger (JIRA)

Jozef Hartinger created CDI-488: ----------------------------------- Summary: InjectionPoint SPI should expose whether an injection point is @TransientReference Key: CDI-488 URL: https://issues.jboss.org/browse/CDI-488 Project: CDI Specification Issues Issue Type: Feature Request Components: Portable Extensions Reporter: Jozef Hartinger Fix For: 2.0 (discussion) Similarly to InjectionPoint.isDelegate(), the SPI should expose whether an injection points requires a @TransientReference or not. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (CDI-45) Optional Injection Points

by Stefan Großmann (JIRA)

[ https://issues.jboss.org/browse/CDI-45?page=com.atlassian.jira.plugin.sys... ] Stefan Großmann commented on CDI-45: ------------------------------------ I guess there will be a way to toggle this property using a CDI-Extension? How would this look like? {code} void processInjectionPoint(@Observes ProcessInjectionPoint pit) { ... pit.getInjectionPoint().setOptional() } {code} > Optional Injection Points > ------------------------- > > Key: CDI-45 > URL: https://issues.jboss.org/browse/CDI-45 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Resolution > Affects Versions: 1.0 > Reporter: Stuart Douglas > Fix For: 2.0 (discussion) > > > There are occoasions where it may be useful for some injection points to be optional, e.g. > @Inject > @Optional > MyBean bean; > This would behave the same as a normal injection point, however it will not cause the deployment to fail if it is not satisified. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (CDI-471) Support repeating qualifiers in typesafe resolution mechanism

by Jozef Hartinger (JIRA)

[ https://issues.jboss.org/browse/CDI-471?page=com.atlassian.jira.plugin.sy... ] Jozef Hartinger commented on CDI-471: ------------------------------------- A prototype implementation of this feature is available in Weld 3.0.0.Alpha1. See http://weld.cdi-spec.org/news/2014/10/02/weld-300Alpha1/ for details. > Support repeating qualifiers in typesafe resolution mechanism > ------------------------------------------------------------- > > Key: CDI-471 > URL: https://issues.jboss.org/browse/CDI-471 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Resolution > Reporter: Antonin Stefanutti > > As Java 8 provides improved support for [repeating annotations|http://docs.oracle.com/javase/tutorial/java/annotations/repea...], it would be valuable to percolate that support into the CDI typesafe resolution mechanism. > For example, one could write: > {code} > @Qualifier > @Repeatable(ContextNames.class) > public interface @ContextName { > String value; > } > public @interface ContextNames { > ContextName[] value(); > } > {code} > And then: > {code} > @ContextName("ctx1") > class CamelContext1 { > } > @ContextName("ctx2") > class CamelContext2 { > } > @Uri("") > @Produces > @ContextName("ctx1") > @ContextName("ctx2") > static ProducerTemplate producerTemplate(InjectionPoint ip, @Any Instance<CamelContext> instance) { > } > {code} > That enables to use annotations both as a CDI qualifiers and a metadata providers while still be relying on standard typesafe resolution mechanism during the deployment phase to detect unsatisfied or ambiguous dependencies. > Support of the annotation container / list for backward compatibility could be provided as well. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 6 months

1
0
0 / 0

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

by Jozef Hartinger (JIRA)

[ https://issues.jboss.org/browse/CDI-468?page=com.atlassian.jira.plugin.sy... ] Jozef Hartinger commented on CDI-468: ------------------------------------- Protype of the InvocationContext change: https://github.com/weld/api/blob/3.0.Alpha1/weld/src/main/java/org/jboss/... > 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 > > 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.3.1#6329)

9 years, 6 months

1
0
0 / 0

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

by Jozef Hartinger (JIRA)

[ https://issues.jboss.org/browse/CDI-486?page=com.atlassian.jira.plugin.sy... ] Jozef Hartinger updated CDI-486: -------------------------------- Priority: Critical (was: Major) Raising the priority as this should definitely be addressed. > 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 (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 (v6.3.1#6329)

9 years, 6 months

1
0
0 / 0

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

by Jozef Hartinger (JIRA)

[ https://issues.jboss.org/browse/CDI-486?page=com.atlassian.jira.plugin.sy... ] Jozef Hartinger commented on CDI-486: ------------------------------------- Yes, it would mean that the methods would be @CallerSensitive. > 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 > Fix For: 2.0 (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 (v6.3.1#6329)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (CDI-481) Introduce AnnotatedParameter.getJavaParameter()

by Jozef Hartinger (JIRA)

[ https://issues.jboss.org/browse/CDI-481?page=com.atlassian.jira.plugin.sy... ] Jozef Hartinger commented on CDI-481: ------------------------------------- Prototype of the new method: https://github.com/weld/api/blob/3.0.Alpha1/weld/src/main/java/org/jboss/... > Introduce AnnotatedParameter.getJavaParameter() > ----------------------------------------------- > > Key: CDI-481 > URL: https://issues.jboss.org/browse/CDI-481 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Portable Extensions > Reporter: Jozef Hartinger > > Make it possible to obtain the Java Reflection object representing the parameter. This is in line with > AnnotatedField.getJavaMember() > AnnotatedMethod.getJavaMember() > AnnotatedConstructor.getJavaMember() > Can be implemented as a default method such as: > {code:JAVA} > default Parameter getJavaParameter() { > Member member = getDeclaringCallable().getJavaMember(); > if (!(member instanceof Executable)) { > throw new IllegalStateException("Parameter does not belong to an executable " + member); > } > Executable executable = (Executable) member; > return executable.getParameters()[getPosition()]; > } > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (CDI-460) Support repeating annotations in CDI SPI

by Jozef Hartinger (JIRA)

[ https://issues.jboss.org/browse/CDI-460?page=com.atlassian.jira.plugin.sy... ] Jozef Hartinger commented on CDI-460: ------------------------------------- Prototype of the CDI SPI change that addresses JDK8 repeating annotations: https://github.com/weld/api/blob/3.0.Alpha1/weld/src/main/java/org/jboss/... > Support repeating annotations in CDI SPI > ---------------------------------------- > > Key: CDI-460 > URL: https://issues.jboss.org/browse/CDI-460 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Portable Extensions > Affects Versions: 2.0 (discussion) > Reporter: Antonin Stefanutti > > In CDI 1.2, it is not explicitly stated whether altering the annotation-based metadata in a way to add multiple annotations of the same type is possible or not. That situation occurs with the following combinations: > {{AnnotatedType.getAnnotations()}} and {{ProcessAnnotatedType.setAnnotatedType(AnnotatedType at)}}, > {{BeanAttributes.getQualifiers()}}, and {{ProcessBeanAttributes.setBeanAttributes(BeanAttributes ba)}}, > {{InjectionPoint.getQualifiers}} and {{ProcessInjectionPoint.setInjectionPoint(InjectionPoint ip)}}. > Being able to decorate these metadata with repeating annotations enables powerful and elegant use cases as discussed in [OWB-1004|https://issues.apache.org/jira/browse/OWB-1004], that is the ability to use an annotation both as a CDI qualifier and a metadata provider during injection. > Given that Java 8 provides support for [repeating annotations|http://docs.oracle.com/javase/tutorial/java/annotations/repea...], it seems logical to have repeating annotations supported at the CDI SPI level. Tough, that's important to have that support explicitly stated and specified in CDI. > Indeed, while Weld permits metadata alteration with repeating annotations, OpenWebBeans does not for the moment though developers understand the need and are willing to open that behavior as discussed in [OWB-1004|https://issues.apache.org/jira/browse/OWB-1004] as long as that support will be made explicit in the specification. > That applies as well for {{EventMetadata.getQualifiers}} in _read-only_. > While that request is technically independent from Java 8, it is correlated to the support of repeating qualifiers in the typesafe resolution mechanism that is likely to be treated as part of the Java 8 stream of the CDI 2.0 specification. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (CDI-458) Give the possibility to deactivate an observer in ProcessObserverMethod

by Jozef Hartinger (JIRA)

[ https://issues.jboss.org/browse/CDI-458?page=com.atlassian.jira.plugin.sy... ] Jozef Hartinger commented on CDI-458: ------------------------------------- Proposed SPI changes: https://github.com/weld/api/blob/3.0.Alpha1/weld/src/main/java/org/jboss/... > Give the possibility to deactivate an observer in ProcessObserverMethod > ----------------------------------------------------------------------- > > Key: CDI-458 > URL: https://issues.jboss.org/browse/CDI-458 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Events, Portable Extensions > Affects Versions: 1.2.Final > Reporter: Antoine Sabot-Durand > Fix For: 2.0 (discussion) > > > Today if a user want to deactivate an observer at deployment time, she needs to observes {{ProcessAnnotatedType}} with {{(a)WithAnnotation(Observes.class)}} and replace the annotatedType by a new one without the {{@Observes}} annotation. It's quite heavy to manage. > We could add a {{veto()}} method in {{ProcessObserverMethod}} to do this in a far easier and intuitive way. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 6 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev October 2014