"tfennelly" wrote : Basically, the ActionProcessor definition seems fundamentally flawed to me in that notification generation (OK and Error) is done seperately from the message processing to which it is inextricably tied. | OK, now I understand. The issue is that the model worked fine before the pipeline change went in, but now it does not fit. In the model prior to pipelining, the notification of success or failure was implicitly tied to the message/object that was used to perform the work. Now it isn't, particularly if we let pipelines continue in the event of a failure. anonymous wrote : | That's what I meant originally when I said that I thought it was "dodgy". The way I see this, saving before/after/whatever objects is not going to fix this properly - the notifications need to be generated in context i.e. in line with the message processing to which they are tied. | I'm not convinced that the pipelining architecture has been fully thought out in terms of errors and successes. It seems like the chaining of "do work" is fine, but how errors or sucess notifications play in this hasn't been fully appreciated. We need to revisit that. BTW, if you raised this as a potential issue when doing the original pipelining work, then it's my fault for not catching it. anonymous wrote : | Doing it any other way is always going to cause trouble for somone. Whether or not this is sorted out for the GA is (I think) a question of how important Notifications are for the GA. | Sounds like a fundamental issue to me. anonymous wrote : | I suggested somewhere else that we could implement a notification mechanism by allowing the process method impls add notification objects to the Message. | Fault's are faults. If an error happens and the element in the chain needs to inform the caller, then the chain processing should stop immediately and return an appropriate message to the caller. The issue at this stage will be that the element in the chain may need to know it was working in a pipeline. However, that's a contract issue and can be fixed later IMO. I would say that both the success and error notifications go to the entity managing the pipeline. If it gets an error then it immediately returns that error message to the caller. If it gets a success then it either returns that message to the caller if there are no other entries in the chain, or it simply calls the next entry in the chain. anonymous wrote : | A list of notifications (info, warn, error) could accumulate on the message as it flows through the pipeline | They could, but I would prefer a much simpler approach: signalling an error notification means "terminate processing and return the notification to the caller"; if the ActionProcessor wants to chain faults that don't really have a significant impact on processing, or warning messages, then it can embed them in the body of the message to be sent on to the next entry in the pipeline. This is an application specific issue at this stage. How (and if) the last entry in the pipeline chooses to then send those chained warnings back to the caller is up to it. anonymous wrote : , being sent once the pipeline processing is complete (the notification list retrieved from the message via some form of getter). This may need to tie in in some way with the message Fault?? | Once we have support for EPRs within the architecture, using the Fault message (and the FaultTo EPR of the Call) would be the natural way to handle this. anonymous wrote : | This would also enable an ActionProcessor impl to send multiple notifications from within the context of the processing of a single message. Starting to sound complex. Let's stick with Occam's Razor for now and K.I.S.S. ;-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3976935#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...