Resolved in commit 7dd19e74d78295a000b47ae369ecce883c17c049.
As of this commit, metadata tracing and metadata timing infrastructure has been considerably enhanced and will be of much more value to Roo add-on developers:
- Metadata logging will no longer appear in the shell, but instead will appear in metadata.log in the current working directory. This file will be overwritten on each Roo startup if metadata logging is activated.
- Metadata logging can be activated via the "metadata trace --level 2" command (as was the case previously).
- Metadata logging can also be activated by editing roo-dev and enabling the "METADATA_TRACE" variable. This is useful if startup-time metadata logging is desired.
- Metadata data logging is no longer limited to simply metadata notifications, as it was in the past. Now all MetadataService operations are also logged, including interactions with the cache and retry logic introduced in
ROO-1879. This provides a very extensive insight into metadata behavior in Roo and metadata troubleshooting simplification.
- Any class that wishes to provide more in-depth metadata information (eg AbstractItdMetadataProvider or one of its subclasses) can obtain a reference to the new MetadataLogger service and use its log methods. This will cause their inclusion in metadata.log, with appropriate indentation and correlation with the event ID. This is far superior to System.out.println(..) or using a debugger, both of which are unrealistic given the large number of operations and cycles that occur to reach a conclusive metadata outcome.
- Metadata timings now include the cost of a MetadataService retrieval, whereas historically they only included metadata notification costs. The costs are now also expressed more robustly, based on nanosecond precision (and reported in nanosecond granularity if a millisecond has not yet been reached). Similarly the number of metadata operations per responsible class is indicated, giving better context regarding invocation frequency.