[cdi-dev] [JBoss JIRA] (CDI-599) New lifecycle event to handle deployment/statup errors

[Antoine Sabot-Durand (JIRA)]

     [ https://issues.jboss.org/browse/CDI-599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Antoine Sabot-Durand closed CDI-599.
------------------------------------
    Resolution: Rejected


too complex to solve one use case. Feature will be done in CDi-527

> New lifecycle event to handle deployment/statup errors
> ------------------------------------------------------
>
>                 Key: CDI-599
>                 URL: https://issues.jboss.org/browse/CDI-599
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Events
>            Reporter: Mark Paluch
>
> With CDI 1.2 the only way to react to deployment/validation errors is to fail on the container start.  Some exceptions could be handled/suppressed such as {{UnproxyableResolutionException}}. This ticket is to discuss a new lifecycle event which carries a deployment/validation error so a SPI developer can handle this problem. An example would be to allow unproxyable types in which case the error is reported, a portable extension tells the event to suppress the problem. This way the problem is handled and does not prevent the container start.
> For the concrete example of allowing proxying of classes with non-private final methods the user gets a mechanism to run an application which does not conform fully with the CDI spec rules but at least the user is able to use his application.
> An example API could look like:
> {code}
> /**
>  * The container fires an event of this type for each deployment validation problem. Unhandled validation problems lead to a
>  * startup exception. Deployment validations can be handled so the container startup is no longer prevented by handled problems.
>  */
> public interface ProcessDeploymentValidation {
> }
> /**
>  * The container fires an event of this type in case of multiple beans match a certain combination of required type and required
>  * qualifiers and are eligible for injection. This problem can be handled by resolving a bean using {@link #resolve(Bean)}.
>  */
> public interface ProcessAmbiguousResolution extends ProcessDeploymentValidation {
>     /**
>      * 
>      * @return the affected InjectionPoint.
>      */
>     InjectionPoint getInjectionPoint();
>     /**
>      * 
>      * @return the set of matching beans for the InjectionPoint.
>      */
>     Set<Bean<?>> getMatchingBeans();
>     /**
>      * Clarify bean resolution by specifying the bean to inject.
>      * 
>      * @param bean
>      */
>     void resolve(Bean<?> bean);
> }
> /**
>  * The container fires an event of this type in case no bean matches a certain combination of required type and required
>  * qualifiers and is eligible for injection. This problem can be handled by providing a bean using {@link #resolve(Bean)}.
>  */
> public interface ProcessUnsatisfiedResolution extends ProcessDeploymentValidation {
>     /**
>      * 
>      * @return the affected InjectionPoint.
>      */
>     InjectionPoint getInjectionPoint();
>     /**
>      * Clarify bean resolution by specifying the bean to inject.
>      * 
>      * @param bean
>      */
>     void resolve(Bean<?> bean);
> }
> /**
>  * The container fires an event of this type in case a contextual reference for a bean with a normal scope and a certain bean
>  * type cannot be obtained because the bean type cannot be proxied by the container.
>  */
> public interface ProcessUnproxyableResolution extends ProcessDeploymentValidation {
>     /**
>      * The unproxyable bean.
>      * 
>      * @return
>      */
>     Bean<?> getBean();
>     /**
>      * Suppres this problem and allow bean instances that are partially unproxied.
>      */
>     void allowUnproxyable();
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)