Details
Major Description
When adapting legacy software into Hivemind I encountered an interesting bug. The software requires a configuration value that has the same syntax as a Himemind symbol - ${symbolname}. The software, at an application defined point in time, then resolves the "legacy symbol".
This logic cannot currently be changed and causes errors to be logged by Hivemind that a symbol could not be resolved:
Error at file:/.../hivemodule.xml, line 36, column 54: No value available for symbol 'request'.
In this example the legacy symbol, ${request}, gets expanded by an application servlet to be an application identifier for the current servlet request - something that can't be determined by symbol source arhitecture.
The runtime behavior ends up okay but not before logging several error messages for missing symbols. For our production environment this can cause operational headache since errors are logged in production.
A workaround is to create a symbol source resolver that accepts this symbol and returns its value as the legacy symbol but I believe this to merely be a workaround (i.e. all customers of hivemind would have to implement this).
IMO, a more appropriate solution would be to mimic Ant's ability to allow for ${...} literals by escaping the '$' with a second '$' as so: $${...}. This then provides an easy migration pattern for our legacy configurations - if we find a ${...} in a legacy configuration, transform it into $${...} in hivemodule.xml.
Thanks.