artifact duplication in reported json for download-http

[badevos]

Hi,

We're running Hawkbit 0.3.0M6 and connect with 'swupdate'. For an artifact that is available, the following json is returned to swupdate:

  "filename": "hawkbit.swu",
  "hashes": {
    "sha1": "f6f08bcdc544c6bc483a315c37c708dad2c731e6",
    "md5": "73671f0494f9537003422ab1eb654bf4",
    "sha256": "093a79300dcaadeb5730a20e896d0bbc833ba6ee355aa71225e949deb56ac2c9"
  },
  "size": 61775872,
  "_links": {
    "download-http": [
      {
        "href": "http://<hawkbit-name>:80/DEFAULT/controller/v1/<id>/softwaremodules/5/artifacts/hawkbit.swu"
      },
      {
        "href": "http://<hawkbit-name>:80/DEFAULT/controller/v1/<id>/softwaremodules/5/artifacts/hawkbit.swu"
      }
    ],
    "md5sum-http": {
      "href": "http://<hawkbit-name>:80/DEFAULT/controller/v1/<id>/softwaremodules/5/artifacts/hawkbit.swu.MD5SUM"
    }
  }
}

In this json, the object download-http is an array with 2 exactly the same objects. swupdate expects a single object at that time ...

We tested this with the docker-image, and there it runs fine, i.e. only a single object is returned to swupdate and not an array.

with wget we can download the file, so that looks good.

Questions:

1. What is the reason for the link duplication?
2. How can we solve this?

Thanks for your feedback. we use the following properties:

DOCKER_REGISTRY_SERVER_URL = "https://index.docker.io",
HAWKBIT_ARTIFACT_URL_PROTOCOLS_DOWNLOADHTTP_PORT = "80",
HAWKBIT_DMF_RABBITMQ_ENABLED = "false",
LOGGING_LEVEL_ORG_ECLIPSE_HAWKBIT = "WARN",
ORG_ECLIPSE_HAWKBIT_REPOSITORY_FILE_PATH = "/opt/hawkbit/artifactrepo",
SERVER_USEFORWARDHEADERS = "true",
SPRING_DATASOURCE_DRIVERCLASSNAME = "com.microsoft.sqlserver.jdbc.SQLServerDriver",
SPRING_JPA_DATABASE = "SQL_SERVER",
WEBSITE_HTTPLOGGING_RETENTION_DAYS = "30",
WEBSITES_ENABLE_APP_SERVICE_STORAGE = "false",

[schabdo]

Could be caused by the second environment variable HAWKBIT_ARTIFACT_URL_PROTOCOLS_DOWNLOADHTTP_PORT. At least somebody else reported similar observation (cf. Gitter). Can you confirm that, maybe by removing the env variable?

[badevos]

The removal of HAWKBIT_ARTIFACT_URL_PROTOCOLS_DOWNLOADHTTP_PORT indeed removes the duplication. Logically the provided download links then contain the default port 8080, which is not what we want. Other combinations of variables HAWKBIT_ARTIFACT_URL_PROTOCOLS_DOWNLOADHTTP_<X> cause the link duplication again ...

[schabdo]

Thanks for your confirmation. FMPOV this must not happen, so relabeled as bug

[VladimirSvoboda]

Could be caused by the second environment variable HAWKBIT_ARTIFACT_URL_PROTOCOLS_DOWNLOADHTTP_PORT. At least somebody else reported similar observation (cf. Gitter). Can you confirm that, maybe by removing the env variable?

I confirm that it is caused by the usage of environment variables for HAWKBIT_ARTIFACT_URL_PROTOCOLS_*. Using a property file instead is a workaround for the issue.

This message contains both more info for the workaround (first part) and then more info about the investigation I made about the cause.

Workaround

If using the container, a solution is to:

1. ensure that you don't have any remaining environment variable starting with: HAWKBIT_ARTIFACT_URL_PROTOCOLS
2. create a config directory
3. create a properties file inside the config directory (if using the mysql container variant, call it application-mysql.properties). See snippet 1
4. mount that directory in the container. See snippet 2

Snippet 1

hawkbit.artifact.url.protocols.download-http.port=80

Snippet 2

If using docker-compose, add this to the hawkbit service definition.

    volumes:
      - type: bind
        source: ./config
        target: /opt/hawkbit/config

Cause of the issue

The issue is caused because of the usage of a dash "-" in the name of the properties hawkbit.artifact.url.protocols.download-http.* and hawkbit.artifact.url.protocols.md5sum-http. Spring actually recommends to not use dashes anymore in property names.

To be more precise, the issue occurs in the file hawkbit-core/src/main/java/org/eclipse/hawkbit/api/ArtifactUrlHandlerProperties.java because of the protocols map. The keys in the maps are:

• download-http for the configuration coming from properties file (as expected)
• downloadhttp (without dash) for the configuration coming from environment variable (normal, Spring cannot guess that there were initially dashes).

As recommended by Spring, I would suggest to remove the dash from the properties and adapt the code further to keep the public API compatibility (mapping downloadhttp to download-http) before generating the HTTP response.