The main service will never run if an error condition exists, I don't think that is something I would consider unexpected. I'm not really sure why the context validation is skipped but I don't think it matters much since the main service won't be run anyway. But anyway, just consider the main service to be set as run-on-error="false" permanently.
Aside from this there is the whole issue of transactions to consider, if a service error results in a transaction rollback then that will effect all other service calls executed within the same transaction. Regards Scott On 6/09/2011, at 10:19 PM, Anne wrote: > Thanks Scott. But I now think it's more complicated than that. > > After BJ's comment I spent nearly all of today going through the code > (ServiceDispatcher.java and friends) to try to answer my question. I > had hoped to avoid doing that, for what I thought was a simple > question. > > It's looking like it wasn't a simple question after all. In the > example you give, nothing after the "in-validate" event will be run > (assuming all have run-on-error="false"). However if instead we set > run-on-error="true" everywhere, then once the in-validate action has > an error, validation of the IN data will be skipped, and the main > service will *not* be run, but all the other SECAs will be run. Not > what I would have expected. > > I intend continuing through ServiceDispatcher and friends tomorrow. > Once I'm done, I'll write up something that will hopefully help the > next person who has questions about secas and errors/failures. > > Cheers, > Anne. > > On 6 September 2011 17:47, Scott Gray <scott.g...@hotwaxmedia.com> wrote: >> run-on-error="true", run this eca service even when the main service flow >> contains an error condition >> ignore-error="true", do not allow an error return from this service to cause >> an error condition in the main service flow >> >> For example if you have a "validate" event eca with ignore-error="false" >> that when executed it returns an error, and you then you have an "invoke" >> event eca with run-on-error="false" then this eca will not be executed >> because an error condition exists. >> >> Regards >> Scott >> >> On 6/09/2011, at 11:56 AM, Anne wrote: >> >>> Does anyone know how "run-on-error" (eca tag) and "ignore-error" >>> (action tag) attributes work for a SECA that is set to run at invoke >>> time? The documentation's wording suggests to me it is talking about a >>> commit or return SECA. >>> >>> Cheers, >>> Anne. >>> >>> On 2 September 2011 15:35, Anne <a...@cohsoft.com.au> wrote: >>>> Hi >>>> >>>> I've successfully added secas many times before, but only on actions >>>> that run after the service, such as "return" or "commit" events. I now >>>> need an "invoke" seca, and it isn't working the way I expected. So I >>>> re-read the documentation, and all that did was confuse me. :-( >>>> Searching the mailing list showed me plenty of examples that did make >>>> sense, but only for "return" or "commit" events, so they didn't help >>>> me at all. >>>> >>>> At http://ofbiz.apache.org/docs/services.html#ECAs it says for the eca >>>> tag "run-on-error Should this ECA run if there is an error in the >>>> service". I know the service it refers to is the one named in the eca >>>> tag. But if the event is set to invoke, the action service is run >>>> before the eca service is invoked. Does this mean the run-on-error >>>> attribute is irrelevant for an invoke event? >>>> >>>> Further down in the same page it says for the action tag "ignore-error >>>> Ignore any errors caused by the action service. If true the error >>>> will cause the original service to fail. Default true.". Does this >>>> mean, if ignore-error is true and the "invoke" action service returns >>>> an error, that: >>>> >>>> 1) the eca service will not be run, and an error will be returned ( I >>>> think not, as the attribute name would then be wrong)? OR >>>> >>>> 2) the eca service will not be run, but a failure will be returned? OR >>>> >>>> 3) the eca service will be run, but a failure (or error) will be >>>> returned no matter the result of the eca service? OR >>>> >>>> 4) the eca service will be run, and the return will be whatever the >>>> eca service returns >>>> >>>> >>>> What I'm trying to do is use a seca to check some things and not run >>>> the main service if the seca action service fails/errors. Perhaps I >>>> should be doing this on "auth" or "in-validate" events, but I'll still >>>> need a better understanding of "run-on-error" and "ignore-error". >>>> >>>> Anyone able to explain? >>>> >>>> Cheers, >>>> Anne. >>>> >>>> >>>> >>>> -- >>>> Coherent Software Australia Pty Ltd >>>> PO Box 2773 >>>> Cheltenham Vic 3192 >>>> Phone: (03) 9585 6788 >>>> Fax: (03) 9585 1086 >>>> Web: http://www.cohsoft.com.au/ >>>> Email: sa...@cohsoft.com.au >>>> >>>> Bonsai ERP, the all-inclusive ERP system >>>> http://www.bonsaierp.com.au/ >>>> >>> >>> >>> >>> -- >>> Coherent Software Australia Pty Ltd >>> PO Box 2773 >>> Cheltenham Vic 3192 >>> Phone: (03) 9585 6788 >>> Fax: (03) 9585 1086 >>> Web: http://www.cohsoft.com.au/ >>> Email: sa...@cohsoft.com.au >>> >>> Bonsai ERP, the all-inclusive ERP system >>> http://www.bonsaierp.com.au/ >> >> > > > > -- > Coherent Software Australia Pty Ltd > PO Box 2773 > Cheltenham Vic 3192 > Phone: (03) 9585 6788 > Fax: (03) 9585 1086 > Web: http://www.cohsoft.com.au/ > Email: sa...@cohsoft.com.au > > Bonsai ERP, the all-inclusive ERP system > http://www.bonsaierp.com.au/
smime.p7s
Description: S/MIME cryptographic signature