About Skywalking the order of plugin actions when intercepting HTTP requests

[llluckyou]

When I was testing locally, I enabled the

-Dskywalking.plugin.springmvc.use_qualified_name_as_endpoint_name=true
-Dskywalking.plugin.toolit.use_qualified_name_as_operation_name=true

parameter, hoping that MVC requests in the code could be intercepted and display fully qualified class names, which was all as expected, like this:

After deploying to the development environment, I used the same plugin. I packaged Docker images locally, and the development environment deployed them based on the packaged images using k8s. Therefore, theoretically, Java agents are completely identical. They call the same HTTP interface, but are intercepted by Tomcat components and displayed as URLs. Why and how should I solve this problem. like this:

[llluckyou]

I tried to remove the Tomcat plugin, and although it could achieve the goal of intercepting the HTTP interface by the Spring MVC component, I found that the traceId had changed to N/A, so I rolled it back

[wu-sheng]

Tomcat plugin doesn't impact Spring MVC plugin at all. We have internal mechanism to skip that. So, Tomcat plugin removed or not, it is transparent.

And about your config, what is the point of toolkit.* ?

[llluckyou]

I made a mistake, there should be no toolkit. * parameter. This is the response I received from the big model earlier, and I found that he answered many non-existent parameters. What I actually configured was this, But the development environment's call to the MVC interface was intercepted by the Tomcat component

-Dskywalking.plugin.springmvc.use_qualified_name_as_endpoint_name=true
-Dskywalking.plugin.springmvc.collect_http_params=true

[wu-sheng]

As I explained, if it goes through spring MVC, the Tomcat one will be overrided automatically, you would not see it, unless it is not a spring call.