November 2012 - cdi-dev - Jboss List Archives

[JBoss JIRA] (CDI-293) Reconsider enum support

by Jozef Hartinger (JIRA)

Jozef Hartinger created CDI-293: ----------------------------------- Summary: Reconsider enum support Key: CDI-293 URL: https://issues.jboss.org/browse/CDI-293 Project: CDI Specification Issues Issue Type: Feature Request Affects Versions: 1.1.PRD Reporter: Jozef Hartinger Assignee: Pete Muir Fix For: 1.1 (Proposed) The current version of the spec introduces support for scanning of enums and injection into enums. I discussed this with Pete and Stuart this week and the conclusion was that it is probably a mistake. There is a problem with the injection part if the enum is shared across multiple CDI applications. If we dropped the injection part, the scanning and processing part themselves does not make much sense as the result of scanning would not be processed by CDI anyhow. However, it is convenient for some extensions to have enums scanned. -- 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, 5 months

2
1
0 / 0

[JBoss JIRA] (CDI-58) Clarify that there can be multiple AnnotatedType instances per Java class

by Jozef Hartinger (JIRA)

[ https://issues.jboss.org/browse/CDI-58?page=com.atlassian.jira.plugin.sys... ] Jozef Hartinger updated CDI-58: ------------------------------- Fix Version/s: 1.1 (Proposed) (was: 1.1.PRD) > Clarify that there can be multiple AnnotatedType instances per Java class > ------------------------------------------------------------------------- > > Key: CDI-58 > URL: https://issues.jboss.org/browse/CDI-58 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Beans, Portable Extensions > Affects Versions: 1.0 > Reporter: Pete Muir > Assignee: Pete Muir > Priority: Critical > Fix For: 1.1 (Proposed) > > > This decision is really important to make. Either we remove/redefine BeanManager#getAnnoatadType(Class) or we remove the 'artificial annotated types'. -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] (CDI-58) Clarify that there can be multiple AnnotatedType instances per Java class

by Jozef Hartinger (JIRA)

[ https://issues.jboss.org/browse/CDI-58?page=com.atlassian.jira.plugin.sys... ] Jozef Hartinger reopened CDI-58: -------------------------------- Reopening. It was discussed internally that instead of introducing the new interface, it may make more sense to introduce a method: {code:JAVA} void addAnnotatedType(AnnotatedType<?> type, String id); {code} The id would not then be exposed by the AnnotatedType itself but an extension could still use it to obtain the result of AnnotatedType processing by calling ABD.getAnnotatedType(Class, ID). If the ID passed was null, the annotated type returned would be the default AnnotatedType (the one that came from scanning bean archives, not the one added by an extension). > Clarify that there can be multiple AnnotatedType instances per Java class > ------------------------------------------------------------------------- > > Key: CDI-58 > URL: https://issues.jboss.org/browse/CDI-58 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Beans, Portable Extensions > Affects Versions: 1.0 > Reporter: Pete Muir > Assignee: Pete Muir > Priority: Critical > Fix For: 1.1.PRD > > > This decision is really important to make. Either we remove/redefine BeanManager#getAnnoatadType(Class) or we remove the 'artificial annotated types'. -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] (CDI-83) Clarify that BeanManager.createAnnotatedType() should return any modifications made by lifecycle events.

by Jozef Hartinger (JIRA)

[ https://issues.jboss.org/browse/CDI-83?page=com.atlassian.jira.plugin.sys... ] Jozef Hartinger reopened CDI-83: -------------------------------- Reopening. The proposal is that the getAnnotatedType() methods are not placed on the BeanManager but rather on the AfterBeanDiscovery event. That naturally constraint the points when those methods make sense. (It is not possible to use the methods before annotated types are discovered and processed. It does not make much sense to use the methods at runtime and prohibiting this also allows container to perform certain optimizations). > Clarify that BeanManager.createAnnotatedType() should return any modifications made by lifecycle events. > -------------------------------------------------------------------------------------------------------- > > Key: CDI-83 > URL: https://issues.jboss.org/browse/CDI-83 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Portable Extensions > Affects Versions: 1.0 > Reporter: Pete Muir > Assignee: Pete Muir > Priority: Minor > Fix For: 1.1.PRD > > -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] (CDI-83) Clarify that BeanManager.createAnnotatedType() should return any modifications made by lifecycle events.

by Jozef Hartinger (JIRA)

[ https://issues.jboss.org/browse/CDI-83?page=com.atlassian.jira.plugin.sys... ] Jozef Hartinger updated CDI-83: ------------------------------- Fix Version/s: 1.1 (Proposed) (was: 1.1.PRD) > Clarify that BeanManager.createAnnotatedType() should return any modifications made by lifecycle events. > -------------------------------------------------------------------------------------------------------- > > Key: CDI-83 > URL: https://issues.jboss.org/browse/CDI-83 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Portable Extensions > Affects Versions: 1.0 > Reporter: Pete Muir > Assignee: Pete Muir > Priority: Minor > Fix For: 1.1 (Proposed) > > -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] (CDI-18) Global enablement of interceptors, decorators and alternatives

by Jozef Hartinger (JIRA)

[ https://issues.jboss.org/browse/CDI-18?page=com.atlassian.jira.plugin.sys... ] Jozef Hartinger commented on CDI-18: ------------------------------------ Plus we should define a new schema. > Global enablement of interceptors, decorators and alternatives > -------------------------------------------------------------- > > Key: CDI-18 > URL: https://issues.jboss.org/browse/CDI-18 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans, Decorators, Interceptors, Packaging and Deployment > Affects Versions: 1.0 > Reporter: Mark Struberg > Assignee: Pete Muir > Priority: Critical > Fix For: 1.1.PRD > > > Currently the spec defines that <interceptors>, <decorators> and <alternatives> affect only the Bean Archives where they are configured in (via beans.xml). > Thus if you e.g. enable an Alternative in a WEB-INF/beans.xml, it does NOT count for the jars in it's WEB-INF/lib folder! > This is pretty unhandy because you would need to repackage all your jars in your WEB-INF/lib folder and add/expand the <alternatives> sections in their beans.xml. > Needless to say that this is not only hard to do in a company build but is also impossibly to handle at deploy time in an OSGi environment! -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] (CDI-18) Global enablement of interceptors, decorators and alternatives

by Jozef Hartinger (JIRA)

[ https://issues.jboss.org/browse/CDI-18?page=com.atlassian.jira.plugin.sys... ] Jozef Hartinger reopened CDI-18: -------------------------------- Reopening because: 1.) If a library globally enables an alternative/interceptor/decorator it is not possible to disable it in other libraries without repackaging the library / other libraries. 2.) In the legacy mode (enablement for bean archive), the priority of an alternative/interceptor/decorator is undefined (other than the first one in the list) > Global enablement of interceptors, decorators and alternatives > -------------------------------------------------------------- > > Key: CDI-18 > URL: https://issues.jboss.org/browse/CDI-18 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans, Decorators, Interceptors, Packaging and Deployment > Affects Versions: 1.0 > Reporter: Mark Struberg > Assignee: Pete Muir > Priority: Critical > Fix For: 1.1.PRD > > > Currently the spec defines that <interceptors>, <decorators> and <alternatives> affect only the Bean Archives where they are configured in (via beans.xml). > Thus if you e.g. enable an Alternative in a WEB-INF/beans.xml, it does NOT count for the jars in it's WEB-INF/lib folder! > This is pretty unhandy because you would need to repackage all your jars in your WEB-INF/lib folder and add/expand the <alternatives> sections in their beans.xml. > Needless to say that this is not only hard to do in a company build but is also impossibly to handle at deploy time in an OSGi environment! -- 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, 5 months

1
0
0 / 0

Converting to asciidoc

by Pete Muir

Hi all Jason is working on converting the spec sources over to asciidoc. This should make it much easier to contribute. Whilst he's doing this, let's hold off on new patches etc. as they will need converting over. The work is going well, we're just patching up the converted sources, and then we need to diff them to check for any errors. pete

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (CDI-268) Remove limitations in the SPI for creating beans

by Jozef Hartinger (JIRA)

Jozef Hartinger created CDI-268: ----------------------------------- Summary: Remove limitations in the SPI for creating beans Key: CDI-268 URL: https://issues.jboss.org/browse/CDI-268 Project: CDI Specification Issues Issue Type: Bug Components: Portable Extensions Affects Versions: 1.1.EDR Reporter: Jozef Hartinger Assignee: Pete Muir Fix For: 1.1 (Proposed) The CDI SPI provides an SPI that helps extension developers to build Bean implementations. An example follows: {code:JAVA} AnnotatedType<Foo> annotatedType = manager.createAnnotatedType(Foo.class); BeanAttributes<Foo> attributes = manager.createBeanAttributes(annotatedType); InjectionTarget<Foo> injectionTarget = manager.createInjectionTarget(annotatedType); Bean<Foo> bean = manager.createBean(attributes, Foo.class, injectionTarget); {code} This sequence allows an extension to easily build Bean<Foo>. Obviously, the extension could modify the artifacts along the way to modify the behavior. However, this SPI has limitations. There is a circular dependency between the initialization of Bean and InjectionTarget which is not expressed by the SPI. A Bean implemetation (be it container-provided one or not) almost always uses an InjectionTarget to delegate bean instance creation and destruction to. So far so good as the InjectionTarget is one of the arguments of BeanManager.createBean() On the other hand, the InjectionTarget also needs a reference to a Bean instance at initialization should it serve as an InjectionTarget for a Bean. This is not obvious but there are two reasons why this is needed: *1.) InjectionPoint.getBean() always returns null* InjectionTarget.getInjectionPoints() returns a set of InjectionPoint instances. The InjectionPoint has the method getBean(). This method would always return null (e.g. for InjectionTarget<Foo> above) because there is no way to tell the container that this InjectionTarget is an InjectionTarget of a Bean. This causes problems since the getBean() method is used for validation of injection points - certain types of injection points are allowed to be placed on beans only (e.g. Bean metadata, injection point metadata). There exists a workaround for this where the ProcessInjectionPoint is used to wrap every such InjectionPoint with a wrapper that returns the Bean instance: {code:JAVA} void wrapInjectionPoints(@Observes ProcessInjectionPoint<Foo, ?> event) { final InjectionPoint delegate = event.getInjectionPoint(); if (delegate.getBean() == null) { event.setInjectionPoint(new ForwardingInjectionPoint() { @Override public Bean<?> getBean() { return bean; } @Override protected InjectionPoint delegate() { return delegate; } }); } } {code} *2.) Decorators cannot be applied* Bean<Foo> in the example above would not be decorated even if there were enabled decorators matching the bean. This is because the InjectionTarget, which takes care of creating instances and whose produce() method is responsible for building decorators for the instance does not know whether what it creates actually is a bean or not. Even if it knew, it would need to know the types and qualifiers of the bean, which it does not. To sum it up: Although BeanAttributes, Bean and InjectionTarget seem to be independent layers out of which a Bean can be composed, there are actually circular relations which the SPI currently fails to notice. -- 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, 5 months

2
3
0 / 0

EG meeting today

by Pete Muir

All With great reluctance I need to cancel the meeting today. Both Jozef and I are in meetings, and Martin is travelling. I think Mark is at ApacheCon anyway. We'll schedule two next week to catch up. Pete

11 years, 5 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev November 2012