February 2013 - cdi-dev - Jboss List Archives

[JBoss JIRA] (CDI-163) Add support injecting Manifest object for JAR defining class

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-163?page=com.atlassian.jira.plugin.sy... ] Pete Muir updated CDI-163: -------------------------- Fix Version/s: TBD (was: 1.1 (Proposed)) > Add support injecting Manifest object for JAR defining class > ------------------------------------------------------------ > > Key: CDI-163 > URL: https://issues.jboss.org/browse/CDI-163 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Pete Muir > Fix For: TBD > > > Currently accessing the Manifest for a class is a nightmare in Java. As CDI knows more about app structure it's not such a problem. > Support a built in bean of type Manifest with qualifiers @Default that is the Manifest for the JAR file which defines the class (as determined by the Jar file spec). -- 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

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (CDI-238) Clarify enablement of a specialized bean

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-238?page=com.atlassian.jira.plugin.sy... ] Pete Muir updated CDI-238: -------------------------- Fix Version/s: 1.1.PFD (was: 1.1 (Proposed)) > Clarify enablement of a specialized bean > ---------------------------------------- > > Key: CDI-238 > URL: https://issues.jboss.org/browse/CDI-238 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Concepts > Affects Versions: 1.1.EDR > Reporter: Jozef Hartinger > Fix For: 1.1.PFD > > > Assume the following class > {code:JAVA} > public class X > {code} > and deployment structure: > {code} > +-application.ear > +-web1.war > +-web2.war > +-lib/ > +-shared.jar > +-X.class > {code} > In addition, we assume the standard accessibility layout, where web archives are isolated and both web archives have access to the shared library archive. Note that the beans.xml file, which is present in web1.war, web2.war and shared.jar is omitted in deployment structure diagrams. > The X bean is available for injection in both web1 and web2 applications. > Furthermore, let's assume that web1 introduces the following bean for its own purpose: > {code:JAVA} > @Specializes > public class Y extends X > {code} > {code} > +-application.ear > +-web1.war > +-WEB-INF/ > +-classes/ > +-Y.class > +-web2.war > +-lib/ > +-shared.jar > +-X.class > {code} > Now assume the following injection point: > {code:JAVA} > @Inject > X bean; > {code} > If the injection point belongs to a bean bundled within web1.war, it should be injected with an instance of Y. > If the injection point belongs to a bean bundled within shared.jar, it should be injected with an instance of X (and not Y). > If the injection point belongs to a bean bundled within web2.war, it should intuitively be injected with X (because Y is not accessible). However, the specification says that: > {quote} > A bean is said to be enabled if it is not specialized by any other enabled bean, as defined in Section 4.3, “Specialization”... > {quote} > which X in this case is. As a result, the X bean is not enabled and the injection point would be unsatisfied if deployed within web2.war. This seems to be very counterintuitive. The fact whether a given bean can/cannot be injected due to specialization should be decided per module and not on the global enabled/disabled level. > The proposed fix is to make a bean available for injection in a given module > - if the bean is not specialized by another enabled bean or > - the bean is specialized by another enabled bean and the specializing bean is not available for injection in the given module. > It should also be clarified if container lifecycle events that are only fired for enabled beans (such ProcessBean and ProcessBeanAttributes) should or should not be fired for beans which are specialized in a certain module but are not in another module. -- 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

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (CDI-142) Clarify behaviour of specializing beans across bean archive boundaries

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-142?page=com.atlassian.jira.plugin.sy... ] Pete Muir updated CDI-142: -------------------------- Fix Version/s: 1.1.PFD (was: 1.1 (Proposed)) > Clarify behaviour of specializing beans across bean archive boundaries > ---------------------------------------------------------------------- > > Key: CDI-142 > URL: https://issues.jboss.org/browse/CDI-142 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Beans, Resolution > Affects Versions: 1.0 > Reporter: Stuart Douglas > Fix For: 1.1.PFD > > > For instance, if a bean in a war specializes a bean in an ejb jar does the bean in the war become visible to other bean archives that would not normally be able to see it? -- 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

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (CDI-241) Support dependency injection within Bean Validation constraint validators

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-241?page=com.atlassian.jira.plugin.sy... ] Pete Muir resolved CDI-241. --------------------------- Assignee: Pete Muir Fix Version/s: 1.1.PFD (was: 1.1 (Proposed)) Resolution: Done BV 1.1 supports this > Support dependency injection within Bean Validation constraint validators > ------------------------------------------------------------------------- > > Key: CDI-241 > URL: https://issues.jboss.org/browse/CDI-241 > Project: CDI Specification Issues > Issue Type: Tracker > Components: Java EE integration > Reporter: Gunnar Morling > Assignee: Pete Muir > Fix For: 1.1.PFD > > > CDI should integrate with Bean Validation to support dependency injection within BV {{ConstraintValidator}} implementations. > From the BV 1.1 [spec early draft|http://beanvalidation.org/1.1/spec/#bootstrapping-usageandcontainer...]: > {quote} > Java EE should obey the rules defined above and enable Context and Dependency Injection (CDI) support to {{ValidatorFactory}} instances. In particular: > * Let {{Validator}} and {{ValidatorFactory}} object be injectable. > * Use a default {{ConstraintValidatorFactory}} implementation that returns CDI managed {{ConstraintValidator}} objects. The scope of these instances is dependent as the Bean Validation provider is responsible for them. > * Provide CDI managed instances of {{ConstraintValidatorFactory}}, {{MessageInterpolator}} and {{TraversableResovler}} if customized classes are requested in the XML deployment descriptor. > {quote} -- 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

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (CDI-242) Support Bean Validation 1.1 method validation

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-242?page=com.atlassian.jira.plugin.sy... ] Pete Muir resolved CDI-242. --------------------------- Assignee: Pete Muir Fix Version/s: 1.1.PFD (was: 1.1 (Proposed)) Resolution: Done BV 1.1 supports this > Support Bean Validation 1.1 method validation > --------------------------------------------- > > Key: CDI-242 > URL: https://issues.jboss.org/browse/CDI-242 > Project: CDI Specification Issues > Issue Type: Tracker > Components: Java EE integration > Reporter: Gunnar Morling > Assignee: Pete Muir > Fix For: 1.1.PFD > > > CDI should integrate with Bean Validation to support the [method validation|http://beanvalidation.org/1.1/spec/#d0e2147] feature defined in BV 1.1. > BV specifies an annotation [@MethodValidated|http://beanvalidation.org/1.1/spec/#validationapi-triggeringmethodvalidation] which could be used as interceptor binding annotation: > {code} > @MethodValidated > public class OrderService { > public OrderService(@NotNull CreditCardProcessor creditCardProcessor) { > //... > } > public void placeOrder( > @NotNull @Size(min=3, max=20) String customerCode, > @NotNull Item item, > @Min(1) int quantity) { > //... > } > } > {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

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (CDI-61) Producers and beans that are under construction

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-61?page=com.atlassian.jira.plugin.sys... ] Pete Muir updated CDI-61: ------------------------- Fix Version/s: TBD (was: 1.1 (Proposed)) > Producers and beans that are under construction > ----------------------------------------------- > > Key: CDI-61 > URL: https://issues.jboss.org/browse/CDI-61 > Project: CDI Specification Issues > Issue Type: Bug > Components: Beans > Affects Versions: 1.0 > Reporter: Pete Muir > Fix For: TBD > > > I think we need the spec to say something about cases where an injection point of a bean resolves to a producer method of the same bean. The implementation should detect that this is a definition error. It shouldn't try to call a producer method on a non-fully-initialized 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

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (CDI-121) TransactionScope

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-121?page=com.atlassian.jira.plugin.sy... ] Pete Muir resolved CDI-121. --------------------------- Fix Version/s: 1.1.PFD (was: 1.1 (Proposed)) Resolution: Done This has been added to Java EE. > TransactionScope > ---------------- > > Key: CDI-121 > URL: https://issues.jboss.org/browse/CDI-121 > Project: CDI Specification Issues > Issue Type: Tracker > Components: Contexts > Environment: Java EE > Reporter: Richard Hightower > Assignee: Richard Hightower > Priority: Minor > Fix For: 1.1.PFD > > Original Estimate: 3 days > Remaining Estimate: 3 days > > Add TransctionalScope as a standard scope to define beans whose lifecycle is the same as a given transaction. > This scope should start automatically when a transaction starts (but lazily when actually needed). -- 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

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (CDI-198) Make beans.xml validation consistent with the ProcessModule event

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-198?page=com.atlassian.jira.plugin.sy... ] Pete Muir updated CDI-198: -------------------------- Fix Version/s: 1.1.PFD (was: 1.1 (Proposed)) > Make beans.xml validation consistent with the ProcessModule event > ----------------------------------------------------------------- > > Key: CDI-198 > URL: https://issues.jboss.org/browse/CDI-198 > Project: CDI Specification Issues > Issue Type: Bug > Components: Portable Extensions > Affects Versions: 1.1.EDR > Reporter: Jozef Hartinger > Priority: Minor > Fix For: 1.1.PFD > > > The validation of enabled interceptors, alternatives and decorators is currently tightly related to the beans.xml file, e.g.: > {quote}If the same class is listed twice under the <interceptors> element, the container automatically detects the problem and treats it as a deployment problem.{quote} > With CDI-97 in place, which allows extensions to change the enabled alternatives, decorators and interceptors, this is no longer sufficient. IMO, the validation of enabled interceptors and decorators should be the following: > 1.) For each deployment descriptor, the container verifies that it does not contain duplicate interceptors, decorators or alternatives. > 2.) For each BDA, the container fires the ProcessModule event allowing extensions to modify enabled alternatives, interceptors and decorators. > 3.) For each BDA, the container verifies that the resulting collection of enabled alternatives, decorators and interceptors does not contain duplicates. > The step 1.) is not actually necessary but may be convenient. -- 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

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (CDI-212) Add BeanManager.createDecorator() and BeanManager.createInterceptor()

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-212?page=com.atlassian.jira.plugin.sy... ] Pete Muir updated CDI-212: -------------------------- Fix Version/s: 1.1.PFD (was: 1.1 (Proposed)) > Add BeanManager.createDecorator() and BeanManager.createInterceptor() > --------------------------------------------------------------------- > > Key: CDI-212 > URL: https://issues.jboss.org/browse/CDI-212 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Portable Extensions > Affects Versions: 1.1.EDR > Reporter: Jozef Hartinger > Fix For: 1.1.PFD > > > It is unclear from the specification whether the BeanManager.createBean() method should ever return an implementation of the Decorator or Interceptor interface. > Method parameters of the createBean() method provide all the necessary information for constructing a Decorator implementation. Therefore, IMHO the method should return a container-provided Decorator implementation if the set of stereotypes returned by BeanAttributes.getStereotypes contains javax.decorator.Decorator. > On the other hand, Interceptors do not fit this model because the AnnotatedType of the bean class is not available to the method and using the reflection API to scan the bean class directly would not be consistent with the rest of the specification. -- 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

11 years, 10 months

1
0
0 / 0

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

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-144?page=com.atlassian.jira.plugin.sy... ] Pete Muir resolved CDI-144. --------------------------- Fix Version/s: 1.1.PFD (was: 1.1 (Proposed)) Resolution: Done This is fixed in JPA > Support Injection into Entity Listeners > --------------------------------------- > > Key: CDI-144 > URL: https://issues.jboss.org/browse/CDI-144 > Project: CDI Specification Issues > Issue Type: Tracker > Affects Versions: 1.0 > Reporter: Cody Lerum > Assignee: Pete Muir > Fix For: 1.1.PFD > > > It would be very convenient if CDI was available inside JPA Entity Listeners. -- 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

11 years, 10 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev February 2013