April 2012 - cdi-dev - Jboss List Archives

by Luigi Bitonti

Hi All, My name is Luigi Bitonti and I am a member of the London Java Community (LJC). We are interested in the CDI 1.1 specification and would like to help by contributing our point of view as developers. We are also keen to help with any tasks you feel like assigning to us. We have read the latest draft specification and put together a first round of comments and questions: All the discussions and development are being tracked on Jira (https://issues.jboss.org/browse/CDI). The whole process seems very transparent and easy to follow which is a very good thing. We view very positively the adoption of JCP 2.8. It looks like there is also a private mailing list the EG uses. Is that in use? What's its purpose? It looks like good work is being done and some interesting new addition have already made it into this new version of the specification, such as: - CDI-86 Support firing general purpose lifecycle events in Java EE environments - CDI-129 Clarify behaviour of @ApplicationScoped in EARs What we would like to see going forward is an "easier and clearer" specification, so the current efforts seem to be going in the right direction. Hopefully more good proposals will be implemented as part of the final version. The lack of clear separation between the SE and EE parts of the specification seems to be an issue that limits adoption. This is also related to the lack of a standard way of bootstrapping the DI container in SE. In this respect we believe the following planned changes will bring improvements: - CDI-160 Split the specification into "Core" and "EE integrations". - CDI-26 Provide a bootstrap API for the CDI container outside of an EE container. Do you think these will make it into CDI 1.1? Other interesting proposals we would like to see implemented are: - CDI-139 Support for unmanaged instances. - CDI-110 Provide support for binding an invocation handler to an interface or abstract class - CDI-30 An API for managing built in contexts I've noticed the first 2 have been voted at the top of the most popular issues. I suppose they are very likely to make it into CDI 1.1. Is that correct? Regarding the following issue, we have a question: - CDI-51 Support static injection Static injection would still not be allowed for final fields, just as for the non-static case, right? Thanks for all your work on the specification. I hope we'll be able to help your efforts going forward. Cheers, Luigi

12 years, 4 months

4
7
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, 4 months

2
4
0 / 0

[JBoss JIRA] (CDI-201) Reflect BeanAttributes within validation rules

by Jozef Hartinger (Created) (JIRA)

Reflect BeanAttributes within validation rules ---------------------------------------------- Key: CDI-201 URL: https://issues.jboss.org/browse/CDI-201 Project: CDI Specification Issues Issue Type: Clarification Components: Portable Extensions Affects Versions: 1.1.EDR1 Reporter: Jozef Hartinger Fix For: 1.1 (Proposed) For example: 1) The spec says: {quote}Each child <class> element must specify the name of an alternative bean class. If there is no class with the specified name, or *if the class with the specified name is not an alternative bean class, the container automatically detects the problem and treats it as a deployment problem*. {quote} Since that "alternative" attribute of a bean can be altered by a portable extension in the ProcessBeanAttributes phase, the specification should instead require for each class listed in the <class> element, each bean that defines the class as its bean class is an alternative. 2) {quote}If Y has a name and X declares a name explicitly, using @Named, the container automatically detects the problem and treats it as a definition error.{quote} The specification should abstract from @Named, since the ProcessBeanAttributes enables an extension to set a bean name without using @Named Likely, there are other similar issues. -- 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, 4 months

2
3
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, 4 months

4
7
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, 4 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, 4 months

2
4
0 / 0

[JBoss JIRA] (CDI-195) Clarify serializability requirements for extension-provided metadata

by Jozef Hartinger (Created) (JIRA)

Clarify serializability requirements for extension-provided metadata -------------------------------------------------------------------- Key: CDI-195 URL: https://issues.jboss.org/browse/CDI-195 Project: CDI Specification Issues Issue Type: Feature Request Components: Portable Extensions Affects Versions: 1.0 Reporter: Jozef Hartinger Fix For: 1.1 (Proposed) The spec never requires an extension-provided implementation of the Bean, Interceptor, Decorator or InjectionPoint to be serializable. The implementation indicates, whether the underlying bean is passivation capable by implementing PassivationCapable, but the implementation itself does not have to be serializable. For both the InjectionPoint bean and Bean metadata bean the spec says: "The built-in implementation must be a passivation capable dependency". However, this is hard to guarantee if an extension provides a non-serializable implementation of a Bean/InjectionPoint interface, e.g. the following code would cause problems at passivation: public class Bar implements Serializable { @Inject private InjectionPoint ip; } If the metadata of the Bar bean (Bean<Bar>) is not serializable, Bar cannot be passivated. -- 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, 4 months

7
9
0 / 0

[JBoss JIRA] (CDI-172) Constructor injection of Java EE components

by Pete Muir (Created) (JIRA)

Constructor injection of Java EE components ------------------------------------------- Key: CDI-172 URL: https://issues.jboss.org/browse/CDI-172 Project: CDI Specification Issues Issue Type: Feature Request Affects Versions: 1.0 Reporter: David Blevins Fix For: 1.1 (Proposed) Ctor injection of e.g. servlets -- 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, 4 months

2
1
0 / 0

[JBoss JIRA] (CDI-175) Support for UEL pluggable type converters

by Pete Muir (Created) (JIRA)

Support for UEL pluggable type converters ----------------------------------------- Key: CDI-175 URL: https://issues.jboss.org/browse/CDI-175 Project: CDI Specification Issues Issue Type: Feature Request Affects Versions: 1.0 Reporter: Pete Muir Priority: Optional Fix For: 1.1 (Proposed) -- 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, 4 months

2
1
0 / 0

[JBoss JIRA] Created: (CDI-144) Support Injection into Entity Listeners

by Cody Lerum (JIRA)

Support Injection into Entity Listeners --------------------------------------- Key: CDI-144 URL: https://issues.jboss.org/browse/CDI-144 Project: CDI Specification Issues Issue Type: Feature Request Reporter: Cody Lerum It would be very convenient if CDI was available inside JPA Entity Listeners. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 4 months

6
15
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev April 2012