Warning: This is a facade provided for use by user code, not for implementation. User implementations of this interface are highly likely to be incompatible with future releases of the product at both binary and source levels.
It looks for element events for special elements and when it finds them it applies a set of preconfigured rules. These rules can do all sorts of different things, including but not limited to adding and removing processes to and from the pipeline, recovering from errors, activating flow control.
In addition to the above a dynamic process also supports the following.
While in pass through mode the dynamic process does not perform any processing of the events it simply passes them straight through. Among other possible uses the template model uses it to defer the evaluation of pipeline content until it is used within the template body.
The {@link #passThroughElementContents} method can be used to control thepass through mode.
If an error occurs in a process within the pipeline then it is important to be able to recover from it. Error recovery must ensure that after it has finished the pipeline is at a well known point within the source infoset and in a well known state.
The main problem with achieving this goal is that when the error occurs most processes within the pipeline will have received an unbalanced set of events, some of which have come from external documents and some of which have come from the source document. In order to recover from errors it is necessary to separate the two sets of events but this is impossible for most processes within the pipeline.
The one process that can distinguish between them is this process (as it only sees events from the source infoset) and hence the reason why this process supports error recovery.
It is not possible for a dynamic process to recover from errors if it has received a fatal error in its input infoset. Therefore, if it does detect one then it ignores any attempt at error recovery.
An operation/process that supports recovering from errors, e.g. the <try> operation, has to perform the following steps in order to recover from errors.
Setting an error recovery point is done in a very similar way to setting a flow control destination point. In fact the error recovery point is used as the destination for flow control.
When error recovery is activated this process uses the flow control mechanism to advance to the error recovery point. It also uses the facilities provided by XMLPipelineContext to recover the state.
Being in error recovery mode has the following effects on this process.
In error recovery mode all events are ignored until the error recovery point is reached at which point error recovery is removed. In addition this process removes all processes from the pipeline up until the point.
If this process detects an error on its input, or is asked to begin error recovery then it cleans up the pipeline as follows.
Starting with the first process it removes it from the pipeline, releases its resources (by invoking {@link XMLProcess#release}) and discards it. It does this until it either reaches the end of the processes that it added to the pipeline, or reaches the process that initiated error recovery.
@volantis-api-include-in PublicAPI @volantis-api-include-in ProfessionalServicesAPI @volantis-api-include-in InternalAPI @mock.generate | |
| |