This section describes how to instrument classes and methods that
are not covered by plugins. You create dynamic concrete aspects by editing
<?xml version="1.0" encoding="UTF-8"?> <aspectj> <aspects> <concrete-aspect name="foo.bar.BazAspect" extends="com.springsource.insight.collection.method.custom.CustomConcretizedOperationCollectionAspect"> <pointcut name="collectionPoint" expression="execution(* foo.bar.Baz.mySuperDuperMethod(..))" /> </concrete-aspect> </aspects> </aspectj>
The following examples illustrate different definitions of the
expression and the effect achieved by each.
Monitor all public methods from any class that is annotated with
execution(* (@foo.bar.MyClassAnnotation *).*(..))
Monitor all public methods from any class ending in
Impl that resides in the foo.bar package or any of its
Monitor all public methods that are annotated with
@MyMethodAnnotation from any class:
execution(@foo.bar.MyMethodAnnotation * *(..))
Monitor all public login methods that accept two String parameters
and that are implemented by
MyClass or any class that extends
The preceding samples are just examples of the instrumentation you can implement with dynamic concrete aspects. See AspectJ documentation for more information.
You cannot refer to the values of intercepted methods arguments, format them, or parse them. Nor can these values be formatted and parsed for extra useful information (at least not via this mechanism; look at the Insight annotations for this purpose).
Instrument only public methods with this tool. Do not instrument constructor executions, static initializers, or field access, even though AspectJ enables this. The result of straying from this recommendation is unknown.
You can define several aspects in this file, each a separate <concrete-aspect> element.
It is possible to assign a score to the endpoints generated by the aspect by using a collection setting named insight.collection.custom-aop.XXX.score, where XXX is the simple aspect name (in effect, the name after stripping the package name). The supported values are:
default. The endpoint's score is based on its
location in the trace tree. The higher up the tree the intercepted
API is found the higher its score, and it is more likely to become
the representative endpoint for the trace. This also the default
scoring if no setting is specified.
minimum . A "catch-all" score that indicates
that if no other "better" endpoint is found, then the intercepted
API is the endpoint.
top. Trumps the minimum score.
ceiling. Trumps the top score.
fixed integer value; if positive, it trumps any of the other
scores (except other higher positive ones). Note: Negative values are reserved for
internal use and should not be used.
You cam control the generated endpoint name, label, and example
strings of the endpoint analysis phase using
settings. These values can also include dynamic modifiers, such as the
class/method name, signature and argument values. See the Using Insight Annotations
for the available modifiers and their meanings.
Any change to the XML file requires restarting the monitored application.