CDI managed bean in Mojarra 2.3 throws PropertyNotFoundException, Target Unreachable, identifier 'localeBean' resolved to null - jsf

I have problem with bean discovery in JSF 2.3 and CDI application. I am using Glassfish 5.0, Java 8 (1.8.0_151). My files:
faces-config.xml
<?xml version='1.0' encoding='UTF-8'?>
<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_3.xsd"
version="2.3">
</faces-config>
LocaleBean:
import javax.enterprise.context.SessionScoped;
import javax.inject.Named;
#Named
#SessionScoped
public class LocaleBean implements Serializable {
}
Message in Glassfish log after submitting a form to this bean:
javax.el.PropertyNotFoundException: /home.xhtml #15,81 value="#{localeBean.language}": Target Unreachable, identifier 'localeBean' resolved to null
Form submit works only if I use imports listed bellow instead of #Named and #SessionScoped from javax.enterprise.context package.
import javax.faces.bean.ManagedBean;
import javax.faces.bean.SessionScoped;
But both are deprecated in JSF 2.3.
Any ideas guys? Thank you!

I have found solution and its description in this topic on GitHub:
https://github.com/javaserverfaces/mojarra/issues/4264

Related

JSF 2.3 CDI not working on tomcat

I am trying to set up jsf 2.3 on tomcat 8 whenever I used #inject I keep having an error with it I have googled and searched on stackoverflow.com yet I can't find a solution to it. I have already installed CDI (Weld) on it following #BalusC example from here How to install and use CDI on Tomcat? yet I keep having unsatisfied dependency: no bean matches the injection point. I can't figure it out is there anything i am missing?
ConfigurationBean.java
import static javax.faces.annotation.FacesConfig.Version.JSF_2_3;
import javax.faces.annotation.FacesConfig;
#FacesConfig(
// Activates CDI build-in beans
version = JSF_2_3
)
public class ConfigurationBean {
}
beans.xml
<?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>
faces-config.xml
<?xml version='1.0' encoding='UTF-8'?>
<faces-config version="2.3"
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_3.xsd">
</faces-config>
PushBean.java
#Named
#ViewScoped
public class PushBean implements Serializable {
#Inject #Push(channel="counter") //This is where i get the error message unsatisfied dependency: no bean matches the injection point
private PushContext push;
}
For me this code looks fine but am wondering if it is netbeans bug. I tried that without using spring just only tomcat with jsf i still get the same error message. I couldn't find any error message inside the stacktrace.
Spring is NOT a full blown CDI container and only 'knows' the #Named and #Inject annotations and consequently does not (most likely) recognize the #Push annotation as a qualifier and cannot find the bean and throws the error you get (posting an explicit error and stacktrace is btw something you should always do in a question!)
See also:
Inject Instance<Interface> : Spring and CDI compatibility
I'd suggest to check your scopes. The built - in CDI scopes are #ApplicationScoped, #SessionScoped, #ConversationScoped and #RequestScoped . There is no #ViewScoped annotation in CDI.
You can inject the same level or broader scope, but not one which is smaller (e.g you cannot inject #RequestScoped into #SessionScoped bean)

WELD-001303: No active contexts for scope type javax.faces.flow.FlowScoped

Just started doing my first steps with FacesFlow with Glassfish 4.1 (i.e. using Mojarra) and when invoking my flow I get an error named
[SEVERE] [] [javax.enterprise.resource.webcontainer.jsf.application] ... Error Rendering View[/register/register.xhtml]
org.jboss.weld.context.ContextNotActiveException: WELD-001303: No active contexts for scope type javax.faces.flow.FlowScoped
at org.jboss.weld.manager.BeanManagerImpl.getContext(BeanManagerImpl.java:708)
Several others had that error too as I can see in the web but the solutions that worked for other somehow dont work for me (see below).
I also tried #SessionScoped which works. So it is related to #FlowScoped.
To what I read in a book that I use to get me up to speed I should be ok from coding and config end since according to API #FlowScoped is CDI based and I use the following code at my backing bean/controller.
#Named
#FlowScoped(value="register")
public class RegisterController implements Serializable {
I have a flow named register whose pages are located in a dirctory /register and the first page of the flow is named register.xhtml
Following snippet I tried both as a register/register-flow.xml config file as well as WEB-INF/faces-config.xml without success.
<?xml version="1.0" encoding="UTF-8"?>
<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">
<flow-definition id="register">
<flow-return id="overview">
<from-outcome>/index</from-outcome>
</flow-return>
</flow-definition>
</faces-config>
What I tried so far:
I found a post suggesting that <Context antiJARLocking="true" path="/PROJEST_NAME"/> would solve the problem but after googling the tag it turns out its an outdated Tomcat tag.
Changing #Named to #ManagedBean didn't really help as suggested on one page. I could open the pages but the data in my controller class would not be available when invoking the next page of the flow anymore. But #ManagedBean shouldn't really work I guess since #FlowScoped is CDI based.
Another post suggested to ensure that javax.faces.CLIENT_WINDOW_MODE is enabled. I tried that via adding the following to my web.xml but without success
<context-param>
<param-name>javax.faces.CLIENT_WINDOW_MODE</param-name>
<param-value>url</param-value>
</context-param>
Another suggested to use Glassfish 4.x which I already do
Any ideas?
With Glassfish 4.1 at least you need to add the cdi-api.jar directory library.
Glassfish includes the weld-osgi-bundle.jar but it also needs cdi-api.jar to work because the CDI bean scopes aren't in the weld-osgi... so make sure you have it if not its here:
[gf_installation_path]/glassfish/modules/cdi-api.jar
This will give you access to the packages used with CDI Beans i.e., javax.enterprise.context.*
If not then probably
this could help
and this
GL!

Why is a CDI Managed Bean in faces-config.xml not registered as an obersver?

I have implemented a CDI Bean which is observing events from another bean:
#SessionScoped
public class FixedItemController implements Serializable {
....
public void onWorkflowEvent(#Observes WorkflowEvent workflowEvent) throws AccessDeniedException {
logger.info("evaluate event...");
....
}
....
}
This works fine as long as I am using the bean in a JSF page with its default name 'fixedItemController'.
But if I declare another instance of that bean in the faces-config.xml like this:
<managed-bean>
<managed-bean-name>myOrderItemController</managed-bean-name>
<managed-bean-class>org.imixs.marty.workflow.FixedItemController</managed-bean-class>
<managed-bean-scope>session</managed-bean-scope>
<managed-property>
<property-name>childItemProperty</property-name>
<property-class>java.lang.String</property-class>
<value>_orderItems</value>
</managed-property>
</managed-bean>
the second instance (myOrderItemController) is not registered automatically as an observer for my WorkflowEvent.
What can I do, to ensure that my second instance - declared by the faces-config.xml - will be immediately instantiated and registered as an observer to my workitemEvent?
faces-config.xml does not register CDI managed beans. It registers JSF managed beans. Effectively, your #{myOrderItemController} is a JSF managed bean. It's like as if you use #ManagedBean instead of #Named. The JSF bean management facility does not scan for CDI specific #Observes annotation.
Keep it a CDI managed bean. Whatever you tried to solve for which you thought that registering it in faces-config.xml would be the right solution has to be solved differently using the CDI API instead of the JSF API.

alternative of #ApplicationScoped annotation in JSF

I am using #ManageBean with #ApplicationScoped and #SessionScoped annotation in MyFaces 2.1.5 version and i am not able to set the scope of bean. Can you please suggest any alternative of #ApplicationScoped and #SessionScoped annotation.

Is it possible intercept a method from #ManagedBean? If not, there alternatives?

I'm new to JSF-2 and CDI (I'm from Spring world).
I want to intercept a method from #ManagedBean but my Interceptor class is never called. Is it possible to do?
LogInterceptor.java
#Interceptor
public class LogInterceptor {
#AroundInvoke
public Object log(InvocationContext ctx) throws Exception {
System.out.println("begin method interceptor");
Object methodReturn = ctx.proceed();
System.out.println("end method interceptor");
return methodReturn;
}
}
RoleMB
#ManagedBean
#ViewScoped
public class RoleMB extends BaseMB {
#Interceptors(LogInterceptor.class)
public void preEditRole(Role role) {
...
}
}
beans.xml
<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">
<interceptors>
<class>br.com.preventsenior.services.log.LogInterceptor</class>
</interceptors>
</beans>
The log(InvocationContext ctx) is never called.
Java EE interceptors work only on CDI managed beans and EJBs, not on JSF managed beans.
So, you've basically 2 options:
Change JSF bean management annotations by CDI bean management annotations (#Named et.al.)
Intercept on an EJB method instead which is in turn invoked by JSF managed bean. In a sane Java EE application, the real business logic belongs in EJBs anyway.

Resources