When a JSF/XPages application starts it reads the faces-config.xml for managed beans, validators etc. Can I manipulate the loaded configuration at runtime? e.g. dynamically add a validator to ensure my custom code will run.
I'm not trying to change the xml file at runtime, but the memory representation after it gets loaded.
XPages uses a JSF 1.x runtime,so JSF 2.0 constructs might not work
Yes, you can add a lot of JSF artifacts which are normally configured in faces-config.xml by among others the Application class as well.
Application application = FacesContext.getCurrentInstance().getApplication();
application.addValidator("fooValidator", "com.example.FooValidator");
// ...
You could do the job in an eagerly initialized application scoped managed bean.
#ManagedBean(eager=true)
#ApplicationScoped
public class Config {
#PostConstruct
public void init() {
// ...
}
}
Related
I use JSF portlets with Liferay. In the bean's constructer, I created some objects and also some clients to access some servers. I don't know where should I deconstruct those objects or use garbage collector and also close those clients when I refreshed the page or redirected any other page.
Thanks for helps.
Don't use the constructor. For sure not if you're using CDI. Also for sure don't rely on GC when it comes to cleaning up expensive resources. Just use #PostConstruct and #PreDestroy annotations on the desired methods. The bean management framework will all by itself explicitly call them when the bean scope starts and ends.
public class Bean {
#PostConstruct
public void init() {
// ...
}
#PreDestroy
public void destroy() {
// ...
}
}
This works on both JSF and CDI managed beans. Only when using #ViewScoped in JSF 2.0-2.1, the #PreDestroy isn't guaranteed to be invoked in all circumstances. In case you're using CDI on a Servlet (i.e. non-Portlet) environment, the OmniFaces #ViewScoped solves this problem of JSF 2.0-2.1 #ViewScoped #PreDestroy fail.
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");
}
guys. I have a Seam project running on Tomcat 6.0.20 (webapp.war) and an EJB project running on JBoss 4.2.3 (ejbapp.ear).
I can access my EJBs in my Seam components using JNDI lookup [initialContext.lookup(...)].
I'd like to have them injected in my Seam components instead.
My Seam components ARE NOT EJBs, so I can't use #EJB annotation. I'd like to have something like this in my Tomcat (Web) app.
#Name("customerAction")
public class CustomerAction {
#In // even with (autoCreate=true) or the EJB name if necessary
private CustomerEJB customerEJB;
...
}
And this in the JBoss (EJB) app.
#Stateless(name="customerEJB")
public class CustomerEJBImpl implements CustomerEJB {
...
}
#Remote
public interface CustomerEJB {
...
}
In my components.xml I have the jndiPattern=ejbapp/#jndiPattern/remote specified just like I currently use to lookup the EJBs (ex: ejbapp/CustomerEJB/remote).
I'm probably missing something in my configuration to make this work.
PS: I'd like NOT HAVE to annotate my EJBs as #Name (Seam) components.
Any suggestions? Thanks in advance.
Thanks for your reply, but it didn't work.
When I declared the EJBs in components.xml, it did inject the object in my Action (Seam component), but as a POJO. I mean, the EntityManager and other EJB injections I had in the injected object didn't work.
I also tried to define the EJB as a Seam component, but, once they are in the webproject inside a JAR file, it didn't load automatically, and trying the scenario above, I got the same error.
Just an FYI, I also declared the Seam interceptor in ejb-jar.xml file.
I have no idea why this is happening, BTW I thought it would be quite a simple thing for Seam to handle.
Anyway..., any other suggestions, guys?
Define your EJB as Seam components in your components.xml
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;
}
}