9:17 a.m.
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.