September 2012 - cdi-dev - Jboss List Archives

[JBoss JIRA] (CDI-257) remove @Dependent parameter section for container events

by Mark Struberg (JIRA)

Mark Struberg created CDI-257: --------------------------------- Summary: remove @Dependent parameter section for container events Key: CDI-257 URL: https://issues.jboss.org/browse/CDI-257 Project: CDI Specification Issues Issue Type: Bug Reporter: Mark Struberg Assignee: Pete Muir Imo we can also get rid of the following paragraph in 6.4.2 " all @Dependent scoped contextual instances injected into method parameters of an observer method of any container lifecycle event, as defined in Section 11.5, “Container lifecycle events”, is destroyed after all observers of the Before- Shutdown event complete," The reason is that we clarified that only a BeanManager (and other Extensions?) can get injected into into an Extension. -- 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, 9 months

2
4
0 / 0

[JBoss JIRA] (CDI-260) Clarify ProcessAnnotatedType definition

by Jozef Hartinger (JIRA)

Jozef Hartinger created CDI-260: ----------------------------------- Summary: Clarify ProcessAnnotatedType definition Key: CDI-260 URL: https://issues.jboss.org/browse/CDI-260 Project: CDI Specification Issues Issue Type: Clarification Components: Portable Extensions Affects Versions: 1.0 Reporter: Jozef Hartinger Priority: Minor Fix For: 1.1 (Proposed) The spec currently says: {quote} The container must fire an event for each Java class or interface it discovers in a bean archive, and for annotated type added by BeforeBeanDiscovery.addAnnotatedType(), except for those annotated with @Vetoed, *before it processes the declared annotations*. {quote} This is inaccurate and I believe that the intention of the spec is to enforce that the PAT events are fired *before the contained processes annotated types*. Note that "processing declared annotations" is only one of multiple parts of the process of creating beans therefore the entire process should be mentioned in the spec instead of one of its subparts. -- 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, 9 months

2
3
0 / 0

[JBoss JIRA] Created: (CDI-170) Either ditch or fix @New

by Mark Struberg (JIRA)

Either ditch or fix @New ------------------------ Key: CDI-170 URL: https://issues.jboss.org/browse/CDI-170 Project: CDI Specification Issues Issue Type: Bug Components: Concepts, Contexts Affects Versions: 1.0 Reporter: Mark Struberg Fix For: TBD The specification of @New is currently not really usable. It is really only for creating injected but unmanaged and unintercepted instances of a class. But this usecase is weird and imo just not needed. If the class under construction is an 'old' Pojo (without @Inject, etc) then it doesn't need to get managed. And it also doesn't provide any benefit over just using new Pojo(); Also you cannot @New classes which don't have a default ct. I just found no sane scenario where we cannot use a producer method instead. Can we simply deprecate @New? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 9 months

8
19
0 / 0

[JBoss JIRA] (CDI-264) The runtime type of any event object should not be assignable to the type of a container lifecycle event

by Martin Kouba (JIRA)

Martin Kouba created CDI-264: -------------------------------- Summary: The runtime type of any event object should not be assignable to the type of a container lifecycle event Key: CDI-264 URL: https://issues.jboss.org/browse/CDI-264 Project: CDI Specification Issues Issue Type: Clarification Reporter: Martin Kouba This was already discussed in CDI-245 WRT application bootstrap (extensions). I believe we should apply the same approach in section "10.3.1. The Event interface" as well. E.g. it should not be possible to fire an event object assignable to {{BeforeShutdown}} via {{Event}} builtin 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, 9 months

2
5
0 / 0

[JBoss JIRA] (CDI-59) Clarify interceptors/decorators aren't applied to the *result* of a producer method or producer field

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-59?page=com.atlassian.jira.plugin.sys... ] Pete Muir resolved CDI-59. -------------------------- Resolution: Done > Clarify interceptors/decorators aren't applied to the *result* of a producer method or producer field > ----------------------------------------------------------------------------------------------------- > > Key: CDI-59 > URL: https://issues.jboss.org/browse/CDI-59 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Beans, Decorators, Interceptors, Resolution > Affects Versions: 1.0 > Reporter: Pete Muir > Assignee: Pete Muir > Priority: Minor > Fix For: 1.1.PRD > > > Interceptors can be applied to the invocation of a producer method, but not to a bean produced by a producer method. Decorators cannot be applied -- 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, 9 months

1
0
0 / 0

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

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-18?page=com.atlassian.jira.plugin.sys... ] Pete Muir commented on CDI-18: ------------------------------ If there are two producers of the same type with the same qualifier then you will get an AmbiguousResolutionExecption. You'll have to provide more details about the issue you are describing. The above proposal would allow you to enable or disable interceptors for the entire application in your root beans.xml. We haven't actually specified allowing you to completely describe the interceptors in your root beans.xml, but rather being able to modify that which the libraries set up. > 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 > Priority: Critical > Fix For: 1.1 (Proposed) > > > 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, 9 months

1
0
0 / 0

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

by Dmitri Zamysloff (JIRA)

[ https://issues.jboss.org/browse/CDI-18?page=com.atlassian.jira.plugin.sys... ] Dmitri Zamysloff commented on CDI-18: ------------------------------------- Sorry, producers of course not providers :) And yes I red it all above. I mean it is still not clear for me if it would be possible specify interceptors for example in WEB-INF for whole classes graph in web application? Right now as described in my post which I have linked we have an issue in jboss. It is pity that we have to register interceptors in each jar where we use them. What I really want to avoid is that the teams which work on parts of our huge solution must be aware of which interceptor classes they have to register in their jar's beans.xml files. I want that they just put empty beans.xml in their jar just to mark one for CDI scanner. I mean probably idea of scopes with levels jar->app->enterprise is not the bad one? Regarding desktop we trying already to adopt weld for our fat client. Everybody here is just infected with CDI. It simplifies a lot of stuff but we need clear playing rules. Rules which help you but not make it inflexible. > 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 > Priority: Critical > Fix For: 1.1 (Proposed) > > > 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, 9 months

1
0
0 / 0

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

by Dmitri Zamysloff (JIRA)

[ https://issues.jboss.org/browse/CDI-18?page=com.atlassian.jira.plugin.sys... ] Dmitri Zamysloff edited comment on CDI-18 at 9/13/12 9:18 AM: -------------------------------------------------------------- Sorry, producers of course not providers :) And yes I red it all above. I mean it is still not clear for me if it would be possible specify interceptors for example in WEB-INF for whole classes graph in web application or not? Right now as described in my post which I have linked we have an issue in jboss. It is pity that we have to register interceptors in each jar where we use them. What I really want to avoid is that the teams which work on parts of our huge solution must be aware of which interceptor classes they have to register in their jar's beans.xml files. I want that they just put empty beans.xml in their jar just to mark one for CDI scanner. I mean probably idea of scopes with levels jar->app->enterprise is not the bad one? Regarding desktop we trying already to adopt weld for our fat client. Everybody here is just infected with CDI. It simplifies a lot of stuff but we need clear playing rules. Rules which help you but not make it inflexible. was (Author: dzcs): Sorry, producers of course not providers :) And yes I red it all above. I mean it is still not clear for me if it would be possible specify interceptors for example in WEB-INF for whole classes graph in web application? Right now as described in my post which I have linked we have an issue in jboss. It is pity that we have to register interceptors in each jar where we use them. What I really want to avoid is that the teams which work on parts of our huge solution must be aware of which interceptor classes they have to register in their jar's beans.xml files. I want that they just put empty beans.xml in their jar just to mark one for CDI scanner. I mean probably idea of scopes with levels jar->app->enterprise is not the bad one? Regarding desktop we trying already to adopt weld for our fat client. Everybody here is just infected with CDI. It simplifies a lot of stuff but we need clear playing rules. Rules which help you but not make it inflexible. > 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 > Priority: Critical > Fix For: 1.1 (Proposed) > > > 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, 9 months

1
0
0 / 0

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

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-18?page=com.atlassian.jira.plugin.sys... ] Pete Muir commented on CDI-18: ------------------------------ Dimitri, thanks for the feedback! For CDI 1.1 we can only specify what happens in a Java EE container, Java SE is not currently a specified platform. However we should certainly consider that case too and make sure what we do define for Java EE does not prohibit a good solution for SE as well. I believe the active proposal addresses your requirements(as I understood them), can you read it over and let us know anything you feel is not met. I'm not sure what PROVIDERS refers to exactly? > 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 > Priority: Critical > Fix For: 1.1 (Proposed) > > > 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, 9 months

1
0
0 / 0

[JBoss JIRA] (CDI-75) Clarify what happens to a bean which belongs to inactive when it observes an event

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-75?page=com.atlassian.jira.plugin.sys... ] Pete Muir commented on CDI-75: ------------------------------ I would propose implementing this by ANDing any values supplied, and calling out illegal combinations: * ALWAYS - legal * IF_EXISTS - legal * IF_ACTIVE - legal * ALWAYS, IF_EXISTS - illegal * ALWAYS, IF_ACTIVE - illegal * IF_EXISTS, IF_ACTIVE - legal * IF_EXISTS, IF_ACTIVE, ALWAYS - illegal An illegal combination would be a definition error. Let's also thing about names. IF_ACTIVE is nice (it has a precedent with IF_EXISTS) however it's not overly accurate (it refers to the context being active), however IF_EXISTS is the same, it refers to whether an instance of the bean defining the observer exists. > Clarify what happens to a bean which belongs to inactive when it observes an event > ---------------------------------------------------------------------------------- > > Key: CDI-75 > URL: https://issues.jboss.org/browse/CDI-75 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Affects Versions: 1.0 > Reporter: Pete Muir > Assignee: Pete Muir > 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, 9 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev September 2012