In this article we’ll be implementing the following functions, the code for which is available for download :

• Write a servlet that will dispatch the requests to our MVC handler class.
• In the MVC Handler, we’ll take a web request and invoke the appropriate controller method
• Take the result from the request mapped method and resolve it to a view which the user is forwarded to

Implementing the Servlet

Our servlet code takes incoming requests and delegates them to the injected MvcHandler instance.

@WebServlet(urlPatterns = "/demo/*")
public class DelegatingServlet extends HttpServlet {

    @Inject
    private MvcHandler mvcHandler;

    protected void doGet(HttpServletRequest req, HttpServletResponse resp)
            throws ServletException, IOException {
        doHandleRequest(req, resp, RequestMethod.GET);
    }

    protected void doPost(HttpServletRequest req, HttpServletResponse resp)
            throws ServletException, IOException {
        doHandleRequest(req, resp, RequestMethod.POST);
    }

    private void doHandleRequest(HttpServletRequest request, HttpServletResponse response,
        RequestMethod requestMethod) {

        mvcHandler.handleRequest(request.getPathInfo(),requestMethod,request,
            response,getServletContext());
    }
}

Our servlet uses the @WebServlet annotation to register the servlet for the /demo/* url path. It injects the instance of our MvcHandler class and uses it to handle the GET and POST requests. When we call the MVC handler, we have to pass in multiple objects that will be used by the handler. Looking ahead, we can see this is going to grow since we have controller methods, model values, outcomes and view names to pass around so we’ll create a new object called a RequestContext that will keep a hold of all these things and we can pass all those items around as a single object.

It makes our method calls look nicer with fewer parameters and we don’t have to keep adding parameters to methods for each new piece of information needed. Working with a single context means we can break the handler down to a specific set of steps with the product of each method (i.e. fetch model values) being held in the context and used in the next method. It also means we can convert it to an interface and/or abstract some of the information available to provide different implementations (i.e portal version). For now, we just need a basic version with a servlet context, request, response objects. We’ll also need to store the controller, the controller method and the outcome from that method.

public class RequestContext {

    private final ServletContext servletContext;
    private final HttpServletRequest request;
    private final HttpServletResponse response;
    private final RequestMethod requestMethod;
    private Object controller;
    private ControllerMethod method;
    private Object outcome;

    public RequestContext(ServletContext servletContext,
            HttpServletRequest request, HttpServletResponse response,
            RequestMethod requestMethod) {
        this.servletContext = servletContext;
        this.request = request;
        this.response = response;
        this.requestMethod = requestMethod;
    }

    //getters and setters omitted
}

Implementing the MVC Handler

Going back to our MVC Handler, the code in this class pulls everything together and orchestrates things as it receives calls from the servlet.

public class MvcHandler {

    @Inject
    private ControllerInfo controllerInfo;

    @Inject
    private ControllerMethodMatcher matcher;

    @Inject
    private BeanManager beanManager;    

	public void handleRequest(RequestContext context) {

		//find the controller method that best matches the request
		context.setMethod(matcher.findMatching(controllerInfo, context));

		if (context.getMethod() != null) {
			Object controller = locateController(context.getMethod().getControllerClass());
			context.setController(controller);
			// start executing the controller method
			executeControllerMethod(context);
			handleResponse(context);
		} else {
			throw new RuntimeException("Unable to find method for "
					+ context.getRequestMethod() + " request with url "
					+ context.getPath());
		}
	}

    private void handleResponse(RequestContext context) {
        if (context.getOutcome() instanceof String) {
            String outcome = (String) context.getOutcome();
            String view = "/"+outcome+".jsp";
            context.forwardTo(view);
        }
    }

    private Object locateController(Class<?> controllerClass) {
          //returns a bean of type controllerClass from CDI
    }

    private void executeControllerMethod(RequestContext context) {
       //executes the controller method on the controller
    }
}

We inject our instance of ControllerInfo which holds all the controller methods and the handleRequest() method is called from the servlet when receives a web request. In order to service the request it takes the following steps :

• Find a matching controller method for this request.
• Locate the controller
• Execute the controller method on that controller instance saving the outcome returned from the method.
• Handle the correct response back to the user.

For now, we are just assuming the controller method returns a string that indicates the view name which we forward to. I added a method to handle forwarding on the request context object.

Matching Methods

The ControllerMethodMatcher is an interface that can be used to locate a controller method in the list of controller methods that matches the incoming request info held in the request context

public interface ControllerMethodMatcher {
    ControllerMethod findMatching(ControllerInfo info,RequestContext context);
}

Our default implementation of this is really simple for now. We iterate through our list of controller methods and check that the request type matches the request method of the incoming request. If it does, then as long as the url path starts with the controller level prefix and ends with the method level suffix, then it is a match. Because we already sorted the controller methods in order of the larger expressions first, we know that the first match we come across is the best for now.

public class DefaultControllerMatcher implements ControllerMethodMatcher {

    public ControllerMethod findMatching(ControllerInfo info,RequestContext context) {
        for (ControllerMethod method : info.getControllerMethods()) {
            if (matches(method, context)) {
                return method;
            }
        }
        return null;
    }

    protected boolean matches(ControllerMethod methodToTest, RequestContext context) {
        String path = context.getPath();
        boolean result = methodToTest.matchesRequestMethod(context.getRequestMethod())
            && (methodToTest.getPrefix() == null || path.startsWith(methodToTest.getPrefix()))
            && (methodToTest.getSuffix() == null || path.endsWith(methodToTest.getSuffix()));
        return result;
    }
}

We can override this class, and re-implement the matches method later on and since we pass in the RequestContext we will have all sorts of information available to us to determine the best match.

Executing the Controller Method

We can just use reflection to execute the controller method instance for now. We assume that there are no params for now, that will come later.

private void executeControllerMethod(RequestContext context) {
	Method javaMethod = context.getMethod().getMethod();
	Object outcome = null;
	try {
		outcome = javaMethod.invoke(context.getController());
	} catch (Exception e) {
		e.printStackTrace();
	}
	context.setOutcome(outcome);
}

Seeing it in action

Finally we can put it all together so we can see it in action in a web application. For now our MVC code is in our web project to make integrating it easier. We can later extract the MVC code to a stand-alone module to use as a library in other projects. We’ve already set up a controller and our servlet, now we just need to create a couple of pages based on the string returned from the mapped methods. If we run the application now and go to a url such as http://localhost:8080/mvcdi/demo/person/list we will get an error message because listPeople.jsp doesn’t exist. We’ll create the following simple jsp pages so we can display something in the browser. Each page just consists of the boilerplate structure and some text that indicates which page we are on.

<html>
  <head>
    <title>View Person</title>
  </head>
  <body>
    View Person
  </body>
</html>

We do this for the following pages in the root of the web directory.

• viewPerson.jsp
• listPeople.jsp
• updatedPerson.jsp
• editPerson.jsp (see below for additional changes)

The one different page is the editPerson.jsp page where we want to put a form containing only a button so we can issue a POST request which maps to the method on the controller that handles the POST request from the editPerson.jsp page and navigates to the updatedPerson.jsp page in response.

<html>
    <head>
        <title>Editing Person</title>
    </head>
    <body>
        Editing Person
        <form method="post">
            Some Form Here<br/>
            <input type="submit" value="Update" />
        </form>
    </body>
</html>

If we go to http://localhost:8080/mvcdi/demo/person/edit and click the submit button, we get sent to the page that tells us we just updated someone because that is the page returned from the controller method for the edit path with a POST request method.

You can download (mvcdi_part2.zip) the code for this as a maven project that can run on any Java EE 6 container and has been tested on both JBoss AS 7 and Glassfish 3.1.1.

This wraps up the second installment of this series on implementing Spring MVC in Java EE 6 and CDI and covers the bulk of the request mapping so we can direct our web requests to controller methods and ultimately to specific pages. Next time we’ll look at providing model data to the pages.

Interestingly, there’s nothing like Spring MVC for Java EE which is a shame because it is a really good framework. So in this series of articles, I’ll be covering different aspects of implementing Spring MVC on CDI with the caveat that this won’t be an exact compatible replica. I’ll be implementing just enough of each feature to demonstrate that it can be done, but I’ll leave enough room so that with more work, it can be a more accurate implementation. It goes without saying that these articles assume you are familiar with Spring MVC 3 using annotations and at least a little bit familiar with CDI. I’ll also mention that the code listed in the articles only contains the code relevant to the implementation for demonstration purposes. I’ve removed a lot of the null checks and other defensive programming code to make things more readable but they are still present in the final code.

In this first part, we will start by laying all the dull ground work as we capture the metadata from the MVC annotations in the following steps :

• Define our MVC annotations
• Define a class to hold our request mapped methods
• Write some code to extract the request mapped methods from a given class and store the metadata

The MVC annotations

To get started we implement the controller and request mapping annotations which are based on the Spring MVC versions. @Controller marks our classes as MVC controllers that implement MVC methods. Each method that can be mapped to a URL is mapped with the @RequestMapping annotation.

@Target({ ElementType.TYPE,ElementType.FIELD})
@Retention(RetentionPolicy.RUNTIME)
public @interface Controller {
}

The request mapping annotation has two attributes (for now), the default value which contains an array of paths that are mapped to this controller or method. For now, we will implement simple path matching, the url must start with the controller path and end with the path defined on the method. We can change to a more complex wildcard/Ant path matching implementation if we want to later. The other attribute on the request mapping is an array of RequestMethod types that indicates the type of requests we want to map to this controller and method. For now, we’ll just deal with POST, GET and DELETE request types :

public enum RequestMethod {
    POST,GET,DELETE
}

Now we can define our request mapping annotation :

@Target({ ElementType.TYPE,ElementType.METHOD})
@Retention(RetentionPolicy.RUNTIME)
public @interface RequestMapping {

    String[] value() default {};
    RequestMethod[] method() default {};
}

Armed with our new annotations, we can go ahead and create our first controller :

@Controller
@RequestMapping("/person/")
public class PersonController {

    @RequestMapping("list")
    public String doListPeople() {
        return "listPeople";
    }

    @RequestMapping("view")
    public String doViewPerson() {
        return "viewPerson";
    }

    @RequestMapping(value="edit",method=RequestMethod.GET)
    public String doGetEditPerson() {
        return "editPerson";
    }

    @RequestMapping(value="edit",method=RequestMethod.POST)
    public String doPostUpdatePerson() {
        return "updatePerson";
    }
}

For now, our controller methods return a String which can be used to determine the final view to render.

The MVC CDI Handler

Originally, I considered writing this as a CDI extension but felt that it wasn’t a good match and instead chose to create a managed MvcHandler bean that will be invoked by the servlet and will lazily initialize its own configuration post construction. This led to a more modular design since I could make the MvcHandler the center of the implementation and it let me write it in a purely managed environment saving me from having to deal with some of the limits extension have compared to managed beans.

Technically, when a web request comes in, we could get a list of controllers and iterate through them to find a matching controller and then search for a method on that controller that matches our request. However, I’m extracting and storing all that metadata on startup since it is more efficient and will allow for more expansion later on. When we start examining different types of metadata, it will get ridiculous doing it all at run time. Also, it lets us optimize a bit since we could have several matches, but some will be better matches than others so we will always need to compare all the controller methods each time a request comes in. Pre-reading it lets us also presort the controller methods into best-fit-first.

Extracting Controller Metadata

We’ll create a class called ControllerInfo that holds the metadata for the controllers. It does this by taking the controller class and iterating through its methods and seeing if they have the request mapping annotation on them. If they do, those methods are added to a list of ControllerMethod objects. This object holds info about a specific mapped method on a controller :

public class ControllerMethod {
    private final String prefix;
    private final String suffix;
    private final RequestMethod[] requestMethod;
    private final Method method;

  //getters and setters
}

The prefix is determined from the request mapping path on the controller class, and the suffix is determined from the request mapping on the method. The request method value indicates which kinds of request methods this method can be mapped to (GET or POST requests). The Method object is a java reflection Method instance that we can use to not only define the class method that is mapped, but also reference the declaring class for when we need to locate the controller bean. Since the path value can be an array of strings if a particular method has multiple paths in the value then there will be mulitple ControllerMethod entries, one for each path as the suffix. However, we don’t split up multiple request method values instead opting to store them as they are as an array.

@Controller
@RequestMapping("/somePath/")
public class MyController {

   @RequestMapping(value={"page1.do","page2.do"},method={GET,POST})
  public void someMethod() {
     ...
  }
}

The above class results in two entries :

The reason for this is it lets us optimize the path matching based on the best match first by sorting based on the length of the suffix path. Again, we can improve this ordering later on by using a better path matcher.

Now we’ve a place to store the controller method information, we can implement the ControllerInfo class which contains the list of Controller method instances:

@ApplicationScoped
public class ControllerInfo {

    private final List<ControllerMethod> controllerMethods = new ArrayList<ControllerMethod>();

    private static final String[] DEFAULT_MAPPING_PATHS = new String[] { "" };

    public static final AnnotationLiteral<Controller> CONTROLLER_LITERAL = new AnnotationLiteral<Controller>() {
        private static final long serialVersionUID = -3226395594698453241L;
    };

    @Inject
    private BeanManager beanManager;

    @PostConstruct
    public void initialize() {
        Set<Bean<?>> controllers = beanManager.getBeans(Object.class,CONTROLLER_LITERAL);
        for (Bean<?> bean : controllers) {
            add(bean.getBeanClass());
        }
        sortControllerMethods();
    }

    private void add(Class<?> clazz) {
    }
}

The initialize method is invoked when this bean is first created. As we’ll see later, this bean is injected into the MvcHandler so this method is only called when needed. It uses the CDI API to locate all beans with a controller qualifier annotation and calls the add(Class<?> clazz) method for each controller class. Finally it makes a call to sort our list of ControllerMethod instances.

In the add method, for the given controller class, we iterate through its methods and see if we can add them as a request mapped method.

private void add(Class<?> clazz) {
    if (clazz.isAnnotationPresent(Controller.class)) {

        Method[] methods = clazz.getMethods();
        String[] controllerPaths = null;

        RequestMapping rm = clazz.getAnnotation(RequestMapping.class);

        if (rm != null) {
            controllerPaths = rm.value();
        }

        // if no paths are specified, then default to one blank path so we always add it
        if (controllerPaths == null || controllerPaths.length == 0) {
            controllerPaths = DEFAULT_MAPPING_PATHS;
        }

        // add methods for each mapped path at the controller level
        for (String prefix : controllerPaths) {
            for (Method m : methods) {
                addMethod(prefix, m);
            }
        }
    }
}

private void addMethod(String prefix, Method javaMethod) {

    RequestMapping mapping = javaMethod.getAnnotation(RequestMapping.class);
    if (mapping != null) {

        String[] paths = mapping.value();

        // if these are blank, fill with defaults
        if (paths == null || paths.length == 0) {
            paths = DEFAULT_MAPPING_PATHS;
        }

        for (String path : paths) {
            controllerMethods.add(new ControllerMethod(javaMethod, prefix,path, mapping.method()));
        }

    }
}

The addMethod function will check for a request mapping annotation on the method, extract the metadata and store it in the list.

This about wraps up the first installment which covers the extraction of request mapped methods and storing them for use later on. Next time we’ll start coding our servlet and core MVC handler that will let us make web requests and invoke the mapped methods on our controller before displaying the appropriate web page.

provider.addRestriction("item.statusCode in (:param)", stateCodeList);

This will cause the list of codes to be expanded into an in SQL statement including checking to exclude null items, and as usual, the restriction is not included if the code list is null or contains only null items.

So I have two problems, the first is getting back up to speed on my code, figuring out where the make the change, and making it. The second is making sure my code changes don’t break anything thats currently working.

For the first problem, I decide to create the unit tests first so I can verify that the change does as expected. Obviously, the tests fail initially, but by looking at the code executed by the tests, I can start to pick out places where I need to start looking to add the new code. After all, tests measure the correctness of the state after the code has been executed. What better place to start looking than seeing what code the test executes. After finding the method that I need to change, I make my code changes and run my tests. All my original tests pass with flying colors, but my new test fails. I take a peek and sure enough I left off the last line of code to add the built object to a list. I put it in, and I have all my tests up and running.

All in all, I’ve made a large change to some sizable (12K+ LOC) code that I haven’t seen in over a year, verified that the change works and that it hasn’t impacted any other code. Not bad for an hour.

Oracle has released the separate API and implementation dependencies which is really how they should be broken down. Now, instead of having one javax.servlet.jstl dependency you will use the following :

<dependency>
    <groupId>javax.servlet.jsp.jstl</groupId>
    <artifactId>jstl-api</artifactId>
    <version>1.2</version>
</dependency>

<dependency>
    <groupId>org.glassfish.web</groupId>
    <artifactId>jstl-impl</artifactId>
    <version>1.2</version>
</dependency>

If you are running code in a container that already contains JSTL you will just use the jstl-api dependency with a scope of provided. This way your code has access to the API that will be provided by the container.

For those of you using the Knappsack archetypes or using the JBoss Java EE 6 API pom, or no doubt some other dependencies that use javax.servlet.jstl, you will have problems because the Java EE 6 pom relies on the javax.servlet.jstl dependency. The answer here is to exclude it from the Java EE 6 dependency and add it separately using the api dependencies described above.

<dependency>
    <groupId>org.jboss.spec</groupId>
    <artifactId>jboss-javaee-6.0</artifactId>
    <version>1.0.0.Final</version>
    <scope>provided</scope>
    <type>pom</type>
    <exclusions>
        <exclusion>
            <groupId>javax.servlet</groupId>
            <artifactId>jstl</artifactId>
        </exclusion>
    </exclusions>

</dependency>

<dependency>
    <groupId>javax.servlet.jsp.jstl</groupId>
    <artifactId>jstl-api</artifactId>
    <version>1.2</version>
    <scope>provided</scope>
</dependency>

I’m surprised that they would eliminate the pom like that, but it may have been due to licensing issues for the reference implementation which I believe has been an issue for some of the standard Java EE APIs and the reason that there is no real definitive deployment of the APIs and we have to mix and match API dependencies from different sources unless you are using the JBoss Java EE 6 dependency to solve the problem.

First off, after a few months of job hunting, I’ve changed jobs, I’m now doing some Java contract work down in Pittsburgh. After 11 years at my old job, it was time to move on. The great thing about contract work is the opportunity to work on a lot of different projects in a lot of different places. After being stuck in Cleveland for 11 years, we are ready for some changes.

I also want to try and get into doing some more Java EE 6 and CDI training. A lot of people are unsure of how it is all meant to work together and are missing out on the real beauty and simplicity of working with these frameworks.

Rick, Rob and I have been doing some more work with CDISource and anticipate a release of our source in the next few weeks. Once thats out, I want to start playing with some of the Seam 3 stuff especially with regards to CDI. We announced CDISource and then all of a sudden we all got busy with different things, and we have some code we want to release for which we have a number of articles to write.

Between moving, unpacking, starting a new gig, which always fries the brain for a few weeks, and having my Mum over from Manchester,England, I haven’t really been having time to write or work on projects.

I have a new release of the Knappsack almost ready to go which includes Spring based archetypes and also a Java EE 6 EAR archetype as well as a couple of new posts.

If you’ve seen my posts or my site before, you’ll no doubt be aware that I have written at great length about Java EE 6, JSF, CDI , EJB and so on. What I haven’t written about is the many frustrations I’ve come up against in dealing with these frameworks on their own and especially when combined, or how their usefulness is often constrained to the application server container.

Java EE in some ways is an archipelago of frameworks that lacks the cohesiveness and all in one wide screen vision that software developers need. Java EE is about the enterprise, in reality its about the web, or even more specifically about Java EE containers. There’s a whole slew of uses for a good type safe and flexible dependency injection and AOP framework and such as CDI outside of Java EE containers but there is very little information and code to make it actually work.

Our goal is to make CDI useful and usable on its own without Java EE 6, and to give developers the tools and information to do so. To let them write vendor neutral and portable code, and apply agile and best practices. Developers know how to write good software and don’t want to sacrifice that for the sake of using a framework to make things easier. To that end we aim to provide code and information that will help facilitate those practices.

There will be some learning for ourselves along the way and we will have to change some of our previously held concepts. I know over the last few weeks having been getting CDI working and useful outside of the web container it has really altered my perspective on how I think about the dependencies and structure in CDI applications. My perspective has changed even more than when I wrote A Little Less Conversation.

As much as I hate to say it, we did come up with a mission statement, although we found it fairly easy and enjoyable to clearly defined the goals and attitudes of the project.

Our mission is to :

• Promote and facilitate the use of the Java Context and Dependency Injection (CDI) framework in relation to as many aspects of application development as possible.
• Enable developers to take advantage of CDI independently of Java EE.
• Provide lightweight, lean and agile access to the underlying CDI container as a core principle in our efforts.
• Make testing easy without requiring a complex set of tools or complex deployment scenarios.
• Enhance both Java EE development as well as the use of CDI in non Java EE application where possible.
• Promote and enable the use of CDI in a vendor neutral environment and maximize the portability of application code across CDI implementations.
• Not reject the ideas of Java EE but expand the usability of CDI outside the borders of Java EE application servers with frameworks that are not a part of the specification.
• Not reject other CDI efforts but to provide another venue to promote those efforts. This is an addition. This is another voice in support of CDI.

We are pretty excited that so far we have been able to live up to the intent of our mission statement with everything we’ve done so far. Over the next few days and weeks you will see articles and tutorials come out of Rick, Rob and I as we write about the CDISource project and we start to showcase some of the code we have written and start giving you an idea of where we are heading.

Right now we have vendor neutral support for starting up CDI outside of the web container and also for testing CDI beans with minimal configuration and intrusion on your test cases. We also have a few other pieces that are nearly ready, as well as dozens of ideas to get started on.

You can start by looking at Ricks brand new introduction of CDI over on JavaLobby.

1. First off, we’re going to change the entity manager that is available for injection to be request scoped. To do this, open up DataRepositoryProducer.java and change the @ConversationScoped annotation on the getEntityManager() method to be @RequestScoped. The reason for this is documented here in A Little Less Conversation.
2. Next we are going to create a simple dao for Course objects, and the only reason to do this is to demonstrate the integration of CDI and the ability to layer your code. Create a new class called CourseDao with the following code.

   package org.fluttercode.restwebdemo.bean;
   
   @Stateless
   @LocalBean
   public class CourseDao {
   
   	@Inject @DataRepository
   	private EntityManager entityManager;
   
   	public void save(Course course) {
   		entityManager.persist(course);
   	}
   
   	public Course update(Course course) {
   		return entityManager.merge(course);
   	}
   
   	public Course find(Long id) {
   		return entityManager.find(Course.class, id);
   	}
   }
   

   This just injects an entityManager and uses it to locate, save and update Course objects.

3. Now create a new CourseService bean that will handle the web services. To start with we want to make it a stateless EJB and inject the course Dao. We are going start by re-implementing the method to return the course name for the given id.

   	@Path("courseName/{id}")
   	@GET
   	public String getCourseName(@PathParam("id") Long id) {
   		Course course = courseDao.find(id);
   		if (course == null) {
   			return "Course not found";
   		} else {
   			return course.getTitle();
   		}
   	}
   

To see this method in action, deploy the application and go to http://localhost:8080/restwebdemo/rest/course/courseName/126. Now we know everything is working and hooked up together, we can look at adding some new functionality.

Let’s start by returning a course with a given id from the service. This is fairly simple given what we already know. The only thing to determine now is what format to return the object as and to convert it to that type. Luckily, Java EE already provides JAXB which can take an object graph and convert it to XML for us as long as we annotate the classes with the annotations to let the JAXB implementation know how to convert it. The same annotations can be used by the body writer that handles JSON.

First we’ll annotate the Course class and make a couple of changes that we need to. Next we’ll create methods to return a Cource object from the service in XML or JSON format.

1. Open the Course class and add the following annotations to the class.

   @Entity
   @XmlRootElement
   @XmlAccessorType(XmlAccessType.FIELD)
   public class Course extends BaseEntity {
      ...
      ...
   }
   

   This tells the JAXB processor that this class can be serialized and to access the values using fields in the class. This also means that any other annotations we want to add to control the serialization needs to be applied to the fields.

This is a simple example, so we don’t want to serialize the teacher or enrolled properties which we can do by marking them with the @XmlTransient attributes. Also, remove the @NotNull annotation from the teacher attribute as we will need it blank later. The following code shows the fields with both the JAXB and JPA annotations. JAXB (like JPA) uses default conventions for fields that don’t have annotations :

	@Column(length = 32, nullable = false)
	@Size(max = 32)
	@NotEmpty(message = "title is required")
	private String title;

	@Column(length = 8, nullable = false)
	@Size(max = 8  )
	@NotEmpty(message = "code is required")
	private String code;

	@ManyToOne(fetch = FetchType.LAZY)
	@XmlTransient
	private Teacher teacher;

	@ManyToMany(mappedBy = "enrolled")
	@XmlTransient
	private List<Student> students = new ArrayList<Student>();

We are just using a simple JAXB model for the sake of the example which is why we aren’t including the Teacher and Student classes.

2. Now in our CourseService class we will create methods to return the course entity and we will create one for JSON and one for XML.

   	@Path("find/{id}/xml")
   	@GET
   	@Produces(MediaType.APPLICATION_XML)
   	public Course getCourseAsXml(@PathParam("id") Long id) {
   		return courseDao.find(id);
   	}
   
   	@Path("find/{id}/json")
   	@GET
   	@Produces(MediaType.APPLICATION_JSON)
   	public Course getCourseAsJson(@PathParam("id") Long id) {
   		return courseDao.find(id);
   	}
   

(note : At this point, I had to switch to using Hibernate as the JPA provider since JAXB didn’t like the interface EclipseLink used for proxying the properties. You can do this using the Glassfish update tool).
If you redeploy the application and browse to http://localhost:8080/restwebdemo/rest/course/find/1/json you should be prompted to save a file, or it will display the text, but the content should be something like :

{"createdOn":"2010-08-27T16:36:57.015-04:00",
  "id":"1",
  "modifiedOn":"2010-08-27T16:36:57.015-04:00",
  "title":"Computing for Beginners",
   "code":"CS101"}

or if you go to http://localhost:8080/restwebdemo/rest/course/find/1/xml you will get an XML version :

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<course>
	<createdOn>2010-08-27T16:36:57.015-04:00</createdOn>
	<id>1</id>
	<modifiedOn>2010-08-27T16:36:57.015-04:00</modifiedOn>
	<title>Computing for Beginners</title>
	<code>CS101</code>
</course>

Now we can grab objects from our web service, we should look at creating objects from the service. We add a new method that takes the title and code values, creates a new Course with those values and saves it using the courseDao.

	@Path("create")
	@PUT
	@Produces(MediaType.APPLICATION_JSON)
	public Course createCourse(@FormParam("title") String title,@FormParam("code") String code) {
		Course course = new Course();
		course.setTitle(title);
		course.setCode(code);
		courseDao.save(course);
		return course;
	}

Here I’ve used the FormParam annotations to plug form values into the method call. You’ll notice that using REST conventions, the method to create a course uses the PUT type of request. Now let’s create a page to enter a title and code and create the course. Notice that our method returns the created course so we can return the course back to the user. This is probably not ideal, but suits for the purposes of demonstration. Now lets create a new HTML page to allow for data entry and calling the web service to create the Course.

<html>
<head>
<title>Insert title here</title>
<script type="text/javascript"
	src="http://localhost:8080/restwebdemo/jquery-1.4.min.js">
</script>
</head>
<body>
<div id="message"
	style="display: none; background: #d0d0f0; padding: 12px">Message Div</div>
<form action="rest/course/create" method="POST">

    <fieldset>
    	<legend>Create Course</legend>
    	<p>
	        Title<br />
    	    <input id="title" /><br />
    	</p>
    	<p>
        	Code<br />
        	<input id="code" /><br />
    	</p>
    	<input type="submit" id="submit" />
	</fieldset>
</form>
</body>

<script type="text/javascript">

//jquery pieces
$(document).ready(function() {

    //change the submit button behaviouus.
    $('#submit').click(function () {
		var title = $("input#title").val();
		var code = $("input#code").val();

		params = "title="+title+"&code="+code;
		//alert("posting form : "+data);
        $.ajax({
               type: "PUT",
               url: "rest/course/create",
               data: params,
               success: function(result) {
        		   showMessage("Created Course "+result.title+" with id "+result.id+" on "+result.createdOn);
               }
        });
		return false;
    });
});

function showMessage(msg) {
	  $('#message').html(msg);
	  $('#message').fadeIn('fast');
	   $('#message').delay(3000).fadeOut('slow');
}
</script>
</html>

This looks a lot code, but not really. We import jquery to help us post our form, and we create our form with the two fields. We use JQuery to add an event handler so when you click submit, it packages up the form, calls our web service with a PUT type of request and grabs the returned object as a JSON object, and displays a message using the values from the new instance obtained from the server. To verify that your course has been created, go to the front page and you should see it listed.

That about wraps it up for this post, the source code can be downloaded from (restwebdemo_pt2), just unzip it, use mvn clean package and deploy the war to glassfish and use the URLs mentioned in the article.

]]> http://www.andygibson.net/blog/tutorial/simple-restful-services-in-glassfish-pt-2/feed/ 0 http://www.andygibson.net/blog/article/double-the-speed-of-some-of-your-jsf-pages-and-dodge-bugs-too/ http://www.andygibson.net/blog/article/double-the-speed-of-some-of-your-jsf-pages-and-dodge-bugs-too/#comments Thu, 17 Mar 2011 12:49:39 +0000 Andy Gibson http://www.andygibson.net/blog/?p=1771 There was a thread on the JSF LinkedIn group about JSF performance and a number of people complained about the fact that as part of the restore view phase, JSF reconstructs the component tree including binding data to data tables causing unnecessary fetches of data from the database. This article looks at one way of avoiding the additional work to fetch the data.

When you first do a postback, the restore view phase rebuilds the tree, including fetching the data to bind it to the data table. Why you ask, well a good question. Typically this wouldn’t be an issue since we want the server state to match the client view state. However, as the developer, we know that for some cases these results are useless since we don’t anticipate using them for anything so fetching them is really a waste of time.

Let’s take a look at this problem in action. You can use the maven archetype to generate the project and code along or download the source from here (fastapp.zip).

1. Create a new maven application using the jee6-servlet-basic knappsack archetype. This gives you an empty Java EE 6 application that can be run using Jetty or Tomcat from the command line.
2. Add a new class that will be our backing bean that returns a list of paginated numbers but takes a long time (2 seconds) to do it.

   @Named
   @RequestScoped
   public class DataBean {
   
   	//indicates the page we are on
   	private int pageNumber = 0;	
   
   	//lazy loaded reference to the results
   	private List<Integer> data;
   
   	//returns the list of data by lazy loading it
   	public List<Integer> getData() {
   		if (data == null) {
   			data = generateData();
   		}
   		return data;
   	}
   
   	//generates the list of data, think of this as an expensive DB operation
   	private List<Integer> generateData()  {
   		System.out.println("Generating Data starting from "+pageNumber);
   
   		//Sleep for 2 seconds while I access the database and do stuff
   		try {
   			Thread.sleep(2000);
   		} catch (InterruptedException e) {
   			e.printStackTrace();
   		}
   
   		//now we actually generate the data
   		List<Integer> results = new ArrayList<Integer>();
   		for (int i = 0;i < 10;i++) {
   			results.add(pageNumber+i);
   		}
   		return results;
   
   	}
   
   	//method to move to the next page in the list
   	public void nextPage() {
   		pageNumber = pageNumber+10;
   		//invalidate the lazy loaded data
   		data = null;
   	}
   
   	//method to move to the previous page in the list
   	public void previousPage() {
   		pageNumber = pageNumber-10;
   		//invalidate the lazy loaded data
   		data = null;
   	}
   
   	//getter/setter for page number
   	public int getPageNumber() {
   		return pageNumber;
   	}
   	public void setPageNumber(int pageNumber) {
   		this.pageNumber = pageNumber;
   	}
   }
   

   We lazy load the results so for each request, we start with nothing and then load the results when the restore view phase looks for them. In the render response phase, the same results are used unless the next/previous page methods are called and the data value is set to null and invalidated. In this case when the data is requested in the render response phase, we see it is null and so it will be loaded fresh for the new page number.

3. Now we modify the existing home.xhtml page to show a table and add two buttons to move to the previous and next pages.

   <ui:define name="content">
   
   	<h:dataTable value="#{dataBean.data}" var="v_value">
   		<h:column>
   			<f:facet name="header">Value</f:facet>
   			#{v_value}
   		</h:column>
   	</h:dataTable>
   	<h:form>
   		<h:commandButton action="#{dataBean.previousPage}" value="Previous" />
   		Page #{dataBean.pageNumber}
   		<h:commandButton action="#{dataBean.nextPage}" value="Next" />
   		<h:inputHidden value="#{dataBean.pageNumber}" />
   	</h:form>
   </ui:define>
   

   Fairly straightforward, we just show the list of numbers and have buttons for navigating. We store the page number in a hidden field and post it back to our backing bean so we have a stateless setup. I also added a phase listener that I’ve used before to log the timing of the JSF requests that is documented in this post (Timing JSF Requests using a Phase Listener). Since this was for Seam originally I modified it by removing the logger code and just pushing the log text to System.out. You can turn it on and off by removing it from the faces-config.xml file in the lifecycle section.

4. In a command console enter mvn clean jetty:run to start the server and go to the home page at http://localhost:8080/fastapp/home.jsf.

When you first go to the page, you trigger a GET request which will cause the data to be loaded one time and displayed. In our output log we see :

Generating Data starting from 0

Fantastic. At this point, we know the page took 2 seconds to render. If we click the next or previous buttons, we cause a postback which will restore the view (including rebuilding the data) and then change the page number which will invalidate the data before again rebuilding the data for the new page. We see this in the log as :

Generating Data starting from 0
Generating Data starting from 10

If you are using the phase listener to time it, you will see the two requests as :

//first request initiated
Executed Phase RESTORE_VIEW 1
Generating Data starting from 0
Execution Time = 2228ms
Executed Phase RENDER_RESPONSE 6

//click next page to trigger the postback and response
Generating Data starting from 0
Executed Phase RESTORE_VIEW 1
Executed Phase APPLY_REQUEST_VALUES 2
Executed Phase PROCESS_VALIDATIONS 3
Executed Phase UPDATE_MODEL_VALUES 4
Executed Phase INVOKE_APPLICATION 5
Generating Data starting from 10
Execution Time = 4116ms
Executed Phase RENDER_RESPONSE 6

You can see the first request took 2 seconds while the second request took over 4 seconds. The problem here is that the data is being fetched twice, once for the restore view and again for the rendering of the response with the new data as you can see in the phase listener log entries.

Solution

The solution to the problem is to skip fetching the data the first time altogether. It isn’t needed, it isn’t even used and it isn’t even the correct data (don’t worry, I’ll explain that later). In the FacesContext object there is a method called getRenderResponse() which returns true if the render response method has been called and we are in the rendering phase. Until we are rendering the page, we don’t really need our data so we only load it if this method returns true.

	//generates the list of data, think of this as an expensive DB operation
	private List<Integer> generateData()  {
		if (!FacesContext.getCurrentInstance().getRenderResponse()) {
			return null;
		}
		System.out.println("Generating Data starting from "+pageNumber);
		...
		...
		...
	}

It’s that simple, now redeploy the application load the page and click next, this time, we only get one data fetch per page request even on postbacks because we don’t bother loading the data until we really need it in the render response and if you look at the timing, our pages are loading twice as fast since we only fetch half the data.

//initial request
Executed Phase RESTORE_VIEW 1
Generating Data starting from 0
Execution Time = 2278ms
Executed Phase RENDER_RESPONSE 6

//click the next button to trigger a postback - look, no data loaded until the response is rendered
Executed Phase RESTORE_VIEW 1
Executed Phase APPLY_REQUEST_VALUES 2
Executed Phase PROCESS_VALIDATIONS 3
Executed Phase UPDATE_MODEL_VALUES 4
Executed Phase INVOKE_APPLICATION 5
Generating Data starting from 10
Execution Time = 2302ms
Executed Phase RENDER_RESPONSE 6

So there you go, you can increase the speed of your JSF pages by only loading data when you really need it, I guess kind of lazy lazy loading data.

What about that bug we are dodging?

Ah yes, that thing, not sure if it can be called a bug but to see the problem, remove the code to check for the render response so we do the double data request on postbacks. Now load up the application and click the next button twice, and you should see the following log :

//initial GET request, we only load the data once
Generating Data starting from 0

//Click next, trigger a postback with two data fetches
Generating Data starting from 0
Generating Data starting from 10

//Click next again, trigger a postback with two more fetches.
Generating Data starting from 0 --err, this isn't right it should be 10
Generating Data starting from 20

When we do the second postback, the first set of data fetched is starting from position 0. We are loading our data using the default pageNumber value of 0. So not only are we loading data we don’t need, we are loading the wrong data. This could have consequences if say you are in a search page and the postback triggers an unconstrained search which may take longer than one with search parameters set.

The reason for this is that the restore view process takes place before the request values are applied so the pageNumber is set to the default value of zero which makes the fetching of the data even more useless. I’m not sure it can be called a bug since the value hasn’t been set at the restore view phase The question is whether it is correct for the restore view phase to fetch data based on values that haven’t yet been initialized and if so, what’s the point?

A Feature?

You know, thinking about it, this might really be a feature, not a bug. It’s feasible to utilize the state of the pageNumber value to determine whether we can return the results if we change its type to Integer. We know that we don’t need to fetch the data if the page number is null because we haven’t hit the read request values stage so we must still be in the restore view stage and therefore don’t need any data.
The only problem comes with the initial setting of the value when you first enter the page, what sets it from null to zero initially. You’d have to fudge around with the getters and settings, plus it would be hard to display that initial page of results since it would always be empty.

The source code for this project is available from here (fastapp.zip). To run, simply unzip, and in the console, type mvn clean jetty:run or mvn clean tomcat:run and go to http://localhost:8080/fastapp/home.jsf.

]]> http://www.andygibson.net/blog/article/double-the-speed-of-some-of-your-jsf-pages-and-dodge-bugs-too/feed/ 8 http://www.andygibson.net/blog/article/generate-test-data-with-datafactory/ http://www.andygibson.net/blog/article/generate-test-data-with-datafactory/#comments Tue, 08 Feb 2011 13:18:51 +0000 Andy Gibson http://www.andygibson.net/blog/?p=1751 DataFactory is a project I just released which allows you to easily generate test data. It was primarily written for populating database for dev or test environments by providing values for names, addresses, email addresses, phone numbers, text, and dates.

To add DataFactory to your maven project, just add it as a dependency in your pom.xml file.

<dependency>
	<groupId>org.fluttercode.datafactory</groupId>
	<artifactId>datafactory</artifactId>
	<version>0.8</version>
	<type>jar</type>
</dependency>

Generating Test Data

Now you can create instances of the DataFactory class and create data :

public class Main {

	public static void main(String[] args) {
		DataFactory df = new DataFactory();
		for (int i = 0; i < 100; i++) {
			String name = df.getFirstName() + " "+ df.getLastName();
			System.out.println(name);
		}
	}
}

The produced output is :

Lindsey Craft
Erica Larsen
Ryan Levine
Erika Smith
Brooklyn Sloan
Karen Mayer
Eddie O'neill
Nancy Stevens

The DataFactory class can generate different types of values, from addresses to random text to random dates, to dates within a fixed time period. Addresses and business names can be created using the following code :

DataFactory df = new DataFactory();
for (int i = 0; i < 100; i++) {
	String address = df.getAddress()+","+df.getCity()+","+df.getNumberText(5);
	String business = df.getBusinessName();
	System.out.println(business + " located at " + address);
}

to produce :

Uvalda Signs located at 1383 Beam Way,Lyons,19316
Alma Accounting located at 1386 Countiss St,Nashville,14967
Fort Stewart Engineering located at 1753 Bethesda Rd,Springfield,26306
Sugar Hill Textiles located at 1141 Loudon Circle,Cordele,83937
Albany Engineering located at 1185 Grieves Avenue,Sugar Hill,36753
Poulan Insurance located at 816 Cohen Blvd,Lake City,74839
Crescent Services located at 1085 Cloveridge Boulevard,Bemiss,08769

Dates

There are a number of features to create dates, the first being creating a random date which is usually in a given sensible date range.

DataFactory df = new DataFactory();
Date minDate = df.getDate(2000, 1, 1);
Date maxDate = new Date();
for (int i = 0; i < 10; i++) {
	Date start = df.getDateBetween(minDate, maxDate);
	System.out.println("Date = "+start);
}

This produces a list of random dates between 1/1/2000 and the current date. Typically, a random date might be constrained by some other date, for example you can’t have an end date that occurs before the start date. In this case, you would plug the start date in as the minimum date value :

DataFactory df = new DataFactory();
Date minDate = df.getDate(2000, 1, 1);
Date maxDate = new Date();

for (int i = 0; i < 10; i++) {
	Date start = df.getDateBetween(minDate, maxDate);
	Date end = df.getDateBetween(start, maxDate);
	System.out.println("Date range = " + dateToString(start) + " to " + dateToString(end));
}

The result is a list of dates where the second date is always later than the first :

Date range = 04/29/2005 to 07/16/2006
Date range = 08/07/2009 to 01/19/2010
Date range = 09/22/2000 to 12/15/2003
Date range = 07/31/2004 to 03/24/2009
Date range = 06/27/2003 to 01/10/2007
Date range = 07/10/2003 to 04/02/2008
Date range = 01/04/2003 to 01/12/2005

In many cases, you might want your end date to be only within a few days of the start date. For example, helpdesk support tickets or hotel stays don’t last for years. To do this, you can specify the number of days from the base date you want to generate a result. In this case, we make the end date within 10 days of the begin date :

for (int i = 0; i < 10; i++) {
	Date start = df.getDateBetween(minDate, maxDate);
	Date end = df.getDate(start, 0, 10); //set end to within 10 days of the start
	System.out.println("Date range = " + dateToString(start) + " to " + dateToString(end));
}

And the result :

Date range = 04/29/2005 to 04/30/2005
Date range = 12/29/2003 to 12/30/2003
Date range = 06/25/2003 to 07/03/2003
Date range = 10/19/2009 to 10/19/2009

You can also specify a negative minimum days value that could return a date prior to the base date or a positive minimum date value to get a later date. Here’s a more complex example that uses different date rules to come up with some complex test data.

for (int i = 0; i < 10; i++) {
	 //generate an order date
	Date orderDate = df.getDateBetween(minDate, maxDate);

	//estimate delivery 4-10 days after ordering
	Date estimatedDeliveryDate = df.getDate(orderDate, 4, 10);

	//deliver between 2 days prior and 3 days after delivery estimate
	Date actualDeliveryDate = df.getDate(estimatedDeliveryDate, -2, 3); 

	String msg =  "Ordered on "+dateToString(orderDate) +
		" deliver by = "+dateToString(estimatedDeliveryDate)+
		" delivered on " + dateToString(actualDeliveryDate);					

	if (estimatedDeliveryDate.before(actualDeliveryDate)) {
		msg = msg + " - LATE";
	}
	if (estimatedDeliveryDate.after(actualDeliveryDate)) {
		msg = msg + " - EARLY";
	}
	System.out.println(msg);
}

Here we calculate an order date, and create a delivery date that is at least 4 days out but no more than 10, and then we created an actual delivery date that is between 2 days prior and 3 days after the expected delivery date.
Notice how we cherry picked the dates, the estimated delivery date is at least 4 days out from the order date, and the actual delivery date will only be at most 2 days prior to the estimated date. This means the actual delivery date is always at least 2 days out from the order date and we won’t get a delivery date value that is before the item was ordered. This code produces the following values :

Ordered on 04/29/2005 deliver by = 05/06/2005 delivered on 05/06/2005
Ordered on 08/07/2009 deliver by = 08/13/2009 delivered on 08/13/2009
Ordered on 09/22/2000 deliver by = 09/27/2000 delivered on 09/25/2000 - EARLY
Ordered on 07/31/2004 deliver by = 08/07/2004 delivered on 08/09/2004 - LATE
Ordered on 06/27/2003 deliver by = 07/04/2003 delivered on 07/04/2003
Ordered on 07/10/2003 deliver by = 07/19/2003 delivered on 07/18/2003 - EARLY
Ordered on 01/04/2003 deliver by = 01/08/2003 delivered on 01/08/2003

Custom Random Values

If there is a set of values that is very specific to your application that you might want to generate data from, you can use methods on the DataFactory class to return values with the option for it to be randomly be a default value.

	public static void main(String[] args) {
		DataFactory df = new DataFactory();

		//favorite animal
		String[] values = {"Cat","Dog","Goat","Horse","Sheep"};
		for (int i = 0; i < 100; i++) {
			System.out.println(df.getItem(values,80,"None"));
		}
	}

This example uses the array of animals and returns a value with a 20% chance of being the default value of “None” to produce the following :

Sheep
None
Dog
Horse

Textual Data

Random text data comes in two forms, absolutely random data and text data made up of words. You can generate either using the following methods :

DataFactory df = new DataFactory();
System.out.println(df.getRandomText(20, 25));
System.out.println(df.getRandomChars(20));
System.out.println(df.getRandomWord(4, 10))

which produces

badly numbers good hot I
ywyypgqorighfawpftjq
demanded

All three of these methods can be passed a single length which returns a fixed length string, or a min/max length which produces a random string with a length somewhere between the min/max. For the single word method, if there are no words in the dictionary of suitable length, then a word is generated using random characters.

Changing the test data values produced

The data used to generate the values come from classes that can be replaced with other versions. For example, the name values can be changed by providing the DataFactory instance with an object that implements the NameDataValues interface. Here is a simple class that does that to return Scandinavian first names and delegates to the the default implementation to return all the other values.

public class ScandinavianNames  implements NameDataValues {

	//first name values to use
	String[] firstNames = {"Anders","Freydís","Gerlach","Sigdis"};

	//delegate to the default implementation for the other values
	NameDataValues defaults = new DefaultNameDataValues();

	public String[] getFirstNames() {
		//return our custom list of names
		return firstNames;
	}

	//for the other values, just use the defaults
	public String[] getLastNames() {
		return defaults.getLastNames();
	}

	public String[] getPrefixes() {
		return defaults.getPrefixes();
	}

	public String[] getSuffixes() {
		return defaults.getSuffixes();
	}

}

Obviously, to use all your own names you would add and return values for last name and the suffix/prefix values. To use this new implementation, just create an instance of the data provider and pass it to the instance of the data factory.

public static void main(String[] args) {
	DataFactory df = new DataFactory();
	df.setNameDataValues(new ScandinavianNames());
	for (int i = 0; i < 10; i++) {
		System.out.println(df.getName());
	}
}

Our results are

Sigdis Craft
Gerlach Larsen
Sigdis Levine
Sigdis Smith
Freydís Sloan
Gerlach Mayer

You can always start working with the default implementation and use a more locale specific implementation if you need it later.

The different pieces that can be replaced are as follows :

• NameDataValues – Generates names and suffix/prefixes
• ContentDataValues.java – Generates words, business types, email domain names and top level domain values
• AddressDataValues – Generates city names, street names and address suffixes

Note that if you intend on replacing the component that generates words, you should have a good collection of words of various lengths from 2 up to say 8 or more characters.

Hopefully this will give you a head start in generating data in development and test environments for new projects. Now I have DataFactory in the Central Maven Repository I plan on using this in the Knappsack archetypes rather than hard coding the data which was in fact generated from an earlier DataFactory implementation.

]]> http://www.andygibson.net/blog/article/generate-test-data-with-datafactory/feed/ 3