DevGrok

JSF 1 is HTTP POST based and, as such, makes it hard to generate friendly/RESTful URLs that are meaningful to the user. Try to serve something like a content management system (CMS) using JSF and you immediately run into problems. However if you write a custom ViewHandler , you can translate the virtual url, such as /page/about/contactUs , into a physical page (view), e.g. /dynamicContent.xhtml . All cases where the ViewHandler references the viewId (which is just the full filename of the page its executing/referencing), need to be mapped correctly so that JSF opens the page that exists, while the user sees the content specified by the URL that maps to a database for example. Below is the view handler that wraps around the Facelets view handler to provide the described functionality.: /** * View Handler that wraps around first Facelets then the default handler, to translate the virtual address of the content page to the physical xhtml * page that will serve it. * * @author Ch...

When trying to undeploy an webapp that uses Google Guice from an webapp server like Tomcat, you may notice that it doesn't undeploy properly. The problem seems to be related to com.google.inject.internal.Finalizer , which is a Thread created to clean up after Guice is finished. However the thread doesn't stop properly. My solution is to modify this class (by just adding that individual source file to the project as I don't want to rebuild the whole project) adding a stop method that can be call from a ServletContextListener.contextDestroyed() . My modified Finializer: private boolean stop = false; /** * Loops continuously, pulling references off the queue and cleaning them up. */ // @SuppressWarnings("InfiniteLoopStatement") @Override public void run() { try { while (!stop) { try { cleanUp(queue.remove()); } catch (InterruptedException e) { /* ignore */ } } } catch (ShutDown shutDown) { /* ignore */ } } public void stopThr...

I had a problem where a command button's action was not being called on the managed bean. When using tiles inside JSF, you may have it set up so that you have a template.jsp and a body.jsp. The template.jsp, using tiles inserts body.jsp. template.jsp defines a <f:view> tag as per normal. Inside body.jsp, whilst you don't technically need a <f:view> tag, you may get some component (namely f:phaseListener ) complaining about not having a view root, so you does it asks and defines the <f:view> at the start of the file. You load up the page, everything renders correctly and you click a submit button. The form validation errors appear as normal, so you fill in some values and click submit again. This time, NOTHING. So you try turning on all the logging and still nothing seems wrong. This happened to me. I wasted quiet a few hours on this one: working out how to log things correctly using eclipse/tomcat and get Java Util Logging working etc. After a ton of breakp...

In JSF 1, there is no provided functionality to invoke an action (by this I mean a java function, not a JSF action invoked by a component). JSF 2 adds functionality to support this, through f:viewParam / f:event and the PreRenderViewEvent . However in JSF 1, you can bind a phase listener to a specific page using the f:phaseListener tag to call the code before the Render Phase. To make sure that the code is only called when the page is access via the url and not from a postback caused by a component you can use the function added in JSF 1.2:  ResponseStateManager.isPostback(FacesContext context) . First off we configure the phase listener in the page (action.xhtml): <html xmlns="http://www.w3.org/1999/xhtml" xmlns:ui="http://java.sun.com/jsf/facelets" xmlns:f="http://java.sun.com/jsf/core"> <f:phaselistener binding="#{urlActionBean.listener}" /> Next is the phase listener and action code: public class UrlActionBean { /*...

After having my elcipse install crashing several times, I thought it a good idea to compile a easily accessible list of plugins I use. Log4E Allows loggers to be added to classes, replaces System.out and printStackTrace etc Website: http://log4e.jayefem.de/content/view/3/2/ Update site: http://log4e.jayefem.de/update Log4Eclipse Log4j socket appender host - allows log4j to send log messages directly to eclipse (no need to inspect log files). I have rebuilt it using log4j 1.2.15 see below. Website: http://www.nitwit.de/log4eclipse/ My build: log4eclipse_0.4.0.jar Subclipse Subversion client Website: http://subclipse.tigris.org/ v1.6 Update site: http://subclipse.tigris.org/update_1.6. x v1.8 Update site: http://subclipse.tigris.org/update_1.8.x JBoss Tools Tools for JBoss server and JSF/Richfaces/Facelets editors. Plus a lot of others (I just use the richfaces plugin). Website: http://www.jboss.org/tools Update site: http://download.jboss.org/jbosstool...

Many times I've come across the classic problem of different logging instances in an web app server. Most of them involve classloader conflicts: The webapp has log4j.jar but the webapp has bundled log4j.jar as well and you get errors. OR you have the log4j.jar in the application server's shared library directory and you have 2 webapps but the configuration conflict - or even just a configuration for the application server itself and one for the webapp. I've finally come across a solution for log4j. It involves using a repository selector based on a context, this is fully described here - Supporting the log4j RepositorySelector in Servlet Containers . So the solution to stop conflicts and independently configure each application is this. First put ALL logging jars in the shared library directory including ( log4j.jar, slf4j-api.jar, slf4j-log4j.jar, commons-logging.jar, etc). This ensures that if they one of the libraries is loaded in the main classloader it can access the ...

After doing a quick search of the web, I did not find any nice solutions to implementing access control in JSF. Using a servlet filter mapping seemed inadequate, and there wasn't any obvious place to start. I initially tried using a custom NavigationHandler, however that is only used after an action is performed (e.g. #{someBean.action} ), and not for directly accessing a URL (e.g. typing in /test.faces). Some more searching revealed that a PhaseListener was the place to do it. After checking the JSF lifecycles I determined that RESTORE_VIEW was the correct place to do it - ALL pages go through at least the RESTORE_VIEW and RENDER_VIEW phases. You can check the viewId in the afterPhase (as the view has been loaded in this phase, hence can't check in beforePhase) and redirect using the navigation handler as nesecary. Below is my implementation of it. I used a flexible inclusion/exclusion filter so I can make the rules as complex as I want. This implementation determines ...