[JBoss JIRA] (CDI-471) Support repeating qualifiers in typesafe resolution mechanism
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-471?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand updated CDI-471:
-------------------------------------
Sprint: Sprint 1
> 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
> Labels: F2F2016
> Fix For: 2.0 .Final
>
>
> 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.4.11#64026)
7 years, 9 months
[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:
-------------------------------------
Sprint: Sprint 1
> 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, 9 months
[JBoss JIRA] (CDI-490) Clarify what happens when an interceptor/decorator is enabled using both @Priority and beans.xml
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-490?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand updated CDI-490:
-------------------------------------
Sprint: Sprint 1
> Clarify what happens when an interceptor/decorator is enabled using both @Priority and beans.xml
> ------------------------------------------------------------------------------------------------
>
> Key: CDI-490
> URL: https://issues.jboss.org/browse/CDI-490
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Decorators, Interceptors
> Affects Versions: 1.2.Final
> Reporter: Jozef Hartinger
> Labels: F2F2016
> Fix For: 2.0 .Final
>
>
> Suppose an InterceptorA has @Priority and is also listed in the beans.xml file of a particular BDA. Such interceptor is for sure enabled because:
> {quote}An interceptor is said to be enabled if it is enabled in at least one bean archive or is listed in the final
> list of interceptors for the application, as defined in Section 11.5.2, “AfterTypeDiscovery event”.{quote}
> it matches both parts of the statement.
> As for ordering, the following statement defines invocation order:
> {quote}Interceptors enabled using @Priority are called before interceptors enabled using beans.xml.{quote}
> Since InterceptorA is enabled by both @Priority and beans.xml, the following applies:
> "Interceptors enabled using @Priority" = \{ InterceptorA \}
> "interceptors enabled using beans.xml" = \{ InterceptorA \}
> We can perform substitution in the statement and we get:
> *\{ InterceptorA \} are called before \{ InterceptorA \}*
> which does not seem right.
> The specification should explicitly address this scenario. There are several options (some of them are better, some are worse):
> 1) Invoke the interceptor twice - each time in the corresponding order given by priority and position in beans.xml
> 2) Invoke the interceptor once in the @Priority part of the invocation chain (@Priority has precedence)
> 3) Invoke the interceptor once in the beans.xml part of the invocation chain (beans.xml has precedence)
> 4) Forbid an interceptor to be enabled by both @Priority and beans.xml
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 9 months
[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:
-------------------------------------
Sprint: Sprint 1
> 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
(v6.4.11#64026)
7 years, 9 months
[JBoss JIRA] (CDI-449) beans.xml examples are not valid
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-449?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand updated CDI-449:
-------------------------------------
Sprint: Sprint 1
> beans.xml examples are not valid
> --------------------------------
>
> Key: CDI-449
> URL: https://issues.jboss.org/browse/CDI-449
> Project: CDI Specification Issues
> Issue Type: Bug
> Affects Versions: 1.2.Final
> Reporter: Martin Kouba
> Fix For: 2.0 .Final
>
>
> The {{beans.xml}} examples in "5.1.1. Declaring selected alternatives", "8.2.2. Decorator enablement and ordering for a bean archive" and "9.4. Interceptor enablement and ordering" (which contain a reference to beans_1_1.xsd) are not valid - {{bean-discovery-mode}} attribute is required. I think it would be appropriate to specify the version attribute as well.
> The last {{beans.xml}} example in "12.4.2. Exclude filters" does not even define the reference to an XSD. Again, I believe the version and bean-discovery-mode attributes should be specified.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 9 months
[JBoss JIRA] (CDI-622) External post-configuration of a bean
by Sven Linstaedt (JIRA)
[ https://issues.jboss.org/browse/CDI-622?page=com.atlassian.jira.plugin.sy... ]
Sven Linstaedt commented on CDI-622:
------------------------------------
>From an integration point of view this proposal may be interesting as afaik there is no "standard" way to configure beans/extensions currently. Each framework and/or extension has their own way to do this. E.g. even deltaspike has several different abstractions of configuration to enable users to customize it for their use.
> External post-configuration of a bean
> -------------------------------------
>
> Key: CDI-622
> URL: https://issues.jboss.org/browse/CDI-622
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Reporter: John Ament
> Fix For: 2.1 (Discussion)
>
>
> The use case here is that a framework has provided the application developer with some bean, X. While the framework can provide internal post construction support for this bean, the application developer has some need to set additional attributes on the bean prior to the bean being injected into its final target.
> The application developer currently has no way to do this. To accomplish this feat, the framework developer must put the burden on the application developer to do both configuration and bootstrapping of this bean. This is a bit of a pain point to be honest.
> One idea I had was to introduce a {{@Configures}} annotation that could be used, similar to observers. These methods (plural) could be called (based on priority) during the post construct phase and may exist in any managed bean.
> {code}
> @Configures
> public void setupWebServer(WebServer webserver, Configuration configuration) {
> webserver.setPort(configuration.getWebServerPort());
> }
> {code}
> In this case, webserver is the bean being configured, configuration is some other bean that retains the configuration data. This should support normal qualifiers, and perhaps provide an injection point for the underlying {{InjectionTarget}}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 9 months
[JBoss JIRA] (CDI-523) CDI spec tries to dispose a container-managed entity manager.
by John Ament (JIRA)
[ https://issues.jboss.org/browse/CDI-523?page=com.atlassian.jira.plugin.sy... ]
Work on CDI-523 started by John Ament.
--------------------------------------
> CDI spec tries to dispose a container-managed entity manager.
> -------------------------------------------------------------
>
> Key: CDI-523
> URL: https://issues.jboss.org/browse/CDI-523
> Project: CDI Specification Issues
> Issue Type: Bug
> Affects Versions: 1.2.Final, 1.1.Final
> Reporter: Martin Andersson
> Assignee: John Ament
> Fix For: 2.0 .Final
>
>
> Section "3.5.2. Declaring a disposer method" has this example:
> {code:java}
> public class Resources {
> @PersistenceContext
> @Produces @UserDatabase
> private EntityManager em;
>
> public void close(@Disposes @UserDatabase EntityManager em) {
> em.close();
> }
> }
> {code}
> The disposer method above call {{EntityManager.close()}} on a container-managed entity manager which result in an {{IllegalStateException}} being thrown *and* the entity manager remains open. This behavior is expected as the JPA specification forbids application code to close a container-managed entity manager. JPA 2.1, section "7.9.1 Container Responsibilities" says:
> {quote}
> The container must throw the IllegalStateException if the application calls EntityManager.close on a container-managed entity manager.
> {quote}
> This has been proved [here|https://github.com/MartinanderssonDotcom/java-ee-concepts/blob/maste...] and a theoretical walkthough surrounding entity managers combined with CDI scopes is available [here|https://github.com/MartinanderssonDotcom/java-ee-concepts/blob/maste...].
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 9 months
[JBoss JIRA] (CDI-523) CDI spec tries to dispose a container-managed entity manager.
by John Ament (JIRA)
[ https://issues.jboss.org/browse/CDI-523?page=com.atlassian.jira.plugin.sy... ]
John Ament reassigned CDI-523:
------------------------------
Assignee: John Ament
> CDI spec tries to dispose a container-managed entity manager.
> -------------------------------------------------------------
>
> Key: CDI-523
> URL: https://issues.jboss.org/browse/CDI-523
> Project: CDI Specification Issues
> Issue Type: Bug
> Affects Versions: 1.2.Final, 1.1.Final
> Reporter: Martin Andersson
> Assignee: John Ament
> Fix For: 2.0 .Final
>
>
> Section "3.5.2. Declaring a disposer method" has this example:
> {code:java}
> public class Resources {
> @PersistenceContext
> @Produces @UserDatabase
> private EntityManager em;
>
> public void close(@Disposes @UserDatabase EntityManager em) {
> em.close();
> }
> }
> {code}
> The disposer method above call {{EntityManager.close()}} on a container-managed entity manager which result in an {{IllegalStateException}} being thrown *and* the entity manager remains open. This behavior is expected as the JPA specification forbids application code to close a container-managed entity manager. JPA 2.1, section "7.9.1 Container Responsibilities" says:
> {quote}
> The container must throw the IllegalStateException if the application calls EntityManager.close on a container-managed entity manager.
> {quote}
> This has been proved [here|https://github.com/MartinanderssonDotcom/java-ee-concepts/blob/maste...] and a theoretical walkthough surrounding entity managers combined with CDI scopes is available [here|https://github.com/MartinanderssonDotcom/java-ee-concepts/blob/maste...].
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 9 months
[JBoss JIRA] (CDI-632) Possible conflict for Implicit bean archive definition between core and SE
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-632?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand updated CDI-632:
-------------------------------------
Fix Version/s: TBD
> Possible conflict for Implicit bean archive definition between core and SE
> --------------------------------------------------------------------------
>
> Key: CDI-632
> URL: https://issues.jboss.org/browse/CDI-632
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Java SE Integration
> Affects Versions: 2.0-EDR2
> Reporter: Antoine Sabot-Durand
> Priority: Minor
> Fix For: TBD
>
>
> Section 12.1 (which should be satisfied in SE an EE) states:
> bq. An implicit bean archive is any other archive which contains one or more bean classes with a bean defining annotation as defined in Bean defining annotations.
> And section 15.1 reads:
> {quote}When running in Java SE, the container must extend the rules defined in Bean archives and also ensure that :
> An archive which doesn’t contain a beans.xml file can’t be discovered as an implicit bean archive unless:
> * the application is launched with system property javax.enterprise.inject.scan.implicit set to true, or
> * the container was initialized with a parameter map containing an entry with javax.enterprise.inject.scan.implicit as key and Boolean.TRUE as value.{quote}
> Perhaps this deserve a bit of clarification.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 9 months
[JBoss JIRA] (CDI-614) Review all read methods at configurators
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-614?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand updated CDI-614:
-------------------------------------
Fix Version/s: 2.0 .Final
> Review all read methods at configurators
> ----------------------------------------
>
> Key: CDI-614
> URL: https://issues.jboss.org/browse/CDI-614
> Project: CDI Specification Issues
> Issue Type: Clarification
> Affects Versions: 2.0-EDR2
> Reporter: Tomas Remes
> Fix For: 2.0 .Final
>
>
> Currently there are several read methods used to initialize given configurator. These methods are at:
> * {{BeanConfigurator}}
> * {{InjectionPointConfigurator}}
> * {{ObserverMethodConfigurator}}
> I think we should review all of them. I don't understand to usage or let say additional value of the following ones:
> * {{ObserverMethodConfigurator#read(javax.enterprise.inject.spi.ObserverMethod<T>)}}
> This allows you to add new observer method based on exsiting one. Although when you want to define some observed type (of this new method) you need to specify subtype of the original type or you will end up with ClassCastException.
> Then there are those at {{InjectionPointConfigurator}} which appears to me completely useless:
> * {{InjectionPointConfigurator#read(java.lang.reflect.Field)}}
> * {{InjectionPointConfigurator#read(java.lang.reflect.Parameter)}}
> * {{InjectionPointConfigurator#read(javax.enterprise.inject.spi.AnnotatedField<?>)}}
> * {{InjectionPointConfigurator#read(javax.enterprise.inject.spi.AnnotatedParameter<?>)}}
> * {{InjectionPointConfigurator#read(javax.enterprise.inject.spi.InjectionPoint)}}
> AFAIK the {{InjectionPointConfigurator}} is available only during {{ProcessInjectionPoint}} lifecycle event. My question is why should I use any of these during this lifecycle event since I can easily call {{event.configureInjectionPoint()}}? Do we want to allow to configure different injection point in non corresponding {{ProcessInjectionPoint}} lifecycle event?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 9 months