--> Ordering & Enablement I've been thinking about this again and again. And honestly I don't like any of the proposed solution (though I don't have any better ;-). Also I came across the following problems. Visibility xxxxxxxxxx Suppose our app is packaged as an EAR. What happens if one of bean archives globally enables interceptor that is not visible for another bean archive? Basically there are two options: 1) the container automatically detects the problem and treats it as a deployment problem - corresponds with 9.4. Interceptor enablement and ordering: "If there is no class with the specified name, or if the class with the specified name is not an interceptor class, the container automatically detects the problem and treats it as a deployment problem." - that's fine, however it degrades global enablement feature 2) the interceptor is disabled (warning is logged...) for affected bean archive only - unclear and error prone - also degrades global enablement feature

Security xxxxxxxx Maybe this is only my paranoia but I'd hate to allow any library and/or its dependencies to silently enable interceptor/decorator in my business code. I know this kind of stuff is partially possible via extensions but this would be even more powerful (and dangerous). BTW something similar is already done in the servlet spec (e.g. @WebServlet annotation) - do you know what servlets your app exposes??? So I wouldn't allow libraries (bean archives in WEB-INF/lib, EAR bundled libs and installed libs) to manage interceptors/decorators/alternatives in my app.

And this leads me to the question: Shouldn't we address the visibility issues, and overall definition of a CDI application (e.g. CDI-129) first?

My two cents... Martin Dne 4.9.2012 16:17, Pete Muir napsal(a): > 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 > _______________________________________________ cdi-dev mailing list cdi-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev