The following comment has been added to this issue:
Author: Howard M. Lewis Ship
Created: Fri, 27 Aug 2004 1:01 PM
Body:
Another option might be to add an "expand-symbols" attribute to read-attribute
or read-content, that would default to true, but could be turned to false for
contributions that should not expand HiveMind symbols.
---------------------------------------------------------------------
View this comment:
http://issues.apache.org/jira/browse/HIVEMIND-47?page=comments#action_37859
---------------------------------------------------------------------
View the issue:
http://issues.apache.org/jira/browse/HIVEMIND-47
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HIVEMIND-47
Summary: Literal ${...} not possible
Type: Bug
Status: Open
Priority: Major
Project: HiveMind
Components:
framework
Versions:
1.0
Assignee: Howard M. Lewis Ship
Reporter: Naresh Sikha
Created: Fri, 27 Aug 2004 12:46 PM
Updated: Fri, 27 Aug 2004 1:01 PM
Environment: Windows XP, IBM JDK 1.4.1, WebSphere 5.1
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.
---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
