Uploaded image for project: 'Alfresco'
  1. Alfresco
  2. ALF-21820

Incorrect share-config-custom.xml lookup order - module JAR share-config-custom.xml may override global share-config-custom.xml

    Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Unprioritized
    • Resolution: Won't Fix
    • Affects Version/s: Community Edition 201612 GA
    • Fix Version/s: None
    • Component/s: Share Application
    • Security Level: external (External user)
    • Labels:
      None
    • Security Severity:
      None

      Description

      The current lookup order for Share-tier configuration XMLs (bean "webframework.configsource") lists the following order for the last couple of lookup paths:

      1. classpath:alfresco/web-extension/share-config-custom.xml
      2. jar:*!/META-INF/share-config-custom.xml
      3. classpath:alfresco/web-extension/share-config-custom-dev.xml
      4. jar:*!/META-INF/share-config-custom-dev.xml
      5. classpath:alfresco/web-extension/smartfolders-amp-actions-config.xml

      This means that a share-config-custom.xml bundled within a module JAR can override any configuration that a customer system administrator has set up in the alfresco/web-extension/share-config-custom.xml file. It does not help that there is a alfresco/web-extension/share-config-custom-dev.xml that could be configured to override such overrides from a module JAR, because the module JAR gets another chance to override the overrides to the overrides of the module JAR...
      The Repository-tier lookup order for alfresco-global.properties realizes that the customer system administrator must always be able to override any module configuration by putting alfresco-global.properties AFTER the alfresco/module/*/alfresco-global.properties

      The lookup order should always ensure that the alfresco/web-extension/share-config-custom.xml and alfresco/web-extension/share-config-custom-dev.xml are loaded AFTER the equivalent files from any module JAR. This is the way that most users expect configuration precedence to work and would make it consistent between Repository and Share.
      Additionally, I would like to submit that the alfresco/web-extension/smartfolders-amp-actions-config.xml is somewhat redundant to share-config-custom.xml and should be loaded prior to share-config-custom.xml to avoid the same kind of override precedence issue.

      This has been filed against 201602 GA but looking at source history has always been this way. The problem was only realized by me when a module JAR share-config-custom.xml contained a default configuration for a new remote endpoint which I could then not override with a server-specific value endpoint URL in alfresco/web-extension/share-config-custom.xml

        Attachments

          Activity

          Hide
          resplin Richard Esplin added a comment -

          Kevin Roast: This report does appear to be an actual issue, but Axel points out that it has always been this way. Do you expect to address this issue in the near future, or should we close the report and keep it in mind when we next improve this functionality?

          Show
          resplin Richard Esplin added a comment - Kevin Roast : This report does appear to be an actual issue, but Axel points out that it has always been this way. Do you expect to address this issue in the near future, or should we close the report and keep it in mind when we next improve this functionality?
          Hide
          resplin Richard Esplin added a comment -

          After discussing this issue with the team, we decided that it is not a priority to fix in the next release of Alfresco. We agree that it isn't the right behavior, but it has always existed and other people have not expressed frustration with the problem.

          Thank you Axel Faust for pointing out another odd behavior that we should guard against in future development.

          Show
          resplin Richard Esplin added a comment - After discussing this issue with the team, we decided that it is not a priority to fix in the next release of Alfresco. We agree that it isn't the right behavior, but it has always existed and other people have not expressed frustration with the problem. Thank you Axel Faust for pointing out another odd behavior that we should guard against in future development.
          Hide
          resplin Richard Esplin added a comment -

          Closing as Won't Fix as we won't be addressing this in the near future.

          Show
          resplin Richard Esplin added a comment - Closing as Won't Fix as we won't be addressing this in the near future.

            People

            • Assignee:
              closedissues Closed Issues
              Reporter:
              afaust Axel Faust
            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:
                Date of First Response: