Adaptive Personalization Manual / Version 2107
Table Of Contents
Implementing your own ContextSource is straightforward. It is quite similar to the implementation
of a Spring HandlerInterceptor in that the interface declares several methods called in a request's
lifecycle. What you do within those methods is entirely up to you, but keep in mind that they are executed for
each request, so
make them fast and
make them robust.
You are free to throw any kind of exception within a ContextSource implementation - the
ContextCollector represents an exception firewall that will log the exception and continue with the
next source.
You will notice that almost all methods in the ContextSource interface expect a
ContextCollection argument. This argument represents the collection used for the current request in
the state at the time of the call. Hence, if source A's preHandle method is executed before source
B's, A will not see any objects added later by B. Keep this in mind if you think about the order of your
sources.
There are a couple of conventions you should follow to create a proper ContextSource:
If you want your
ContextSourceto be independent of the type of context object it manages (if your source is only concerned with storing and not modifying contexts in any way, for example), support theContextFactoryorContextCoDecinterfaces. Most context objects implement these interfaces and thus can readily be used by any source that supports them.If your source serializes and persists context objects, check for the
DirtyFlagMaintainerinterface on a context object before storing it. If the interface is implemented and the dirty flag is not set, you do not need to store the context because it has not changed since it was last read. Make sure that you reset the dirty flag if you save the context.
Finally, if you do not need to execute logic in all request phases, you might want to derive your source from
AbstractContextSource, which provides empty implementations of all ContextSource
methods.
