Validation groups can be used to control which rules validation rules to run. A validation group can be identified by any Java interface (not class!). Multiple validation groups may be specified when validating. In this example, I added a validation group named MyValidationGroup ( src/main/java/com/example/MyValidationGroup.java in Maven project): package com.example; public interface MyVal... and added a @Size rule for a person's name, because my database can only store up to 15 characters for a person's name: package com.example; import javax.validatio... Now validate Person with a JUnit test ( src/test/java/com/example/TestPersonWithGroup.java in Maven project): package com.example; import java.util.Set; ... Test with " mvn clean test ". The rules where groups is not specified, which belong to the javax.validation.groups.Default group, are not executed with these tests.

In this simple example, I create a simple validating bean and create a JUnit test to test the validation. The bean ( src/main/java/com/example/Person.java ): package com.example; import javax.validatio... The test ( src/test/java/com/example/TestPerson.java ): package com.example; import java.util.Set; ... Run the test: mvn clean test You'll notice that one test passed and the other failed. The tests require that a person must have a name and the name cannot be empty, so @NotNull is not the right rule to use here. To make sure that the name is not empty, we need to use @Pattern . But since a null String matches any pattern, @NotNull is also needed: package com.example; import javax.validatio...

Here are some ways to run a main method using Maven: Use the exec plugin: mvn exec:java -Dexec.mainClass="com.example.App" or, with arguments: mvn exec:java -Dexec.mainClass="com.example.App" -... Attach it to a build phase with the build element: <build> <plugins> <plugin> ... If you want to run main from Maven, it's probably just some test code. You are better off just to write a test case, or call the main method from a test class: package com.example; import junit.framework...

This is a series of notes on building custom JSF 2.0 facelet taglibs, ordered from the simplest to the less simple. Hopefully it can help you to get started on how to build custom taglibs for JSF. A simple JSF facelets taglib example The simplest taglib I can think of. Using EL expression with a custom tag Make tag attributes dynamic. Mixing custom tag with facelet ui taglibs Discover things you might run into when you get into more details. Which EL context to use? Using the wrong EL context can lead to subtle bugs. JSF facelet taglib backed by a UI component A UIComponent can be a tag handler, without being TagHandler . Using tag handler, UI component and renderer with a JSF facelet...

Step 1: Repackage a web app as EAR A Java EE application is a multimodule Maven project. At the very least you'll need to package a WAR and an EAR. To get started, I'll simply re-package the simple webapp as an EAR. Create a directory named javaee-app Copy the webapp from here to javaee-app . Rename struts1app to webapp . Create pom.xml under javaee-app : <project> <modelVersion>4.0.0</modelVersion>... Create a directory named ear under javaee-app . Create pom.xml under ear : <project> <modelVersion>4.0.0</modelVersion>... Modify pom.xml in the webapp directory so that it looks like this: <project> <modelVersion>4.0.0</modelVersion> ... Build with " mvn package " in the javaee-app directory. You can see that ear-1.0.ear is successfully generated in javaee-app/ear/target . Maven successfully resolves dependencies between the sub-projects....

This is a simple example to demonstrate the templating power of JSF facelets. If you've used struts tiles before, you'll recognize the simplicity of templating with facelets. I've stripped out everything else except the pages themselves, just to put our focus on facelets. This is a Maven based project, and you need Tomcat (or any servlet container) to run the resulting webapp. To begin with this is the list of files: ./pom.xml ./src/main/webapp/home.xhtml ./src... I left faces-config.xml in there for completeness sake, it may not be needed. The Maven POM ( pom.xml ): <?xml version="1.0" encoding="UTF-8"?> <project... Web app configuration ( WEB-INF/web.xml ): <?xml version="1.0" encoding="UTF-8"?> <web-app... Empty WEB-INF/faces-config.xml : <?xml version="1.0" encoding="UTF-8"?> <!-- Thi... index.jsp is simply a redirect to home.jsf : <% response.sendRedirect("home.jsf"); %>...

The only explanation of why some Java EE API classes are stripped off methods implementations I can find is this JBos forum post: What's the cause of this exception: java.lang.ClassFormatError: Absent Code? which also provides some workarounds for these crippled API classes. The explanation offered was: When one compiles, they want to run as well. By the way, we have been promoting full set of Java EE APIs which can only be used for compilation - they are stripped off method details. That way, user can't take those artifacts and try to use it in runtime. Honestly, I don't see any logic in those statements. This is the only place any such explanation is offered. Yes only from this JBos forum post! There's no public...

I built a very basic JSF application and deployed to Tomcat 7.0.22, but it failed with this error: Caused by: java.lang.ClassFormatError: Absent Code... That looks weird and I wasn't able to find a sensible explanation! So I copied the jsf-api-2.1.jar , which was downloaded from the java.net Maven repository by Maven, into a temp folder. And tested it with this simple program: public class ClassFormatErrorTest { public ... I also copied servlet-api.jar from Tomcat's lib folder to the temp folder. Sure enough it failed with the same error: C:\tmp>java -cp .;jsf-api-2.1.jar;servlet-api.jar ... But when I replaced the javax.faces.webapp.FacesServlet class with one I compiled from source, the error disappears! Conclusions: The jar file jsf-api-2.1.jar from java.net Maven repository is good for compilation only (cannot be used...

This is a bare bones, no frills, just the facts tutorial on JSTL. I will not bother you with theories, principles, best practices, anecdotes, or any other junk, because JSTL is shallow and simple, and I don't want to make it sound deep or complex. Getting ready JSTL/JSP Expression Language JSTL implicit variables A simple test application for JSTL Expanding the simple JSTL test application Core Tags Basic tags : <c:out> , <c:set> , <c:remove> , <c:catch> Flow control tags : <c:if> , <c:choose> , <c:when> , <c:otherwise> , <c:forEach> , <c:forTokens> URL Tags : <c:import> , <c:url> , <c:redirect> , <c:param> Internationalization (i18n) and formatting tags I18N Overview Set locale : <fmt:setLocale> , <fmt:requestEncoding> Format messages : <fmt:message> , <fmt:bundle> , <fmt:setBundle> , <fmt:param>...

This is a simple web application with a single servlet and a single JSP page. It is intended to be a test bed for JSTL tags. You may want to store all syntax, rules, and exceptions in your head, but in my opinion nothing beats a simple test program that allows you play with it all you want. So here it is (build with Maven ). Prerequisites: Maven: http://maven.apache.org/ . You don't need any prior knowledge of Maven, but you need to install the binary. JBoss: http://jboss.org/jbossas/downloads/ , or Tomcat: http://tomcat.apache.org/ if you don't run the SQL tests. You need to know how to deploy a web application (shh! Don't tell your boss it's just copying a file to the deployment folder). Steps: The directory...