Re: [cdi-dev] Minutes from 03 September meeting

Finally, we discussed (2). 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 (2).

Present ====== Pete Muir Jozef Hartinger Martin Kouba Mark Struberg (quiet, as it was a US holiday) Ordering & Enablement ================== 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. @Vetoed ======= We agreed this does address much of the problem it sets out to solve "CDI, leave my class alone, hands off or I drop you". It's not perfect, but it is useful. We will add it, and then look at the feedback, do we have people wanting a inbetween level of control? @Named clarification ================= Approved my new pull. Should address stereotypes as well. scan.xml ======= Pete to push this to Java EE EG. _______________________________________________ cdi-dev mailing list cdi-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev