[JBoss JIRA] (CDI-282) Vetoing types - clarify consequences
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-282?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba commented on CDI-282:
----------------------------------
In fact I was thinking of something like this:
{code}
@Vetoed
@Target({ TYPE, METHOD, PARAMETER, FIELD })
@Retention(RUNTIME)
@Documented
@Qualifier
public @interface Predator {
}
/**
* Predator annotation is vetoed. Does it mean the Tiger bean has Any and Default qualifiers only?
*/
@Predator
public class Tiger {
}
{code}
> Vetoing types - clarify consequences
> ------------------------------------
>
> Key: CDI-282
> URL: https://issues.jboss.org/browse/CDI-282
> Project: CDI Specification Issues
> Issue Type: Clarification
> Reporter: Martin Kouba
> Assignee: Pete Muir
> Priority: Critical
> Fix For: 1.1.PFD
>
>
> The spec currently says {{@Vetoed}} type is *prevented from being considered by CDI* and {{ProcessAnnotatedType.veto()}} forces the container to ignore the type. This is quite obvious for classes and interfaces. However not so clear when vetoing annotations (e.g. qualifier). I think ignoring means not being considered as qualifier (thus affects resolution). Other (rather theoretical) example is vetoing non-contextual instances - should it prevent performing dependency injection?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 12 months
FYI : Adopt-A-JSR Kickoff - JSR #346 a.k.a. CDI 1.1
by w0mbat
Hey folks!
I just wanted to inform everybody, that the JUG Cologne will be holding a Kickoff Event for CDI 1.1 on Friday, 18. Jan. 2013 because we joined the Adopt-A-JSR program.
We will be presenting some general information about the program and what we want to achieve with it. The will be a CDI HackNight afterwards where everybody can join in.
The first part will be presented onsite but we will stream it via Hangout OnAIr into the world. The results of the HackNight will be summarized afterwards and made public to everyone.
If you have anything special that should be discussed, presented or tested, please let me know! I am always there for ideas, criticism and feedback.
Last but not least the official link to the event:
https://plus.google.com/events/cugl8udr2uqka40ob9lejjutifc
Cheers,
Daniel Sachse
--
Wombat Software Technologies
Inh. Daniel Sachse
Bremsstraße 6c, D-50969 Köln
Web: http://www.w0mb.at
Email: mail(a)w0mb.at
Phone: 0221/16905638
Mobile: 01578/4922886
11 years, 12 months
Type closure
by Arne Limburg
Hi,
I just stumbled about the org.jboss.jsr299.tck.tests.implementation.producer.field.definition.ProducerFieldDefinitionTest.testApiTypeForArrayTypeReturn test from the tck,
which tests (among other things) that a bean of type Spider-array has just two types: Spider[].class and Object.class. This makes me wonder, since Spider[] also implements Clonable and Serializable. So my question:
Do Clonable and Serializable belong to the type closure of a bean? If not, where can I find the corresponding part in the spec?
Regards,
Arne
11 years, 12 months
[JBoss JIRA] (CDI-232) Relax requirements for built-in Instance
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-232?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba commented on CDI-232:
----------------------------------
By the way this applies to the built-in Event as well.
{quote}
The container must provide a built-in bean with:
* Event<X> in its set of bean types, for every Java type X that does not contain a type variable,
* ...
{quote}
> 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.EDR
> Reporter: Martin Kouba
> Fix For: TBD
>
>
> 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
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 12 months
[JBoss JIRA] (CDI-289) Clarify what happens if a CDI-scoped stateful session bean is removed due to exception
by João Bosco Monteiro (JIRA)
[ https://issues.jboss.org/browse/CDI-289?page=com.atlassian.jira.plugin.sy... ]
João Bosco Monteiro commented on CDI-289:
-----------------------------------------
Where is the FAQ? I would like to know how to proceed in such cases
> Clarify what happens if a CDI-scoped stateful session bean is removed due to exception
> --------------------------------------------------------------------------------------
>
> Key: CDI-289
> URL: https://issues.jboss.org/browse/CDI-289
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Java EE integration
> Affects Versions: 1.1.PRD
> Reporter: Jozef Hartinger
> Assignee: Pete Muir
> Labels: faq
> Fix For: 1.1 (Proposed)
>
>
> {code:JAVA}
> @ApplicationScoped
> @Stateful
> public class Foo {
> ...
> }
> {code}
> According to the EJB spec (4.6.2) the instance of Foo will be removed if a method invocation on Foo throws a runtime exception that is not an application exception. CDI should clarify if in that case a new instance of Foo replaces the old instance or whether the clients will keep receiving NoSuchEJBException for the rest of the application lifetime.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 12 months
