That last paragraph describes the cleanup I want to do. If a
LocalDispatcher contains things specific to an application, then why are
some of those things kept in GenericDispatcher and others are kept in
DispatchContext? This is the feature-envy part - they are both trying to
be the same thing.
It would simpler and cleaner if we keep application-specific bits in
GenericDispatcher, and just have DispatchContext reference it.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 8/31/2014 10:56 AM, Jacopo Cappellato wrote:
On Aug 31, 2014, at 11:36 AM, Jacopo Cappellato
<jacopo.cappell...@hotwaxmedia.com> wrote:
a) what is the original concern of DispatchContext and of GenericDispatcher
This comes from this old but still interesting document:
http://ofbiz.apache.org/docs/services.html
========================================
*Service Dispatcher*
The Service Dispatcher handles dispatching services to the appropriate Service
Engine where it is then invoked. There is exactly one ServiceDispatcher for
each Entity Delegator. If there are multiple delegators in an application there
will also be multiple dispatchers. The ServiceDispatcher is accessed via a
LocalDispatcher. There can be many LocalDispatchers associated with a
ServiceDispatcher. Each LocalDispatcher is uniquely named and contains its own
list of service definitions. When creating an instance of a LocalDispatcher, a
DispatchContext is also created and passed to the ServiceEngine.
A LocalDispatcher is associated with an application. Applications never talk
directly to the ServiceDispatcher. The LocalDispatcher contains an API for
invoking services, which are routed through the ServiceDispather. However,
applications may be running in different threads than the actual
ServiceDispatcher, so it is left to the LocalDispatcher to keep a
DispatchContext which among other things keeps a reference to the applications
classloader.
*Dispatch Context*
The DispatchContext is created by the LocalDispatcher upon instantiation. This
is the runtime dispatcher context. It contains necessary information to process
services for each dispatcher. This context contains the reference to each of
the service definition files, the classloader which should be used for
invocation, a reference to the delegator and its dispatcher along with a 'bag'
of user defined attributes. This context is passed on to each service when
invoked and is used by the dispatcher to determine the service's model.
========================================
Jacopo
