You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@turbine.apache.org by "T. Schmidt (JIRA)" <ji...@apache.org> on 2011/09/09 10:53:09 UTC
[jira] [Created] (TRB-86) fulcrum-yaafi; strange configuration
resolving
fulcrum-yaafi; strange configuration resolving
----------------------------------------------
Key: TRB-86
URL: https://issues.apache.org/jira/browse/TRB-86
Project: Turbine
Issue Type: Bug
Components: Fulcrum
Affects Versions: Core 2.3.3
Environment: fulcrum-yaafi-1.0.6
Reporter: T. Schmidt
Priority: Minor
I've got a problem with two different (configuration) scenarios, which behave differently - but should (imho) not.
The first one configures a 'default'-tag which holds a variable that should be resolved - the appropriate componentResolve.xml is below too. The 'default'-tag in the componentResolve.xml is empty. The second configuration has an empty 'default'-tag in the componentConfiguration.xml.
In the first case the resolving is successfully made - the config-entry is an empty string. In the second case the config-entry is null. I would expect that an empty tag would result in an emtpy string - to be able to distinguish between emtpy tags and non-existing tags (there are other ways to do this - i know).
If this null-behavior is expected than
I would like to imitate the "empty tags are null" behavior in my CustomResolver. This isn't possible because of the ServiceContainerImpl class. Here the resolver items are hold in a Properties object, which cannot hold null-object as values. However the ConfigurationUtil class (which does the resolving) expects a Map, the using of a Map which accepts null as values (instead of Properties) would solve this problem.
Configuration examples:
componentConfiguration (1):
...
<SecurityService>
<permissions>
<default>${SecurityService.permissions.default}</default>
</permissions>
...
</SecurityService>
...
componentConfiguration (2):
...
<SecurityService>
<permissions>
<default></default>
</permissions>
...
</SecurityService>
...
componentResolve (1+2):
...
<SecurityService>
<permissions>
<default></default>
</permissions>
...
</SecurityService>
...
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (TRB-86) fulcrum-yaafi; strange
configuration resolving
Posted by "Thomas Vandahl (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TRB-86?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13104713#comment-13104713 ]
Thomas Vandahl edited comment on TRB-86 at 9/14/11 5:47 PM:
------------------------------------------------------------
Same application, somewhat different environment. The variables are being resolved using a DatabaseConfiguration object (o.a.commons.configuration). The Properties object barfs on setProperty(key, value) for values of null (Oracle: empty string is the same as null). I also suggest to change the signature of resolve() to
Map<String, String> resolve(Map<String, String>).
was (Author: tv):
Same application, somewhat different environment. The variables are being resolved using a DatabaseConfiguration object (o.a.commons.configuration). The Properties object barfs on setProperty(key, value) for values of null. I also suggest to change the signature of resolve() to
Map<String, String> resolve(Map<String, String>).
> fulcrum-yaafi; strange configuration resolving
> ----------------------------------------------
>
> Key: TRB-86
> URL: https://issues.apache.org/jira/browse/TRB-86
> Project: Turbine
> Issue Type: Bug
> Components: Fulcrum
> Affects Versions: Core 2.3.3
> Environment: fulcrum-yaafi-1.0.6
> Reporter: T. Schmidt
> Assignee: Siegfried Goeschl
> Priority: Minor
>
> I've got a problem with two different (configuration) scenarios, which behave differently - but should (imho) not.
> The first one configures a 'default'-tag which holds a variable that should be resolved - the appropriate componentResolve.xml is below too. The 'default'-tag in the componentResolve.xml is empty. The second configuration has an empty 'default'-tag in the componentConfiguration.xml.
> In the first case the resolving is successfully made - the config-entry is an empty string. In the second case the config-entry is null. I would expect that an empty tag would result in an emtpy string - to be able to distinguish between emtpy tags and non-existing tags (there are other ways to do this - i know).
> If this null-behavior is expected than
> I would like to imitate the "empty tags are null" behavior in my CustomResolver. This isn't possible because of the ServiceContainerImpl class. Here the resolver items are hold in a Properties object, which cannot hold null-object as values. However the ConfigurationUtil class (which does the resolving) expects a Map, the using of a Map which accepts null as values (instead of Properties) would solve this problem.
> Configuration examples:
> componentConfiguration (1):
> ...
> <SecurityService>
> <permissions>
> <default>${SecurityService.permissions.default}</default>
> </permissions>
> ...
> </SecurityService>
> ...
> componentConfiguration (2):
> ...
> <SecurityService>
> <permissions>
> <default></default>
> </permissions>
> ...
> </SecurityService>
> ...
> componentResolve (1+2):
> ...
> <SecurityService>
> <permissions>
> <default></default>
> </permissions>
> ...
> </SecurityService>
> ...
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TRB-86) fulcrum-yaafi; strange configuration
resolving
Posted by "Thomas Vandahl (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TRB-86?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13104713#comment-13104713 ]
Thomas Vandahl commented on TRB-86:
-----------------------------------
Same application, somewhat different environment. The variables are being resolved using a DatabaseConfiguration object (o.a.commons.configuration). The Properties object barfs on setProperty(key, value) for values of null. I also suggest to change the signature of resolve() to
Map<String, String> resolve(Map<String, String>).
> fulcrum-yaafi; strange configuration resolving
> ----------------------------------------------
>
> Key: TRB-86
> URL: https://issues.apache.org/jira/browse/TRB-86
> Project: Turbine
> Issue Type: Bug
> Components: Fulcrum
> Affects Versions: Core 2.3.3
> Environment: fulcrum-yaafi-1.0.6
> Reporter: T. Schmidt
> Assignee: Siegfried Goeschl
> Priority: Minor
>
> I've got a problem with two different (configuration) scenarios, which behave differently - but should (imho) not.
> The first one configures a 'default'-tag which holds a variable that should be resolved - the appropriate componentResolve.xml is below too. The 'default'-tag in the componentResolve.xml is empty. The second configuration has an empty 'default'-tag in the componentConfiguration.xml.
> In the first case the resolving is successfully made - the config-entry is an empty string. In the second case the config-entry is null. I would expect that an empty tag would result in an emtpy string - to be able to distinguish between emtpy tags and non-existing tags (there are other ways to do this - i know).
> If this null-behavior is expected than
> I would like to imitate the "empty tags are null" behavior in my CustomResolver. This isn't possible because of the ServiceContainerImpl class. Here the resolver items are hold in a Properties object, which cannot hold null-object as values. However the ConfigurationUtil class (which does the resolving) expects a Map, the using of a Map which accepts null as values (instead of Properties) would solve this problem.
> Configuration examples:
> componentConfiguration (1):
> ...
> <SecurityService>
> <permissions>
> <default>${SecurityService.permissions.default}</default>
> </permissions>
> ...
> </SecurityService>
> ...
> componentConfiguration (2):
> ...
> <SecurityService>
> <permissions>
> <default></default>
> </permissions>
> ...
> </SecurityService>
> ...
> componentResolve (1+2):
> ...
> <SecurityService>
> <permissions>
> <default></default>
> </permissions>
> ...
> </SecurityService>
> ...
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TRB-86) fulcrum-yaafi; strange configuration
resolving
Posted by "Siegfried Goeschl (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TRB-86?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Siegfried Goeschl reassigned TRB-86:
------------------------------------
Assignee: Siegfried Goeschl
> fulcrum-yaafi; strange configuration resolving
> ----------------------------------------------
>
> Key: TRB-86
> URL: https://issues.apache.org/jira/browse/TRB-86
> Project: Turbine
> Issue Type: Bug
> Components: Fulcrum
> Affects Versions: Core 2.3.3
> Environment: fulcrum-yaafi-1.0.6
> Reporter: T. Schmidt
> Assignee: Siegfried Goeschl
> Priority: Minor
>
> I've got a problem with two different (configuration) scenarios, which behave differently - but should (imho) not.
> The first one configures a 'default'-tag which holds a variable that should be resolved - the appropriate componentResolve.xml is below too. The 'default'-tag in the componentResolve.xml is empty. The second configuration has an empty 'default'-tag in the componentConfiguration.xml.
> In the first case the resolving is successfully made - the config-entry is an empty string. In the second case the config-entry is null. I would expect that an empty tag would result in an emtpy string - to be able to distinguish between emtpy tags and non-existing tags (there are other ways to do this - i know).
> If this null-behavior is expected than
> I would like to imitate the "empty tags are null" behavior in my CustomResolver. This isn't possible because of the ServiceContainerImpl class. Here the resolver items are hold in a Properties object, which cannot hold null-object as values. However the ConfigurationUtil class (which does the resolving) expects a Map, the using of a Map which accepts null as values (instead of Properties) would solve this problem.
> Configuration examples:
> componentConfiguration (1):
> ...
> <SecurityService>
> <permissions>
> <default>${SecurityService.permissions.default}</default>
> </permissions>
> ...
> </SecurityService>
> ...
> componentConfiguration (2):
> ...
> <SecurityService>
> <permissions>
> <default></default>
> </permissions>
> ...
> </SecurityService>
> ...
> componentResolve (1+2):
> ...
> <SecurityService>
> <permissions>
> <default></default>
> </permissions>
> ...
> </SecurityService>
> ...
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira