June 2016 - cdi-dev - Jboss List Archives

'implicit bean' definition, section 2.5.1

by Mark Struberg

"A bean class with a bean defining annotation is said to be an implicit bean." That sounds pretty weird to me. I would have expected it exactly the other way around. A bean with a @SessionScoped annotation is rather an explicit bean to me. Any reason for this section? LieGrue, strub

8 years, 9 months

2
2
0 / 0

[JBoss JIRA] (CDI-420) add a bean-discovery-mode 'scoped'

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-420?page=com.atlassian.jira.plugin.sy... ] Martin Kouba commented on CDI-420: ---------------------------------- Hm, what about making it more generic? E.g. something like introducing "exclude filters" for Bean discovery: {code:xml} <beans xmlns="http://xmlns.jcp.org/xml/ns/javaee">  <scan> <exclude name="com.acme.rest.*" /> </scan>  <process> <exclude name="*"> <if-no-bean-defining-annotation /> </exclude> </process> </beans> {code} > add a bean-discovery-mode 'scoped' > ---------------------------------- > > Key: CDI-420 > URL: https://issues.jboss.org/browse/CDI-420 > Project: CDI Specification Issues > Issue Type: Bug > Components: Packaging and Deployment > Affects Versions: TBD > Reporter: Mark Struberg > Fix For: 2.0 (discussion) > > > This is for some future CDI release. > We currently only have 3 bean-discovery-modes > * none > * all > * annotated > The spec also currently says that ProcessAnnotatedType will only get fired (12.4) for > • each Java class, interface or enum deployed in an explicit bean archive, and > • each Java class with a bean defining annotation in an implicit bean archive. > • each session bean > Which means that we do not get the ProcessAnnotatedType (PAT) event for any class in an 'annotated' or 'implicit' BDA which does _not_ have a bean defining annotation. > It might be useful to fire the ProcessAnnotatedType for all classes, but do not pick them up as Beans if they (after PAT) do not have a valid scope. Effectively doing the processing but not make them @Dependent automatically if there is no scope annotation at the end of the PAT processing. > I'm not yet 100% sure how important this distinction is in practice. Just writing this up to not forget about the idea... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (CDI-420) add a bean-discovery-mode 'scoped'

by Mark Struberg (JIRA)

[ https://issues.jboss.org/browse/CDI-420?page=com.atlassian.jira.plugin.sy... ] Mark Struberg commented on CDI-420: ----------------------------------- I thought about this now for quite a few weeks. I think we should still address this within the spec. It would be a shame if we would have to add an Extension for this. It should really be part of core CDI. There are 2 options left in the game: 1.) {code} <beans bean-discovery-mode="scoped">.. {code} 2.) {code} <beans bean-discovery-mode="all"> <autoDependent>false</autoDependent> {code} > add a bean-discovery-mode 'scoped' > ---------------------------------- > > Key: CDI-420 > URL: https://issues.jboss.org/browse/CDI-420 > Project: CDI Specification Issues > Issue Type: Bug > Components: Packaging and Deployment > Affects Versions: TBD > Reporter: Mark Struberg > Fix For: 2.0 (discussion) > > > This is for some future CDI release. > We currently only have 3 bean-discovery-modes > * none > * all > * annotated > The spec also currently says that ProcessAnnotatedType will only get fired (12.4) for > • each Java class, interface or enum deployed in an explicit bean archive, and > • each Java class with a bean defining annotation in an implicit bean archive. > • each session bean > Which means that we do not get the ProcessAnnotatedType (PAT) event for any class in an 'annotated' or 'implicit' BDA which does _not_ have a bean defining annotation. > It might be useful to fire the ProcessAnnotatedType for all classes, but do not pick them up as Beans if they (after PAT) do not have a valid scope. Effectively doing the processing but not make them @Dependent automatically if there is no scope annotation at the end of the PAT processing. > I'm not yet 100% sure how important this distinction is in practice. Just writing this up to not forget about the idea... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (CDI-613) Container should be able to receive information about the context in which it was bootstraped

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-613?page=com.atlassian.jira.plugin.sy... ] Martin Kouba commented on CDI-613: ---------------------------------- I believe it is a more general problem (not only Java EE). A portable extension is instantiated by the CDI container and as such has no "reference" to any related technology/framework resources during bootstrap (i.e. during container lifecycle event delivery). So I think a kind of _"bootstrap configuration/metadata"_ is missing. The truth is this would probably require a standardized Bootstrap API. And this would be tricky, especially in the context of Java EE. > Container should be able to receive information about the context in which it was bootstraped > --------------------------------------------------------------------------------------------- > > Key: CDI-613 > URL: https://issues.jboss.org/browse/CDI-613 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Java EE integration > Reporter: Antoine Sabot-Durand > Fix For: 2.0 (proposed) > > > Today it's impossible to know what is the outside context of the CDI container (i.e what is the application or EE module it belongs to). > This is problematic for other spec like JPA who needs to retrieve their information (persistence units) from a portable extension. > This would help solving issues like WFLY-2387 in a portable way. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (CDI-613) Container should be able to receive information about the context in which it was bootstraped

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-613?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-613: ------------------------------------- Fix Version/s: 2.0 (proposed) > Container should be able to receive information about the context in which it was bootstraped > --------------------------------------------------------------------------------------------- > > Key: CDI-613 > URL: https://issues.jboss.org/browse/CDI-613 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Java EE integration > Reporter: Antoine Sabot-Durand > Fix For: 2.0 (proposed) > > > Today it's impossible to know what is the outside context of the CDI container (i.e what is the application or EE module it belongs to). > This is problematic for other spec like JPA who needs to retrieve their information (persistence units) from a portable extension. > This would help solving issues like WFLY-2387 in a portable way. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (CDI-613) Container should be able to receive information about the context in which it was bootstraped

by Antoine Sabot-Durand (JIRA)

Antoine Sabot-Durand created CDI-613: ---------------------------------------- Summary: Container should be able to receive information about the context in which it was bootstraped Key: CDI-613 URL: https://issues.jboss.org/browse/CDI-613 Project: CDI Specification Issues Issue Type: Feature Request Components: Java EE integration Reporter: Antoine Sabot-Durand Today it's impossible to know what is the outside context of the CDI container (i.e what is the application or EE module it belongs to). This is problematic for other spec like JPA who needs to retrieve their information (persistence units) from a portable extension. This would help solving issues like WFLY-2387 in a portable way. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (CDI-612) ObserverMethodConfigurator.notifyWith() should probably accept a functional interface whose method throws java.lang.Exception

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-612?page=com.atlassian.jira.plugin.sy... ] Martin Kouba updated CDI-612: ----------------------------- Fix Version/s: 2.0-EDR2 > ObserverMethodConfigurator.notifyWith() should probably accept a functional interface whose method throws java.lang.Exception > ----------------------------------------------------------------------------------------------------------------------------- > > Key: CDI-612 > URL: https://issues.jboss.org/browse/CDI-612 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 2.0-EDR1 > Reporter: Martin Kouba > Fix For: 2.0-EDR2 > > > The regular observer methods may also throw checked exceptions (wrapped and rethrown as an (unchecked) {{ObserverException}}). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (CDI-612) ObserverMethodConfigurator.notifyWith() should probably accept a functional interface whose method throws java.lang.Exception

by Martin Kouba (JIRA)

Martin Kouba created CDI-612: -------------------------------- Summary: ObserverMethodConfigurator.notifyWith() should probably accept a functional interface whose method throws java.lang.Exception Key: CDI-612 URL: https://issues.jboss.org/browse/CDI-612 Project: CDI Specification Issues Issue Type: Clarification Affects Versions: 2.0-EDR1 Reporter: Martin Kouba The regular observer methods may also throw checked exceptions (wrapped and rethrown as an (unchecked) {{ObserverException}}). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (CDI-611) Enhance 10.3.3. Multiple event qualifiers section

by John Ament (JIRA)

[ https://issues.jboss.org/browse/CDI-611?page=com.atlassian.jira.plugin.sy... ] John Ament commented on CDI-611: -------------------------------- The fact that event qualifiers and bean qualifiers don't work the same way is still an issue for a number of developers I've worked with. > Enhance 10.3.3. Multiple event qualifiers section > ------------------------------------------------- > > Key: CDI-611 > URL: https://issues.jboss.org/browse/CDI-611 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Affects Versions: 2.0-EDR1 > Reporter: Matej Novotny > > While the current spec is in fact correct, it is quite hard to decipher what it is actually trying to convey. > Elsewhere in the spec, we talk about subsets of qualifiers while here we don't. There is a code sample and a sentence saying *"Then this observer method will only be notified if all the observed event qualifiers are specified when the event is fired:"* > This can be interpreted as: > * _"I must fire an event with exactly the same qualifiers as this observer has in order to notify it"_ (*wrong assumption* - it can have more qualifiers) > * _"I must fire an event which will contain at least the same qualifiers as this observer has in order to notify it"_ (*correct* - yet not so obvious) > I will try to come up with some improvement to make this clear. As it is, it always takes me several reading to soak it in. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (CDI-611) Enhance 10.3.3. Multiple event qualifiers section

by Matej Novotny (JIRA)

Matej Novotny created CDI-611: --------------------------------- Summary: Enhance 10.3.3. Multiple event qualifiers section Key: CDI-611 URL: https://issues.jboss.org/browse/CDI-611 Project: CDI Specification Issues Issue Type: Clarification Components: Events Affects Versions: 2.0-EDR1 Reporter: Matej Novotny While the current spec is in fact correct, it is quite hard to decipher what it is actually trying to convey. Elsewhere in the spec, we talk about subsets of qualifiers while here we don't. There is a code sample and a sentence saying *"Then this observer method will only be notified if all the observed event qualifiers are specified when the event is fired:"* This can be interpreted as: * _"I must fire an event with exactly the same qualifiers as this observer has in order to notify it"_ (*wrong assumption* - it can have more qualifiers) * _"I must fire an event which will contain at least the same qualifiers as this observer has in order to notify it"_ (*correct* - yet not so obvious) I will try to come up with some improvement to make this clear. As it is, it always takes me several reading to soak it in. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 9 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev June 2016