November 2012 - cdi-dev - Jboss List Archives

[JBoss JIRA] Created: (CDI-129) introduce @EnterpriseScoped (or similar)

by Mark Struberg (JIRA)

introduce @EnterpriseScoped (or similar) ---------------------------------------- Key: CDI-129 URL: https://issues.jboss.org/browse/CDI-129 Project: CDI Specification Issues Issue Type: Feature Request Components: Contexts Affects Versions: 1.0 Reporter: Mark Struberg Since @ApplicationScoped currently is defined in 6.5.2 as to be 'like in the Servlet specification' this means that you will get a new instance for every WebApplication (WAR file). There is currently no specified CDI scope for providing a single shared instance for a whole EAR. We could (ab-)use @Singleton for that, but this is currently not well defined at all. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

9
144
0 / 0

[JBoss JIRA] (CDI-233) Specify target bean archive for bean added via AfterBeanDiscovery.addBean()

by Martin Kouba (JIRA)

Martin Kouba created CDI-233: -------------------------------- Summary: Specify target bean archive for bean added via AfterBeanDiscovery.addBean() Key: CDI-233 URL: https://issues.jboss.org/browse/CDI-233 Project: CDI Specification Issues Issue Type: Clarification Reporter: Martin Kouba This may have impact, provided that alternatives, interceptors or decorators are used. -- 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, 1 month

3
10
0 / 0

[JBoss JIRA] (CDI-200) ProcessBeanAttributes needs clarification

by Jozef Hartinger (Created) (JIRA)

ProcessBeanAttributes needs clarification ----------------------------------------- Key: CDI-200 URL: https://issues.jboss.org/browse/CDI-200 Project: CDI Specification Issues Issue Type: Clarification Components: Portable Extensions Affects Versions: 1.1.EDR1 Reporter: Jozef Hartinger Fix For: 1.1 (Proposed) The specification should clarify the following cases: * whether the ProcessBeanAttributes event should be fired for Beans registered using AfterBeanDiscovery.addBean() - if yes, it is necessary to clarify what would the value returned by PBA.getAnnotated() be. * whether the ProcessBeanAttributes event should be fired for built-in beans (my interpretation is that this is not required) The attributes represented by a BeanAttributes object are not completely independent. It is necessary to clarify how the set BeanAttributes object is treated. I can see two options: * the container takes the final values of a BeanAttributes object and uses them * the container itself updates certain attributes to match CDI rules for example ** if an extension adds a @Named qualifier to the set of qualifiers, this change is automatically reflected within the name attribute ** if an extension adds a stereotype, which is (transitively) annotated with @Named, the default name is implied and reflected within the name attribute ** if an extension adds a stereotype, which is (transitively) annotated with @Alternative, this fact is reflected within the isAlternative attribute ** if an extension adds a stereotype, which is (transitively) annotated with a scope annotation, this fact is reflected within the scope attribute In theory, conflicts may occur where for example an extension may set different values for the @Named qualifier and for the name attribute. With the latter approach, an extension loses part of the control. On the other hand, this approach may be more convenient. Another area that needs clarification is specialization. Suppose having beans A and B where B specializes A. According to the specification, the result of specialization should be visible at the time the ProcessBeanAttributes event is fired for B (the qualifiers and name of B are updated with values of A). The scenarios that need clarification are: * In the ProcessBeanAttributes phase, a qualifier is added to A (making B no longer a valid substite of A). Should the container detect this as a definition error or rather apply specialization (update the set of qualifiers of B) once again? The same applies for name. * Similarly, the set of qualifiers of B may be reduced by an extension, causing the same problem. -- 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, 1 month

2
5
0 / 0

[JBoss JIRA] (CDI-84) Non EE modules should be able to inject/lookup in JNDI a BeanManager

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-84?page=com.atlassian.jira.plugin.sys... ] Pete Muir updated CDI-84: ------------------------- Labels: visibility (was: ) > Non EE modules should be able to inject/lookup in JNDI a BeanManager > -------------------------------------------------------------------- > > Key: CDI-84 > URL: https://issues.jboss.org/browse/CDI-84 > Project: CDI Specification Issues > Issue Type: Tracker > Components: Java EE integration, Packaging and Deployment > Affects Versions: 1.0 > Reporter: Aslak Knutsen > Labels: visibility > Fix For: 1.1 (Proposed) > > > EE.5.19 > A bean manager is only available in modules in which CDI has been enabled. > Where EE modules are defined to be; ejb-jar, rar, client jar and war. > This is a missmatch between the EE spec and the CDI spec. According to the CDI spec, any archive with a beans.xml is defined as a BeanArchive and should be included in a BeanManager, EE define it to be only EE modules should trigger BeanManager creation. > Opening this up to follow the CDI spec will let any library use the BeanManager to introspect other BeanArchives without having to involve the owning EE module in the loop. -- 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

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (CDI-23) Allow BeanManager to be resolved as though you were in another bean archive

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-23?page=com.atlassian.jira.plugin.sys... ] Pete Muir updated CDI-23: ------------------------- Labels: visibility (was: ) > Allow BeanManager to be resolved as though you were in another bean archive > --------------------------------------------------------------------------- > > Key: CDI-23 > URL: https://issues.jboss.org/browse/CDI-23 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Portable Extensions, Resolution > Affects Versions: 1.0 > Reporter: Pete Muir > Assignee: Pete Muir > Labels: visibility > Fix For: 1.1 (Proposed) > > > Currently it's not possible to access beans as though you were in another bean manager, something that is useful for extensions to be able to do. For example, if I want to create a facade over the ELResolver, or access a particular configuration bean. -- 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

12 years, 1 month

1
0
0 / 0

Re: [cdi-dev] [Vote] @ApplicationScoped and visibility

by Mark Struberg

perfectly fine for EJBs. But we are talking about CDI and not about EJB! I've seen no single CDI container doing this so far. ------------------------------ Stuart Douglas schrieb am Mo., 26. Nov 2012 14:11 PST: >In AS7 we set the TCCL on each EJB invocation. There is no explicit requirement to do this is in the EJB spec as far as I can see, however I can't really imagine an implementation not doing this, as you could potentially end up with a TCCL that cannot see the EJB class. > >Stuart > > >Pete Muir wrote: >> On 26 Nov 2012, at 19:41, Mark Struberg wrote: >> >>> I believe the OWB actually follows 1a >>> as the question is currently written. When the EJB is executing, >>> the thread context classloader would be that of the ejb module so the correct >>> bean would be injected for that module. >> >> Nope, OWB follows 1b and is thus perfectly in sync with all the other EE containers I tested (feel free to grab my app and test yourself!). CDI != EJB. There is (currently) no magical TCCL change involved in any CDI call chain. Not in OWB and also not in Weld so far afaik. >> >> Right. Weld never sets the TCCL. But other things such as EJB might to in JBoss AS. Stuart, can you comment? >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev .

12 years, 1 month

3
3
0 / 0

[JBoss JIRA] (CDI-281) ObserverMethod.notify() breaks backwards compatibility

by Jozef Hartinger (JIRA)

Jozef Hartinger created CDI-281: ----------------------------------- Summary: ObserverMethod.notify() breaks backwards compatibility Key: CDI-281 URL: https://issues.jboss.org/browse/CDI-281 Project: CDI Specification Issues Issue Type: Bug Components: Events Affects Versions: 1.1.EDR Reporter: Jozef Hartinger Assignee: Jozef Hartinger Fix For: 1.1 (Proposed) ObserverMethod.notify(T event, Set<Annotation> qualifiers) has been added post CDI 1.0 as part of CDI-36. The added method breaks backwards compatibility (an existing 1.0 Extension may be registering an ObserverMethod implementation that would not implement that method, since it is not part of the 1.0 API). We should probably isolate that method into a subinterface e.g.: {code:JAVA} public interface CuriousObserverMethod<T> extends ObservetMethod<T> { void notify(T event, Set<Annotation> qualifiers); } {code} -- 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

12 years, 1 month

2
4
0 / 0

[JBoss JIRA] (CDI-286) Inconsistencies in chapter "Validation of passivation capable beans and dependencies"

by Martin Kouba (JIRA)

Martin Kouba created CDI-286: -------------------------------- Summary: Inconsistencies in chapter "Validation of passivation capable beans and dependencies" Key: CDI-286 URL: https://issues.jboss.org/browse/CDI-286 Project: CDI Specification Issues Issue Type: Bug Reporter: Martin Kouba The spec states in 6.6.4. "Validation of passivation capable beans and dependencies": {quote} If a bean which declares a passivating scope type, or any stateful session bean, has a decorator or interceptor which is not a passivation capable dependency, the container automatically detects the problem and treats it as a deployment problem. {quote} WRT CDI-136 "If a bean which declares a passivating scope type, or any stateful session bean," should be replaced with: "If a managed bean or stateful session bean which declares a passivating scope". I'm not sure about the wording _"has a decorator or interceptor which is not a passivation capable dependency"_ because the wording in section 6.6.1. "Passivation capable beans" is _"interceptors and decorators of the bean are passivation capable"_ (passivation capable dependency vs passivation capable). -- 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

12 years, 1 month

2
7
0 / 0

[JBoss JIRA] (CDI-282) Vetoing types - clarify consequences

by Martin Kouba (JIRA)

Martin Kouba created CDI-282: -------------------------------- Summary: 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 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

12 years, 1 month

2
6
0 / 0

[JBoss JIRA] (CDI-289) Clarify what happens if a CDI-scoped stateful session bean is removed due to exception

by Jozef Hartinger (JIRA)

Jozef Hartinger created CDI-289: ----------------------------------- Summary: 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 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

12 years, 1 month

2
2
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev November 2012