September 2012 - cdi-dev - Jboss List Archives

[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 7:34 AM: -------------------------------------------------------------- Hi together, as the follow-up to the thread https://community.jboss.org/thread/200853. INTERCEPTORS The specification says that the "beans.xml" is valid per beans archive. But as a specification user I would prefer to have the validity of registered interceptors hierarchically. That means following: IN CONTAINER 1. The first level where the beans.xml file must appear is the bean archive (jar file) if and only if the classes in jar utilize CDI. Already there the first interceptors can be defined. In other words - I CAN say which interceptors I want to use per default for my interception bindings. Defined interceptors will be active only if this definition is not overridden on upper level. AND - if within the jar I declare interceptors I MUST create META-INF/beans.xml where I CAN register my interceptors. My registered interceptors will be active for all binding and not only in this particular jar only in case my jar is together with other jars in class path and my interceptors are not overridden in upper layers or in jar which use interceptor bindings itself. 2. The second and third level are the web/service/resource and enterprise applications respectively. On these levels the application assembly must be able to override the interceptors defined on lower level. Means: if I have registered interceptor for @Foo @Default in jar, the application which have this jar in class path can override registered interceptor by registering another interceptor for the same binding and qualifier in own beans.xml file. DESKTOP 1. The first level as in container. 3. The desktop applications which utilize CDI instantiating implementation directly must be able to provide top-level beans.xml to the implementation. Ddefinitions in this beans.xml will override existing interceptor registrations on class path. ------------------------ PROVIDERS I think it is necessary to clarify the situation with providers also. what happens so far if I have two providers of the same type in class path???? was (Author: dzcs): Hi together, as the follow-up to the thread https://community.jboss.org/thread/200853. INTERCEPTORS The specification says that the "beans.xml" is valid per beans archive. But as a specification user I would prefer to have the validity of registered interceptors hierarchically. That means following: IN CONTAINER 1. The first level where the beans.xml file must appear is the bean archive (jar file) if and only if the classes in jar utilize CDI. Already there the first interceptors can be defined. In other words - I CAN say which interceptors I want to use per default for my interception bindings. Defined interceptors will be active only if this definition is not overridden on upper level. AND - if within the jar I declare interceptors I MUST create META-INF/beans.xml where I CAN register my interceptors. My registered interceptors will be active for all binding and not only in this particular jar only in case my jar is together with other jars in class path and my interceptors are not overridden in upper layers or in jar which use interceptor bindings itself. 2. The second and third level are the web and enterprise applications respectively. On these levels the application assembly must be able to override the interceptors defined on lower level. Means: if I have registered interceptor for @Foo @Default in jar, the application which have this jar in class path can override registered interceptor by registering another interceptor for the same binding and qualifier in own beans.xml file. DESKTOP 1. The first level as in container. 3. The desktop applications which utilize CDI instantiating implementation directly must be able to provide top-level beans.xml to the implementation. Ddefinitions in this beans.xml will override existing interceptor registrations on class path. ------------------------ PROVIDERS I think it is necessary to clarify the situation with providers also. what happens so far if I have two providers of the same type in class path???? > 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, 8 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: ------------------------------------- Hi together, as the follow-up to the thread https://community.jboss.org/thread/200853. INTERCEPTORS The specification says that the "beans.xml" is valid per beans archive. But as a specification user I would prefer to have the validity of registered interceptors hierarchically. That means following: IN CONTAINER 1. The first level where the beans.xml file must appear is the bean archive (jar file) if and only if the classes in jar utilize CDI. Already there the first interceptors can be defined. In other words - I CAN say which interceptors I want to use per default for my interception bindings. Defined interceptors will be active only if this definition is not overridden on upper level. AND - if within the jar I declare interceptors I MUST create META-INF/beans.xml where I CAN register my interceptors. My registered interceptors will be active for all binding and not only in this particular jar only in case my jar is together with other jars in class path and my interceptors are not overridden in upper layers or in jar which use interceptor bindings itself. 2. The second and third level are the web and enterprise applications respectively. On these levels the application assembly must be able to override the interceptors defined on lower level. Means: if I have registered interceptor for @Foo @Default in jar, the application which have this jar in class path can override registered interceptor by registering another interceptor for the same binding and qualifier in own beans.xml file. DESKTOP 1. The first level as in container. 3. The desktop applications which utilize CDI instantiating implementation directly must be able to provide top-level beans.xml to the implementation. Ddefinitions in this beans.xml will override existing interceptor registrations on class path. ------------------------ PROVIDERS I think it is necessary to clarify the situation with providers also. what happens so far if I have two providers of the same type in class path???? > 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, 8 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 Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-75?page=com.atlassian.jira.plugin.sys... ] Martin Kouba edited comment on CDI-75 at 9/13/12 3:09 AM: ---------------------------------------------------------- +1 for redefining notifyObservers as an array. The only inconsistency I see is notifyObservers={ALWAYS, IF_EXISTS, IF_CONTEXT_ACTIVE}... we'll have to define some priorities or something similar. was (Author: mkouba): +1 for redefining notifyObservers as an array. The only inconsistency I see is *notifyObservers*={ALWAYS, IF_EXISTS, IF_CONTEXT_ACTIVE}_... we'll have to define some priorities or something similar. > 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, 8 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 Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-75?page=com.atlassian.jira.plugin.sys... ] Martin Kouba edited comment on CDI-75 at 9/13/12 3:06 AM: ---------------------------------------------------------- +1 for redefining notifyObservers as an array. The only inconsistency I see is *notifyObservers*={ALWAYS, IF_EXISTS, IF_CONTEXT_ACTIVE}_... we'll have to define some priorities or something similar. was (Author: mkouba): +1 for redefining notifyObservers as an array. The only inconsistency I see is *notifyObservers={ALWAYS, IF_EXISTS, IF_CONTEXT_ACTIVE}*... we'll have to define some priorities or something similar. > 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, 8 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 Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-75?page=com.atlassian.jira.plugin.sys... ] Martin Kouba edited comment on CDI-75 at 9/13/12 3:05 AM: ---------------------------------------------------------- +1 for redefining notifyObservers as an array. The only inconsistency I see is *notifyObservers={ALWAYS, IF_EXISTS, IF_CONTEXT_ACTIVE}*... we'll have to define some priorities or something similar. was (Author: mkouba): +1 for redefining notifyObservers as an array. The only inconsistency I see is *notifyObservers={{ALWAYS, IF_EXISTS, IF_CONTEXT_ACTIVE}*... we'll have to define some priorities or something similar. > 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, 8 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 Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-75?page=com.atlassian.jira.plugin.sys... ] Martin Kouba commented on CDI-75: --------------------------------- +1 for redefining notifyObservers as an array. The only inconsistency I see is *notifyObservers={{ALWAYS, IF_EXISTS, IF_CONTEXT_ACTIVE}*... we'll have to define some priorities or something similar. > 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, 8 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: ------------------------------ Jens, I like your proposal. Two points 1. We could redefine notifyObservers as an array to allow notifyObservers={IF_EXISTS, IF_ACTIVE} which I think is a bit cleaner than the compound enum value (but not that clean)! 2. I think this is backwards compat, as long as the default remains ALWAYS WDYT about (1)? > 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, 8 months

1
0
0 / 0

[JBoss JIRA] Created: (CDI-110) Allow proxying of abstract classes (Service Handler)

by George Gastaldi (JIRA)

Allow proxying of abstract classes (Service Handler) ---------------------------------------------------- Key: CDI-110 URL: https://issues.jboss.org/browse/CDI-110 Project: CDI Specification Issues Issue Type: Feature Request Components: Inheritance and Specialization Affects Versions: 1.1 (Proposed) Reporter: George Gastaldi According to mojavelinux: {quote} <mojavelinux> service handler, interceptors and decorators are all complementary <mojavelinux> and cdi is missing the first...which we now realize {quote} CDI 1.1 should provide a way to inject abstract classes by specifying a ServiceHandler (Check http://docs.jboss.org/seam/3/solder/latest/reference/en-US/html/serviceha...) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 8 months

10
34
0 / 0

[JBoss JIRA] (CDI-24) Make it easier to build passivating contexts by making sure Contextual objects passed to them are serializable

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-24?page=com.atlassian.jira.plugin.sys... ] Pete Muir updated CDI-24: ------------------------- Assignee: Pete Muir Fix Version/s: 1.1.PRD (was: 1.1 (Proposed)) Please review https://github.com/jboss/cdi/pull/111 > Make it easier to build passivating contexts by making sure Contextual objects passed to them are serializable > -------------------------------------------------------------------------------------------------------------- > > Key: CDI-24 > URL: https://issues.jboss.org/browse/CDI-24 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Contexts > Affects Versions: 1.0 > Reporter: Pete Muir > Assignee: Pete Muir > Fix For: 1.1.PRD > > > OWB ensures that any Contextual impl passed to a passivating context is serializable, making it much easier to impl a custom passivating context. We should probably make this required by the 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, 8 months

1
0
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 updated CDI-59: ------------------------- Assignee: Pete Muir (was: Marius Bogoevici) Fix Version/s: 1.1.PRD (was: 1.1 (Proposed)) Please review https://github.com/jboss/cdi/pull/110 > 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, 8 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev September 2012