OpenTracing for EJB modules

[Valerii Pekarskyi]

I have recently migrated the application from Wildfly 10 to Wildfly 24 and now am looking into OpenTracing that comes with the versions 19 and newer. The blog post https://jbossorg.github.io/wildflysite/news/2020/03/19/Micro_Profile_OpenTracing_Comes_To_WildFly/ shows how to enable JaxRS endpoints tracing and see the output in local Jaeger, that works great for me too.

Unfortunately simple jax-rs endpoints tracing is not enough, I would like to see traces for the beans called from these endpoints, as the opentracing-demo application shows.

The issue is the beans of my interest are mainly located in another module that is not a WAR module, but an EJB residing in the same EAR.

Trying to debug the tracer instantiation and injection during the application startup I see that there is a TracingDeploymentProcessor [https://github.com/wildfly/wildfly/blob/24.x/microprofile/opentracing-extension/src/main/java/org/wildfly/extension/microprofile/opentracing/TracingDeploymentProcessor.java#L191] that goes through the deployment module and instantiates properly configured tracer for WAR modules during deployment. However, the same process does not work properly for EJB as at line 216 serviceName is '' (as it only is read from the deploymentUnit' WarMetaData).

It seems that the TracingDeploymentProcessor expects an EJB developer to provide own implementation of TracingFactory/TracingResolver/Tracer that will be returned by TracerResolver.resolveTracer(), but it is a bit of a hassle to provide that while web modules have such a convenient shortcut.

So the question is whether EJB tracing is expected to work with current OpenTracing integration, and maybe someone may point me to the direction to the correct implementation?

Best regards,

Valerii

[Jignesh Patel]

Hi Valerii

I am willing to learn what challenges you faced while upgrading from wildfly 10 to wildfly 24.

Jignesh Patel

iCare.com LLC 

Las Olas City Centre, Suite 1400
401 East Las Olas Boulevard
Fort Lauderdale, Florida  33301
Office: 800-784-8045
jig...@icare.com

--
You received this message because you are subscribed to the Google Groups "WildFly" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wildfly+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/wildfly/92b7caa0-75b3-4f38-98c5-095cbb62fe60n%40googlegroups.com.

[Valerii Pekarskyi]

Hi  Jignesh,

Our application uses custom modules, some of them were eliminated as newer library version existed in the base modules.

I had performed upgrade in several steps, 10->14->17 ->22->24 if I am not mistaken. During the upgrade some libraries versions should be upgraded. The most challenging I believe was the Infinispan upgrade that broke support of custom DTO marshalling between application nodes nodes and required these DTOs be extracted into a Wildfly module along with the compile-time processor for protobuf marshalling.

https://github.com/wildfly/wildfly-server-migration helped me a lot with the migration. Note that it supports migration to latest versions only, but git tags exist for older versions too. There is a compilation error that require you to remove customized dependency repository, but everything else works good.