[
https://issues.jboss.org/browse/CDI-118?page=com.atlassian.jira.plugin.sy...
]
Dan Allen updated CDI-118:
--------------------------
Description:
While it's true that deployment exceptions are not a public API when developing with
the CDI programming model, they are a public API for tools and in testing environments. It
would be useful to standardize the deployment-related error and exception classes so that
these tools don't have to rely on classes from the implementation.
One example occurs in the CDI-TCK and it's counterpart, Arquillian. A test may want to
verify that the code will result in a deployment error. Currently, to detect this
exception, it's necessary to rely on an implementation specific exception class, which
makes the test non-portable.
Another example is a tool that starts a CDI runtime or server that provides CDI. The tool
has to check for the implementation-specific exception to know if the deployment error is
caused by CDI (and to capture and report that error). It's important both when CDI is
used for standalone bootstrap and for a container that provides CDI.
Proposed API:
javax.enterprise.inject.DeploymentException extends RuntimeException
was:
While it's true that deployment exceptions are not a public API when developing with
the CDI programming model, they are a public API for tools and in testing environments. It
would be useful to standardize the deployment-related error and exception classes so that
these tools don't have to rely on classes from the implementation.
One example occurs in the CDI-TCK and it's counterpart, Arquillian. A test may want to
verify that the code will result in a deployment error. Currently, to detect this
exception, it's necessary to rely on an implementation specific exception class, which
makes the test non-portable.
Another example is a tool that starts a CDI runtime or server that provides CDI. The tool
has to check for the implementation-specific exception to know if the deployment error is
caused by CDI (and to capture and report that error). It important both when CDI is used
for standalone bootstrap and for a container that provides CDI.
Proposed APIs:
javax.enterprise.inject.DeploymentException extends RuntimeException
Standardize deployment-related exception classes
------------------------------------------------
Key: CDI-118
URL:
https://issues.jboss.org/browse/CDI-118
Project: CDI Specification Issues
Issue Type: Feature Request
Components: Packaging and Deployment
Affects Versions: 1.0
Reporter: Dan Allen
Fix For: 1.1 (Proposed)
While it's true that deployment exceptions are not a public API when developing with
the CDI programming model, they are a public API for tools and in testing environments. It
would be useful to standardize the deployment-related error and exception classes so that
these tools don't have to rely on classes from the implementation.
One example occurs in the CDI-TCK and it's counterpart, Arquillian. A test may want
to verify that the code will result in a deployment error. Currently, to detect this
exception, it's necessary to rely on an implementation specific exception class, which
makes the test non-portable.
Another example is a tool that starts a CDI runtime or server that provides CDI. The tool
has to check for the implementation-specific exception to know if the deployment error is
caused by CDI (and to capture and report that error). It's important both when CDI is
used for standalone bootstrap and for a container that provides CDI.
Proposed API:
javax.enterprise.inject.DeploymentException extends RuntimeException
--
This message is automatically generated by JIRA.
For more information on JIRA, see:
http://www.atlassian.com/software/jira