September 2012 - cdi-dev - Jboss List Archives

[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 updated CDI-75: ------------------------- Fix Version/s: 1.1 (Proposed) (was: 1.1.PRD) Forum Reference: http://lists.jboss.org/pipermail/weld-dev/2010-April/002425.html (was: http://lists.jboss.org/pipermail/weld-dev/2010-April/002425.html) > 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-255) Support for Implicit Producers

by Pete Muir (JIRA)

Pete Muir created CDI-255: ----------------------------- Summary: Support for Implicit Producers Key: CDI-255 URL: https://issues.jboss.org/browse/CDI-255 Project: CDI Specification Issues Issue Type: Tracker Reporter: Pete Muir An implicit producer could be registered for every unambiguous resource the Java EE container knows about. -- 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

11 years, 8 months

1
5
0 / 0

[JBoss JIRA] (CDI-27) Support declarative transactions on managed beans

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-27?page=com.atlassian.jira.plugin.sys... ] Pete Muir updated CDI-27: ------------------------- Fix Version/s: 1.1 (Proposed) (was: 1.1.PRD) > Support declarative transactions on managed beans > ------------------------------------------------- > > Key: CDI-27 > URL: https://issues.jboss.org/browse/CDI-27 > Project: CDI Specification Issues > Issue Type: Tracker > Components: Java EE integration > 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-50) Ability to veto beans, both unconditionally and based on classes visible

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-50?page=com.atlassian.jira.plugin.sys... ] Pete Muir resolved CDI-50. -------------------------- Resolution: Done We've added @Vetoed. This addresses the majority of use cases "Please don't touch my bean CDI". We'll see if the community want a more fine grained approach to addresses other use cases. > Ability to veto beans, both unconditionally and based on classes visible > ------------------------------------------------------------------------ > > Key: CDI-50 > URL: https://issues.jboss.org/browse/CDI-50 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Concepts, Packaging and Deployment > Affects Versions: 1.0 > Reporter: Pete Muir > Assignee: Pete Muir > Fix For: 1.1.PRD > > > This should support both a straight veto, and conditional based on classes available. > Seam Solder supports this as @Veto and @Requires({Foo.class, Bar.class}). > Mark Struberg proposed using @Optional -- 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-4) Need a way to provide ordering for Event observers

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-4?page=com.atlassian.jira.plugin.syst... ] Pete Muir updated CDI-4: ------------------------ Summary: Need a way to provide ordering for Event observers (was: Need a way to provide ordering for Event observers, interceptors, decorators and alternatives) Fix Version/s: TBD (was: 1.1.PRD) Fix issue title to just be about event observers. Defer > Need a way to provide ordering for Event observers > -------------------------------------------------- > > Key: CDI-4 > URL: https://issues.jboss.org/browse/CDI-4 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Events, Portable Extensions > Affects Versions: 1.0 > Environment: All > Reporter: Lincoln Baxter III > Assignee: Pete Muir > Fix For: TBD > > > There needs to be a way to specify some kind of ordering for Event observers. > Understandably, this is somewhat counter-intuitive to the general concept of observing an event, but there is going to be need for this in an upcoming JBoss project. While it can be done manually, it might be nice to have a built-in API. -- 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-4) Need a way to provide ordering for Event observers, interceptors, decorators and alternatives

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-4?page=com.atlassian.jira.plugin.syst... ] Pete Muir reopened CDI-4: ------------------------- > Need a way to provide ordering for Event observers, interceptors, decorators and alternatives > --------------------------------------------------------------------------------------------- > > Key: CDI-4 > URL: https://issues.jboss.org/browse/CDI-4 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Events, Portable Extensions > Affects Versions: 1.0 > Environment: All > Reporter: Lincoln Baxter III > Assignee: Pete Muir > Fix For: 1.1.PRD > > > There needs to be a way to specify some kind of ordering for Event observers. > Understandably, this is somewhat counter-intuitive to the general concept of observing an event, but there is going to be need for this in an upcoming JBoss project. While it can be done manually, it might be nice to have a built-in API. -- 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 Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-18?page=com.atlassian.jira.plugin.sys... ] Pete Muir commented on CDI-18: ------------------------------ >From the CDI 1.1 EG meeting on 3rd Sept ---- We discussed the ordering and enablement issue, and how it intersects with bean archives. We all agreed that the key issue to allowing default/global enablement of interceptors, decorators and alternatives was to provide a global ordering solution. We discussed the three proposals: (1) Relative ordering of individual interceptors, decorators and alternatives using either a name or an ordering qualifier (2) Ordinal/magic number based ordering of individual interceptors, decorators and alternatives (3) Ordinal/magic number based ordering of lists of interceptors, decorators and alternatives (i.e. the ability to specify an order of beans.xml, which themselves specify a partial ordering of interceptors, decorators and alternatives) We discussed the merits of each. In general, we didn't feel any solution is excellent, however this is a problem we must solve, so we must pick the best, even if it isn't perfect. Pete expressed concerns over the understandability of the merge of partial orders done in (3). Consider an application which has 10 libraries, each of which specify 10 interceptors in an order. There is some overlap between the lists. For a user to comprehend the overall order is not trivial in this case, it requires a tool to tell you the order. We discussed (1) and Mark expressed concerns that you can't easily express some well know use cases using it, without explicitly specifying the interceptor by name. For example, consider a TransactionInterceptor, which needs to be "outside all". This must specify "outside all". However, any other interceptor which wants to be outside everything should specify "outside all, inside TransactionInterceptor". This gets complex quite quickly. Its a less complex algorithm to comprehend than (1), but still requires quite a bit of thought to understand the overall order. Finally, we discussed (1). We agreed that it has some good precedents (e.g. httpd, SYS-V init) that have worked well for a long time. It's trivial to comprehend, and also quick to compute. It does require a knowledge of the position of other algorithms, but so do all other approaches considered. We agreed to recommend approach (1). A lower number indicates the interceptor or decorator should appear earlier in the call stack, a higher number indicates it should appear later in the call stack. A higher number alternative takes precedence over a lower number alternative (OPEN ISSUE: how does this interact with class hierarchies?). Two interceptors, decorators and alternatives with the same number have the same precedence, and their order is not defined. We discussed that we should use recommended ranges for the magic numbers. For example: 1-100: System interceptors, decorators and alternatives (interceptors specified by CDI or the Java EE platform specs) 100 - 1000: Extension interceptors, decorators and alternatives (interceptors provided by extension libraries such as Deltaspike) 1000 - 2000: Application interceptors, decorators and alternatives (interceptors provided by an application or internal extension) 2000 - 3000: Extension interceptors, decorators and alternatives 3000 - 3100: System interceptors, decorators and alternatives Note that we need to allow system interceptors to go before (e.g transaction) or after (e.g. validation). Using this "pyramid" of ranges allows for this. Next, we discussed that this needs to be overridable by the SPI, and that the SPI should present a merged view of all interceptors, decorators and alternatives. This should be delivered once, for the whole application. The extension can mutate the list, to change which interceptors, decorators and alternatives are enabled, and the ordering. We looked at the events, and agreed that deferring it as late as possible is good, to allow extensions to have as much info as possible. AfterBeanDiscovery is as late as it can go, as we need this info to perform validation. Next, we discussed where the ordinal number can be placed, and said that: * A bean archive which declares an interceptor (alternative or decorator) can set the ordinal, by adding an entry in beans.xml like: <beans> <interceptors> <class priority="1001">com.acme.FooInterceptor</class> </interceptors> </beans> OPEN ISSUE: Is priority the right attribute? * The application can override the ordering, by specifying the interceptor class, and providing another ordinal. It can able disable an interceptor, decorator or alternative, by adding the enabled="false" attribute. OPEN ISSUE: Can other libraries disable interceptors and change the precedence? If so, which one wins? Finally, we decided to remove the ProcessModule event. > 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-4) Need a way to provide ordering for Event observers, interceptors, decorators and alternatives

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-4?page=com.atlassian.jira.plugin.syst... ] Pete Muir resolved CDI-4. ------------------------- Fix Version/s: 1.1.PRD (was: 1.1 (Proposed)) Resolution: Duplicate Issue I'm marking this as a dupe of CDI-18 as we need to consider both issues in parallel. > Need a way to provide ordering for Event observers, interceptors, decorators and alternatives > --------------------------------------------------------------------------------------------- > > Key: CDI-4 > URL: https://issues.jboss.org/browse/CDI-4 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Events, Portable Extensions > Affects Versions: 1.0 > Environment: All > Reporter: Lincoln Baxter III > Assignee: Pete Muir > Fix For: 1.1.PRD > > > There needs to be a way to specify some kind of ordering for Event observers. > Understandably, this is somewhat counter-intuitive to the general concept of observing an event, but there is going to be need for this in an upcoming JBoss project. While it can be done manually, it might be nice to have a built-in API. -- 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-58) Clarify that there can be multiple AnnotatedType instances per Java class

by Mark Struberg (JIRA)

[ https://issues.jboss.org/browse/CDI-58?page=com.atlassian.jira.plugin.sys... ] Mark Struberg commented on CDI-58: ---------------------------------- looks good. You might add that getId() must return a unique Id (e.g. prefixed with the Extension name) and "If multiple IdentifiedAnnotatedTypes with the same class and Id get added, the container automatically detects the problem and treats it as a definition error." > 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, 8 months

1
0
0 / 0

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

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-58?page=com.atlassian.jira.plugin.sys... ] Pete Muir commented on CDI-58: ------------------------------ We discussed this in a special EG meeting last week. The conclusion was * allow multiple annotated types per class instance * introduce an {code} public interface IdentifiedAnnotatedType<X> extends AnnotatedType<X> { public String getId(); } {code} * if addAnnotatedType() is called, an existing AnnotatedType already exists in the bean archive (either due to scanning, or due to a previous addAnnotatedType() operation) then an instance of IdentifiedAnnotatedType must be passed, otherwise, a deployment exception will occur. * we will recommend extensions always add IdentifiedAnnotatedTypes so that they cannot cause a deployment exception due to unexpected external circumstances. > 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, 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