Turbine
  1. Turbine
  2. TRB-86

fulcrum-yaafi; strange configuration resolving

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: Core 2.3.3
    • Fix Version/s: None
    • Component/s: Fulcrum
    • Labels:
      None
    • Environment:
      fulcrum-yaafi-1.0.6

      Description

      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>
      ...

        Activity

        Hide
        Thomas Vandahl added a comment - - edited

        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>).

        Show
        Thomas Vandahl added a comment - - edited 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>).

          People

          • Assignee:
            Siegfried Goeschl
            Reporter:
            T. Schmidt
          • Votes:
            1 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:

              Development