Sorry I didn't review this before (was on vacation at the time). Few specific things.
- API should be separate and in a org.mule.api package tree.
- "message.processing" doesn't seem a very good package name, isn't there anything better?
- "org.mule.message.processing.PhaseResultNotifier.phaseSuccessfully()" shouldn't that be "phaseCompletedSuccessfully" or phaseSuccessfull()?
My overall concern with this though is:
- I can't find any discussion or design document around this on a fairly significant addition to mule-core, which I'd have expected. Is there anything?
- Mule already has a processing model (with it's limitations of course) and this package appears to introduce another one using a different approach for use in some specific cases as well as including some interfaces that have significant similarities with existing mule constructs. e.g. MessageProcessContext & MuleEvent. I'm not saying this wasn't required, just not something we should do without careful consideration. Was it not possible to either i) achieve what was required with existing processing model or ii) improve existing model to cater for needs?
Given this, and given it's only actually used for http currently, does it really make sense to introduce this into mule-core at this point?
On Sun, Jan 6, 2013 at 12:06 AM, <[hidden email]> wrote:
|Free forum by Nabble||Edit this page|