You are a lifesaver. I've been focusing on the extension modules and their dependencies to make sure the classes were visible. I didn't realize that I would need to go up the dep chain a bit more and modify the smallrye module as well, but, sure enough, that did the trick. Thanks for taking a look and walking me through that.

For the record, I had to mark the microprofile extension module dependency as optional for non-MP builds to succeed. With that done, I'm past my roadblock and can press on.

If you make it to the F2F, there's a drink of your choice on me on the company waiting for you! :P

Jason Lee

Principal Software Engineer

Red Hat JBoss EAP



On Mon, Nov 21, 2022 at 6:47 AM Matej Novotny <manovotn@redhat.com> wrote:
Hi

thanks for providing more details, I was able to reproduce it.

Here is a short breakdown of how I tried to figure out the root cause of this issue.
Sorry if I'll be stating obvious steps, I just wanted to provide an understandable approach to how I "debugged" it.
You need to identify:
  • What bean is missing? In this case it is OpenTelemetryConfig bean
  • Where is the declaration of the bean (class based, producer, CDI extension). Here, it is coming from MicroProfileTelemetryCdiExtension
  • In which WFLY module is this located? This is in microprofile/galleon-common/src/main/resources/modules/system/layers/base/org/wildfly/extension/microprofile/telemetry-api/main/module.xml
Next up, you look at the injection point that tries to obtain this bean and do a similar process:
  • Where is the injection point? What class in what JAR? This is in io.smallrye.opentelemetry.implementation.cdi.OpenTelemetryProducer which is part of SR-opentelemetry-cdi JAR
  • What WFLY module ends up having this JAR? I found this in ee-feature-pack/common/src/main/resources/modules/system/layers/base/io/smallrye/opentelemetry/main/module.xml

Now, for injection to work, the WFLY module that has the injection point needs to depend on the module that contains the bean declaration.

Therefore, when I build WFLY from your branch and then go into WFLY/dist/target/wildfly-28.0.0.Beta1-SNAPSHOT/modules/system/layers/base/io/smallrye/opentelemetry/main/module.xml,
and add the following dep <module name="org.wildfly.extension.microprofile.telemetry-api"/>
I can see the app deployed without exception.

Now, in terms of code changes that should be something like this - https://github.com/jasondlee/wildfly/compare/WFLY-17156...manovotn:WFLY-17156_fix?expand=1
However, the above change fails during galleon build and I am failing to understand why. I assume you'll know better than me :)

Hope this helps
Matej

On Fri, Nov 18, 2022 at 4:14 PM Jason Lee <jasondlee@redhat.com> wrote:
Sorry. I assumed some context. :) Yes, it's the same application.

The MP Telemetry extension is building upon the existing (and newly modified as part of this change) OpenTelemetry extension. This error occurs when using the standalone-microprofile.xml configuration.

You should be able to reproduce simply by starting the MP config and deploying the test application.

Jason Lee

Principal Software Engineer

Red Hat JBoss EAP



On Fri, Nov 18, 2022 at 8:18 AM Matej Novotny <manovotn@redhat.com> wrote:
Hi Jason,

You did not mention what app you are deploying there. Is it the same as before? I.e. https://github.com/jasondlee/multiservice-otel-demo?

With that one, I am not seeing the failure and I did the following:
* Built your branch of SR OT
* Built your branch of WFLY
* Deploy service1 WAR onto (non-preview) WFLY version

What am I missing?

Matej

On Thu, Nov 17, 2022 at 6:05 PM Jason Lee <jasondlee@redhat.com> wrote:
I'm trying to add a module for MP Telemetry support, and I'm running into a CDI injection issue that is identical, at least in terms of error reporting, to the issue that I ran into with the OpenTelemetry module. One would think that I could just do to this module what I did to the other and the problem would be solved, but, sadly, that has not been the case so far. I'm asking here to help with both visibility (external and internal) and archiving. :)

Before I get into describing the problem, the code can be found at https://github.com/jasondlee/wildfly/tree/WFLY-17156. Note that I'm using a local build of smallrye-opentelemetry as I have some changes that are needed and for which a PR has been opened (https://github.com/smallrye/smallrye-opentelemetry/pull/174).

With that, here's the error message:

{"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-2" => {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"service1-1.0-SNAPSHOT.war\".WeldStartService" => "Failed to start service
    Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type OpenTelemetryConfig with qualifiers @Default
  at injection point [UnbackedAnnotatedField] @Inject io.smallrye.opentelemetry.implementation.cdi.OpenTelemetryProducer.config
  at io.smallrye.opentelemetry.implementation.cdi.OpenTelemetryProducer.config(OpenTelemetryProducer.java:0)
"}}}}

I've gone so far as to copy and paste the module definitions from opentelemetry to microprofile-telemetry, with those definitions being here:

OpenTelemetry:

MicroProfile Telemetry:

I've also compared the modules exported in my dependency processor DPU:

The CDI Extension (https://github.com/jasondlee/wildfly/blob/WFLY-17156/microprofile/microprofile-telemetry-api/src/main/java/org/wildfly/extension/microprofile/telemetry/cdi/MicroProfileTelemetryCdiExtension.java) is actually running and the bean is added, but there's something not quite right about (I'm guessing) the module dependencies and/or exports that I'm just not seeing. I spent pretty much all of yesterday and all of today so far digging and comparing, but I'm not finding anying, so here I am once again asking for help. :)

I really need two things: 1) A solution to the problem, and 2) Any tips on tracking down these kinds of issues would be GREAT! :) Matej, in helping me last time, said I'd need "a magic wand, a CDI scrying orb, and at least two rubber ducks". If any of you have spares lying around, I can give you my shipping address. :)

Thanks.

Jason Lee

Principal Software Engineer

Red Hat JBoss EAP


_______________________________________________
wildfly-dev mailing list -- wildfly-dev@lists.jboss.org
To unsubscribe send an email to wildfly-dev-leave@lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s