After switching @ManagedBean to @Named: javax.el.PropertyNotFoundException: Target Unreachable, identifier 'person' resolved to null [duplicate]
Asked Answered
H

3

3

I am just testing out this JSF page, so I don't set the action attribute in the <h:commandButton/>. This is a very simple form with 3 input boxes for First Name, Last Name, and Email, and one button called Save. Every time I click that button, I receive this error

javax.el.PropertyNotFoundException: /index.xhtml @19,106 value="#{person.firstName}": Target Unreachable, identifier 'person' resolved to null

but if I annotate my JavaBean @ManagedBean, then the form go through just fine, but every time I switch back to using @Named Bean, I receive that error again. I have tried some of the suggestions I found on this site such as restarting the server, checking the presence of the getters, but those did not help.

<?xml version='1.0' encoding='UTF-8' ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
      xmlns:h="http://java.sun.com/jsf/html"
      xmlns:f="http://java.sun.com/jsf/core">
    <h:head>
        <meta charset="UTF-8" />
        <title>Simple Form Created Using Facelets</title>
    </h:head>

    <h:body>
        <h:messages/>
        <h:form>
            <h:panelGrid columns="2" columnClasses="rightColumn, leftColumn">

                <h:outputLabel for="firstName" value="First Name:" />
                <h:inputText id="firstName" value="#{person.firstName}"
                             label="First Name"/>

                <h:outputLabel for="lastName" value="Last Name:" />
                <h:inputText id="lastName" value="#{person.lastName}" label="Last Name"/>

                <h:outputLabel for="email" value="Email:"/>
                <h:inputText id="email" value="#{person.email}" label="Email" />

                <h:panelGroup />
                <h:commandButton value="Submit"/>
            </h:panelGrid>
        </h:form>
    </h:body>
</html>

This is my JavaBean class

import javax.annotation.PostConstruct;
import javax.faces.bean.RequestScoped;
import javax.inject.Named;

@Named
@RequestScoped
public class Person {

    private String firstName = "empty";
    private String lastName = "empty";
    private String email = "empty";

    public void Person() {}

    public String getFirstName() {
        return firstName;
    }

    public void setFirstName(String firstName) {
        this.firstName = firstName;
    }

    public String getLastName() {
        return lastName;
    }

    public void setLastName(String lastName) {
        this.lastName = lastName;
    }

    public String getEmail() {
        return email;
    }

    public void setEmail(String email) {
        this.email = email;
    }
}

This is the web.xml file.

<?xml version="1.0" encoding="UTF-8"?>
<web-app version="3.1" 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/web-app_3_1.xsd">

    <context-param>
        <param-name>javax.faces.PROJECT_STAGE</param-name>
        <param-value>Development</param-value>
    </context-param>

    <servlet>
        <servlet-name>Faces Servlet</servlet-name>
        <servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
        <load-on-startup>1</load-on-startup>
    </servlet>

    <servlet-mapping>
        <servlet-name>Faces Servlet</servlet-name>
        <url-pattern>/faces/*</url-pattern>
    </servlet-mapping>

    <session-config>
        <session-timeout>
            30
        </session-timeout>
    </session-config>

    <welcome-file-list>
        <welcome-file>faces/index.xhtml</welcome-file>
    </welcome-file-list>
</web-app>
Hurff answered 16/4, 2015 at 7:9 Comment(17)
Oh, I forgot to mention, it is GlassFish 4.1Hurff
Should indeed just work out the box in a Java EE 7 container. Do you have a /WEB-INF/beans.xml?Copalm
No, I don't. That's what I thought tooHurff
The RequestScoped should be javax.enterprise.context.RequestScoped for CDI. Do not mix the JSF scope and CDI scope.Amberjack
@Charlee That's correct (I already wanted to side-remark this in my answer, if any), but this is not the cause of that problem. A scope-less CDI bean defaults in a JSF page to request scope already.Copalm
@Copalm I totally agree with you.Amberjack
@BalusC, why do I need the beans.xml file to get CDI Bean to work ?Hurff
It's likely another GF4 bug. Have you tried removing all the config files web.xml, faces-config.xml and beans.xml so that bare defaults are used?Copalm
@Copalm No I have not, I tried creating the faces-config.xml file, but it did not solve the problem until I added the beans.xml, but if I removed the beans.xml, I got that errorHurff
Do you have any JARs in /WEB-INF/lib?Copalm
@Copalm I don't even have that lib folder, I just added the JSF jar file by right clicking the Libraries section in Netbeans, but that did not make any difference since GlassFish has that jar toosHurff
You should indeed not have any.Copalm
I had been using GlassFish Server 4.0 for a long time until I upgraded GlassFish to 4.1 a few months ago and I have been using GlassFish Server 4.1 since then. No beans.xml was ever needed explicitly in both 4.0 and 4.1. (The application has already traversed through all Mojarra 2.2.x versions alternatively - starting from Mojarra 2.2.0 to 2.3.0-m01).Stuppy
@Copalm @Stuppy I don't know what is going with my GS, the standard resource location is not working for me either. I test a dummy script file, put it in a scripts subfolder under the resources folder, and the resources folder is under META-INF and then at the application root using <h:outputScript />, but I keep getting Unable to find resource . My structure is like this, JavaServerFaces is the parent directory where all other folders are located, then in it, there is the resources folder, inside the resources folder is the scripts sub folder where the script file is storedHurff
Slip the resources folder directly into the web application root. (META-INF is meant for a standalone module in a separately packaged JAR file which finally ends up in /WEB-INF/lib in the associated WAR).Stuppy
@Stuppy Yeah, I have done that too, I have the resources folder in the JavaServerFaces parent folder, and the resources folder is then sub-divided into smaller folders for better resource organizing, in this case, I hate the scripts sub-folder which contains a dummy javascript file. Aghh, so frustrating, I don't know what is wrong with my GSHurff
You may want to look into this answer in case you might accidentally be missing something. Perhaps, something along the line <h:outputScript library="..." name="..." /> is going wrong. And please do not forget to hard-deploy the application at least once after these changes have been made. If the problem still persists, you may want to put a separate question.Stuppy
H
1

This is the best answer to my problem LINK . Also, cdi-1.2 jar file is not available in GS 4.1 for some reason, that is why the package javax.enterprise.* was not present in my Netbeans, I had to manually download that jar from http://cdi-spec.org/. Now everything works fine including DI. And I did not have to create any configuration files to get it to work either.

Hurff answered 18/4, 2015 at 23:48 Comment(2)
It is available in GlassFish 4.1 as obvious which is already a Java EE compliant-container but those classes are packaged under a library named Java EE 7 API Library containing a single large JAR file named javaee-api-7.0.jar. You can add that library to the compile-time class-path of your web module as and when required. There is no need to add the CDI library separately as needed in bare-bones Servlet containers like Apache Tomcat, Eclipse Jetty.Stuppy
The reason CDI 1.2 jar isn't available in GlassFish 4.1 is because it packages CDI 1.1.Shortening
B
1

The main problem is that your using JSF annotations instead of CDI annoations. To fix that, change the import:

import javax.faces.bean.RequestScoped;

to

import javax.enterprise.context.RequestScoped;

However, another solution is to create a beans.xml file.

To do that, create one in the WEB-INF folder with the following content:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://java.sun.com/xml/ns/javaee"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/beans_1_0.xsd">
</beans>

The presence of a beans.xml file signals the servlet container that the application uses JSR-299 (Contexts and Dependency Injection) - without it, the application's classes will not be scanned for CDI annotations either and dependency injection will not be performed. If you don't use CDI (e.g. you only use plain JSF managed beans), you don't need beans.xml.

See also:

Bradfield answered 16/4, 2015 at 10:10 Comment(3)
Uh! Java EE 7 (GlassFish 4.1). beans.xml is unnecessary unless explicitly needed.Stuppy
Hey, it works. Why is that? Doesn't the Java EE specs state that the configuration files are optional?Hurff
Sorry, I think this is more of a hack rather a permanent solution.Hurff
S
1

You need to change your request scoped annotation from faces to CDI.

The reason being is if you look at your annotations

import javax.annotation.PostConstruct;
import javax.faces.bean.RequestScoped;
import javax.inject.Named;

@Named
@RequestScoped

None of these are CDI "bean defining annotations" so if you're using bean-discovery-mode="annotated" it's not going to work for you.

Shortening answered 16/4, 2015 at 10:50 Comment(2)
Because it didn't explain anything. Explain how to fish instead of only giving the fish.Copalm
I know the question is old but... In your beans.xml change annotated to all. It should fix the problem, at least it did with my error.Epagoge
H
1

This is the best answer to my problem LINK . Also, cdi-1.2 jar file is not available in GS 4.1 for some reason, that is why the package javax.enterprise.* was not present in my Netbeans, I had to manually download that jar from http://cdi-spec.org/. Now everything works fine including DI. And I did not have to create any configuration files to get it to work either.

Hurff answered 18/4, 2015 at 23:48 Comment(2)
It is available in GlassFish 4.1 as obvious which is already a Java EE compliant-container but those classes are packaged under a library named Java EE 7 API Library containing a single large JAR file named javaee-api-7.0.jar. You can add that library to the compile-time class-path of your web module as and when required. There is no need to add the CDI library separately as needed in bare-bones Servlet containers like Apache Tomcat, Eclipse Jetty.Stuppy
The reason CDI 1.2 jar isn't available in GlassFish 4.1 is because it packages CDI 1.1.Shortening

© 2022 - 2024 — McMap. All rights reserved.