Identifying and solving javax el PropertyNotFoundException Target Unreachable

Question

When trying to reference a managed bean in EL like so   bean entity property   sometimes a javax el PropertyNotFoundException  Target Unreachable exception is being thrown  usually when a bean property is to be set  or when a bean action is to be invoked   There seem to be five different kinds of messages    Target Unreachable  identifier  bean  resolved to null Target Unreachable   entity  returned null Target Unreachable   null  returned null Target Unreachable    0   returned null Target Unreachable   BracketSuffix  returned null   What do they all mean  How are they caused and how should they be solved

User · Answer

For those who are still stuck     Using NetBeans 8 1 and GlassFish 4 1 with CDI  for some reason I had this issue only locally  not on the remote server  What did the trick   -  using javaee-web-api 7 0 instead of the default pom version provided by NetBeans  which is javaee-web-api 6 0  so    lt dependency gt       lt groupId gt javax lt  groupId gt       lt artifactId gt javaee-web-api lt  artifactId gt       lt version gt 7 0 lt  version gt       lt scope gt provided lt  scope gt       lt type gt jar lt  type gt   lt  dependency gt    -  upload this javaee-web-api-7 0 jar as a lib to on the server  lib folder in the domain1 folder  and restart the server

User · Answer

1  Target Unreachable  identifier  bean  resolved to null This boils down to that the managed bean instance itself could not be found by exactly that identifier  managed bean name  in EL like so   bean   Identifying the cause can be broken down into three steps  a  Who s managing the bean  b  What s the  default  managed bean name  c  Where s the backing bean class  1a  Who s managing the bean  First step would be checking which bean management framework is responsible for managing the bean instance  Is it CDI via  Named  Or is it JSF via  ManagedBean  Or is it Spring via  Component  Can you make sure that you re not mixing multiple bean management framework specific annotations on the very same backing bean class  E g   Named  ManagedBean   Named  Component  or  ManagedBean  Component  This is wrong  The bean must be managed by at most one bean management framework and that framework must be properly configured  If you already have no idea which to choose  head to Backing beans   ManagedBean  or CDI Beans   Named   and Spring JSF integration  how to inject a Spring component service in JSF managed bean  In case it s CDI who s managing the bean via  Named  then you need to make sure of the following   CDI 1 0  Java EE 6  requires an  WEB-INF beans xml file in order to enable CDI in WAR  It can be empty or it can have just the following content       lt  xml version  quot 1 0 quot  encoding  quot UTF-8 quot   gt     lt beans xmlns  quot http   java sun com xml ns javaee quot            xmlns xsi  quot http   www w3 org 2001 XMLSchema-instance quot           xsi schemaLocation  quot http   java sun com xml ns javaee                              http   java sun com xml ns javaee beans 1 0 xsd quot  gt     lt  beans gt    CDI 1 1  Java EE 7  without any beans xml  or an empty beans xml file  or with the above CDI 1 0 compatible beans xml will behave the same as CDI 1 0  When there s a CDI 1 1 compatible beans xml with an explicit version  quot 1 1 quot   then it will by default only register  Named beans with an explicit CDI scope annotation such as  RequestScoped   ViewScoped   SessionScoped   ApplicationScoped  etc  In case you intend to register all beans as CDI managed beans  even those without an explicit CDI scope  use the below CDI 1 1 compatible  WEB-INF beans xml with bean-discovery-mode  quot all quot  set  the default is bean-discovery-mode  quot annotated quot         lt  xml version  quot 1 0 quot  encoding  quot UTF-8 quot   gt     lt beans xmlns  quot http   xmlns jcp org xml ns javaee quot           xmlns xsi  quot http   www w3 org 2001 XMLSchema-instance quot           xsi schemaLocation  quot http   xmlns jcp org xml ns javaee                               http   xmlns jcp org xml ns javaee beans 1 1 xsd quot           version  quot 1 1 quot  bean-discovery-mode  quot all quot  gt     lt  beans gt    When using CDI 1 1  with bean-discovery-mode  quot annotated quot   default   make sure that you didn t accidentally import a JSF scope such as javax faces bean RequestScoped instead of a CDI scope javax enterprise context RequestScoped  Watch out with IDE autocomplete   When using Mojarra 2 3 0-2 3 2 and CDI 1 1  with bean-discovery-mode  quot annotated quot   default   then you need to upgrade Mojarra to 2 3 3 or newer due to a bug  In case you can t upgrade  then you need either to set bean-discovery-mode  quot all quot  in beans xml  or to put the JSF 2 3 specific  FacesConfig annotation on an arbitrary class in the WAR  generally some sort of an application scoped startup class    When using JSF 2 3 on a Servlet 4 0 container with a web xml declared conform Servlet 4 0  then you need to explicitly put the JSF 2 3 specific  FacesConfig annotation on an arbitrary class in the WAR  generally some sort of an application scoped startup class   This is not necessary in Servlet 3 x   Non-Java EE containers like Tomcat and Jetty doesn t ship with CDI bundled  You need to install it manually  It s a bit more work than just adding the library JAR s   For Tomcat  make sure that you follow the instructions in this answer  How to install and use CDI on Tomcat   Your runtime classpath is clean and free of duplicates in CDI API related JARs  Make sure that you re not mixing multiple CDI implementations  Weld  OpenWebBeans  etc   Make sure that you don t provide another CDI or even Java EE API JAR file along webapp when the target container already bundles CDI API out the box   If you re packaging CDI managed beans for JSF views in a JAR  then make sure that the JAR has at least a valid  META-INF beans xml  which can be kept empty      In case it s JSF who s managing the bean via the since 2 3 deprecated  ManagedBean  and you can t migrate to CDI  then you need to make sure of the following   The faces-config xml root declaration is compatible with JSF 2 0  So the XSD file and the version must at least specify JSF 2 0 or higher and thus not 1 x       lt faces-config       xmlns  quot http   java sun com xml ns javaee quot        xmlns xsi  quot http   www w3 org 2001 XMLSchema-instance quot        xsi schemaLocation  quot http   java sun com xml ns javaee http   java sun com xml ns javaee web-facesconfig 2 0 xsd quot        version  quot 2 0 quot  gt   For JSF 2 1  just replace 2 0 and 2 0 by 2 1 and 2 1 respectively  If you re on JSF 2 2 or higher  then make sure you re using xmlns jcp org namespaces instead of java sun com over all place       lt faces-config       xmlns  quot http   xmlns jcp org xml ns javaee quot        xmlns xsi  quot http   www w3 org 2001 XMLSchema-instance quot        xsi schemaLocation  quot http   xmlns jcp org xml ns javaee http   xmlns jcp org xml ns javaee web-facesconfig 2 2 xsd quot        version  quot 2 2 quot  gt   For JSF 2 3  just replace 2 2 and 2 2 by 2 3 and 2 3 respectively   You didn t accidentally import javax annotation ManagedBean instead of javax faces bean ManagedBean  Watch out with IDE autocomplete  Eclipse is known to autosuggest the wrong one as first item in the list   You didn t override the  ManagedBean by a JSF 1 x style  lt managed-bean gt  entry in faces-config xml on the very same backing bean class along with a different managed bean name  This one will have precedence over  ManagedBean  Registering a managed bean in faces-config xml is not necessary since JSF 2 0  just remove it   Your runtime classpath is clean and free of duplicates in JSF API related JARs  Make sure that you re not mixing multiple JSF implementations  Mojarra and MyFaces   Make sure that you don t provide another JSF or even Java EE API JAR file along webapp when the target container already bundles JSF API out the box  See also  quot Installing JSF quot  section of our JSF wiki page for JSF installation instructions  In case you intend to upgrade container-bundled JSF from the WAR on instead of in container itself  make sure that you ve instructed the target container to use WAR-bundled JSF API impl   If you re packaging JSF managed beans in a JAR  then make sure that the JAR has at least a JSF 2 0 compatible  META-INF faces-config xml  See also How to reference JSF managed beans which are provided in a JAR file   If you re actually using the jurassic JSF 1 x  and you can t upgrade  then you need to register the bean via  lt managed-bean gt  in faces-config xml instead of  ManagedBean  Don t forget to fix your project build path as such that you don t have JSF 2 x libraries anymore  so that the  ManagedBean annotation wouldn t confusingly successfully compile      In case it s Spring who s managing the bean via  Component  then you need to make sure of the following   Spring is being installed and integrated as per its documentation  Importantingly  you need to at least have this in web xml       lt listener gt         lt listener-class gt org springframework web context ContextLoaderListener lt  listener-class gt     lt  listener gt   And this in faces-config xml       lt application gt         lt el-resolver gt org springframework web jsf el SpringBeanFacesELResolver lt  el-resolver gt     lt  application gt     above is all I know with regard to Spring     I don t do Spring     feel free to edit comment with other probable Spring related causes  e g  some XML configuration related trouble     In case it s a repeater component who s managing the  nested  bean via its var attribute  e g   lt h dataTable var  quot item quot  gt    lt ui repeat var  quot item quot  gt    lt p tabView var  quot item quot  gt   etc  and you actually got a  quot Target Unreachable  identifier  item  resolved to null quot   then you need to make sure of the following   The   item  is not referenced in binding attribtue of any child component  This is incorrect as binding attribute runs during view build time  not during view render time  Moreover  there s physically only one component in the component tree which is simply reused during every iteration round  In other words  you should actually be using binding  quot   bean component  quot  instead of binding  quot   item component  quot   But much better is to get rid of component bining to bean altogether and investigate ask the proper approach for the problem you thought to solve this way  See also How does the   39 binding  39  attribute work in JSF  When and how should it be used     1b  What s the  default  managed bean name  Second step would be checking the registered managed bean name  JSF and Spring use conventions conform JavaBeans specification while CDI has exceptions depending on CDI impl version   A FooBean backing bean class like below       Named   public class FooBean     will in all bean management frameworks have a default managed bean name of   fooBean   as per JavaBeans specification   A FOOBean backing bean class like below       Named   public class FOOBean     whose unqualified classname starts with at least two capitals will in JSF and Spring have a default managed bean name of exactly the unqualified class name   FOOBean   also conform JavaBeans specificiation  In CDI  this is also the case in Weld versions released before June 2015  but not in Weld versions released after June 2015  2 2 14 2 3 0 B1 3 0 0 A9  nor in OpenWebBeans due to an oversight in CDI spec  In those Weld versions and in all OWB versions it is only with the first character lowercased   fOOBean    If you have explicitly specified a managed bean name foo like below       Named  quot foo quot     public class FooBean     or equivalently with  ManagedBean name  quot foo quot   or  Component  quot foo quot    then it will only be available by   foo  and thus not by   fooBean      1c  Where s the backing bean class  Third step would be doublechecking if the backing bean class is at the right place in the built and deployed WAR file  Make sure that you ve properly performed a full clean  rebuild  redeploy and restart of the project and server in case you was actually busy writing code and impatiently pressing F5 in the browser  If still in vain  let the build system produce a WAR file  which you then extract and inspect with a ZIP tool  The compiled  class file of the backing bean class must reside in its package structure in  WEB-INF classes  Or  when it s packaged as part of a JAR module  the JAR containing the compiled  class file must reside in  WEB-INF lib and thus not e g  EAR s  lib or elsewhere  If you re using Eclipse  make sure that the backing bean class is in src and thus not WebContent  and make sure that Project  gt  Build Automatically is enabled  If you re using Maven  make sure that the backing bean class is in src main java and thus not in src main resources or src main webapp  If you re packaging the web application as part of an EAR with EJB WAR s   then you need to make sure that the backing bean classes are in WAR module and thus not in EAR module nor EJB module  The business tier  EJB  must be free of any web tier  WAR  related artifacts  so that the business tier is reusable across multiple different web tiers  JSF  JAX-RS  JSP Servlet  etc    2  Target Unreachable   entity  returned null This boils down to that the nested property entity as in   bean entity property  returned null  This usually only exposes when JSF needs to set the value for property via an input component like below  while the   bean entity  actually returned null   lt h inputText value  quot   bean entity property  quot    gt   You need to make sure that you have prepared the model entity beforehand in a  PostConstruct  or  lt f viewAction gt  method  or perhaps an add   action method in case you re working with CRUD lists and or dialogs on same view   Named  ViewScoped public class Bean        private Entity entity      getter  setter is not necessary         Inject     private EntityService entityService        PostConstruct     public void init                In case you re updating an existing entity          entity   entityService getById entityId               Or in case you want to create a new entity          entity   new Entity                         As to the importance of  PostConstruct  doing this in a regular constructor would fail in case you re using a bean management framework which uses proxies  such as CDI  Always use  PostConstruct to hook on managed bean instance initialization  and use  PreDestroy to hook on managed bean instance destruction   Additionally  in a constructor you wouldn t have access to any injected dependencies yet  see also NullPointerException while trying to access  Inject bean in constructor  In case the entityId is supplied via  lt f viewParam gt   you d need to use  lt f viewAction gt  instead of  PostConstruct  See also When to use f viewAction   preRenderView versus PostConstruct  You also need to make sure that you preserve the non-null model during postbacks in case you re creating it only in an add   action method  Easiest would be to put the bean in the view scope  See also How to choose the right bean scope   3  Target Unreachable   null  returned null This has actually the same cause as  2  only the  older  EL implementation being used is somewhat buggy in preserving the property name to display in the exception message  which ultimately incorrectly exposed as  null   This only makes debugging and fixing a bit harder when you ve quite some nested properties like so   bean entity subentity subsubentity property   The solution is still the same  make sure that the nested entity in question is not null  in all levels   4  Target Unreachable    0   returned null This has also the same cause as  2  only the  older  EL implementation being used is buggy in formulating the exception message  This exposes only when you use the brace notation    in EL as in   bean collection index   where the   bean collection  itself is non-null  but the item at the specified index doesn t exist  Such a message must then be interpreted as   Target Unreachable   collection 0   returned null  The solution is also the same as  2  make sure that the collection item is available   5  Target Unreachable   BracketSuffix  returned null This has actually the same cause as  4  only the  older  EL implementation being used is somewhat buggy in preserving the iteration index to display in the exception message  which ultimately incorrectly exposed as  BracketSuffix  which is really the character    This only makes debugging and fixing a bit harder when you ve multiple items in the collection   Other possible causes of javax el PropertyNotFoundException   javax el ELException  Error reading   39 foo  39  on type com example Bean javax el ELException  Could not find property actionMethod in class com example Bean javax el PropertyNotFoundException  Property   39 foo  39  not found on type com example Bean javax el PropertyNotFoundException  Property   39 foo  39  not readable on type java lang Boolean javax el PropertyNotFoundException  Property not found on type org hibernate collection internal PersistentSet Outcommented Facelets code still invokes EL expressions like   bean action    and causes javax el PropertyNotFoundException on   bean action

User · Answer

I decided to share my solution  because although many answers provided here were helpful  I still had this problem  In my case  I am using JSF 2 3  jdk10  jee8  cdi 2 0 for my new project and I did run my app on wildfly 12  starting server with parameter standalone sh -Dee8 preview mode true as recommended on wildfly website  The problem with  bean resolved to null    disappeared after downloading wildfly 13  Uploading exactly the same war to wildfly 13 made it all work

User · Answer

As for  2  in my case it magically came to life after replacing    lt body gt    tag with    lt h body gt    After having done several  simpler  to be honest  JSF projects  I couldn t remember of doing anything different setting it up now  and I got this kind of error for the first time  I was making a very basic login page  username  password  user Bean     and set up everything like usual  The only difference I spotted is tags aforementioned  Maybe someone finds this useful

User · Answer

The issue in my case was I included a constructor taking parameters but not an empty constructor with the Inject annotation  like so     Inject public VisitorBean        I just tested it without any constructor and this appears to work also

User · Answer

I decided to share my finding on this error after resolving it myself   First of all  BalusC solutions should be taken seriously but then there is another likely issue in Netbeans to be aware of especially when building an Enterprise Application Project EAR  using Maven   Netbeans generates  a parent POM file  an EAR project  an EJB project and a WAR project   Everything else in my project was fine  and I almost assumed the problem is a bug in probably GlassFish 4 0 I had to install and plug it into Netbeans  because GlassFish 4 1 has a Weld CDI bug which makes the embedded GlassFish 4 1 in Netbeans 8 0 2 unusable except through a patch   Solution   To resolve the  Target Unreachable  identifier  bean  resolved to null  error-  I Right-click the parent POM project  and select Properties  A Project Properties Dialog appears  click  Sources   you will be surprised to see the  Source Binary Format  set to 1 5 and  Encoding  set to Windows 1250  Change the  Source Binary Format  to 1 6 0r 1 7  whichever you prefer to make your project CDI compliant  and  Encoding  to UTF-8    Do the same for all the other subprojects EAR  EJB  WAR  if they are not already compartible  Run your project  and you won t get that error again    I hope this helps someone out there having similar error

User · Answer

In my case  I commited a spell mistake in  Named  beanName    it was suppose to be  beanName   but I wrote  beanNam   for example

User · Answer

I got stuck on this error because in the class that has the  SpringBootApplication I forgot to specify the controller s package name   I wanted to be more specific this time pointing out which components Spring had to scan  instead of configuring the base package   It was like this    ComponentScan basePackages     br com company project repository    br com company project service     But the correct form is one of these    ComponentScan basePackages     br com company project repository    br com company project service    br com company project controller      ComponentScan basePackages     br com company project    I decided to share my solution  because although the correct answer is very comprehensive  it doesn t cover this  idiotic  mistake

User · Answer

I had the same problem  The solution turned out to be much simpler  It appears that a datatable wants the method in the form of a getter  ie getSomeMethod    not just someMethod    In my case in the  datatable I was calling findResults  I changed the method in my backing bean to getFindResults   and it worked    A commandButton worked find without the get which served to make it only more confusing

User · Answer

Another clue  I was using JSF  and added mvn dependencies                       com sun faces             jsf-api             2 2 11                lt dependency gt           lt groupId gt com sun faces lt  groupId gt           lt artifactId gt jsf-impl lt  artifactId gt           lt version gt 2 2 11 lt  version gt       lt  dependency gt    Then  I tried to change to Primefaces  and add primefaces dependency    lt dependency gt       lt groupId gt org primefaces lt  groupId gt       lt artifactId gt primefaces lt  artifactId gt       lt version gt 6 0 lt  version gt   lt  dependency gt    I changed my xhtml from h  to p   adding xmlns p  http   primefaces org ui to the template  Only with JSF the proyect was running ok  and the managedbean was reached ok  When I add Primefaces I was getting the unreachable object  javax el propertynotfoundexception   The problem was that JSF was generating the ManagedBean  not Primefaces  and I was asking primefaces for the object  I had to delete jsf-impl from my  pom  clean and install the proyect  All went ok from this point  Hope that helps

User · Answer

In my case  el-ri-1 0 jar  was missing

User · Answer

It can also be a bug in Mojarra 2 3 https   github com eclipse-ee4j mojarra issues 4734

User · Answer

EL interprets   bean propretyName  as described - the propertyName becomes getPropertyName   on the assumption you are using explicit or implicit methods of generating getter setters  You can override this behavior by explicitly identifying the name as a function    bean methodName    This calls the function method Name   directly without modification     It isn t always true that your  accessors are named  get

User · Answer

When I remove AnnotationConfigWebApplicationContext context param from web xml file This is work   If you have got like param which as shown below you must remove it from web xml file   lt context-param gt       lt param-name gt contextClass lt  param-name gt       lt param-value gt        org springframework web context support AnnotationConfigWebApplicationContext    lt  param-value gt   lt  context-param gt

User · Answer

Working with JSF in the old style You have to define the managed bean in the  beans-config xml file  located in the WEB-INF folder  and make a reference to it in the web xml file  this way   beans-config xml   lt managed-bean gt     lt managed-bean-name gt  the name by wich your backing bean will be referenced  lt  managed-bean-name gt     lt managed-bean-class gt  your backing bean fully qualified class name  lt  managed-bean-class gt     lt managed-bean-scope gt session lt  managed-bean-scope gt       lt  managed-bean gt     I ve tried using other scopes  but       web xml   lt context-param gt     lt param-name gt javax faces CONFIG FILES lt  param-name gt     lt param-value gt   WEB-INF beans-config xml lt  param-value gt   lt  context-param gt

User · Answer

I am using wildfly 10 for javaee container   I had experienced  Target Unreachable   entity  returned null  issue  Thanks for suggestions by BalusC but the my issue out of the solutions explained   Accidentally using  import com sun istack logging Logger   instead of  import org jboss logging Logger   caused CDI implemented JSF EL  Hope it helps to improve solution

User · Answer

For 1  topic  Target Unreachable  identifier  bean  resolved to null    I checked valuable answers the  BalusC and the other sharers but I exceed the this problem like this on my scenario  After the creating a new xhtml with different name and creating bean class with different name then I wrote  not copy-paste  the codes step by step to the new bean class and new xhtml file

[jsf] Identifying and solving javax.el.PropertyNotFoundException: Target Unreachable

Examples related to jsf

Examples related to cdi

Examples related to el

Examples related to managed-bean

Examples related to propertynotfoundexception