0

We are migrating a few old systems written in Java 5, 6 and 7 to Java 8 and from JBoss 7 to Wildfly 14. After the migration, I get all the time this kind of error:

WELD-001408: Unsatisfied dependencies for type InterfaceTypeConverterProvider with qualifiers @Named

I understand that from CDI 1.2 things changed and the @Inject don't work as it used to be and it need some refactoring. I got many errors like this, some of them are classes in my own project that try to Inject other classes also inside my project, those ones I can fix.

The problem is: My project loads some classes that tries to inject other classes from outside, that are jar dependencies that I have no control over it and I can't change the code on those jars.

For example:

11:15:54,552 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service jboss.deployment.unit."myApp-war-9.2-JAVA8-SNAPSHOT.war".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."myApp-war-9.2-JAVA8-SNAPSHOT.war".WeldStartService: Failed to start service at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1728)
  at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1556)
  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 46 exceptions:
Exception 0 :
org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type InterfaceTypeConverterProvider with qualifiers @Named
  at injection point [BackedAnnotatedParameter] Parameter 1 of [BackedAnnotatedMethod] @Inject public thirdPartJar.converter.context.AbstractConverter.setTypeConverterProvider(@Named InterfaceTypeConverterProvider)
  at thirdPartJar.converter.context.AbstractConverter.setTypeConverterProvider(AbstractConverter.java:0)
WELD-001475: The following beans match by type, but none have matching qualifiers:
  - Managed Bean [class thirdPartJar.converter.context.TypeConverterProvider] with qualifiers [@Any @Default]

The error shows the problem in the class thirdPartJar.converter.context.AbstractConverter and I can't touch the code on that one... so, what should I do ? Is it possible to downgrade Wildfly Weld or force it to use an older version of CDI ?

This is my beans.xml with the discover all but it still can't find the implementations.

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://xmlns.jcp.org/xml/ns/javaee"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/beans_1_1.xsd"
       version="1.2" bean-discovery-mode="all">
</beans>
André Silva
  • 103
  • 8
  • The search term you should use is 'bean discovery' E.g. https://stackoverflow.com/questions/18310388/meaning-of-bean-discovery-mode-annotated-in-cdi-1-1 – Kukeltje May 02 '19 at 10:53
  • @Kukeltje I tried that before, I added on beans.xml on my app(not the 3rd part jar) but I still get errors, the only difference is now I see the same errors but inside my project. I have more than 1.000 Injects in this project, I really don't want to refactor everything, is there a way I can fix this without having to change all the interfaces ? – André Silva May 02 '19 at 13:00
  • Ahh... this is my beans.xml: ` ` – André Silva May 02 '19 at 13:05
  • See [ask] about the 'search, keep track and mention thing' – Kukeltje May 02 '19 at 13:18
  • From the stack it seems like you are actually having problems injecting beans from WAR into the 3rd party JAR, is that right? AKA, is the bean implementing `InterfaceTypeConverterProvider` with qualifier `@Named` in the WAR? If so then you are observing an enforcement of Java EE "umbrella" spec visibility rules. There are multitude of those but in your case the catch is that WAR can see beans from its dependencies (the 3rd party WAR) but the opposite is not true. The JAR cannot see any beans in the WAR and altering beans discovery mode won't help that. – Siliarus May 06 '19 at 08:27

1 Answers1

2

The beans.xml always only applies to the archive it's in (be it jar or war). So you're setting the bean-discovery-mode only for your own archive, not for the 3rd party one.

Easiest option: Repackage the 3rd party jar and include a fitting beans.xml.

Non-intrusive option: Write a producer that supplies the expected beans. Normally, this can be a simple method:

@Produces
@Named
public InterfaceTypeConverterProvider createInterfaceTypeConverterProvider() {
    return new InterfaceTypeConverterProvider();
}

I take it that there is no injection within the class. Otherwise it should already have been cdi enabled.

jokster
  • 577
  • 5
  • 14