Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Swordfish Documentation: Architecture: Interceptor Framework"
Line 16: | Line 16: | ||
</osgi:interfaces> | </osgi:interfaces> | ||
</osgi:service> | </osgi:service> | ||
− | </pre> | + | </pre> |
− | + | ||
==== Pros ==== | ==== Pros ==== | ||
*Only one implementation class required | *Only one implementation class required | ||
− | *Service registration straightforward | + | *Service registration straightforward |
− | ==== Cons | + | ==== Cons ==== |
− | *different method names require conditional processing in chain execution | + | *different method names require conditional processing in chain execution |
== Option 2 (proposed by Zsolt) == | == Option 2 (proposed by Zsolt) == | ||
Line 77: | Line 76: | ||
*New dimensions can easily be added by defining additional properties | *New dimensions can easily be added by defining additional properties | ||
− | *Unified interface makes chain execution straightforward (no conditional processing) | + | *Unified interface makes chain execution straightforward (no conditional processing) |
− | ==== Cons | + | ==== Cons ==== |
*Interceptor implementation scattered over multiple classes if different behaviour is required | *Interceptor implementation scattered over multiple classes if different behaviour is required |
Revision as of 10:49, 12 November 2009
Contents
Option 1 (proposed by Jürgen)
In option 1, we would have four interfaces representing the four processing positions. An interceptor might implement only a subset of these interfaces.
Example of interceptor registration:
<bean id="exampleInterceptor" class="org.eclipse.swordfish.plugins.samples.ExampleInterceptor"/> <osgi:service ref="exampleInterceptor"> <osgi:interfaces> <value>org.eclipse.swordfish.core.ConsReqInterceptor</value> <value>org.eclipse.swordfish.core.ConsResInterceptor</value> <value>org.eclipse.swordfish.core.ProvReqInterceptor</value> <value>org.eclipse.swordfish.core.ProvresInterceptor</value> </osgi:interfaces> </osgi:service>
Pros
- Only one implementation class required
- Service registration straightforward
Cons
- different method names require conditional processing in chain execution
Option 2 (proposed by Zsolt)
In option 2, we would have a uniform interface but up to four different classes implementing this interface, one for each processing position.
Example of interceptor registration:
<bean id="exampleConsReqInterceptor" class="org.eclipse.swordfish.plugins.samples.ExampleConsReqInterceptor"/> <bean id="exampleConsResInterceptor" class="org.eclipse.swordfish.plugins.samples.ExampleConsResInterceptor"/> <bean id="exampleProvReqInterceptor" class="org.eclipse.swordfish.plugins.samples.ExampleProvReqInterceptor"/> <bean id="exampleProvResInterceptor" class="org.eclipse.swordfish.plugins.samples.ExampleProvResInterceptor"/> <osgi:service ref="exampleConsReqInterceptor" interface=“org.eclipse.swordfish.core.Interceptor“> <osgi:service-properties> <entry key=“role“ value=“consumer“/> <entry key=“scope“ value=“request“/> </osgi:service-properties> </osgi:service> <osgi:service ref="exampleConsResInterceptor" interface=“org.eclipse.swordfish.core.Interceptor“> <osgi:service-properties> <entry key=“role“ value=“consumer“/> <entry key=“scope“ value=“response“/> </osgi:service-properties> </osgi:service> <osgi:service ref="exampleProviderReqInterceptor" interface=“org.eclipse.swordfish.core.Interceptor“> <osgi:service-properties> <entry key=“role“ value=“provider“/> <entry key=“scope“ value=“request“/> </osgi:service-properties> </osgi:service> <osgi:service ref="exampleProvResInterceptor" interface=“org.eclipse.swordfish.core.Interceptor“> <osgi:service-properties> <entry key=“role“ value=“provider“/> <entry key=“scope“ value=“response“/> </osgi:service-properties> </osgi:service>
If the interceptor should exhibit the same behaviour in all four processing positions, only one implementation class would be needed that is registered as shown below:
<bean id="exampleInterceptor" class="org.eclipse.swordfish.plugins.samples.ExampleInterceptor"/> <osgi:service ref="exampleInterceptor" interface=“org.eclipse.swordfish.core.Interceptor“> <osgi:service-properties> <entry key=“role“ value=“consumer,provider“/> <entry key=“scope“ value=“request,response“/> </osgi:service-properties> </osgi:service>
Pros
- New dimensions can easily be added by defining additional properties
- Unified interface makes chain execution straightforward (no conditional processing)
Cons
- Interceptor implementation scattered over multiple classes if different behaviour is required