avoid base field substitution

[droslbl]

Greetings @wistefan

I got a ticket because apparently it is possible to change base fields in TMForum using @schemalocation, I dont think this is intended since in the documentation @schemalocation is described for adding additional attributes rather than changing existing ones. Although I might be wrong...

In case it is not intented, here is a PR that tries to solve that problem by checking with beanDescription the fields in the target class as well as the commons

Here is a curl that can trigger this substitution:

curl --location 'http://localhost:8632/productOffering' \
--header 'Content-Type: application/json' \
--data-raw '{
    "href": "adsadada",
    "name": "Premium Internet Package",
    "description": "Ultra high-speed fiber internet",
    "isBundle": false,
    "isSellable": true,
    "lifecycleStatus": "Active",
    "version": "1.0",
    "statusReason": "Available for purchase",
    "validFor": {
        "startDateTime": "2025-01-01T00:00:00Z",
        "endDateTime": "2025-12-31T23:59:59Z"
    },
    "@schemaLocation": "https://raw.githubusercontent.com/fge/sample-json-schemas/refs/heads/master/json-home/json-home.json",
    "property2": "value2",
    "property1": "value1",
    "resources": ""
}'

Best regards

[Sh3rd3n]

Guys, when are you planning to merge this PR?

[wistefan]

shouldn't the propertiesNode be under "properties", instead of "definitions"? Please do not use magic constants, make them actual constants

[wistefan]

You should add a test for this. I'm pretty sure that this wont give you the fieldnames used in the json-schema, since the json property names are defined via Jackson-Annotation, rather than the raw-property names.

[wistefan]

Not every extendable entity has an id or href defined. With this, none such entity could be extended with an id or href.