[JBoss JIRA] Created: (CDI-121) TransactionScope
by Richard Hightower (JIRA)
TransactionScope
----------------
Key: CDI-121
URL: https://issues.jboss.org/browse/CDI-121
Project: CDI Specification Issues
Issue Type: Feature Request
Components: Contexts
Affects Versions: 1.1 (Proposed)
Environment: Java EE
Reporter: Richard Hightower
Priority: Minor
Add TransctionalScope as a standard scope to define beans whose lifecycle is the same as a given transaction.
This scope should start automatically when a transaction starts (but lazily when actually needed).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 4 months
calling 'equals' on a proxy?
by Mark Struberg
Hi Pete, others!
Do you remember our discussion about what should happen if equals() gets called on a proxy?
Should it route to the equals method of the currently proxied instance?
LieGrue,
strub
13 years, 2 months
[JBoss JIRA] Created: (CDI-118) Standardize deployment-related exception classes
by Dan Allen (JIRA)
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 important both when CDI is used for standalone bootstrap and for a container that provides CDI.
Proposed APIs:
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
13 years, 2 months
[JBoss JIRA] Created: (CDI-119) Standard way to obtain a BeanManager regardless of environment
by Cloves Almeida (JIRA)
Standard way to obtain a BeanManager regardless of environment
--------------------------------------------------------------
Key: CDI-119
URL: https://issues.jboss.org/browse/CDI-119
Project: CDI Specification Issues
Issue Type: Feature Request
Reporter: Cloves Almeida
Priority: Minor
As an alternative to #CDI-117:
There should be a standard way to obtain a BeanManager instance regardless of environment. I propose a BeanManagerFactory that would implement the following resolution:
1) if in a JEE environment, use the JNDI resolution already proposed on spec
2) if in a non-JEE servlet container, use the servlet context attribute as proposed in #CDI-117
3) else, fallback on a "singleton" BeanManager
For extensability, one could override the resolution mechanism by providing his own BeanManagerResolver.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 3 months
[JBoss JIRA] Created: (CDI-133) Further clarify the notion of a decorated type
by Marius Bogoevici (JIRA)
Further clarify the notion of a decorated type
----------------------------------------------
Key: CDI-133
URL: https://issues.jboss.org/browse/CDI-133
Project: CDI Specification Issues
Issue Type: Clarification
Reporter: Marius Bogoevici
Priority: Optional
Essentially, remove the period between the first and second statement and use a single phrase instead:
{quote}
The set of decorated types of a decorator includes all bean types of the managed bean which are Java interfaces, except for <literal>java.io.Serializable</literal>. The decorator bean class and its superclasses are not decorated types of the decorator.
{quote}
This is a rather cosmetic change, but can improve the readability of the section.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 3 months