Transaction Scope for CDI
by Reza Rahman
CDI enthusiasts,
Pete, I and Nigel (JMS 2 spec lead) have been discussing the issue of the
transaction scope behind the scenes the past few weeks. Attached is what we
came up with and feel it meets the various related use-cases the most
effectively. The downside is that it is quite involved (conceptually) and
might take a bit of patience to absorb. Please give it a read and let me
know your thoughts.
Cheers,
Reza
12 years
[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
Mutable annotation literals
by Pete Muir
All
Marko has added caching for the hashcode value on AnnotationLiteral, which is based on the premise that an AnnotationLiteral is not mutable.
https://github.com/luksa/cdi/commit/f3c200fcdf8ca8681c194c921567aedcce375102
This is a reasonable thing to require (as real annotations are normally immutable!) and a very good optimisation, however it is not backwards compatible, as we have not previously required AnnotationLiteral to be immutable.
An alternative option is to introduce the ImmutableAnnotationLiteral subclass, which would require any concrete instances to be immutable and could use this optimisation. We could "deprecate" AnnotationLiteral (as described in java.net/projects/javaee-spec/pages/CompatibilityRequirements).
Note that regardless, we can apply the minor optimisation suggested by Mark, that we return 0 if the annotation has no members.
Pete
12 years
[JBoss JIRA] (CDI-232) Relax requirements for built-in Instance
by Martin Kouba (JIRA)
Martin Kouba created CDI-232:
--------------------------------
Summary: 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.EDR1
Reporter: Martin Kouba
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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years
[JBoss JIRA] (CDI-189) Event qualifiers - empty set
by Jozef Hartinger (Created) (JIRA)
Event qualifiers - empty set
----------------------------
Key: CDI-189
URL: https://issues.jboss.org/browse/CDI-189
Project: CDI Specification Issues
Issue Type: Bug
Components: Events
Affects Versions: 1.1.EDR1, 1.0
Reporter: Jozef Hartinger
Priority: Minor
Fix For: 1.1.EDR2
The spec says:
{quote}
An event comprises:
* A Java object—the event object
* A (*possibly empty*) set of instances of qualifier types—the event qualifiers
{quote}
while at the same it says that:
{quote}
*Every* event has the qualifier @javax.enterprise.inject.Any, even if it does not explicitly declare this qualifier.
{quote}
which impliest that a set of qualifiers of an event cannot be empty.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years
[JBoss JIRA] (CDI-192) Unify coding style of the SPI interfaces
by Jozef Hartinger (Created) (JIRA)
Unify coding style of the SPI interfaces
----------------------------------------
Key: CDI-192
URL: https://issues.jboss.org/browse/CDI-192
Project: CDI Specification Issues
Issue Type: Bug
Components: Portable Extensions
Affects Versions: 1.1.EDR1
Reporter: Jozef Hartinger
Priority: Trivial
Fix For: 1.1 (Proposed)
The [JLS|http://java.sun.com/docs/books/jls/third_edition/html/interfaces.html...] says:
{quote}
For compatibility with older versions of the Java platform, it is permitted but discouraged, as a matter of style, to redundantly specify the abstract modifier for methods declared in interfaces.
It is permitted, but strongly discouraged as a matter of style, to redundantly specify the public modifier for interface methods.
{quote}
The vast majority of CDI API interfaces specifies the public modifier while leaving out the abstract modifier, however, there are exceptions:
{code:JAVA}
public interface Context {
...
boolean isActive();
}
{code}
{code:JAVA}
public interface BeanAttributes<T> {
public abstract Set<Type> getTypes();
public abstract Set<Annotation> getQualifiers();
...
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years