Community
Participate
Working Groups
I have request to customize the velocity logger. One use case for this is to keep all the tigerstripe generated logs under one specified directory (including velocity.log). I request to check if it is possible to provide this option via "preferences" window? and project specific preferences can override the same. Here is some info from velocity that helps with this. http://velocity.apache.org/engine/releases/velocity-1.5/developer-guide.html#velocity_configuration_keys_and_values http://velocity.apache.org/engine/releases/velocity-1.5/developer-guide.html#configuring_logging I checked part of tigerstipe source and found that only classpath and resourceloaders seem to be customized for velocity. It would be useful if the logger can be customizable too.
As a first pass, I am looking at the following approach. This gives the information that is required, but does not have the "preference" behaviour requested in teh enahncement request. 1. The logging of the velocity instance that is used for the persistence (ie internal to Tigerstripe) will be moved to the tigerstripe directory ie alongside tigerstripe.log 2. For plugins, the log will be created in the same location as the pluginlog (where enabled). The log name will be created by removing the extension from the plugin log and inserting "velocity" and re-appending the extension... So for example if my pluginlog is set to "logs/createXML.log", I will get an additional log "logs/createXML.velocity.log". If there is no extension, the just append the word ".velocity" to the end. If logging is not enabled for a plugin, then the velocity log messages will be appended to the velocity.log i the tigerstripe directory (as now - except for the location). NOTE THAT : When using a plugin, the velocity log will also contain information about the "internal" templates that are used to create the tigerstripeReport.xml (if enabled).
Changes described in comment #1 implemented. Some intermittent problems with close / refresh: a) Sometimes (and I can't work out out a pattern), the velocity log for a plugin is not refreshed at the end of generate run. b) Similarly - when the above happens, the log appears to not be closed, and so cannot be deleted. This latter point looks similar to the problem we have with log4J and capturing the stdout into a log - could be the same issues? I'm a bit stuck on these at the moment!
We looked into this and decided against implementing this enhancement due to the amount of changes required.
