Agreed, most of case would have worked OOTB, but better to have a specific name
indeed. So I expect it will work now, OK thanks.
BTW, I began to study the Executor framework, interesting.
Jacques
From: "Jacopo Cappellato" <[email protected]>
No, I didn't. But the NPE that was initially reported was actually caused by an
issue in the construction mechanism of the
ServiceDispatcher/GenericDispatcher classes and this is fixed by my recent
refactoring; I believe that the error should not happen
again (and changing the name from JMSDispatcher to "entity-default" was really
a wrong way to fix it, because it was simply
working if the "entity-default" dispatcher exists... and this may depend on how
the system is configured).
Jacopo
On Jul 23, 2012, at 8:48 AM, Jacques Le Roux wrote:
Hi Jacopo,
In r1364222 I saw you changed back the name of the AbstractJmsListener to
JMSDispatcher. Did you check if it works when you set a
jms-service in serviceengine.xml, like with DCC?
Jacques
From: "Jacopo Cappellato" <[email protected]>
On Jul 20, 2012, at 9:33 AM, Adrian Crum wrote:
I agree there is a lot of feature envy between classes. The API could be
cleaned up a lot.
From my perspective, the GenericDispatcher.getLocalDispatcher method should not
exist - since it forces you to reference an
implementation. Instead, there should be a separate service dispatcher factory.
I agree this is the right direction to go.
In rev. 1364222, I did a first pass cleanup of the code in the DispatchContext
and in the methods related to the
creation/retrieval of ServiceDispatcher/GenericDispatcher objects; this should
simplify the refactoring of the API and now the
code is a bit cleaner and more readable.
Since this first pass is quite relevant in terms of code changes (unfortunately
I couldn't find a better way to split these in
more commits) I would really appreciate your reviews and bug reports (if any)
and also your patience if you will find issues
caused by this change: I will do my best to fix them asap.
Jacopo
