Arjan Tijms' Weblog

JPA provides multiple ways to obtain entities. There is a very simple programmatic API that allows us to get an entity by ID, there's a more elaborate one called the Criteria API and then there's a query language called JPQL (Java Persistence Query Language). JPQL is an object oriented query language that is based on the simplicity of SQL, but works directly on objects and their properties. The problem with such a language that's used inside another language (Java) is where to store the query definition. Traditionally there have been 2 solutions: Store the definitions in annotations on some entity. Construct strings holding the definitions inline in your Java code. The first solution is called a Named Query in JPA, it looks like this: @NamedQueries(value={ @NamedQuery( name = "Website.getWebsiteByUserId", query="select website from Website website where website.userId = :userId") @NamedQuery(...) }) @Entity public class Web

It's well known that Facelets is the far superior technology when it comes to authoring pages using JSF. By default, Facelets has no provisions to include content from JSP pages, or Servlets for that matter. Normally this really isn't needed. Facelets provides a better and clearer templating mechanism than what JSP has ever offered. Facelets & JSP in one app However, when migrating a large application you might have to run a while in mixed-mode, that is running with both Facelets and JSP pages in a single application. It ain't pretty, but it is explicitly supported . Ever wondered why you are forced to use prefix mapping for this? Well, the Facelets view handler delegates to the default view handler for createView, which transforms a view ID suffix like .jsf or .xhtml to a default one (e.g. .jsp), but leaves the suffix alone when using a prefix mapping like /faces/*. The Facelets viewhandler later decides to handle a request itself or delegate again to the default