[ https://issues.jboss.org/browse/CDI-599?page=com.atlassian.jira.plugin.sy... ] Mark Paluch updated CDI-599: ---------------------------- Description: 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} was: 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. -- This message was sent by Atlassian JIRA (v6.4.11#64026)