Annotation processing happens in a sequence of {@linkplain javax.annotation.processing.RoundEnvironment rounds}. On each round, a processor may be asked to {@linkplain #process process} asubset of the annotations found on the source and class files produced by a prior round. The inputs to the first round of processing are the initial inputs to a run of the tool; these initial inputs can be regarded as the output of a virtual zeroth round of processing. If a processor was asked to process on a given round, it will be asked to process on subsequent rounds, including the last round, even if there are no annotations for it to process. The tool infrastructure may also ask a processor to process files generated implicitly by the tool's operation.
Each implementation of a {@code Processor} must provide apublic no-argument constructor to be used by tools to instantiate the processor. The tool infrastructure will interact with classes implementing this interface as follows:
The tool uses a discovery process to find annotation processors and decide whether or not they should be run. By configuring the tool, the set of potential processors can be controlled. For example, for a {@link javax.tools.JavaCompiler JavaCompiler} the list of candidate processors to run can be{@linkplain javax.tools.JavaCompiler.CompilationTask#setProcessors set directly} or controlled by a {@linkplain javax.tools.StandardLocation#ANNOTATION_PROCESSOR_PATH search path}used for a {@linkplain java.util.ServiceLoader service-style}lookup. Other tool implementations may have different configuration mechanisms, such as command line options; for details, refer to the particular tool's documentation. Which processors the tool asks to {@linkplain #process run} is a functionof the types of the annotations {@linkplain AnnotatedConstruct present} on the {@linkplain RoundEnvironment#getRootElements root elements}, what {@linkplain #getSupportedAnnotationTypes annotation types a processorsupports}, and whether or not a processor {@linkplain #process claims the annotation types it processes}. A processor will be asked to process a subset of the annotation types it supports, possibly an empty set. For a given round, the tool computes the set of annotation types that are present on the elements enclosed within the root elements. If there is at least one annotation type present, then as processors claim annotation types, they are removed from the set of unmatched annotation types. When the set is empty or no more processors are available, the round has run to completion. If there are no annotation types present, annotation processing still occurs but only universal processors which support processing all annotation types, {@code "*"}, can claim the (empty) set of annotation types.
An annotation type is considered present if there is at least one annotation of that type present on an element enclosed within the root elements of a round. For this purpose, a type parameter is considered to be enclosed by its {@linkplain TypeParameterElement#getGenericElement genericelement}. Annotations on {@linkplain java.lang.annotation.ElementType#TYPE_USE type uses}, as opposed to annotations on elements, are ignored when computing whether or not an annotation type is present.
An annotation is present if it meets the definition of being present given in {@link AnnotatedConstruct}. In brief, an annotation is considered present for the purposes of discovery if it is directly present or present via inheritance. An annotation is not considered present by virtue of being wrapped by a container annotation. Operationally, this is equivalent to an annotation being present on an element if and only if it would be included in the results of {@link Elements#getAllAnnotationMirrors(Element)} called on that element. Sinceannotations inside container annotations are not considered present, to properly process {@linkplain java.lang.annotation.Repeatable repeatable annotation types}, processors are advised to include both the repeatable annotation type and its containing annotation type in the set of {@linkplain #getSupportedAnnotationTypes() supported annotation types} of aprocessor.
Note that if a processor supports {@code "*"} and returns {@code true}, all annotations are claimed. Therefore, a universal processor being used to, for example, implement additional validity checks should return {@code false} so as to not prevent other suchcheckers from being able to run.
If a processor throws an uncaught exception, the tool may cease other active annotation processors. If a processor raises an error, the current round will run to completion and the subsequent round will indicate an {@linkplain RoundEnvironment#errorRaised error was raised}. Since annotation processors are run in a cooperative environment, a processor should throw an uncaught exception only in situations where no error recovery or reporting is feasible.
The tool environment is not required to support annotation processors that access environmental resources, either {@linkplain RoundEnvironment per round} or {@linkplain ProcessingEnvironment cross-round}, in a multi-threaded fashion.
If the methods that return configuration information about the annotation processor return {@code null}, return other invalid input, or throw an exception, the tool infrastructure must treat this as an error condition.
To be robust when running in different tool implementations, an annotation processor should have the following properties:
The {@link Filer} interface discusses restrictions on howprocessors can operate on files.
Note that implementors of this interface may find it convenient to extend {@link AbstractProcessor} rather than implementing thisinterface directly. @author Joseph D. Darcy @author Scott Seligman @author Peter von der Ahé @since 1.6
Processor class serves three purposes: it allows global Saxon configuration options to be set; it acts as a factory for generating XQuery, XPath, and XSLT compilers; and it owns certain shared resources such as the Saxon NamePool and compiled schemas. This is the first object that a Saxon application should create. Once established, a Processor may be used in multiple threads. It is possible to run more than one Saxon Processor concurrently, but only when running completely independent workloads. Nothing can be shared between Processor instances. Within a query or transformation, all source documents and schemas must be built using the same Processor, which must also be used to compile the query or stylesheet.
Interface describing business logic responsible for processing an incoming remoting request, and creating the corresponding response.
Processor post processes the output.
The processor then deals with a message. It returns false if no further processing is desired. It can have a name (or null)
Processors can either devolve processing to other processors (e.g. a rule, stage, etc) or deal with the message itself (e.g. mediator)
The purpose of processors is to unload data from the import container and push it to the workspace, with various strategy. For instance a processor could either create a new workspace or append data to the current workspace, managing doubles. @author Mathieu Bastian @see ImportController
This interface is implemented by the connectors that want to process messages. Processors usually send messages out of the framework to operators, integrators or other applications.
@author German EscobarProcessor used to process messages from a connected transport. This will process each request from a provided transport and pass those requests to a container. The transport provided can be either a direct transport or provide some form of secure encoding such as SSL.
@author Niall Gallagher
@see org.simpleframework.transport.Transport
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |