we are using PicketLink 2.7 in an EE7 CDI/JSF app with Wildfly.
According to the PicketLink documentation there are some EL methods
like #{hasRole('ROLE_NAME')}. When we try to use these in an JSF page
<ui:fragment rendered="#{hasRole('ROLE_NAME')}">
we get
Caused by: javax.el.ELException: Function 'hasRole' not found
When we use the EL expression on a CDI bean with
#Restrict("#{hasRole('ROLE_NAME')}")
public void doWhatEver(){}
It works fine (throwing an exception when it doesn't have the role).
So the PicketLink interceptor is configured in beans.xml, we use the uber dependency for PicketLink in the pom file.
What are we missing?
The methods are provided by org.picketlink.internal.el.ELFunctionMethods
as far as I can make out:
public static boolean hasRole(String roleName)
Checks if an authenticated user is granted with a role with the given name.
This method requires that valid ELEvaluationContext associated with the current invation thread.
The EL expressions defined by PicketLink are not available in JSF context. I was facing the same problem and decided to use an #ApplicationScoped bean with the needed methods:
#Named("auth")
#ApplicationScoped
public class AuthorizationManager {
#Inject Identity identity;
#Inject PartitionManager partitionManager;
public void hasRole(String roleName) {
return AuthorizationUtil.hasRole(identity, this.partitionManager, roleName);
}
}
Then you can use it in JSF like:
<ui:fragment rendered="#{auth.hasRole('ROLE_NAME')}">
Related
I've been trying to use JSF 2.3 with TomEE server and I'm having problems using the #Inject annotation with the FacesContext object.
When I use it, i get the following exception while starting my TomEE server:
SEVERE: CDI Beans module deployment failed
org.apache.webbeans.exception.WebBeansDeploymentException: javax.enterprise.inject.UnsatisfiedResolutionException: Api type [javax.faces.context.FacesContext] is not found with the qualifiers
Qualifiers: [#javax.enterprise.inject.Default()]
Am I missing something?
Thanks.
Seems like some JSF2.3 features must be activated by setting the used JSF version.
Try setting JSF version by adding this empty class:
import javax.faces.annotation.FacesConfig;
/**
* The presence of the #FacesConfig annotation on a managed bean deployed within an application enables version specific
* features. In this case, it enables JSF CDI injection and EL resolution using CDI.
*
*/
#FacesConfig(version = FacesConfig.Version.JSF_2_3)
public class ConfigurationBean {
}
from https://github.com/javaee/glassfish/issues/22094
I'm developing a real time application. I have websockets and application scoped managed bean. I'm trying to access the application scoped managed bean from a websocket but I can't. Is this possible?
This is my websocket and managed bean (application scoped):
#ServerEndpoint("/mediador")
#ManagedBean(eager = true)
#ApplicationScoped
public class Mediador implements Serializable {
#ManagedProperty(value = "#{aplicacion}")
private Aplicacion aplicacion;
...
And my "Aplicacion" managed bean:
#ManagedBean(eager = true)
#ApplicationScoped
public class Aplicacion implements Serializable {
...
If I try to access in Mediador class to de managed property "aplicacion" it's null so I get a NullPointerException.
Thanks
This is really not right.
#ServerEndpoint("/mediador")
#ManagedBean(eager = true)
#ApplicationScoped
public class Mediador implements Serializable {
WS (JSR-356 WebSocket) API and JSF API are completely independent from each other. They know nothing from each other and won't take mixed annotations from each other into account.
Effectively, you end up with two instances of the class. One as a WS managed server endpoint as available by ws://.../mediador, and one as a JSF managed bean as available by #{mediador}. The #ManagedProperty is only recognized by JSF managed bean facility and it'll work in the JSF managed bean instance only.
Use CDI instead. It works across the entire Java EE web application. Not only in WebSocket endpoints, but also in JSF managed beans, WebServlets, WebFilters, WebListeners, JAX-RS resources, JAX-WS resources, etcetera. Eventually, JSF managed bean facility will be deprecated in favor of CDI. This will happen in Java EE 9 or perhaps already 8.
#ServerEndpoint("/mediador")
public class Mediador { // Shouldn't be serializable!
#Inject
private Aplicacion aplicacion;
// ... (no getter+setter needed!)
}
#Named
#ApplicationScoped // javax.enterprise.context
public class Aplicacion { // Shouldn't be serializable!
// ...
}
Unrelated to the concrete problem: implementing websockets in JSF rightly is not exactly trivial, certainly not if you'd like to take into account JSF session and view scopes, and would like to be able to target a specific user during push. You'd better look at an existing push component. See also How can server push asynchronous changes to a HTML page created by JSF?
I have an annotation configured request-scoped TwitterTemplate bean and I want to inject that bean into an xml configured inbound-channel-adapter.
What is the best way to do that and are there any implications that need to be considered in case of multiple sessions accessing the same inbound-channel-adapter?
Have you got any examples of twitter inbound-channel-adapter configured through java?
Inject an ApplicationContext object into your xml configured bean, as a property.
Your xml configured bean can implement InitializingBean and override the afterPropertiesSet method, where you get an instance of your twitterBean as shown in the code below.
You context gets merged irrespective of the configuration mechanism you use.
YourXmlBean implements InitializingBean {
ApplicationContext ctx;
TwitterTemplate twitBean;
...
#Override
public void afterPropertiesSet(){
twitBean = (TwitterTemplate) ctx.getBean("twitterTemplate");
}
I can't seem to find a way to force an application-scoped managed bean to be instantiated/initialized when the web app is started. It seems that application-scoped beans get lazy-instantiated the first time the bean is accessed, not when the web app is started up. For my web app this happens when the first user opens a page in the web app for the first time.
The reason I want to avoid this is because a number of time-consuming database operations happen during the initialization of my application-scoped bean. It has to retrieve a bunch of data from persistent storage and then cache some of it that will be frequently displayed to the user in the form of ListItem elements, etc. I don't want all that to happen when the first user connects and thus cause a long delay.
My first thought was to use an old style ServletContextListener contextInitialized() method and from there use an ELResolver to manually request the instance of my managed bean (thus forcing the initialization to happen). Unfortunately, I can't use an ELResolver to trigger the initialization at this stage because the ELResolver needs a FacesContext and the FacesContext only exists during the lifespan of a request.
Does anyone know of an alternate way to accomplish this?
I am using MyFaces 1.2 as the JSF implementation and cannot upgrade to 2.x at this time.
My first thought was to use an old style ServletContextListener contextInitialized() method and from there use an ELResolver to manually request the instance of my managed bean (thus forcing the initialization to happen). Unfortunately, I can't use an ELResolver to trigger the initialization at this stage because the ELResolver needs a FacesContext and the FacesContext only exists during the lifespan of a request.
It doesn't need to be that complicated. Just instantiate the bean and put it in the application scope with the same managed bean name as key. JSF will just reuse the bean when already present in the scope. With JSF on top of Servlet API, the ServletContext represents the application scope (as HttpSession represents the session scope and HttpServletRequest represents the request scope, each with setAttribute() and getAttribute() methods).
This should do,
public void contextInitialized(ServletContextEvent event) {
event.getServletContext().setAttribute("bean", new Bean());
}
where "bean" should be the same as the <managed-bean-name> of the application scoped bean in faces-config.xml.
Just for the record, on JSF 2.x all you need to do is to add eager=true to #ManagedBean on an #ApplicationScoped bean.
#ManagedBean(eager=true)
#ApplicationScoped
public class Bean {
// ...
}
It will then be auto-instantiated at application startup.
Or, when you're managing backing beans by CDI #Named, then grab OmniFaces #Eager:
#Named
#Eager
#ApplicationScoped
public class Bean {
// ...
}
Romain Manni-Bucau posted a neat solution to this that uses CDI 1.1 on his blog.
The trick is to let the bean observe the initialization of the built-in lifecycle scopes, i.e. ApplicationScoped in this case. This can also be used for shutdown cleanup. So an example looks like this:
#ApplicationScoped
public class ApplicationScopedStartupInitializedBean {
public void init( #Observes #Initialized( ApplicationScoped.class ) Object init ) {
// perform some initialization logic
}
public void destroy( #Observes #Destroyed( ApplicationScoped.class ) Object init ) {
// perform some shutdown logic
}
}
As far as I know, you can't force a managed bean to be instantiated at application startup.
Maybe you could use a ServletContextListener which, instead of instantiating your managed bean, will perform all the database operations itself?
Another solution might be to instantiate your bean manually at application startup, and then set the bean as an attribute of your ServletContext.
Here is a code sample:
public class MyServletListener extends ServletContextListener {
public void contextInitialized(ServletContextEvent sce) {
ServletContext ctx = sce.getServletContext();
MyManagedBean myBean = new MyManagedBean();
ctx.setAttribute("myManagedBean", myManagedBean);
}
}
In my opinion, this is far from clean code, but it seems like it does the trick.
Additionally to BalusC's answer above you could use #Startup and #Singleton (CDI), e.g.
//#Named // javax.inject.Named: only needed for UI publishing
//#Eager // org.omnifaces.cdi.Eager: seems non-standard like taken #Startup below
#Startup // javax.ejb.Startup: like Eager, but more standard
#Singleton // javax.ejb.Singleton: maybe not needed if Startup is there
//#Singleton( name = "myBean" ) // useful for providing it with a defined name
#ApplicationScoped
public class Bean {
// ...
}
which is nicely explained here.
Works in JPA 2.1 at least.
Which JSF 1.2 component is responsible for instantiating managed bean specified in faces-config.xml?
I'd like to replace this component with my custom-made version which will perform some additional tasks after bean instance is successfully created.
No one component is responsible for that. It is just EL which is responsible for that. If the expression #{beanname} returns null, it will create one which is associated with the managed bean name.
In your specific case, the normal way to solve this problem is just making use of the constructor of the bean or a public method of the bean annotated with #PostConstruct.
public class Bean {
public Bean() {
// Put code here which is to be executed during construction, but before
// setting of the managed properties (<managed-property> declarations).
}
#PostConstruct
public void init() {
// Put code here which is to be executed AFTER construction
// and the setting of managed properties.
}
}
If you really want to take the EL resolving in your own hands, then best what you can do is to implement a custom ELResolver. You can find here an article about that.
Here is the JSP resolver structure detailed in the JSF 1.2 spec:
Faces ELResolver for JSP
|_ faces.ImplicitObjectELResolverForJSP
|_ faces.ManagedBeanELResolver
|_ faces.ResourceBundleELResolver
|_ ELResolvers in application configuration resources
|_ faces.VariableResolverChainWrapper (wraps deprecated API)
|_ faces.PropertyResolverChainWrapper (wraps deprecated API)
|_ ELResolvers from Application.addELResolver()
Managed beans will be instantiated by the faces.ManagedBeanELResolver (which is just a label developers can refer to it by, not the name of a public class).
The top-level ELResolver is provided via the Application (which you can provide via an ApplicationFactory). But, although the JSF specification details behaviour, the API does not expose the means by which the managed beans will be instantiated. It would be difficult to decorate the implementation to disambiguate between a newly instantiated bean and a bean that was returned from the request/session/application scope.
BalusC's post gives a couple of good strategies for approaching this problem.
Although JSF 2.0 brings changes to the managed bean facility, it does not, to the best of my knowledge, change this aspect of the API.
#PostConstruct is the way to go for JSF 1.2.
If you are using JavaEE 6 then you can also use #Produces annotation on a method to create custom factory method.
public class CustomBeanFactory {
#Produces
public Bean getBean() {
Bean bean = new Bean();
System.out.println("Created new bean.");
return bean;
}
}