August 2012 - cdi-dev - Jboss List Archives

[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-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-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

CDI 1.1 EG special meeting (discuss multiple annotated types with Stuart)

by pmuir＠redhat.com

The following is a new meeting request: Subject: CDI 1.1 EG special meeting (discuss multiple annotated types with Stuart) Organiser: Peter Muir <pmuir(a)redhat.com> Time: Thursday, 30 August 2012, 15:00:00 BST - 16:00:00 BST Invitees: "cdi-dev(a)lists.jboss.org" <cdi-dev(a)lists.jboss.org>, "sdouglas(a)redhat.com" <sdouglas(a)redhat.com> *~*~*~*~*~*~*~*~*~* http://www.timeanddate.com/worldclock/fixedtime.html?msg=CDI+EG+meeting+%... We will try to use Google Hangout, join #jsr346 10 minutes before the meeting to request an invite. Otherwise switch to the phone teleconference, see https://docs.google.com/spreadsheet/pub?key=0ApqHbXzB1R1gdGRFWXB4TVpNeWFJ... for details.

12 years, 4 months

1
0
0 / 0

[JBoss JIRA] (CDI-235) Clarify which scopes are active during @PostConstruct of remote EJBs and @Startup

by Joe Bergmark (JIRA)

Joe Bergmark created CDI-235: -------------------------------- Summary: Clarify which scopes are active during @PostConstruct of remote EJBs and @Startup Key: CDI-235 URL: https://issues.jboss.org/browse/CDI-235 Project: CDI Specification Issues Issue Type: Clarification Components: Contexts Affects Versions: 1.0 Reporter: Joe Bergmark Fix For: 1.1 (Proposed) There is a very similar snippet regarding when scopes are active for all EJBs in 6.7.1 and 6.7.3. Neither appears to directly address @PostConstruct, though 6.7.3 does address @PreDestroy. It makes sense to me that application scope would be active during @PostConstruct, but that request scope might not be as @PostConstruct might be called outside of a business method invocation. I believe 7.2 states that lifecycle callbacks are not business method invocations. This is a slightly more generic version of CDI-219, which specifically addresses request scope in EJB @Singleton @Startup @PostConstruct methods. -- 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

CDI 1.1 EG special meeting (discuss multiple annotated types with Stuart)

by pmuir＠redhat.com

The following is a new meeting request: Subject: CDI 1.1 EG special meeting (discuss multiple annotated types with Stuart) Organiser: Peter Muir <pmuir(a)redhat.com> Time: Thursday, 30 August 2012, All day Invitees: "cdi-dev(a)lists.jboss.org" <cdi-dev(a)lists.jboss.org>, "sdouglas(a)redhat.com" <sdouglas(a)redhat.com> *~*~*~*~*~*~*~*~*~* http://www.timeanddate.com/worldclock/fixedtime.html?msg=CDI+EG+meeting+%... We will try to use Google Hangout, join #jsr346 10 minutes before the meeting to request an invite. Otherwise switch to the phone teleconference, see https://docs.google.com/spreadsheet/pub?key=0ApqHbXzB1R1gdGRFWXB4TVpNeWFJ... for details.

12 years, 4 months

1
0
0 / 0

Minutes from EG meeting 20/08/2012

by Pete Muir

Present: Pete Muir Mark Struberg Joe Bergmark Mike Brock Jozef Hartinger Antoine Sabot Durand Fabien Marsaud Recap from last week ================= * Multiple Annotated Types - we need to schedule a meeting which Stuart can make, to discuss. Pete to arrange. * Should we use private methods as sources of observers, producers and initializers. Mike checked JLS, it is possible. EJB spec set the precedent to use them. We will use them. Pete to write up. Scopes for non Http Request ====================== Joe had dug into this. EG conclusion was that we should require a remote invocation to *always* be in a new request scope, and that it must not be shared or interfere with the lifecycle of an existing request scope. Joe to write up spec changes with help from Pete. We also discussed that we should explicitly require the application scope to be available during @Singleton @Startup @PostConstruct methods. Joe to write up CDI spec changes. Pete to discuss integration with Java EE spec leads. Disposers on specialized beans ========================= Mark outlined a potential issue here. Jozef and Pete think this is an implementation issue, not a spec issue. Mark to work with Martin to produce TCK test and if a spec issue is discovered, we will fix it then. Short lived producers on longer scoped beans ==================================== AKA the manager pattern. CDI-230 was discussed and we decided this is better addressed by a FAQ. Issue has been rejected. No further action. @Veto ===== Pete proposed dropping @Veto, and instead being able to declaratively and explicitly control whether a bean is enabled or disabled. Pete to write up full proposal. @HandlesTypes ============= This is issue CDI-43. Full notes on https://issues.jboss.org/browse/CDI-43. Pete to write up spec changes based on EG discussion. See you all the same time next week :-)

12 years, 4 months

5
11
0 / 0

Topics for todays meeting

by Pete Muir

Hi team, Here's a list of what I've prepared for this meeting: * CDI-245 & CDI-249 Discussion how extensions work, and what can be injected into them, with a proposal at https://github.com/jboss/cdi/pull/89 * CDI-43 Adding filters to extensions to limit when they are called, with a proposal at https://github.com/jboss/cdi/pull/88 * CDI-165 Encourage custom context implementations to fire events when they are initialized and destroyed, with a proposal at https://github.com/jboss/cdi/pull/87 * CDI-184 Add CDI.setCDIProvider() for environments where service providers don't work e.g. OSGi with a proposal at https://github.com/jboss/cdi/pull/86 * CDI-183 Require CDI.current() to work in Java EE servers with a proposal at https://github.com/jboss/cdi/pull/85 * CDI-197 Try to clarify order of container lifecycle events with a proposal at https://github.com/jboss/cdi/pull/83 * CDI-213 Observer methods and transactions (Jens, if you can join the meeting we can discuss, otherwise let's defer) * CDI-201 Clarify some validation rules around BeanAttributes, with a proposal at https://github.com/jboss/cdi/pull/80 * CDI-234 Handle array and annotation valued members on qualifiers, with a proposal at https://github.com/jboss/cdi/pull/79 * CDI-187 Interceptors and decorators should be required to be passivation capable, not serializable, with a proposal at https://github.com/jboss/cdi/pull/78 * CDI-177 Better handling of @Named defaults for qualifiers with a proposal at https://github.com/jboss/cdi/pull/77/files * CDI-218 Allow use of WEB-INF/classes/META-INF/beans.xml with a proposal at https://github.com/jboss/cdi/pull/74 * CDI-214, Remove BeanManager from Servlet context, a revert of CDI-73 with a proposal at https://github.com/jboss/cdi/pull/74 * CDI-138, allow definition of qualifiers and interceptor bindings using annotated types, to allow @Nonbinding to be added programmatically to member values with a proposal at https://github.com/jboss/cdi/pull/41 Pete

12 years, 4 months

3
5
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev August 2012