1

I have an EAR File that contains two WARs. In WAR1 there is a JSF application (everything worked fine with JSF2.2 and ManagedBeans). After migrating to JSF2.3 with CDI beans I'm getting the following Exception when trying to access the web applicaton:

WELD-001456: Argument bean must not be null (complete stack trace below)

Here my EAR's structure

EAR   
  |- WAR1
      |-WEB-INF\beans.xml
      |-WEB-INF\lib\myfaces-api-2.3.7.jar
      |-WEB-INF\lib\myfaces-impl-2.3.7.jar   
  |- WAR2
      |-WEB-INF\beans.xml

If I deploy the EAR with just WAR1 it works. I googled but could not find an answer. I'm using Wildfly 19.1.0. The same exception happened also just after the upgrade to myfaces2.3.7 (without the migration to CDI).

Caused by: org.jboss.weld.exceptions.IllegalArgumentException: WELD-001456: Argument bean must not be null
at [email protected]//org.jboss.weld.util.Preconditions.checkArgumentNotNull(Preconditions.java:40)
at [email protected]//org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:708)
at [email protected]//org.jboss.weld.util.ForwardingBeanManager.getReference(ForwardingBeanManager.java:64)
at [email protected]//org.jboss.weld.bean.builtin.BeanManagerProxy.getReference(BeanManagerProxy.java:87)
at deployment.myapp.ear.web.war//org.apache.myfaces.cdi.util.CDIUtils.resolveInstance(CDIUtils.java:65)
at deployment.myapp.ear.web.war//org.apache.myfaces.cdi.util.CDIUtils.lookup(CDIUtils.java:52)
at deployment.myapp.ear.web.war//org.apache.myfaces.el.unified.ResolverBuilderBase.isReplaceImplicitObjectResolverWithCDIResolver(ResolverBuilderBase.java:232)
at deployment.myapp.ear.web.war//org.apache.myfaces.el.unified.ResolverBuilderForFaces.build(ResolverBuilderForFaces.java:108)
at deployment.myapp.ear.web.war//org.apache.myfaces.application.ApplicationImpl.createFacesResolver(ApplicationImpl.java:408)
at deployment.myapp.ear.web.war//org.apache.myfaces.application.ApplicationImpl.getELResolver(ApplicationImpl.java:389)
at deployment.myapp.ear.web.war//org.apache.myfaces.context.servlet.FacesContextImplBase.getELContext(FacesContextImplBase.java:230)
at deployment.myapp.ear.web.war//javax.faces.context.FacesContextWrapper.getELContext(FacesContextWrapper.java:85)
at deployment.myapp.ear.web.war//org.apache.myfaces.application.ApplicationImpl._handleResourceDependency(ApplicationImpl.java:2551)
at deployment.myapp.ear.web.war//org.apache.myfaces.application.ApplicationImpl._handleResourceDependencyAnnotations(ApplicationImpl.java:2515)
at deployment.myapp.ear.web.war//org.apache.myfaces.application.ApplicationImpl._handleAnnotations(ApplicationImpl.java:2285)
at deployment.myapp.ear.web.war//org.apache.myfaces.application.ApplicationImpl.createComponent(ApplicationImpl.java:1537)
at deployment.myapp.ear.web.war//org.apache.myfaces.view.facelets.compiler.FaceletsCompilerSupport.loadLibraries(FaceletsCompilerSupport.java:141)
at deployment.myapp.ear.web.war//org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage.loadLibraries(FaceletViewDeclarationLanguage.java:2549)
at deployment.myapp.ear.web.war//org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage.createCompiler(FaceletViewDeclarationLanguage.java:2188)
at deployment.myapp.ear.web.war//org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage.initialize(FaceletViewDeclarationLanguage.java:2487)
at deployment.myapp.ear.web.war//org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage.<init>(FaceletViewDeclarationLanguage.java:308)
at deployment.myapp.ear.web.war//org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguageStrategy.<init>(FaceletViewDeclarationLanguageStrategy.java:52)
at deployment.myapp.ear.web.war//org.apache.myfaces.view.ViewDeclarationLanguageFactoryImpl.initialize(ViewDeclarationLanguageFactoryImpl.java:129)
at deployment.myapp.ear.web.war//org.apache.myfaces.view.ViewDeclarationLanguageFactoryImpl.getViewDeclarationLanguage(ViewDeclarationLanguageFactoryImpl.java:78)
at deployment.myapp.ear.web.war//org.apache.myfaces.application.ViewHandlerImpl.getViewDeclarationLanguage(ViewHandlerImpl.java:185)
at deployment.myapp.ear.web.war//javax.faces.application.ViewHandlerWrapper.getViewDeclarationLanguage(ViewHandlerWrapper.java:148)
at deployment.myapp.ear.web.war//org.apache.myfaces.shared.application.DefaultViewHandlerSupport.checkResourceExists(DefaultViewHandlerSupport.java:591)
at deployment.myapp.ear.web.war//org.apache.myfaces.shared.application.DefaultViewHandlerSupport.handleSuffixMapping(DefaultViewHandlerSupport.java:521)
at deployment.myapp.ear.web.war//org.apache.myfaces.shared.application.DefaultViewHandlerSupport.calculateViewId(DefaultViewHandlerSupport.java:86)
at deployment.myapp.ear.web.war//org.apache.myfaces.application.ViewHandlerImpl.deriveLogicalViewId(ViewHandlerImpl.java:124)
at deployment.myapp.ear.web.war//javax.faces.application.ViewHandlerWrapper.deriveLogicalViewId(ViewHandlerWrapper.java:127)
at deployment.myapp.ear.web.war//org.apache.myfaces.lifecycle.RestoreViewExecutor.execute(RestoreViewExecutor.java:222)
at deployment.myapp.ear.web.war//org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:195)
at deployment.myapp.ear.web.war//org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:142)
at deployment.myapp.ear.web.war//javax.faces.webapp.FacesServlet.service(FacesServlet.java:204)
... 72 more
Improve this question
3
  • It seams to be a bug on myfaces CDIUtils.java#L65. The bean manager does not resolve the desired bean. I can't help any further without knowing which bean is not being injected or how your beans are (or not) annotated). Can you add the CDI beans affected?
    – Paulo Araújo
    Commented Feb 23, 2021 at 18:48
  • 1
    BeanManager: Weld BeanManager for myapp.ear [bean count=31]. beans is an empty collection; I cannot see which bean(s) is causing the issue
    – Neo
    Commented Feb 24, 2021 at 10:46
  • Can you post a small project that reproduces the issue, or show the concrete code? It would be valuable to know how you are injecting your beans. Also, myfaces published a new stable version (2.3.8). Please update your libs and report if the bug is still there.
    – Paulo Araújo
    Commented Feb 24, 2021 at 11:34

1 Answer 1

Reset to default
0

Each ear and war in jboss has its own bean manager. The static method CDI.current().getBeanManager() used by myfaces can return the wrong one. I solved a similar issue with this additional configuration in ServletContextListener:

servletContext.setInitParameter("org.apache.myfaces.annotation.USE_CDI_FOR_ANNOTATION_SCANNING", "true");
servletContext.setAttribute("javax.enterprise.inject.spi.BeanManager", (new InitialContext()).lookup("java:comp/BeanManager"));
Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.