Convert jaxrs-1.0 tests to java

[laurit]

Part of #7195

[jaydeluca]

not related to your test, but it's strange to me that the groovy test used the post method but asserted that the spans were GETs

[laurit]

In groovy test the server span isn't created from the actual request but with runWithHttpServerSpan that just uses GET.

[jaydeluca]

are we intentionally avoiding using hasAttributesSatisfyingExactly here so that we don't need to to assert all the other attributes on this span? Also the groovy tests expected an error.type that I don't see on this test's spans, is that an artifact of us switching the test dependencies from using the dropwizard testing package to using jetty directly?

[laurit]

Yes, I intentionally skipped listing all attributes, but I guess they could be added for consistency with other tests. I was also confused by the error.type it is added because runWithHttpServerSpan uses

opentelemetry-java-instrumentation/testing-common/src/main/java/io/opentelemetry/instrumentation/testing/TestInstrumenters.java

Line 138 in e27a76a

private enum HttpServerGetter implements HttpServerAttributesGetter<String, Void> {

that returns null from getHttpResponseStatusCode and

opentelemetry-java-instrumentation/instrumentation-api/src/main/java/io/opentelemetry/instrumentation/api/semconv/http/HttpCommonAttributesExtractor.java

Line 106 in e27a76a

errorType = getter.getErrorType(request, response, error);

interprets null as non successful request. I suspect this behavior might not conform to the spec as the spec says If the request has completed successfully, instrumentations SHOULD NOT set error.type. Does lack of status code mean that the request has failed? Imo not too important as real instrumentations always set the status code, and if they don't then there really must have been an error. cc @trask

[trask]

I think it's ok to interpret null response status code as "not completed successfully", since a "successful" HTTP response would always have a response status code