Make MongoDB collection names configurable for AAS and Submodel registries

[geso02]

Description:

This MR introduces configurable properties for MongoDB collection names in the AAS Registry and Submodel Registry.
Previously, collection names were hardcoded via @document annotations. These have been replaced by configurable properties, allowing users to override them in application.yaml while still defaulting to the existing names.

Changes:

Added configuration properties:

basyx.aasregistry.mongodb.collectionName (default: aasdescriptors)

basyx.submodelregistry.mongodb.collectionName (default: submodeldescriptors)

Updated storage implementations to resolve collection names via configuration

Removed static @document annotations to avoid conflicts

Retained @id annotations for proper _id mapping in MongoDB

Adjusted Lombok configuration to ensure builds succeed with newer Java versions via Maven

Why:

Gives users flexibility to customize collection names for different environments or deployments, and improves build compatibility with modern Java versions.

Issue:

Closes #873

[seicke]

@aaronzi Should'nt it be aasdescriptors at this point? See #900

[aaronzi]

Good catch

[geso02]

Quick thought: Changing the default collection name could be a breaking change for existing deployments - they'd lose access to their data after upgrading since the app would look for a different collection.
Maybe it's better to keep the old default for backward compatibility? Users who want the new name can still configure it via the property. The configurability is already there, so new deployments can easily use better naming.

[aaronzi]

It would be a breaking change if we had a full release of BaSyx Java (which is not the case). But you are right, this could potentially cause issues when the next milestone is released or if somebody deploys the snapshots. But having a semantically incorrect collection name is also not really helpful. Maybe it would be enough to inform users about this change once a release is published. This way they can just apply the necessary setting and won't loose their data

[seicke]

@aaronzi / @geso02

How to specify/set up a self-chosen MongoDB collection name, e.g. for the BaSyx AAS Registry using environment variables in a docker compose file?

I assumed it should be working with environment variable SPRINT_DATA_MONGODB_COLLECTIONNAME

...
  basyx-aas-registry-dev:
    image: eclipsebasyx/aas-registry-log-mongodb:2.0.0-SNAPSHOT
    environment:
      SERVER_SERVLET_CONTEXT_PATH: /
      BASYX_CORS_ALLOWED_ORIGINS: '*'
      BASYX_CORS_ALLOWED_METHODS: GET,POST,PATCH,DELETE,PUT,OPTIONS,HEAD
      BASYX_FEATURE_AUTHORIZATION_ENABLED: true
      BASYX_FEATURE_AUTHORIZATION_TYPE: rbac
      BASYX_FEATURE_AUTHORIZATION_JWTBEARERTOKENPROVIDER: keycloak
      BASYX_FEATURE_AUTHORIZATION_RBAC_FILE: file:/workspace/config/rbac_rules.json
      SPRING_SECURITY_OAUTH2_RESOURCESERVER_JWT_ISSUER_URI: http://${KEYCLOAK_HOST}:${KEYCLOAK_PORT}/realms/${KEYCLOAK_REALM}
      SPRING_DATA_MONGODB_URI: mongodb://${MONGO_ADMIN}:${MONGO_ADMIN_PASSWORD}@${MONGO_HOST}:${MONGO_PORT}
      SPRING_DATA_MONGODB_DATABASE: aas-registry
      SPRINT_DATA_MONGODB_COLLECTIONNAME: aasdescriptorstest
    volumes:
      - ./conf/basyx/aas-registry/basyx_aas_registry_rbac_rules.json:/workspace/config/rbac_rules.json
    ports:
      - ${BASYX_AAS_REGISTRY_PORT_PUBLISHED}:${BASYX_AAS_REGISTRY_PORT}
...

so that the collection name aasdescriptorstest instead of the default aasdescriptors is used. But it seems not working, after docker compose up the default collection name is still used:

[aaronzi]

You got a typo there @seicke . It's SPRING and not SPRINT

[seicke]

@aaronzi You are absoluty right, sorry for that!

However, even with SPRING_DATA_MONGODB_COLLECTIONNAME: aasdescriptorstest the collection is named aasdescriptors (default collection name)

[seicke]

It has to be BASYX_AASREGISTRY_MONGODB_COLLECTIONNAME: aasdescriptorstest instead of SPRING_DATA_MONGODB_COLLECTIONNAME: aasdescriptorstest

[aaronzi]

Yes, you are right. I missed that but it's clear from the code in this PR

[aaronzi]

Quick thought: Changing the default collection name could be a breaking change for existing deployments - they'd lose access to their data after upgrading since the app would look for a different collection. Maybe it's better to keep the old default for backward compatibility? Users who want the new name can still configure it via the property. The configurability is already there, so new deployments can easily use better naming.

So what I have done now is I reverted both the default submodel registry collection name (to submodelDescriptor) and the default aas registry collection name (to assetAdministrationShellDescriptor). Now there should be no breaking changes anymore