Uploaded image for project: 'Labs'
  1. Labs
  2. LABS-366

[basics] Take control of service discovery

    Details

    • Type: New Feature
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: Current
    • Fix Version/s: Current
    • Component/s: Magma
    • Labels:
      None

      Description

      Currently "standard" Java service loading is used for converters and formatters. This system has a number of drawbacks :

      • It depends on classpath sorting for dealing with duplicates
      • It is a "recent" standard (at least not back compatible with java 5)

      Taking control of this mechanism using the default Settings system would bring a number of advantages :

      • Unified and uniform configuration
      • Conflict resolution based on environment, user, defaults and the rest (as it happens for other settings)
      • Possibility to implement LABS-365

        Activity

        Hide
        s.gianni Simone Gianni added a comment -

        The new service discovery system mimics java services, but is based on properties. As such, keys are the service class followed by any differentiation string, and values are concrete implementation class names. For example, a converter will now be installed in the common settings file, like

        org.apache.magma.conversion.Converter.something=com.company.concrete.ConverterImpl

        The "something" in the key is not really used for any purpose, except differentiating the different keys and thus giving the possibility to override them. This sytem is okay but is still missing the order of precedence of possible different implementations. For example, I could have a generic converter, able to convert everything using the toString method or a format of XML serialization, and want it as the last resort if a better one is not found for a specific type. This is available in java services, but it is not clear if it is an implementation detail or if is a documented behaviour. In any case, it is not available in a consistent way when more than one service definition file is found on the classpath.

        Raw alphabetical sorting of keys could be a solution, but would also make keys more difficult to override. Up to now this feature has not been necessary, it could be for LABS-352, in which case it will be implemented.

        Show
        s.gianni Simone Gianni added a comment - The new service discovery system mimics java services, but is based on properties. As such, keys are the service class followed by any differentiation string, and values are concrete implementation class names. For example, a converter will now be installed in the common settings file, like org.apache.magma.conversion.Converter.something=com.company.concrete.ConverterImpl The "something" in the key is not really used for any purpose, except differentiating the different keys and thus giving the possibility to override them. This sytem is okay but is still missing the order of precedence of possible different implementations. For example, I could have a generic converter, able to convert everything using the toString method or a format of XML serialization, and want it as the last resort if a better one is not found for a specific type. This is available in java services, but it is not clear if it is an implementation detail or if is a documented behaviour. In any case, it is not available in a consistent way when more than one service definition file is found on the classpath. Raw alphabetical sorting of keys could be a solution, but would also make keys more difficult to override. Up to now this feature has not been necessary, it could be for LABS-352 , in which case it will be implemented.

          People

          • Assignee:
            s.gianni Simone Gianni
            Reporter:
            s.gianni Simone Gianni
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development