Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ClassNotFoundException: brave.http.HttpClientHandler when running in certain environments #399

Open
3 of 4 tasks
jamesdh opened this issue Apr 5, 2021 · 2 comments
Open
3 of 4 tasks

Comments

@jamesdh
Copy link

jamesdh commented Apr 5, 2021

Task List

  • Steps to reproduce provided
  • Stacktrace (if present) provided
  • Example that reproduces the problem uploaded to Github
  • Full description of the issue provided (see below)

Steps to Reproduce

I was working through the Micronaut GCP docs to get logging + tracing working correctly on an app deployed to a GKE Autopilot cluster. The logging I was able to get configured but have not had much luck getting tracing working correctly. When I eventually pushed my changes, my automated tests ran via GitHub Actions, at which point I would get a failure due to a ClassNotFoundException that appears to be related to brave:

Caused by: java.lang.ClassNotFoundException: brave.http.HttpClientHandler
	at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:581)
	at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522)
	... 84 more

But when running tests locally, I have no such issue. I tried disabling both zipkin tracing and gcp tracing in application.yml, but it made no difference.

However, after taking a look at the release notes, it appears beginning with Brave v5.13 they made some changes to their maven BOM which could be the cause of any such transitive dependency issues:

End users can opt-in to io.zipkin.brave:brave-bom to pin our versions, but we will no longer use tools like BOMs for internal convenience.

I'm afraid I'm too inexperienced with both GCP/GKE and Brave to understand what's going on here, but I'm guessing it's somehow related to the fact that GitHub Actions are themselves running in a cloud environment, which in turn is incorrectly being detected and thus it tries to run brave?

Manually adding runtimeOnly("io.zipkin.brave:brave-instrumentation-http:5.13.3") to build.gradle got around this testing quirk, but I'm guessing that isn't the expected behavior...

Environment Information

  • Operating System: GitHub Actions Linux runner
  • Micronaut Version: 2.4.2
  • JDK Version: Java_Adopt_jdk/11.0.10-9/x64
@caiolopes
Copy link

I am facing the same problem here.

My test fails only on GitHub Actions, but locally it works.

  • Operating System: GitHub Actions Linux runner
  • Micronaut Version: 3.1.3
  • JDK Version: OpenJDK 16 64-Bit
io.micronaut.context.exceptions.BeanInstantiationException: 
Error instantiating bean of type  [io.micronaut.http.server.RouteExecutor]

Message: brave/http/HttpClientHandler
Path Taken: NettyEmbeddedServer.buildDefaultServer(NettyHttpServerConfiguration configuration) --> new DefaultNettyEmbeddedServerFactory(ApplicationContext applicationContext,[RouteExecutor routeExecutor],MediaTypeCodecRegistry mediaTypeCodecRegistry,StaticResourceResolver staticResourceResolver,ThreadFactory nettyThreadFactory,HttpCompressionStrategy httpCompressionStrategy,EventLoopGroupFactory eventLoopGroupFactory,EventLoopGroupRegistry eventLoopGroupRegistry) --> new RouteExecutor([Router router],BeanContext beanContext,RequestArgumentSatisfier requestArgumentSatisfier,HttpServerConfiguration serverConfiguration,ErrorResponseProcessor errorResponseProcessor,ExecutorSelector executorSelector)
Caused by: java.lang.NoClassDefFoundError: brave/http/HttpClientHandler
Caused by: java.lang.ClassNotFoundException: brave.http.HttpClientHandler

@danielmatthews84
Copy link

I've just ran into this same problem. Unfortunately I can't add brave-instrumentation-http to the classpath as it replaces the OpenTracingServerFilter bean from micronaut-trace.

Running locally is working as expected but fails on GCP.

Strangely it seems that enabling metrics in application.yml fixes the issue.

  • Micronaut Version: 3.5.3

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants