October 2014 - cdi-dev - Jboss List Archives

[JBoss JIRA] (CDI-4) Need a way to provide ordering for Event observers

by Jozef Hartinger (JIRA)

[ https://issues.jboss.org/browse/CDI-4?page=com.atlassian.jira.plugin.syst... ] Jozef Hartinger commented on CDI-4: ----------------------------------- Proposed changes to @Priority and ObserverMethod SPI: https://github.com/weld/api/blob/3.0.Alpha1/weld/src/main/java/org/jboss/... https://github.com/weld/api/blob/3.0.Alpha1/weld/src/main/java/org/jboss/... > Need a way to provide ordering for Event observers > -------------------------------------------------- > > Key: CDI-4 > URL: https://issues.jboss.org/browse/CDI-4 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Events, Portable Extensions > Affects Versions: 1.0 > Environment: All > Reporter: Lincoln Baxter III > Assignee: Pete Muir > Fix For: 2.0 (discussion) > > > There needs to be a way to specify some kind of ordering for Event observers. > Understandably, this is somewhat counter-intuitive to the general concept of observing an event, but there is going to be need for this in an upcoming JBoss project. While it can be done manually, it might be nice to have a built-in API. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (CDI-475) Support type annotation in assignability of parameterized types

by Antonin Stefanutti (JIRA)

[ https://issues.jboss.org/browse/CDI-475?page=com.atlassian.jira.plugin.sy... ] Antonin Stefanutti commented on CDI-475: ---------------------------------------- Hi Jozef, In the provided use case, the event is delivered to the {{@Observes ProcessAnnotatedType<@ContextName ? extends CamelContext>}} method for the {{CamelContext}} type being annotated with the {{@ContextName}} annotation at the class level only. That differs from the semantic provided by the {{@WithAnnotations}} which meets another need. In that perspective, that story is broader than CDI-472 and can be applied to other lifecycle events, e.g.: {code} <X> void processManagedBean(@Observes ProcessManagedBean<@MyQualifier X>){} {code} where the {{ProcessManagedBean}} would be delivered for every managed bean of type {{X}} qualified with the {{@MyQualifier}} qualifier. Besides the semantic of type annotations for parameterized type assignability in the typesafe resolution mechanism has to be assessed, for example: {code} @Produces List<@MyAnnotation MyType> producer(){} @Inject List<@MyAnnotation MyType> list; {code} These are just ideas that should be elaborated in the [Java SE 8 enhancement workshop|https://docs.google.com/document/d/1KUaxXIXJ_r-h5UJGIij6I4vrLS7u...]. Hope that clarifies at least in what way that differs from CDI-472. > Support type annotation in assignability of parameterized types > --------------------------------------------------------------- > > Key: CDI-475 > URL: https://issues.jboss.org/browse/CDI-475 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Resolution > Reporter: Antonin Stefanutti > > Since Java 8 provides support for type annotations, the assignability of parameterized types rules could be updated to support that feature that may add value in a number of use cases. > For example, with lifecycle events resolution, instead of writing: > {code} > Set<Annotation> contextNames = new HashSet<>(); > void camelContextNames(@Observes ProcessAnnotatedType<? extends CamelContext> pat) { > if (pat.getAnnotatedType().isAnnotationPresent(ContextName.class)) > contextNames.add(pat.getAnnotatedType().getAnnotation(ContextName.class)); > } > {code} > One could directly write: > {code} > void camelContextNames(@Observes ProcessAnnotatedType<@ContextName ? extends CamelContext> pat) { > contextNames.add(pat.getAnnotatedType().getAnnotation(ContextName.class)); > } > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 2 months

1
0
0 / 0

Configuration

by Anatole Tresch

Hi All I would like to give you a short summary on Java (EE) Configuration after haviong discussed things with multiple stakeholders: - There is not enough momentum for SE related JSR as of now. That is basically not that bad as it sounds, since we can still tweak System.getProperties(). - The current SE related Configuration Proposal (and existing experimental code) is planned to be released into a new Apache Incubator project, where different stakeholders (Walmart, Sixt, Credit Suisse, LJC, SouJava, JUG Berlin Brandenburg, Redhat? ) can help to get that library to top level quality quickly. This way we can quite probably gain further assistance and support and might be able to file a JSR a bit later. This plan is well aligned with people from Oracle as well as Tomitriibe (David Blevins). - In the meantime Oracle proposed, we should take up Java (EE) configuration within CDI 2.0. Reza Razman meant that there were huge cost cuts be one of the reasons, why things were not further evolving there. This could change within the next year again and we should start with the work nevertheless in the meantime. It could even be that there will be some kind of JSR started for this as well. So summarizing, it would be probably a good idea to "restart" the configuration stream, I assume. Unfortunately I will miss the IRC chat this week quite probably due to holidays. -Anatole -- *Anatole Tresch* Java Engineer & Architect, JSR Spec Lead Glärnischweg 10 CH - 8620 Wetzikon *Switzerland, Europe Zurich, GMT+1* *Twitter: @atsticks* *Blogs: **http://javaremarkables.blogspot.ch/ <http://javaremarkables.blogspot.ch/>* *Google: atsticksMobile +41-76 344 62 79*

10 years, 2 months

1
0
0 / 0

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

by Mohan Radhakrishnan (JIRA)

[ https://issues.jboss.org/browse/CDI-486?page=com.atlassian.jira.plugin.sy... ] Mohan Radhakrishnan commented on CDI-486: ----------------------------------------- Hi, This JEP(http://openjdk.java.net/jeps/176) proposes a new way of enforcing the security permissions. Does this mean that the SPI methods will be annotated with @ CallerSensitive How does one update the issues list with these types of queries assuming it is valid ? I am still learning the ropes. Thanks, Mohan On Thu, Oct 2, 2014 at 12:44 PM, Jozef Hartinger (JIRA) <issues(a)jboss.org> > 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)

10 years, 2 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: ------------------------------------- We should probably introduce a new permission and make it a requirement for calling BeanManagerMethod methods such as createInjectionTarget(), createProducer(), etc. > 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)

10 years, 2 months

2
1
0 / 0

[JBoss JIRA] (CDI-475) Support type annotation in assignability of parameterized types

by Jozef Hartinger (JIRA)

[ https://issues.jboss.org/browse/CDI-475?page=com.atlassian.jira.plugin.sy... ] Jozef Hartinger commented on CDI-475: ------------------------------------- How is this different from CDI-472? > Support type annotation in assignability of parameterized types > --------------------------------------------------------------- > > Key: CDI-475 > URL: https://issues.jboss.org/browse/CDI-475 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Resolution > Reporter: Antonin Stefanutti > > Since Java 8 provides support for type annotations, the assignability of parameterized types rules could be updated to support that feature that may add value in a number of use cases. > For example, with lifecycle events resolution, instead of writing: > {code} > Set<Annotation> contextNames = new HashSet<>(); > void camelContextNames(@Observes ProcessAnnotatedType<? extends CamelContext> pat) { > if (pat.getAnnotatedType().isAnnotationPresent(ContextName.class)) > contextNames.add(pat.getAnnotatedType().getAnnotation(ContextName.class)); > } > {code} > One could directly write: > {code} > void camelContextNames(@Observes ProcessAnnotatedType<@ContextName ? extends CamelContext> pat) { > contextNames.add(pat.getAnnotatedType().getAnnotation(ContextName.class)); > } > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 2 months

1
0
0 / 0

Weld 3.0.0.Alpha1 released

by Jozef Hartinger

http://weld.cdi-spec.org/news/2014/10/02/weld-300Alpha1/

10 years, 2 months

2
1
0 / 0

[JBoss JIRA] (CDI-487) Clarify decorator beans relationship to EJB spec

by Tomas Remes (JIRA)

Tomas Remes created CDI-487: ------------------------------- Summary: Clarify decorator beans relationship to EJB spec Key: CDI-487 URL: https://issues.jboss.org/browse/CDI-487 Project: CDI Specification Issues Issue Type: Clarification Components: Decorators, Java EE integration Affects Versions: 1.2.Final Reporter: Tomas Remes In "8.1. Decorator beans" there are two following sentences: {quote} Decorators of a session bean must comply with the bean provider programming restrictions defined by the EJB specification. Decorators of a stateful session bean must comply with the rules for instance passivation and conversational state defined by the EJB specification. {quote} I guess the first sentence corresponds "somehow" to "4.9 The Responsibilities of the Bean Provider" in EJB spec. This EJB chapter (specifically 4.9.2) specifies e.g that session bean class must not be abstract. This seems to contradict bit with abstract decorator for session bean, which is legal in CDI. This restriction would be IMO unnecessary. I am also not sure about implications of the second sentence. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 2 months

1
0
0 / 0

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

by Jozef Hartinger (JIRA)

Jozef Hartinger created CDI-486: ----------------------------------- Summary: 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)

10 years, 2 months

1
0
0 / 0

Updated Invitation: CDI weekly meeting @ Weekly from 09:00 to 10:00 on Wednesday except Wed 1 Oct 09: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 09:00 to 10:00 on Wednesday except Wed 1 Oct 09:00 Pacific Time (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.

10 years, 2 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev October 2014