OPTIONS requests to /api/* return HTTP 500, causing CORS failures

[yolabingo]

Parent Issue

No response

Problem Statement

EDIT: this impacts other apis, not just /api/content

These return HTTP 500:

curl -X OPTIONS --head https://demo.dotcms.com/api/v1/appconfiguration
curl -X OPTIONS --head https://demo.dotcms.com/api/v1/contenttype

but /api/v1/graphql is ok.

OPTIONS requests to /api/content/* return a HTTP 500 error.

Browsers making client-side fetch api and XHR requests may enforce CORS restrictions, which require a valid server response to these OPTIONS requests. This means it is not currently possible to make client-side javascript requests to /api/content/* from web browsers.

See the Slack link below for more details

Steps to Reproduce

curl -X OPTIONS --head https://demo.dotcms.com/api/content/id/574f0aec-185a-4160-9c17-6d037b298318/

Acceptance Criteria

OPTIONS requests to /api/content/* return proper CORS headers

dotCMS Version

22.06 LTS and later - not sure which agile release first does this

the issue is not present in 21.06 LTS

Proposed Objective

Core Features

Proposed Priority

Priority 1 - Show Stopper

External Links... Slack Conversations, Support Tickets, Figma Designs, etc.

Cloud customer reported this issue https://dotcms.zendesk.com/agent/tickets/112877

See this Slack post for more details https://dotcms.slack.com/archives/C028Z3R2D/p1691775252548639

Assumptions & Initiation Needs

No response

Quality Assurance Notes & Workarounds

No response

Sub-Tasks & Estimates

No response

[erickgonzalez]

This is broken due the remove of jaxws libs #24843

[erickgonzalez]

Let's add this instead of the old libs implementation 'org.glassfish.jaxb:jaxb-runtime:2.3.3'

[bryanboza]

Fixed, tested locally on the last master and now we are returning 200 instead the 500 error