You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hivemind.apache.org by hi...@jakarta.apache.org on 2004/08/27 21:47:19 UTC
[jira] Created: (HIVEMIND-47) Literal ${...} not possible
Message:
A new issue has been created in JIRA.
---------------------------------------------------------------------
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 12:46 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: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
[jira] Closed: (HIVEMIND-47) Literal ${...} not possible
Posted by hi...@jakarta.apache.org.
Message:
The following issue has been closed.
Resolver: Howard M. Lewis Ship
Date: Wed, 1 Sep 2004 6:20 AM
Used your suggestion: $${foo} becomes ${foo}.
---------------------------------------------------------------------
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: Closed
Priority: Major
Resolution: FIXED
Project: HiveMind
Components:
framework
Fix Fors:
1.0
Versions:
1.0
Assignee: Howard M. Lewis Ship
Reporter: Naresh Sikha
Created: Fri, 27 Aug 2004 12:46 PM
Updated: Wed, 1 Sep 2004 6:20 AM
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: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
[jira] Commented: (HIVEMIND-47) Literal ${...} not possible
Posted by hi...@jakarta.apache.org.
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: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
[jira] Commented: (HIVEMIND-47) Literal ${...} not possible
Posted by hi...@jakarta.apache.org.
The following comment has been added to this issue:
Author: Naresh Sikha
Created: Fri, 27 Aug 2004 1:43 PM
Body:
This is possible but, in general, I want symbols to be expanded for all my configurations (the default behavior). In this particular case I just want to pass the literal string '${request}' on to my application. At least in this case I view disabling symbol parsing to be too much effort - if I had to disable symbol parsing it would be over one attribute of one element - not the entire configuration. Hope this sheds a bit more light on the issue.
Thanks.
---------------------------------------------------------------------
View this comment:
http://issues.apache.org/jira/browse/HIVEMIND-47?page=comments#action_37861
---------------------------------------------------------------------
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:43 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: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
[jira] Commented: (HIVEMIND-47) Literal ${...} not possible
Posted by hi...@jakarta.apache.org.
The following comment has been added to this issue:
Author: Marcus Brito
Created: Fri, 27 Aug 2004 1:17 PM
Body:
expand-symblos would'n solve all problems. In the same contribution you might want to substitute a symbol, but still treat ${} as a literal. So I guess escaping is the best solution.
---------------------------------------------------------------------
View this comment:
http://issues.apache.org/jira/browse/HIVEMIND-47?page=comments#action_37860
---------------------------------------------------------------------
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:17 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: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org