One way to allow a delegate to terminate subsequent flow of a primary CAS would be for the built-in UIMA flow controller to assign FinalStep() to CASes containing some "drop-cas-mark".
Assuming your OUTER_AAE is not using a custom flow controller, this would allow the OUTER_AAE to respect a mark set by the delegate INNER_AAE without changing any code in the OUTER. The next problem would be establishing a convention for the drop-cas-mark. On Mon, Sep 7, 2015 at 12:34 PM, Richard Eckart de Castilho <[email protected]> wrote: > I don't think that cas.deleteView() would be a clean solution unless UIMA > would be default drop any CAS that has its only remaining view removed. > > Dropping the whole unit-of-work (the CAS) instead of stripping its content > appear to me a cleaner solution. > > -- Richard > > On 07.09.2015, at 17:45, Eddie Epstein <[email protected]> wrote: > > > There was a Jira opened 7 years ago to support a cas.deleteView() method, > > but it has been ignored due to lack of interest. > > See https://issues.apache.org/jira/browse/UIMA-830 > > > > Eddie > > > > On Mon, Sep 7, 2015 at 11:20 AM, Zesch, Torsten < > [email protected]> > > wrote: > > > >> Only if it could completely empty the CAS including the document text, > but > >> as far as I know the document text cannot be changed once it is set. > >> > >> Am 07/09/15 17:14 schrieb "Eddie Epstein" unter <[email protected]>: > >> > >>> Can the filter in the INNER_AAE modify such CASes, perhaps > >>> by deleting data, that would result in the existing consumer > >>> effectively ignoring them? > >>> > >>> On Mon, Sep 7, 2015 at 11:08 AM, Zesch, Torsten < > [email protected] > >>> > >>> wrote: > >>> > >>>>> The consumer does not have to be modified if the flow controller > >>>>> drops CASes marked to be ignored. > >>>>> > >>>>> Sounds like the issue in this case is that the consumer is in the > >>>>> OUTER_AAE, and there is a desire not to have any components > >>>>> in the OUTER_AAE be aware of the filtering operation. > >>>>> Is this right? > >>>> > >>>> Yes exactly. > >>>> > >>>> -Torsten > >>>> > >>>> > >> > >> > >
