0

In a simple JSF 2.2 project using Mojarra. There is a managed bean:

@RequestScoped
@Named(value="myHello")
public Hello {
    private String name = "test";
    public void setName(String name) {
        this.name = name;
    }
    public String getName() {
        return name;
    }
}

and this managed bean is used in a jsf with placeholder #{myHello.name}. In order to make the CDI work, weld 3.1.3 Final (CDI 2.0 implementation) is added as dependency

The compiled war is deployed to a Tomcat 8 servlet container.

Unexpected result: the JSF can be displayed fluently, but #{myHello.name} didn't ouput test as expected but nothing

The ogirinal solution was add an empty beans.xml to WEB-INF directory according to the answer in How to install and use CDI on Tomcat?, and it indeed can work out this problem.

But being that the note in Weld 3.1.3 Final specification:

The beans.xml file is no longer required for CDI enablement as of CDI 1.1. CDI is automatically enabled for archives which don’t contain beans.xml but contain one or more bean classes with a bean defining annotation

An empty beans.xml would not be necessary any more.

Question:

  • Why is an empty beans.xml still compulsory?
  • How to make the placeholder #{myHello.name} work properly without an empty beans.xml?
Rui
  • 2,967
  • 4
  • 27
  • 54
  • 1
    uhhhhh.... you mention java-ee 7 in the first line. If you are running tomcat you are not running java-ee 7. And just adding weld as a dependency does not make CDI available in tomcat if I remember correctly (and sort of confirmed by https://stackoverflow.com/questions/18995951/how-to-install-and-use-cdi-on-tomcat a beans.xml is still needed. No idea if this Q/A contains outdated info, but it confirms to what you see – Kukeltje Dec 27 '19 at 10:07
  • I agree with you that I am not running Java-EE 7 and, I indeed found the solution from exactly the same link you mentioned. But in that link there is no explanation an empty `beans.xml` is still needed and the pertinent *Tomcat* is of version 7. According to my understanding, the configuration of `beans.xml` should be based on the **Weld 3.1.3 spec**, it is not – Rui Dec 27 '19 at 10:17
  • Yes, but it might just be that to trigger CDI in general (not just the scanning of the beans but just to start it) in Tomcat (or other servlet engines) this is just needed. Remove the beans.xml and scan the logs to see if CDI is started at all). Sorry, but this is all I can help with since I (for simplicity around things like this) just by default run a java-ee server – Kukeltje Dec 27 '19 at 10:21
  • I need explanation at length, and I don't think this has any deal with Tomcat but the implementation of CDI in Weld – Rui Dec 27 '19 at 10:23
  • I suspect there is a difference in 'enabling' (bootstrapping) CDI (Weld) in a servlet container and having CDI automatically scan (**after** it has been bootstrapped) the jar/war files. The latter is what your quote refers to, the link is about the former (I think). Since In my java ee applications I can leave the beans.xml out fine (weld is bootstrapped by the container already) I cannot imagine it is the CDI implementation of Weld. What you can try is to not use a beans.xml and see if you can inject a bean in servlet. If that works, it might be JSF related (what is your jsf version?) – Kukeltje Dec 27 '19 at 12:07
  • Thanks a lot :) I definitely will try with the servlet instead of JSF :) – Rui Dec 27 '19 at 12:09

0 Answers0