Add support for RESTEasy4

[carlfranz]

Add an agent plugin to support

• Add a test case for the new plugin, refer to the doc
• Add a component id in the component-libraries.yml
• Add a logo in the UI repo

• If this pull request closes/resolves/fixes an existing issue, replace the issue number. Closes #.
• Update the CHANGES log.

[wu-sheng]

Please make sure you finish the test scenarios, which are mentioned by the plugin develop doc.

[carlfranz]

Please make sure you finish the test scenarios, which are mentioned by the plugin develop doc.

We are working on that.

[wu-sheng]

When you are ready, please add your case into GHA control file.

About docs, you need to update

1. changes.md in the root
2. supported-list to add new version.

[wu-sheng]

When you are ready, please add your case into GHA control file.

This is still missing. We only could use GitHub action to test your scenario after you add it.

[wu-sheng]

One question, what are the differences between 3.x and 4.x plugins? I noticed they are very similar.

[wu-sheng]

One question, what are the differences between 3.x and 4.x plugins? I noticed they are very similar.

Could you example this first?

[carlfranz]

One question, what are the differences between 3.x and 4.x plugins? I noticed they are very similar.

Could you example this first?

It is a different artifact name from 3.x and 4.x. In the first one is resteasy-jaxrs and in the latter is resteasy-core.

[wu-sheng]

It is a different artifact name from 3.x and 4.x. In the first one is resteasy-jaxrs and in the latter is resteasy-core.

I think the jar names don't matter when do instrumentation. The class's signature(class name, package name, method name and parameters with types) matters. Have you faced exceptions or something when you put 3.x plugin in 4.x runtime?

[carlfranz]

It is a different artifact name from 3.x and 4.x. In the first one is resteasy-jaxrs and in the latter is resteasy-core.

I think the jar names don't matter when do instrumentation. The class's signature(class name, package name, method name and parameters with types) matters. Have you faced exceptions or something when you put 3.x plugin in 4.x runtime?

Using the 3.x plugin with a resteasy 4.x application throws a ClassNotFoundException.

[wu-sheng]

I see, could you post the error here?

[carlfranz]

java.lang.NoSuchMethodError: 'org.jboss.resteasy.spi.ResteasyUriInfo org.jboss.resteasy.spi.HttpRequest.getUri()'
	at org.apache.skywalking.apm.plugin.resteasy.v3.server.SynchronousDispatcherInterceptor.beforeMethod(SynchronousDispatcherInterceptor.java:50)
	at org.apache.skywalking.apm.agent.core.plugin.interceptor.enhance.InstMethodsInter.intercept(InstMethodsInter.java:76)
	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java)
	at org.jboss.resteasy.core.SynchronousDispatcher.lambda$invoke$4(SynchronousDispatcher.java:261)
	at org.jboss.resteasy.core.SynchronousDispatcher.lambda$preprocess$0(SynchronousDispatcher.java:161)
	at org.jboss.resteasy.core.interception.jaxrs.PreMatchContainerRequestContext.filter(PreMatchContainerRequestContext.java:364)
	at org.jboss.resteasy.core.SynchronousDispatcher.preprocess(SynchronousDispatcher.java:164)
	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:247)
	at io.quarkus.resteasy.runtime.standalone.RequestDispatcher.service(RequestDispatcher.java:73)
	at io.quarkus.resteasy.runtime.standalone.VertxRequestHandler.dispatch(VertxRequestHandler.java:151)
	at io.quarkus.resteasy.runtime.standalone.VertxRequestHandler$1.run(VertxRequestHandler.java:91)
	at io.quarkus.vertx.core.runtime.VertxCoreRecorder$13.runWith(VertxCoreRecorder.java:545)
	at org.jboss.threads.EnhancedQueueExecutor$Task.run(EnhancedQueueExecutor.java:2449)
	at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1478)
	at org.jboss.threads.DelegatingRunnable.run(DelegatingRunnable.java:29)
	at org.jboss.threads.ThreadLocalResettingRunnable.run(ThreadLocalResettingRunnable.java:29)
	at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
	at java.base/java.lang.Thread.run(Thread.java:833)```

[wu-sheng]

There is code style in the root, please make sure your plugins and test codes could pass verfication.

[wu-sheng]

Your new case is not working, please check this locally

https://github.com/apache/skywalking-java/runs/6415702839?check_suite_focus=true

[wu-sheng]

Why ge 10? I can't see you wrote 10+ expected segments.

[wu-sheng]

I think you didn't test this case locally, please make sure you have passed cases locally first.

[wu-sheng]

@carlfranz Do you still work on this? It is no update for weeks.

[carlfranz]

Hello @wu-sheng we are facing issues on the build. We cannot replicate locally the error we have with the GH pipeline. I'm not sure to find time to work on this anymore. It's frustrating because we were one step away to do it.

[wu-sheng]

expected:	Span[-1, 0] HEAD:/resteasy-4.x-scenario/healthCheck
actual:	span[-1, 0] /update/1
reason:	[operation name]: expected=>{HEAD:/resteasy-4.x-scenario/healthCheck}, actual=>{/update/1}

From the CI loga, actually, your expected data file added resteasy-4.x-scenario, but you can see the actual data without this prefix.

Have you run the tests locally?

[carlfranz]

We can't replicate the error locally. I think the issue is in the expected data file. I admit it is copied from spring scenario, I can't figure out how it works.

[wu-sheng]

Please follow the plugin test doc

https://skywalking.apache.org/docs/skywalking-java/latest/en/setup/service-agent/java-agent/plugin-test/

You should be able to run it on any Linux and Intel based MacOS.

[wu-sheng]

No update in two weeks. If you still want to continue on this, please let us know. All these tests could run and check on Linux locally, don't have to be on GitHub CI