Issues referencing a DAPS

[AnaCarolinaChaves]

I am currently working with the Dataspace Connector v7.1.0 and I am trying to connect to a DAPS installed in another device.
When I test the DAPS endpoints with a test script (that tests the endpoint) everything works fine.

However, when I try to integrate with the Connector there is an Client Unknown error. The logs I am getting are:

ERROR - PRODUCTIVE_DEPLOYMENT: No IDS-Message sent! No DAT could be acquired from DAPS! [code=(IMSCOE0001), reason=(Error connecting to DAPS (possibly currently not reachable or wrong DAPS-URL): Unexpected code Response{protocol=http/1.1, code=400, message=Bad Request, url=http://vcese19.inesctec.pt:4567/auth/token} Body: {"error":"invalid_client","error_description":"Client unknown"})]

2022-06-02T17:18:51,478 [http-nio-8079-exec-2] WARN - Connection to DAPS could not be established. [exception=(Error connecting to DAPS (possibly currently not reachable or wrong DAPS-URL): Unexpected code Response{protocol=http/1.1, code=400, message=Bad Request, url=http://vcese19.inesctec.pt:4567/auth/token} Body: {"error":"invalid_client","error_description":"Client unknown"})]

2022-06-02T17:18:51,505 [http-nio-8079-exec-2] WARN - Unable to retrieve valid DAT. [exception=(Access is denied)]

The environment variables defined on the connector are:

- 'configuration.path=/tmp/conf/config.json'
 - 'configuration.keyStorePassword=<PASSWORD>'
 - 'DAPS_URL=http://<DAPS_MACHINE>:4567'
- 'DAPS_TOKEN_URL=http://<DAPS_MACHINE>:4567/auth/token'
 - 'DAPS_KEY_URL=http://<DAPS_MACHINE>:4567/auth/jwks.json'
 - 'DAPS_INCOMING_DAT_DEFAULT_WELLKNOWN=/jwks.json'
 - 'server.ssl.enabled=false'

On the config file I updated the line to include the new certificate:

"ids:keyStore" : {
"@id" : "file:///tmp/conf/conn_producer.p12"
}

[tmberthold]

For the context info: International-Data-Spaces-Association/omejdn-daps#25

[AnaCarolinaChaves]

I was able to fix the issue.
It was necessary to remove the docker volumes. Building the application was not enough.

[tmberthold]

I'm glad to hear that!

If the DSC was started as a Docker image with a persistent database, it stores the configuration in the database on initial startup and loads it directly from the database from the second startup. The configuration can be changed at runtime by API calls, and the changes are in turn saved to the database. If the DSC container is restarted or needs to reboot, the changed settings remain available, instead of overwriting these again by the configuration file.

However, a reload from the configuration file can be forced, even without having to remove the volumes:

DataspaceConnector/src/main/resources/application.properties

Line 85 in b361395

configuration.force.reload=false