"WELD-001414: Bean name is ambiguous" when there is just one bean with that name

[mthmulders]

Describe the bug
My Jakarta EE 10 application fails to start in OpenLiberty 26.0.0.1 with "WELD-001414: Bean name is ambiguous" when there is just one bean with that name.

Steps to Reproduce
Deploy the example app to a clean OpenLiberty server. Alternatively, run mvn liberty:dev -pl :runtime -am in the project.

Expected behavior
The application starts correctly

Diagnostic information:

• OpenLiberty Version: 26.0.0.1
• Affected feature(s): not sure.
• Java Version:

  openjdk version "25.0.1" 2025-10-21 LTS
  OpenJDK Runtime Environment Temurin-25.0.1+8 (build 25.0.1+8-LTS)
  OpenJDK 64-Bit Server VM Temurin-25.0.1+8 (build 25.0.1+8-LTS, mixed mode, sharing)
  

• server.xml configuration:

  <?xml version="1.0" encoding="UTF-8"?>
  <server description="server">
      <featureManager>
          <platform>jakartaee-10.0</platform>
  
          <!-- Features managed by the Jakarta EE platform -->
          <feature>cdi</feature>
          <feature>jsonb</feature>
          <feature>pages</feature>
          <feature>restfulWS</feature>
          <feature>servlet</feature>
          <feature>validation</feature>
      </featureManager>
  
      <application location="openliberty-mvc-ear.ear" name="openliberty-mvc-ear" />
  
      <logging traceSpecification="*=audit:org.jboss.weld.context.*=finest"
               isoDateFormat="true" />
  
      <applicationMonitor dropinsEnabled="false" />
      <webContainer deferServletLoad="false" />
      <cdi enableImplicitBeanArchives="false" />
  </server>

• If it would be useful, upload the messages.log file found in $WLP_OUTPUT_DIR/messages.log

Additional context
Add any other context about the problem here.

[mthmulders]

The full log message:

[2026-01-29T22:06:55.834+0100] 0000003b com.ibm.ws.app.manager.AppMessageHelper                      E CWWKZ0002E: An exception occurred while starting the application openliberty-mvc-ear. The exception message was: com.ibm.ws.container.service.state.StateChangeException: org.jboss.weld.exceptions.DeploymentException: WELD-001414: Bean name is ambiguous. Name mvc resolves to beans: [Managed Bean [class org.eclipse.krazo.MvcContextImpl] with qualifiers [@Default @Named @Any], Managed Bean [class org.eclipse.krazo.MvcContextImpl] with qualifiers [@Default @Named @Any]]

Attached are a few ffdc-files.

ffdc_26.01.29_22.06.55.0.log
ffdc_26.01.29_22.06.55.1.log
ffdc_26.01.29_22.06.55.2.log

Happy to provide any additional context and/or data if that would help the investigation.

Also, I should mention that I used a patched version of the Jakarta MVC library - my patch includes adding a beans.xml to the krazo-core and krazo-resteasy modules. The content of those files is identical:

<?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_2_0.xsd"
       version="2.0" bean-discovery-mode="annotated">
    <trim />
</beans>

Without that, there would be no bean discovery in the Krazo JARs (due to <cdi enableImplicitBeanArchives="false" />), and you would get another error:

WELD-001408: Unsatisfied dependencies for type Models with qualifiers @Default
  at injection point [BackedAnnotatedParameter] Parameter 1 of [BackedAnnotatedConstructor] @Inject public it.mulders.openliberty.tests.web.home.HomeController(Models, ServiceInterface)
  at it.mulders.openliberty.tests.web.home.HomeController.<init>(HomeController.java:35)

This has been reported in eclipse-ee4j/krazo#395.

I can provide the binaries for that patched version, if desired.

[benjamin-confino]

Thank you for the recreate app, I've assigned myself to this issue and will look into it

[benjamin-confino]

Hello.

I see the issue, you've hit one of the more obscure interactions within CDI but it should all be straight forward once you know what's going on.

By default, if an archive contains a CDI Extension, CDI will not scan that archive for beans. However, when you put the beans.xml file setting the mode to annotated into the Krazo JARs you overwrote that default.

This means that the classes with CDI bean defining annotations were discovered twice, one when CDI scanned the jar, and once when the CDI extension here explicitly told CDI to scan the class.

And since it was scanned and registered twice, CDI cannot tell which of the two registered beans it should use and promptly throws an exception.

---

In the beans.xml file you've added to Krazo, if you change the scanning mode from annotated to none. That means CDI will see the archive, will trigger the extension, but will not independently scan the jar. So CDI will only have one instance of a bean that implements the MvcContext interface.

However when I tried this locally I got a different error

org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type KrazoConfig with qualifiers @Default
  at injection point [UnbackedAnnotatedField] @Inject private org.eclipse.krazo.security.CsrfTokenManager.krazoConfig
  at org.eclipse.krazo.security.CsrfTokenManager.krazoConfig(CsrfTokenManager.java:0)

I can see that the class KrazoConfig is shown to CDI via the extension, and that should be enough to make CDI turn it into a bean. The extension skips it past the point where CDI checks if it has an annotation, and applies the annotation scanning rules from the BDA.

Even more curiously. If I remove the beans.xml entirely, and remove <cdi enableImplicitBeanArchives="false" /> it all works fine. So clearly something in the weld implementation of CDI actually changed behaviour based on the beans.xml after the bean discovery phase.

---

I'm not sure if that's a bug in weld or intended, but from your end there is a a clear next step: If you remove <cdi enableImplicitBeanArchives="false" /> and the beans.xml files in your Krazo jars it should start working.

If you do have a constraint that requires <cdi enableImplicitBeanArchives="false" /> to remain in place, the simplest fix may be to patch KrazoConfig so it has a CDI annotation like @Dependent or @ApplicationScoped.

And I will look deeper into what is casing Weld's behaviour to vary after bean discovery.

[manovotn]

Also, I should mention that I used a patched version of the Jakarta MVC library - my patch includes adding a beans.xml to the krazo-core and krazo-resteasy modules. The content of those files is identical:

<?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_2_0.xsd"
       version="2.0" bean-discovery-mode="annotated">
    <trim />
</beans>

Side note - the <trim /> element shouldn't do anything.
This is meant for so called explicit bean archives where even beans without annotation would be picked up.
You are already running annotated mode so any discovered annotated type must have had some bean defining annotation to begin with.

From the specification:

An explicit bean archive may be marked as 'trimmed' by...

The definition of an explicit bean archive is then here:

An explicit bean archive is an archive which contains a beans.xml file with bean-discovery-mode of all.

[manovotn]

By default, if an archive contains a CDI Extension, CDI will not scan that archive for beans. However, when you put the beans.xml file setting the mode to annotated into the Krazo JARs you overwrote that default.

This can be a bit misleading.
A CDI extension should always be discovered, regardless of whether the archive is recognized as a bean archive.
However, bean discovery will only happen if it is a bean archive. That in turn depends on several conditions, one of which is that an archive with no beans.xml or one with none discovery mode and a CDI extension is not a bean archive.
CDI spec text with more details - https://jakarta.ee/specifications/cdi/4.0/jakarta-cdi-spec-4.0#bean_archive_full

This means that the classes with CDI bean defining annotations were discovered twice, one when CDI scanned the jar, and once when the CDI extension here explicitly told CDI to scan the class.

This is my understanding as well. You in fact do have two beans with the same name.
The extension registers it here and then the class itself has bean defining annotation (@RequestScoped in this case) meaning that with annotated discovery mode, CDI container will pick it up.

Even more curiously. If I remove the beans.xml entirely, and remove <cdi enableImplicitBeanArchives="false" /> it all works fine.

I don't know what exactly does that configuration do (it's not a Weld one, nor one from CDI itself) but removing beans.xml means that you will end up with archive that is not a bean archive by CDI specification.
That means you should still discover the extension that registers the beans but you will not perform any discovery in said archive.
That seems to check out with the outcome you are seeing?

[manovotn]

@benjamin-confino I will try to answer your question from the weld-dev mailing list here, so that all information is in one place.

Namely this part:

I've found that if I have no beans.xml in the krazo jar, this works fine, and the
various injection points expecting a KrazoConfig in this jar are happy. But if I add a
beans.xml file with a scanning mode of none, I get UnsatisfiedResolutionExceptions for
KrazoConfig.

The no beans.xml part is hopefully answered by my earlier comment so let's focus on the none discovery mode.
Frankly, this should behave exactly the same as it falls under the very same specification section as to when the archive is not a bean archive.

From the exception you are seeing I would assume that the Krazo extension isn't triggered whatsoever. An extension should always be discovered, regardless of whether the archive is a bean archive.
Did you try debugging the extension to see if it gets triggered and attempts to register those beans?

Furthermore, tt is important to note that the discovery of extensions lies with the integrator (Liberty, WildFly, ...) not Weld itself!
Weld provides an SPI through which the integrator feeds it back to us, see the Deployment SPI.

This indeed looks like a bug but likely a bug in how Liberty executes CDI extension discovery for non-bean archives.

BTW feel free to ask further if any of my comments are unclear :)

[mthmulders]

Thank you, @benjamin-confino, for your thorough investigation and clear explanation of what is going on.

It's strange to read that you were able to get the application. I've tried the same thing (setting bean-discovery-mode to "none"), but then had to patch Krazo's EventDispatcher class (adding @Dependent) to get the application to start.

Although the application did start, it doesn't work yet - upon hitting http://localhost:9080/, it throws this error in messages.log:

[INFO] [ERROR   ] RESTEASY002375: Error processing request GET / - it.mulders.openliberty.tests.web.home.HomeController.show
[INFO] Cannot produce Configuration

Also thanks to @manovotn for diving deeper into the Weld implementation and the CDI spec. I could not observe any difference between having or not having the <trim /> inside beans.xml.

The <cdi enableImplicitBeanArchives="false" /> is a configuration element in OpenLiberty. I prefer to have it as I believe it reduces startup time, because OpenLiberty will not scan all other JAR files inside the EAR for potential beans. I would say a decent Jakarta EE application (or framework) should actually report itself as a bean archive - that's why I've logged eclipse-ee4j/krazo#395 after all :-).

[manovotn]

Also thanks to @manovotn for diving deeper into the Weld implementation and the CDI spec. I could not observe any difference between having or not having the inside beans.xml.

That confirms what I said earlier, it has no effect :)

The is a configuration element in OpenLiberty. I prefer to have it as I believe it reduces startup time, because OpenLiberty will not scan all other JAR files inside the EAR for potential beans.

Interesting, I imagine this can break fair amount of libraries in an unexpected way.

I would say a decent Jakarta EE application (or framework) should actually report itself as a bean archive - that's why I've logged eclipse-ee4j/krazo#395 after all :-).

That is exactly what implicit bean archive does by definition though.
For any class to become a bean it has to explicitly declare bean defining annotation. If the framework/library does nothing towards becoming a CDI bean archive, CDI will just leave it alone. But the moment its authors annotate classes with proper annotations, CDI will go and pick those exact classes as beans.
Plus, starting with CDI 4.0, even empty beans.xml means annotated discovery (before that you were getting all which indeed created tons of useless "beans").

[benjamin-confino]

Hello @manovotn

Thank you for joining us.

I don't know what exactly does that configuration do (it's not a Weld one, nor one from CDI itself)

The technical internals of enableImplicitBeanArchives: When the value is true (the default) an archive with no beans.xml has a scanning mode of annotated (or none if we found an extension in the archive). When the value is false an archive with no beans.xml has a scanning mode of none

And yes, a lot of libraries will be unhappy if you set it to false. But as you've seen our customers like having the option.

---

From the exception you are seeing I would assume that the Krazo extension isn't triggered whatsoever. An extension should always be discovered, regardless of whether the archive is a bean archive.
Did you try debugging the extension to see if it gets triggered and attempts to register those beans?

I did and it definately registered. I can see WELD-000162 in the output. Let me give you the whole nine yards:

I generated some traces using the following recreate steps:

1) clone the repo
2) edit ./runtime/src/main/liberty/config/server.xml; remove `enableImplicitBeanArchives` and update the trace statement to the one at: https://www.ibm.com/support/pages/mustgather-cdi-problems-websphere-application-server
3) run the server, then stop the server, save the logs.
4) edit ~/.m2/repository/org/eclipse/krazo/krazo-core/4.0.1/krazo-core-4.0.1.jar; add a beans.xml with a scanning mode of `none`
5) run the server, then stop the server, save the logs.

When I look both sets of logs I see (many intermediate lines have been cut) I see the same in both:

[2/4/26, 11:36:16:092 GMT] 00000048 id=00000000 com.ibm.ws.cdi.impl.weld.BeanDeploymentArchiveImpl           > scanForBeanClassNames [ BDA for openliberty-mvc-ear#EAR/liborg.eclipse.krazo-krazo-core-4.0.1.jar(EAR_LIB) ] Entry 
[2/4/26, 11:36:16:092 GMT] 00000048 id=a6ec286f com.ibm.ws.cdi.impl.weld.BeanDeploymentArchiveImpl           > getBeanDiscoveryMode Entry 
[2/4/26, 11:36:16:092 GMT] 00000048 id=a6ec286f com.ibm.ws.cdi.impl.weld.BeanDeploymentArchiveImpl           < getBeanDiscoveryMode Exit  
                                                                                                               NONE

All as expected.

[2/4/26, 11:36:16:098 GMT] 00000048 id=00000000 com.ibm.ws.cdi.impl.weld.BeanDeploymentArchiveImpl           3 scan [ BDA for openliberty-mvc-ear#EAR/liborg.eclipse.krazo-krazo-core-4.0.1.jar(EAR_LIB) ] AFTER SCAN. Bean classes: { org.eclipse.krazo.cdi.KrazoCdiExtension = class org.eclipse.krazo.cdi.KrazoCdiExtension}

Also as expected, we find the extension and nothing else.

[2/4/26, 11:36:16:303 GMT] 00000048 id=00000000 org.jboss.weld.bootstrap.events.BeforeBeanDiscoveryImpl      1 addAnnotatedType WELD-000162: BeforeBeanDiscovery.addAnnotatedType() called by org.eclipse.krazo.cdi.KrazoCdiExtension@9f689ac0 for [BackedAnnotatedType] public @Named @RequestScoped class org.eclipse.krazo.MvcContextImpl

[2/4/26, 11:36:16:305 GMT] 00000048 id=00000000 org.jboss.weld.bootstrap.events.BeforeBeanDiscoveryImpl      1 addAnnotatedType WELD-000162: BeforeBeanDiscovery.addAnnotatedType() called by org.eclipse.krazo.cdi.KrazoCdiExtension@9f689ac0 for [BackedAnnotatedType] public  class org.eclipse.krazo.KrazoConfig

As expected, the extension is calling addAnnotatedType

But

Exception 1 :
org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type KrazoConfig with qualifiers @Default
  at injection point [UnbackedAnnotatedField] @Inject private org.eclipse.krazo.MvcContextImpl.krazoConfig
  at org.eclipse.krazo.MvcContextImpl.krazoConfig(MvcContextImpl.java:0)

The error concerns the two types that went through addAnnotatedType. Though MvcContextImpl has a bean defining annotation and KrazoConfig does not which might be important.

Three of the exceptions were saying KrazoConfig could not be injected, the fourth was saying EventDispatcher could not be injected. That class is also run through addAnnotatedType and has no BDA. Note also that mthmulders got past this error when adding @Dependent to EventDispatcher

Given that the trace shows the same results for Liberty's behaviour in both cases, I was wondering if perhaps there was a difference in weld.

---

One final bit of context.

BeanDeploymentArchiveImpl is our implementation of org.jboss.weld.bootstrap.spi.BeanDeploymentArchive and Bean classes: { org.eclipse.krazo.cdi.KrazoCdiExtension = class org.eclipse.krazo.cdi.KrazoCdiExtension} shows what we'll return for the getBeanClasses() method; a set consisting of every value on the left side of an =.

---

Just for reference, if put a beans.xml with a scanning mode of annotated in krazo-core-4.0.1.jar I get this

[2/4/26, 13:19:55:017 GMT] 00000048 id=00000000 com.ibm.ws.cdi.impl.weld.BeanDeploymentArchiveImpl           3 scan [ BDA for openliberty-mvc-ear#EAR/liborg.eclipse.krazo-krazo-core-4.0.1.jar(EAR_LIB) ] AFTER SCAN. Bean classes: { org.eclipse.krazo.MvcContextImpl = class org.eclipse.krazo.MvcContextImpl, org.eclipse.krazo.binding.BeanValidationProducer = class org.eclipse.krazo.binding.BeanValidationProducer, org.eclipse.krazo.binding.BindingResultManager = class org.eclipse.krazo.binding.BindingResultManager, org.eclipse.krazo.binding.ConstraintViolationTranslator = class org.eclipse.krazo.binding.ConstraintViolationTranslator, org.eclipse.krazo.binding.convert.ConverterRegistry = class org.eclipse.krazo.binding.convert.ConverterRegistry, org.eclipse.krazo.binding.validate.ValidationInterceptor = class org.eclipse.krazo.binding.validate.ValidationInterceptor, org.eclipse.krazo.bootstrap.CoreFeature = class org.eclipse.krazo.bootstrap.CoreFeature, org.eclipse.krazo.cdi.AroundControllerInterceptor = class org.eclipse.krazo.cdi.AroundControllerInterceptor, org.eclipse.krazo.cdi.KrazoCdiExtension = class org.eclipse.krazo.cdi.KrazoCdiExtension, org.eclipse.krazo.cdi.RedirectScopeManager = class org.eclipse.krazo.cdi.RedirectScopeManager, org.eclipse.krazo.core.Messages = class org.eclipse.krazo.core.Messages, org.eclipse.krazo.core.ModelsImpl = class org.eclipse.krazo.core.ModelsImpl, org.eclipse.krazo.engine.ViewEngineFinder = class org.eclipse.krazo.engine.ViewEngineFinder, org.eclipse.krazo.event.AfterControllerEventImpl = class org.eclipse.krazo.event.AfterControllerEventImpl, org.eclipse.krazo.event.AfterProcessViewEventImpl = class org.eclipse.krazo.event.AfterProcessViewEventImpl, org.eclipse.krazo.event.BeforeControllerEventImpl = class org.eclipse.krazo.event.BeforeControllerEventImpl, org.eclipse.krazo.event.BeforeProcessViewEventImpl = class org.eclipse.krazo.event.BeforeProcessViewEventImpl, org.eclipse.krazo.event.ControllerRedirectEventImpl = class org.eclipse.krazo.event.ControllerRedirectEventImpl, org.eclipse.krazo.forms.FormMethodOverwriteFilter = class org.eclipse.krazo.forms.FormMethodOverwriteFilter, org.eclipse.krazo.jaxrs.JaxRsContextProducer = class org.eclipse.krazo.jaxrs.JaxRsContextProducer, org.eclipse.krazo.lifecycle.RequestLifecycle = class org.eclipse.krazo.lifecycle.RequestLifecycle, org.eclipse.krazo.locale.DefaultLocaleResolver = class org.eclipse.krazo.locale.DefaultLocaleResolver, org.eclipse.krazo.locale.LocaleResolverChain = class org.eclipse.krazo.locale.LocaleResolverChain, org.eclipse.krazo.security.CsrfImpl = class org.eclipse.krazo.security.CsrfImpl, org.eclipse.krazo.security.CsrfTokenManager = class org.eclipse.krazo.security.CsrfTokenManager, org.eclipse.krazo.security.EncodersImpl = class org.eclipse.krazo.security.EncodersImpl, org.eclipse.krazo.uri.UriTemplateParser = class org.eclipse.krazo.uri.UriTemplateParser, org.eclipse.krazo.util.CdiUtils = class org.eclipse.krazo.util.CdiUtils}

[benjamin-confino]

@mthmulders

First, you said you added @Dependent to EventDispacher. Did you also do the same to KrazoConfig?

Secondly, please can you put the following in your server.xml

<logging traceSpecification="*=info:JCDI=all:com.ibm.ws.webbeans*=all:org.apache.webbeans*=all:org.jboss.weld*=all:com.ibm.ws.cdi*=all:*=info:com.ibm.ws.jaxrs*=all:com.ibm.websphere.jaxrs*=all:org.apache.wink.*=all:org.apache.cxf.*=all" />

Then rm wlp/usr/defaultServer/logs/* and regenerate the traces. Then zip up wlp/usr/defaultServer and attach it to a comment.

I'm going to ask one of the resteasy team if that trace statement is correct. I've got a suspicion our documentation is out of date.

[mthmulders]

@mthmulders

First, you said you added @Dependent to EventDispacher. Did you also do the same to KrazoConfig?

No, I added @ApplicationScoped there as it seems to be it only has "global" values injected.

Secondly, please can you put the following in your server.xml

<logging traceSpecification="*=info:JCDI=all:com.ibm.ws.webbeans*=all:org.apache.webbeans*=all:org.jboss.weld*=all:com.ibm.ws.cdi*=all:*=info:com.ibm.ws.jaxrs*=all:com.ibm.websphere.jaxrs*=all:org.apache.wink.*=all:org.apache.cxf.*=all" />

Then rm wlp/usr/defaultServer/logs/* and regenerate the traces. Then zip up wlp/usr/defaultServer and attach it to a comment.

Just to confirm: I've kept enableImplicitBeanArchives set to false.

Attached the new traces: traces.zip

I'm going to ask one of the resteasy team if that trace statement is correct. I've got a suspicion our documentation is out of date.

[benjamin-confino]

No, I added @ApplicationScoped there as it seems to be it only has "global" values injected.

Thank you, that still fits my theory that CDI is ignoring these two classes because they had no BeanDefiningAnnotation, despite them being registered through an extension.

Its strange that a beans.xml setting the scanning mode to none behaves differently on that point than the scanning mode being set to none because there is no beans.xml and an extension. Hopefully manovotn will have an idea.

Just to confirm: I've kept enableImplicitBeanArchives set to false.

Attached the new traces: traces.zip

Thanks for the confirmation.

I looked at the traces. The error happens because Configuration is null at: https://github.com/eclipse-ee4j/krazo/blob/releases/4.0.1/core/src/main/java/org/eclipse/krazo/jaxrs/JaxRsContextProducer.java#L85

And Configuration should be set by this line: https://github.com/eclipse-ee4j/krazo/blob/main/core/src/main/java/org/eclipse/krazo/jaxrs/PostMatchingRequestFilter.java#L66

Using a @Context annotated field. I had a quick check at our Resteasy/CDI integration code and I don't think we use CDI for injecting that, but I'll double check that with the resteasy team.