RestIT test works with `(jakarta.ws.rs.core.MediaType) Hal#APPLICATION_HAL_JSON_TYPE`

[yanavasileva]

After update to Spring Boot 3, RestIT started to fail with NoSuchFieldError: APPLICATION_HAL_JSON_TYPE. Due to unresolved dependency issue (javax/jakarta), we decided to simplify the rest and avoid using the MediaType type (https://github.com/camunda/camunda-bpm-platform/issues/3441#issuecomment-1593378231).

Error details

``` testTaskFilterResultContentType(org.camunda.bpm.rest.RestIT) Time elapsed: 5.494 s <<< ERROR! java.lang.NoSuchFieldError: APPLICATION_HAL_JSON_TYPE at org.camunda.bpm.rest.RestIT.assertMediaTypesOfResource(RestIT.java:308) at org.camunda.bpm.rest.RestIT.testTaskFilterResultContentType(RestIT.java:174) [ERROR] testSingleTaskContentType(org.camunda.bpm.rest.RestIT) Time elapsed: 5.245 s <<< ERROR! java.lang.NoSuchFieldError: APPLICATION_HAL_JSON_TYPE at org.camunda.bpm.rest.RestIT.assertMediaTypesOfResource(RestIT.java:308) at org.camunda.bpm.rest.RestIT.testSingleTaskContentType(RestIT.java:150) [ERROR] testTaskQueryContentType(org.camunda.bpm.rest.RestIT) Time elapsed: 5.178 s <<< ERROR! java.lang.NoSuchFieldError: APPLICATION_HAL_JSON_TYPE at org.camunda.bpm.rest.RestIT.assertMediaTypesOfResource(RestIT.java:308) at org.camunda.bpm.rest.RestIT.testTaskQueryContentType(RestIT.java:140) ```

Acceptance Criteria (Required on creation)

• Revert the workaround and ensure Hal class and MediaType can be resolved correctly in the Spring Boot integration test setup

Hints

• rewrite the tests to not use the jersey apache client 4

Links

• follow up of #3441

Breakdown

### Pull Requests

Dev2QA handover

• [ ] Does this ticket need a QA test and the testing goals are not clear from the description? Add a Dev2QA handover comment

[punitdarira]

Hi @yanavasileva, When I try to test the changes by running mvn install -Pintegration-test-spring-boot-starter in the qa-webapp-ce-runtime project, I get this error- ### Error querying database. Cause: org.h2.jdbc.JdbcSQLSyntaxErrorException: Table "ACT_RE_DECISION_DEF" not found; Am I missing something?

[yanavasileva]

@punitdarira, when you are in the root of the mono repo try running the following:

mvn clean install -Pintegration-test-spring-boot-starter -f spring-boot-starter/pom.xml

[punitdarira]

@yanavasileva , I get the same error through this above cmd

[yanavasileva]

@punitdarira make sure to drop all of local changes that you have (might be related to some changes that you worked on). Also use JDK 17 and Maven 3.8.6. If none of that works, please share the stack trace and the output of the maven execution, I am not sure to what might be related.

[punitdarira]

stacktrace.txt @yanavasileva, I used JDK 17 and maven wrapper in the project itself.

[punitdarira]

@yanavasileva , Please ignore. It resolved after the whole build of the workspace. Sorry for the trouble!

[punitdarira]

@yanavasileva

1. Just wanted to make sure that the usage of jersey apache client doesn't have to do anything with the dependency issue of javax/jakarta right?
2. I think spring webclient would be a good option to use.
3. from your comment , the jakarta field does not resolve as there is a second javax on the classpath. How did you find this? class loader logs? Are we aiming for the jakarta version to get resolved? Because if we are, then there should be a mapping for javax to jakarta for integration testing right? Sorry but I am not very confident with Maven. I am trying to learn it.

[yanavasileva]

Just wanted to make sure that the usage of jersey apache client doesn't have to do anything with the dependency issue of javax/jakarta right?

I am not sure, I wrote that a note to try out "rewrite the tests to not use the jersey apache client 4". So my suspect at the time was the client.

I think spring webclient would be a good option to use.

Maybe, I am not sure without exploring the option in detail. We need to keep in mind that the test should work with all supported environments.

from your https://github.com/camunda/camunda-bpm-platform/issues/3441#issuecomment-1593378231, the jakarta field does not resolve as there is a second javax on the classpath. How did you find this?

Debugging and checking the class loaders. Due to time restrictions, I didn't get to the bottom of the issue, therefore this open ticket.