Search code examples
javaexceptionjakarta-eecdithorntail

Thorntail: Unsatisfied dependencies for type LoggingFraction with qualifiers @Any


I'm just getting started with Thorntail, and am trying to do the simplest of tests. I've written up a HealthCheck implementation that just returns a success status. That's all. When I run mvn thorntail:run, however, I get an error saying:

Unsatisfied dependencies for type LoggingFraction with qualifiers @Any

Here is the relevant part of the stacktrace:

2019-05-13 16:33:28,475 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service jboss.deployment.unit."holocron-data-services-0.1-SNAPSHOT.war".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."holocron-data-services-0.1-SNAPSHOT.war".WeldStartService: Failed to start service
    at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1730)
    at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1558)
    at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
    at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
    at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
    at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
    at java.lang.Thread.run(Thread.java:748)
Caused by: org.jboss.weld.exceptions.DeploymentException: Exception List with 2 exceptions:
Exception 0 :
org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type LoggingFraction with qualifiers @Any
  at injection point [BackedAnnotatedField] @Inject @Any private org.wildfly.swarm.logging.runtime.LoggingCustomizer.fraction
  at org.wildfly.swarm.logging.runtime.LoggingCustomizer.fraction(LoggingCustomizer.java:0)

    at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:378)
    at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:290)
    at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:143)
    at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:164)
    at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:526)
    at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:64)
    at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:62)
    at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:62)
    at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:55)
    at java.util.concurrent.FutureTask.run(FutureTask.java:266)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
    at java.lang.Thread.run(Thread.java:748)
    at org.jboss.threads.JBossThread.run(JBossThread.java:485)
Exception 1 :
org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type LoggingFraction with qualifiers @Any
  at injection point [BackedAnnotatedField] @Inject @Any private org.wildfly.swarm.logging.runtime.EarlyLoggingCustomizer.fraction
  at org.wildfly.swarm.logging.runtime.EarlyLoggingCustomizer.fraction(EarlyLoggingCustomizer.java:0)

    at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:378)
    at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:290)
    at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:143)
    at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:164)
    at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:526)
    at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:64)
    at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:62)
    at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:62)
    at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:55)
    at java.util.concurrent.FutureTask.run(FutureTask.java:266)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
    at java.lang.Thread.run(Thread.java:748)
    at org.jboss.threads.JBossThread.run(JBossThread.java:485)

    at org.jboss.weld.bootstrap.ConcurrentValidator.validateBeans(ConcurrentValidator.java:72)
    at org.jboss.weld.bootstrap.Validator.validateDeployment(Validator.java:487)
    at org.jboss.weld.bootstrap.WeldStartup.validateBeans(WeldStartup.java:490)
    at org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:93)
    at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:98)
    at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1738)
    at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1700)
    ... 6 more
    Suppressed: org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type LoggingFraction with qualifiers @Any
  at injection point [BackedAnnotatedField] @Inject @Any private org.wildfly.swarm.logging.runtime.LoggingCustomizer.fraction

I'm not explicitly including the Logging fraction. When I do, I get the exact same error. I'm not doing anything overly complex. This is basically just a glorified "Hello, World" that is causing this error. Any advice on what I'm doing wrong?


Solution

  • This is most likely "the classpath problem". Thorntail typically runs from an uberjar, but mvn thorntail:run by default tries to assemble a similar environment from the Maven dependency set (aka "classpath"). This doesn't always work correctly. You can switch to the uberjar by mvn thorntail:run -Dthorntail.useUberJar. Please let us know if that works for you.

    Side note: I've proposed several times to switch the default behavior to using the uberjar. Perhaps it's finally time to do it :-)