November 2011 - cdi-dev - Jboss List Archives

[JBoss JIRA] Created: (CDI-161) Java DSL to define beans to create and deploy

by Pete Muir (JIRA)

Java DSL to define beans to create and deploy --------------------------------------------- Key: CDI-161 URL: https://issues.jboss.org/browse/CDI-161 Project: CDI Specification Issues Issue Type: Feature Request Components: Packaging and Deployment Affects Versions: 1.0 Reporter: Pete Muir Fix For: 1.1 (Proposed) This would be especially useful in Java SE mode -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

2
3
0 / 0

[JBoss JIRA] (CDI-180) Clarify request context lifecycle during remote method invocation of EJB

by Martin Kouba (Created) (JIRA)

Clarify request context lifecycle during remote method invocation of EJB ------------------------------------------------------------------------ Key: CDI-180 URL: https://issues.jboss.org/browse/CDI-180 Project: CDI Specification Issues Issue Type: Clarification Affects Versions: 1.0 Reporter: Martin Kouba CDI 1.0 spec states in *6.7.1. Request context lifecycle*: "The request scope is active: during any remote method invocation of any EJB" and "The request context is destroyed: after the EJB remote method invocation" However it doesn't cover various invocation scenarios. For example it's possible to do in-VM invocation (via remote interface) from the same deployment or from a different deployment. Is the request context shared in this case? Will be destroyed after the EJB remote method invocation? Also take into account that application servers often do optimization and handle remote interface calls in a local interface manner within the same JVM. -- 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, 3 months

8
13
0 / 0

[JBoss JIRA] Created: (CDI-143) Add a Util.getAnnotation(Member, Class<? extends Annotation>) style method

by Pete Muir (JIRA)

Add a Util.getAnnotation(Member, Class<? extends Annotation>) style method -------------------------------------------------------------------------- Key: CDI-143 URL: https://issues.jboss.org/browse/CDI-143 Project: CDI Specification Issues Issue Type: Feature Request Components: Portable Extensions Affects Versions: 1.0 Reporter: Pete Muir Fix For: 1.1 (Proposed) This would return information including stereotype information and is useful for other specs or frameworks to integrate with CDI. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

1
2
0 / 0

[JBoss JIRA] Created: (CDI-109) Invalid beans should not be injectable into extensions

by John Ament (JIRA)

Invalid beans should not be injectable into extensions ------------------------------------------------------ Key: CDI-109 URL: https://issues.jboss.org/browse/CDI-109 Project: CDI Specification Issues Issue Type: Feature Request Reporter: John Ament Currently, you can inject beans that may not be ready yet into the extension's call back methods. As an example, I can inject something application scoped like this in to an extension, but it should really be throwing a definition exception (or similar): public void handleABD(@Observes AfterBeanDiscovery abd, MyApplicationScopedBean masb) { } Pete had noted that really the only safe thing to inject, other than the observed call back, is the bean manager. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

10
18
0 / 0

[JBoss JIRA] (CDI-183) Clarify that CDI.current() can be called by anyone and not just CDI extensions

by Emmanuel Bernard (Created) (JIRA)

Clarify that CDI.current() can be called by anyone and not just CDI extensions ------------------------------------------------------------------------------ Key: CDI-183 URL: https://issues.jboss.org/browse/CDI-183 Project: CDI Specification Issues Issue Type: Clarification Reporter: Emmanuel Bernard Fix For: 1.1 (Proposed) http://docs.jboss.org/cdi/spec/1.1.EDR1/html/spi.html#provider EDR1 makes it a bit unclear that this is allowed. -- 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, 3 months

2
2
0 / 0

[JBoss JIRA] Created: (CDI-151) Remove from section 6.7 JMS notes

by John Ament (JIRA)

Remove from section 6.7 JMS notes --------------------------------- Key: CDI-151 URL: https://issues.jboss.org/browse/CDI-151 Project: CDI Specification Issues Issue Type: Clarification Reporter: John Ament In section 6.7, a reference is made to JMS Message Listeners. MessageListeners (as bound to the consumers) are not available in JMS in an EE environment. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

3
9
0 / 0

[JBoss JIRA] (CDI-187) Clarify serializability requirements for interceptors/decorators

by Jozef Hartinger (Created) (JIRA)

Clarify serializability requirements for interceptors/decorators ---------------------------------------------------------------- Key: CDI-187 URL: https://issues.jboss.org/browse/CDI-187 Project: CDI Specification Issues Issue Type: Clarification Components: Contexts, Decorators, Interceptors Affects Versions: 1.1.EDR1 Reporter: Jozef Hartinger Fix For: 1.1.EDR2 The spec says: {quote}A managed bean is passivation capable if and only if the bean class is serializable and all interceptors and decorators of the bean *are serializable*.{quote} The "interceptors and decorators of the bean *are serializable*" part is problematic. While it is fine to examine the defining class in case of standard interceptors/decorators, the question is: How to find out whether an extension-provided interceptor/decorator in serializable? It does not make sense to check the implementation of the Interceptor/Decorator interfaces nor to examine the class returned by Bean.getBeanClass() as that would break the abstraction. IMHO, the spec should say that: {quote}A managed bean is passivation capable if and only if the bean class is serializable and all interceptors and decorators of the bean are *passivation capable*.{quote} Where a standard interceptor/decorator would be passivation capable if and only if it implemented the Serializable interface whereas the following section of the spec would handle extension-provided interceptors/decorators. {quote}A custom implementation of Bean is passivation capable if it implements the interface PassivationCapable. An imple- mentation of Contextual that is not a bean is passivation capable if it implements both PassivationCapable and Serial- izable. {quote} -- 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, 3 months

2
4
0 / 0

[JBoss JIRA] (CDI-197) Clarify the order of container lifecycle events

by Jozef Hartinger (Created) (JIRA)

Clarify the order of container lifecycle events ----------------------------------------------- Key: CDI-197 URL: https://issues.jboss.org/browse/CDI-197 Project: CDI Specification Issues Issue Type: Clarification Components: Portable Extensions Affects Versions: 1.1.EDR1 Reporter: Jozef Hartinger Fix For: 1.1 (Proposed) The order in which the following event types are fired is not clear from the spec: * ProcessModule * ProcessBeanAttributes * ProcessInjectionTarget -- 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, 3 months

4
9
0 / 0

[JBoss JIRA] Created: (CDI-165) Support lifecycle events for non-builtin contexts

by Jozef Hartinger (JIRA)

Support lifecycle events for non-builtin contexts ------------------------------------------------- Key: CDI-165 URL: https://issues.jboss.org/browse/CDI-165 Project: CDI Specification Issues Issue Type: Feature Request Components: Contexts Affects Versions: 1.0 Reporter: Jozef Hartinger Priority: Minor Fix For: 1.1 (Proposed) The original idea was to extend the API for context implementations to be able to notify the container of a context initialization / destruction. Based on this notification, the container would then notify the application by firing @Initialized(X) / @Destroyed(X) Object (where X is the scope annotation of the context - see CDI-86). I don't think this double-notification approach is a good idea anymore. Instead, the specification should simply mention that the extensions providing an implementation of Context are encouraged to fire a @Initialized(X) event when the context is initialized and @Destroyed(X) event when the context is destroyed (again, see CDI-86 for details). Extensions are free to choose a payload that makes most sense for the given context (e.g. UIViewRoot instance for @ViewScoped) or Object otherwise. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

2
4
0 / 0

[JBoss JIRA] (CDI-184) Make sure that CDI.current() works in a modular environment

by Emmanuel Bernard (Created) (JIRA)

Make sure that CDI.current() works in a modular environment ----------------------------------------------------------- Key: CDI-184 URL: https://issues.jboss.org/browse/CDI-184 Project: CDI Specification Issues Issue Type: Feature Request Reporter: Emmanuel Bernard Fix For: 1.1 (Proposed) OSGi containers and other modular environments tend to hide service files and consider them implementation details. That means that a naive current classloader based implementation won't discover the various CDI implementations. There are several approaches to try and work around this problem in EE specs h4. JPA 2's approach JPA 2 does have a static getter / setter pair {code}PersistenceProviderResolverHolder.getPersistenceProviderResolver() PersistenceProviderResolverHolder.setPersistenceProviderResolver(){code} which holds the resolver to use. A modular environment is free to override the default resolver. h4. Bean Validation's approach Bean Validation uses a different approach to work around the nasty static field. {code} Validation .byDefaultProvider() .providerResolver( myOSGiResolver ) .configure() //we have ways to customize the ValidatorFactory further .buildValidatorFactory(); {code} Note that Bean VAlidation approach has another benefit, you can physically ask for a specific Bean Validation provider implementation {code} Validation .byProvider( HibernateValidator.class ) .configure() .ignoreXmlConfiguration() //bean validation configuration .failSafe() //Hibernate specific configuration (type safe) .buildValidatorFactory(); {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, 3 months

4
7
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev November 2011