Target Unreachable, identifier in JSF 2.2 [duplicate] - spring

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?

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:
<?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>
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="1.1", 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="all" set (the default is bean-discovery-mode="annotated").
<?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_1_1.xsd"
version="1.1" bean-discovery-mode="all">
</beans>
When using CDI 1.1+ with bean-discovery-mode="annotated" (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="annotated" (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="all" 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.
When using CDI 3.0, the first version with package renamed from javax.* to jakarta.*, then you need to ensure that all deployment descriptor files beans.xml, web.xml, faces-config.xml are conform the new jakartaee schemas and thus not conform the old javaee schemes.
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="https://jakarta.ee/xml/ns/jakartaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="https://jakarta.ee/xml/ns/jakartaee
https://jakarta.ee/xml/ns/jakartaee/beans_3_0.xsd"
version="3.0" bean-discovery-mode="all">
</beans>
Non-JEE 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.
<faces-config
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/web-facesconfig_2_0.xsd"
version="2.0">
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.
<faces-config
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-facesconfig_2_2.xsd"
version="2.2">
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 <managed-bean> 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 "Installing JSF" 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 <managed-bean> 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:
<listener>
<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>
And this in faces-config.xml:
<application>
<el-resolver>org.springframework.web.jsf.el.SpringBeanFacesELResolver</el-resolver>
</application>
(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. <h:dataTable var="item">, <ui:repeat var="item">, <p:tabView var="item">, etc) and you actually got a "Target Unreachable, identifier 'item' resolved to null", 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="#{bean.component}" instead of binding="#{item.component}". 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 'binding' 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("foo")
public class FooBean {}
or equivalently with #ManagedBean(name="foo") or #Component("foo"), 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 > 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.
<h:inputText value="#{bean.entity.property}" />
You need to make sure that you have prepared the model entity beforehand in a #PostConstruct, or <f:viewAction> 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 <f:viewParam>, you'd need to use <f:viewAction> 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 'foo' on type com.example.Bean
javax.el.ELException: Could not find property actionMethod in class com.example.Bean
javax.el.PropertyNotFoundException: Property 'foo' not found on type com.example.Bean
javax.el.PropertyNotFoundException: Property 'foo' 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}

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:
<dependency>
<groupId>javax</groupId>
<artifactId>javaee-web-api</artifactId>
<version>7.0</version>
<scope>provided</scope>
<type>jar</type>
</dependency>
-> 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.

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.

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.

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 :)

It can also be a bug in Mojarra 2.3 https://github.com/eclipse-ee4j/mojarra/issues/4734

In my case, I commited a spell mistake in #Named("beanName"), it was suppose to be "beanName", but I wrote "beanNam", for example.

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 .

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.

As for #2, in my case it magically came to life after replacing
<body>
tag with
<h:body>
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.

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.

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.

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
<context-param>
<param-name>contextClass</param-name>
<param-value>
org.springframework.web.context.support.AnnotationConfigWebApplicationContext
</param-value>
</context-param>

First at all, I work with: Eclipse, Weblogic, CDI, JSF, PrimeFaces. If you too, maybe my solution could help you.
In my case, the reason of the error was a little setting on "Eclipse".
Check this:
Right click over your Weblogic server on "Servers" tab
Select "Properties"
In the new little window of Properties, expand "Weblogic" menu
Inside "Weblogic" menu, clic over "Publishing" option
Now, on the right side, be sure that option "Publish as an exploded archive" is checked.
In my case, I had checked "Publish as a virtual application", so, changing that I solved "Target Unreachable" error.

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
<managed-bean>
<managed-bean-name>"the name by wich your backing bean will be referenced"</managed-bean-name>
<managed-bean-class>"your backing bean fully qualified class name"</managed-bean-class>
<managed-bean-scope>session</managed-bean-scope>
</managed-bean>
(I've tried using other scopes, but ...)
web.xml
<context-param>
<param-name>javax.faces.CONFIG_FILES</param-name>
<param-value>"/WEB-INF/beans-config.xml</param-value>
</context-param>

Another clue:
I was using JSF, and added mvn dependencies:
com.sun.faces
jsf-api
2.2.11
<dependency>
<groupId>com.sun.faces</groupId>
<artifactId>jsf-impl</artifactId>
<version>2.2.11</version>
</dependency>
Then, I tried to change to Primefaces, and add primefaces dependency:
<dependency>
<groupId>org.primefaces</groupId>
<artifactId>primefaces</artifactId>
<version>6.0</version>
</dependency>
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.

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...".

In my case "el-ri-1.0.jar" was missing.

Related

CDI Bean recreated on every <h:inputtext>ajax call [duplicate]

This doesn't seem right. I was doing some cleanup of my code and I just noticed this. Every ajax request is firing the constructor and #PostConstruct of my #ViewScoped bean. Even a simple database pagination is firing it.
I understood that #ViewScoped is longer than #RequestScoped and that it shouldn't be reconstructed on every request. Only after a complete page reload by GET.
In other words, your #ViewScoped bean behaves like a #RequestScoped bean. It's been recreated from scratch on every postback request. There are many possible causes for this, most of which boils down that the associated JSF view is not available anymore in the JSF state which in turn is by default associated with the HTTP session.
Provided that you can assure that the HTTP session itself is not the root cause of the problem, i.e. when #SessionScoped works absolutely fine, then walk through the below list of possible causes. Otherwise, if the HTTP session itself is also trashed and recreated on every single request, then you need to take a step back and look at session cookie and server configuration. Any cause related to a broken HTTP session is at least beyond the context of JSF.
You're using Mojarra 2.1.17 or older, and the view contains EL expressions which bind a view scoped bean property to a tag attribute which is evaluated during view build time. Examples are JSTL <c:if>, <c:forEach>, etc or JSF <ui:include>, <x:someComponent id="#{...}", <x:someComponent binding="#{...}">, etc. This is caused by a bug in Mojarra (issue 1496). See also Why does #PostConstruct callback fire every time even though bean is #ViewScoped? JSF
This is already fixed in Mojarra version 2.1.18. If you can't upgrade to a newer version, the workaround is to disable partial state saving as below in web.xml, see also JSTL in JSF2 Facelets... makes sense?
<context-param>
<param-name>javax.faces.PARTIAL_STATE_SAVING</param-name>
<param-value>false</param-value>
</context-param>
Or when you want to target a specific set of JSF views only:
<context-param>
<param-name>javax.faces.FULL_STATE_SAVING_VIEW_IDS</param-name>
<param-value>/foo.xhtml;/bar.xhtml;/folder/baz.xhtml</param-value>
</context-param>
Important to mention is that binding the value of JSF component's id or binding attribute to a view scoped bean property is a bad practice. Those should really be bound to a request scoped bean property, or an alternative should be sought. See also How does the 'binding' attribute work in JSF? When and how should it be used?
You're using Mojarra 2.2.0, only that version has a (yet unknown) bug in maintaining the view scope which is already fixed in 2.2.1, see also issue 2916. Solution is to upgrade to a newer version.
The #ViewScoped annotation is imported from the wrong package. JSF offers two #ViewScoped annotations, one from javax.faces.bean package for JSF managed beans annotated with #ManagedBean, and another one from javax.faces.view package for CDI managed beans annotated with #Named. When the bean scope annotation does not match the bean management annotation, then the actual bean scope will become the bean management framework's default scope, which is #RequestScoped in JSF managed beans and #Dependent in CDI managed beans.
You need to ensure that you have either of the following constructs and don't mix them, see also #ViewScoped bean recreated on every postback request when using JSF 2.2.
import javax.faces.bean.ManagedBean;
import javax.faces.bean.ViewScoped;
#ManagedBean
#ViewScoped
public class CorrectJSFViewScopedBean implements Serializable {
import javax.inject.Named;
import javax.faces.view.ViewScoped;
#Named
#ViewScoped
public class CorrectCDIViewScopedBean implements Serializable {
The view is (accidentally?) marked transient via <f:view transient="true">. This basically turns on "stateless JSF", which is new since Mojarra 2.1.19. Hereby the JSF view simply won't be saved in the JSF state at all and logical consequence is that all referenced view scoped beans can't be associated with the JSF view anymore. See also What is the usefulness of statelessness in JSF?
The web application is configured with com.sun.faces.enableRestoreView11Compatibility context param set to true in an incorrect attempt to "avoid" ViewExpiredException. With this context param, the ViewExpiredException will never be thrown, but the view (and all associated view scoped beans) will just be recreated from scratch. However, if that happens on every request, then this approach actually hides another problem: the views expire way too soon. This indicates a possible problem in maintaining the JSF view states and/or the HTTP session. How to solve/configure that properly, head to javax.faces.application.ViewExpiredException: View could not be restored.
The web application's runtime classpath is polluted with multiple different versioned JSF API or impl related classes. This causes a corruption/mismatch in the identifiers/markers for the JSF view state. You need to make sure you don't have multiple JSF API JAR files in webapp's /WEB-INF/lib. In case you're using Maven, make carefully sure that you mark server-provided libraries as <scope>provided</scope>. See also "Installing JSF" section in our JSF wiki page and the answer to this related question: How to properly install and configure JSF libraries via Maven?.
When you're using PrimeFaces <p:dialog>, then make sure that the <p:dialog> has its own <h:form> and that it is not nested in another <h:form>. See also p:fileUpload inside p:dialog losing #ViewScoped values.
When you're combining PrimeFaces FileUploadFilter with PrettyFaces, then make sure that the FileUploadFilter also runs on PrettyFaces-rewritten/forwarded requests. See also ViewScoped bean rebuilt when FileUploadListener called using PrettyFaces and How to use PrimeFaces p:fileUpload? Listener method is never invoked or UploadedFile is null / throws an error / not usable.
When you're using PrettyFaces, a badly configured rewrite rule which redirects CSS/JS/image resources to a JSF page tied to a #ViewScoped bean will also give misleading behavior. See also CDI ViewScope & PrettyFaces: Multiple calls to #PostConstruct (JSF 2.2).

faces-config.xml and Target Unreachable [duplicate]

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?
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:
<?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>
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="1.1", 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="all" set (the default is bean-discovery-mode="annotated").
<?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_1_1.xsd"
version="1.1" bean-discovery-mode="all">
</beans>
When using CDI 1.1+ with bean-discovery-mode="annotated" (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="annotated" (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="all" 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.
When using CDI 3.0, the first version with package renamed from javax.* to jakarta.*, then you need to ensure that all deployment descriptor files beans.xml, web.xml, faces-config.xml are conform the new jakartaee schemas and thus not conform the old javaee schemes.
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="https://jakarta.ee/xml/ns/jakartaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="https://jakarta.ee/xml/ns/jakartaee
https://jakarta.ee/xml/ns/jakartaee/beans_3_0.xsd"
version="3.0" bean-discovery-mode="all">
</beans>
Non-JEE 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.
<faces-config
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/web-facesconfig_2_0.xsd"
version="2.0">
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.
<faces-config
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-facesconfig_2_2.xsd"
version="2.2">
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 <managed-bean> 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 "Installing JSF" 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 <managed-bean> 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:
<listener>
<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>
And this in faces-config.xml:
<application>
<el-resolver>org.springframework.web.jsf.el.SpringBeanFacesELResolver</el-resolver>
</application>
(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. <h:dataTable var="item">, <ui:repeat var="item">, <p:tabView var="item">, etc) and you actually got a "Target Unreachable, identifier 'item' resolved to null", 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="#{bean.component}" instead of binding="#{item.component}". 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 'binding' 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("foo")
public class FooBean {}
or equivalently with #ManagedBean(name="foo") or #Component("foo"), 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 > 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.
<h:inputText value="#{bean.entity.property}" />
You need to make sure that you have prepared the model entity beforehand in a #PostConstruct, or <f:viewAction> 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 <f:viewParam>, you'd need to use <f:viewAction> 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 'foo' on type com.example.Bean
javax.el.ELException: Could not find property actionMethod in class com.example.Bean
javax.el.PropertyNotFoundException: Property 'foo' not found on type com.example.Bean
javax.el.PropertyNotFoundException: Property 'foo' 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}
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:
<dependency>
<groupId>javax</groupId>
<artifactId>javaee-web-api</artifactId>
<version>7.0</version>
<scope>provided</scope>
<type>jar</type>
</dependency>
-> 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.
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.
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.
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 :)
It can also be a bug in Mojarra 2.3 https://github.com/eclipse-ee4j/mojarra/issues/4734
In my case, I commited a spell mistake in #Named("beanName"), it was suppose to be "beanName", but I wrote "beanNam", for example.
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 .
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.
As for #2, in my case it magically came to life after replacing
<body>
tag with
<h:body>
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.
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.
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.
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
<context-param>
<param-name>contextClass</param-name>
<param-value>
org.springframework.web.context.support.AnnotationConfigWebApplicationContext
</param-value>
</context-param>
First at all, I work with: Eclipse, Weblogic, CDI, JSF, PrimeFaces. If you too, maybe my solution could help you.
In my case, the reason of the error was a little setting on "Eclipse".
Check this:
Right click over your Weblogic server on "Servers" tab
Select "Properties"
In the new little window of Properties, expand "Weblogic" menu
Inside "Weblogic" menu, clic over "Publishing" option
Now, on the right side, be sure that option "Publish as an exploded archive" is checked.
In my case, I had checked "Publish as a virtual application", so, changing that I solved "Target Unreachable" error.
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
<managed-bean>
<managed-bean-name>"the name by wich your backing bean will be referenced"</managed-bean-name>
<managed-bean-class>"your backing bean fully qualified class name"</managed-bean-class>
<managed-bean-scope>session</managed-bean-scope>
</managed-bean>
(I've tried using other scopes, but ...)
web.xml
<context-param>
<param-name>javax.faces.CONFIG_FILES</param-name>
<param-value>"/WEB-INF/beans-config.xml</param-value>
</context-param>
Another clue:
I was using JSF, and added mvn dependencies:
com.sun.faces
jsf-api
2.2.11
<dependency>
<groupId>com.sun.faces</groupId>
<artifactId>jsf-impl</artifactId>
<version>2.2.11</version>
</dependency>
Then, I tried to change to Primefaces, and add primefaces dependency:
<dependency>
<groupId>org.primefaces</groupId>
<artifactId>primefaces</artifactId>
<version>6.0</version>
</dependency>
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.
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...".
In my case "el-ri-1.0.jar" was missing.

JSF beans and serializability issue

I have problem with JSF beans using Spring managed services. I got an error telling, that spring bean used in JSF bean is not serializable.
#ManagedProperty("#{customerService}")
private CustomerService customerService;
I can't make the service serializable, because it is using JdbcTemplate which itself isn't serializable. Moreover, serializing Spring beans which have application scope makes no sense at all, so I don't understand, why someone's code is attempting to serialize them.
I have worked with JSF project using Spring services, and there were no such issues, so such cooperation must be possible. But this project is made from scratch based on example projects, so there must be something wrong with the configuration of spring-JSF cooperation, but I don't know where to search.
The configuration of Spring for JSF is:
<!-- JSF and Spring are integrated -->
<application>
<el-resolver>
org.springframework.web.jsf.el.SpringBeanFacesELResolver
</el-resolver>
</application>
How to solve this issue?
There is no way to avoid JSF serialization mist. Even ApplicationScoped beans are serialized (when they are injected into other beans).
But the solution was made on the Spring side. You have to use scoped proxy.
To wrap the bean into serializable proxy you have to add to bean body:
<aop:scoped-proxy proxy-target-class="true"/>
The spring aop namespace and spring-aop dependency must be added.
http://www.springframework.org/schema/aop http://www.springframework.org/schema/aop/spring-aop-3.0.xsd
And this is it! In the bean will be the serializable element, the proxy that will re-load bean from Spring context on deserialization.
The only mist here is that I have to create cglib class-level-proxy. JRE proxy was not working because the interface was not available during deserialization... I don't understand fully why but I have working solution at least.

WAS 6.1 JDK & Spring Autowiring

By default, autowiring happens by propertyname. It seems if I compile my application with the WAS 6.1 JDK, spring cannot autowire my dependencies by name and then instead reverts to type which is causing an issue because of some ambiguous Validator references in my controllers. The controller properties are all of type Validator and there are 9 validators defined in the context file so spring complains that it finds too many matches. I know one way around this would be to use the actual implementation class as the type for the validator instances in my controller classes, but I want to know if anyone else has encountered this problem with autowiring by name failing when compiled with the WAS 6.1 jdk.

Spring Instantiation and 'unused beans'

I'm working on a project which means customising an existing application (JasperServer 3.7.1) which is implemented in Spring 2.5.6 (plus a host of other Spring frameworks).
The application consists of a host of applicationContext*.xml containing the bean definitions which when wired together by Spring bring the app to life - I think it's a typical Spring app configuration as although it my first experience using Spring, it seems all quite well put together and follows a lot of the examples I have seen on the web and in books..
Because I'm actually modifying an existing application, changing beans like filterChainProxy (because we have our own security model ,for example) I'm wary of changing the actual config files that come with the product - instead, where possible, I'd prefer to add extra appContext config files to the existing ones which override existing beans (ie leave the original config in tact, as much as possible).
This I've managed to do by creating beans implementing BeanFactoryPostProcessor which on pre-bean initialisation allow me to change the existing property values/bean references to custom ones. This all seems to be working fine.
My query is, say I had a bean with a property that referred to another bean, and my overrider bean changed that reference to my own version of bean, will Spring still instantiate the bean that is no longer referred to ? The reason for asking obviously is that some of these unused beans may be taking up resources, which may be an unwanted overhead.
Thanks in advance
I'm not sure I follow your example, but it might help to clarify a few things.
Generally, Spring will instantiate a bean for every non-abstract bean definition in the context (this is ignoring things like non-singleton bean scopes, but I'll ignore that for the purposes of this explanation). If multiple bean definition files are used, and some bean names are duplicated, then some definitions will be overridden by others. so far, so good, this seems to be what you wanted.
Once the bean definitions have been established, and any duplicated dealt with, then Spring will then instantiate a bean for each of those definitions. If you have changed the definition of BeanA so that it no longer refers to BeanB, but instead refers to BeanC, but the definition of BeanB still exists, then BeanB will still be instantiated, even if it's not being used.
If that example is not representative of your question, then please elaborate.

Resources