[Jakarta HiveMind Wiki] New: InterceptorOrderingProposal

[hi...@jakarta.apache.org]

   Date: 2004-04-12T12:24:18
   Editor: HowardLewisShip <hl...@apache.org>
   Wiki: Jakarta HiveMind Wiki
   Page: InterceptorOrderingProposal
   URL: http://wiki.apache.org/jakarta-hivemind/InterceptorOrderingProposal

   no comment

New Page:

#pragma section-numbers off

= Problem Description =

As of this writing (Apr 12 2004, not quite release 1.0-alpha-4), having multiple interceptors for a single service is somewhat problematic.

Currently, when an interceptor is contributed into a service point, you need to specify its '''order''', an integer value. The contributed interceptors are
sorted into ascending order and applied in that order.

attachment:interceptors.png

This not currently a big issue, since there's only a single interceptor shipped with the framework, the logging interceptor.

However, using explicit ordering ''feels'' limiting.  It's more natural to think in  terms of ordering ... order "security" before "performance" and order "logging" after everything else.

In addition, it is likely that developers will frequently want to apply the same ''set'' of interceptors to many services; typically a logging interceptor, and some kind of performance monitor.

= <interceptor-set> =

The first potential solution is to provide a set of interceptors:
{{{
  <service-point id="MyService" ...>
    <interceptor-set set-id="StandardSet"/>
  </service-point>

  <interceptor-set id="StandardSet">
     <interceptor service-id="hivemind.lib.PerformanceInterceptor"/>
     <interceptor service-id="hivemind.LoggingFactory"/>
  </interceptor-set>
}}}

Here, instead of defining an explicit order via an {{{order}}} attribute, there's an implicit order, based on simple position.

I'm not completely thrilled with this solution.
  * '''Plus''': It's succinct, and makes uniformity of many services pretty easy.
  * '''Neutral''': Do we only allow a single <interceptor> or <interceptor-set> per <service-point>? If not, we're kind of back where we started ... need some ordering.
  * '''Minus''': The more interesting interceptors (such as a hypothetical security interceptor) will require service parameters, which will be unique for each service.
  
= Ordering Via Dependencies =

A more complex, but generally more palatable, solution is to explicitly set the dependencies, perhaps as:

{{{
  <service-point id="MyService" ...>
    ...
  </service-point>

  <implementation service-id="MyService">
    <interceptor name="logging" service-id="hivemind.LoggingInterceptor" after="*"/>
  </implementation>

  <!-- And in a different module perhaps ... -->

  <implementation service-id="MyService">
    <interceptor name="perf" service-id="hivemind.lib.PerforamnceInterceptor"/>
    <interceptor name="security" service-id="hivemind.lib.SecurityInterceptor" before="perf">
      <method name="foo" allow="admin"/>
      ...
    </interceptor>
  </implementation>
}}}

So, each interceptor has a {{{name}}} attribute (which is presumably unique), and can specify which interceptors come before them (equivalent to lower order numbers in the current system), and which come after (equivalent to higher order numbers). In some cases, an interceptor may need to specify both {{{before}}} and {{{after}}}. In some cases, a comma-seperated list is appropriate. As in the example above, the occasional use of a wildcard is appropriate.

---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-cvs-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-cvs-help@jakarta.apache.org