A number of people assume that there is some meaning to all these different types of beans that they just don’t understand. However, the problem is down to the different APIs overlapping which is unfortunate.

JSF Managed Beans, CDI Beans and EJBs

JSF was initially developed with its own managed bean and dependency injection mechanism which was enhanced for JSF 2.0 to include annotation based beans. When CDI was released with Java EE 6, it was regarded as the managed bean framework for that platform and of course, EJBs outdated them all having been around for well over a decade.

The problem of course is knowing which one to use and when, but they all involve the same process. Typically a class has to be identified as a managed bean, and where necessary, will need a scope,qualifiers and a name if it is to be used in JSF. What follows is a brief description of the different types of managed beans and how and when to use them.

Let’s start with the simplest, JSF Managed beans.

JSF Managed Beans

In short, don’t use them if you are developing for Java EE 6 and using CDI. They provide a simple mechanism for dependency injection and defining backing beans for web pages, but they are far less powerful than CDI beans.

They can be defined using the @javax.faces.bean.ManagedBean annotation which takes an optional name parameter. This name can be used to reference the bean from JSF pages.

Scope can be applied to the bean using one of the different scopes defined in the javax.faces.bean package which include the request, session, applicaion, view and custom scopes.

@ManagedBean(name="someBean")
@RequestScoped
public class SomeBean {
    ....
    ....
}

JSF beans cannot be mixed with other kinds of beans without some kind of manual coding.

CDI Beans

CDI is the bean management and dependency injection framework that was released as part of Java EE 6 and it includes a complete, comprehensive managed bean facility. CDI beans are far more advanced and flexible than simple JSF managed beans. They can make use of interceptors, conversation scope, Events, type safe injection, decorators, stereotypes and producer methods.

To deploy CDI beans, you must place a file called beans.xml in a META-INF folder on the classpath. Once you do this, then every bean in the package becomes a CDI bean. There are a lot of features in CDI, too many to cover here, but as a quick reference for JSF-like features, you can define the scope of the CDI bean using one of the scopes defined in the javax.enterprise.context package (namely, request, conversation, session and application scopes). If you want to use the CDI bean from a JSF page, you can give it a name using the javax.inject.Named annotation. To inject a bean into another bean, you annotate the field with javax.inject.Inject annotation.

@Named("someBean")
@RequestScoped
public class SomeBean {

    @Inject
    private SomeService someService;
}

Automatic injection like that defined above can be controlled through the use of Qualifiers that can help match the specific class that you want injected. If you have multiple payment types, you might add a qualifier for whether it is asynchronous or not. While you can use the @Named annotation as a qualifier, you shouldn’t as it is provided for exposing the beans in EL.

CDI handles the injection of beans with mismatched scopes through the use of proxies. Because of this you can inject a request scoped bean into a session scoped bean and the reference will still be valid on each request because for each request, the proxy re-connects to a live instance of the request scoped bean.

CDI also has support for interceptors, events, the new conversation scope and many other features which makes it a much better choice over JSF managed beans.

EJB

EJBs predate CDI beans and are in someways similar to CDI beans and in other ways very different. Primarily, the differences between CDI beans and EJBs is that EJBs are :

• Transactional
• Remote or local
• Able to passivate stateful beans freeing up resources
• Able to make use of timers
• Can be asynchronous

The two types of EJBs are called stateless and stateful. Stateless EJBs can be thought of as thread safe single-use beans that don’t maintain any state between two web requests. Stateful EJBs do hold state and can be created and sit around for as long as they are needed until they are disposed of.

Defining an EJB is simple, you just add either a javax.ejb.Stateless or javax.ejb.Stateful annotation to the class.

@Stateless
public class BookingService {

  public String makeReservation(Item Item,Customer customer) {
    ...
    ...
  }
}

Stateless beans must have a dependent scope while a stateful session bean can have any scope. By default they are transactional, but you can use the transaction attribute annotation.

While EJBs and CDI beans are very different in terms of feaures, writing the code to integrate them is very similar since CDI beans can be injected into EJBs and EJBs can be injected into CDI beans. There is no need to make any distinction when injecting one into the other. Again, the different scopes are handled by CDI through the use of proxying. One exception to this is that CDI does not support the injection of remote EJBs but that can be implemented by writing a simple producer method for it.

The javax.inject.Named annotation as well as any Qualifiers can be used on an EJB to match it to an injection point.

When to use which bean

How do you know when to use which bean? Simple.

Never use JSF managed beans unless you are working in a servlet container and don’t want to try and get CDI working in Tomcat (although I have a Maven archetype for that so there’s no excuse).

In general, you should use CDI beans unless you need the advanced functionality available in the EJBs such as transactional functions. You can write your own interceptor to make CDI beans transactional, but for now, its simpler to use an EJB until CDI gets transactional CDI beans which is just around the corner. If you are stuck in a servlet container and are using CDI, then either hand written transactions or your own transaction interceptor is the only option without EJBs.

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.

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.

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.

<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.

The descriptors project contains classes implementing DSLs for creating configuration files that can be exported to text. These files can then be added to the Shrinkwrap archive. Here’s a basic example that adds a beans.xml for CDI support.

// first create the descriptor
BeansDescriptor bd = Descriptors.create(BeansDescriptor.class);

// add alternatives classes
bd.alternativeClasses(EmailEventHandler.class, LogEventHandler.class)
.decorator(BillingProcessorDecorator.class);// add decorator classes

System.out.println(bd.exportAsString());

Produces a result of

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<beans xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/beans1_0.xsd">
    <decorators>
        <class>org.demo.beans.BillingProcessorDecorator</class>
    </decorators>
    <alternatives>
        <class>org.demo.EventHandlers.EmailEventHandler</class>
        <class>org.demo.EventHandlers.LogEventHandler</class>
    </alternatives>
</beans>

First you must get an instance of the descriptor which is the basis for the dsl, and then you can define the properties for the descriptor using the methods defined on it, chaining the calls as needed.

Another example uses the PersistenceDescriptor and can be used to create persistence.xml files :

PersistenceDescriptor pd = Descriptors.create(PersistenceDescriptor.class);

pd.persistenceUnit("myUnit")
		.classes(Person.class, User.class)
		.description("Default Persistence Unit")
		.formatSql()
		.schemaGenerationMode(SchemaGenerationModeType.CREATE_DROP)
		.jtaDataSource("java:/DefaultDS")
		.property("hibernate.cache.provider_class","org.hibernate.cache.HashtableCacheProvider")
		.version("2.0");

		System.out.println(pd.exportAsString());

Produces :

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<persistence xmlns="http://java.sun.com/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="2.0" xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd">
    <persistence-unit name="myUnit">
        <description>Default Persistence Unit</description>
        <jta-data-source>java:/DefaultDS</jta-data-source>
        <class>org.demo.model.Person</class>
        <class>org.demo.model.User</class>
        <properties>
            <property name="hibernate.format_sql" value="true"/>
            <property name="hibernate.hbm2ddl.auto" value="create-drop"/>
            <property name="eclipselink.ddl-generation" value="drop-and-create-tables"/>
            <property name="hibernate.cache.provider_class" value="org.hibernate.cache.HashtableCacheProvider"/>
        </properties>
    </persistence-unit>
</persistence>

The project also supports importing configuration files to the associated description type since the descriptors are modeled using JAXB XML bindings. At the moment the following descriptor types are supported :

• web.xml – Web deployment descriptor file
• persistence.xml – JPA Persistence config file
• faces-config.xml – Configuration file for Java Server Faces
• beans.xml – Triggers the use of CDI and can contain configuration info

While the goal is to use these to help generate Shrinkwrap archives, particularly for Arquillian testing, there’s nothing wrong with using them to automatically generate configuration files, especially for new projects.

So now we have a new version, priced at just $199, where you can choose to use a limited version of a dead language (and probably with licensing restrictions). I always find it interesting to see which features they leave out of the basic version, let’s take a look at the Feature Matrix :

• No Code formatting
• No Class Explorer
• No autocompletion for DTD based documents
• No To-Do Lists
• No refactorings
• No diagramming of any kind
• No unit testing
• NO DATABASE SUPPORT (except for Interbase)
• No logging
• No Reports
• No network components

Eh, I could go on but I won’t, to anyone familiar with something like Eclipse most of these items are the basic elements of any IDE that you wouldn’t want to do without. The point is, for $199 today, you can have an IDE from 15-20 years ago. For an extra $600 you can have the professional version which gets you all the basics, but not much more. To create multi-tier datasnap applications, you are looking at spending thousands on an enterprise or architect license. Compare this to the range and scope of the Java APIs that you can get and use for free, whether it be data access, network components, web frameworks or a variety of web servers.

When I moved from Delphi to Java, or even .net, it was like coming out from under a rock and seeing the surface of the Earth for the first time. I have no desire to pay $199 to go back under there.

The Delphi Market

Of course, there is a market for Delphi, there are plenty of places that use it internally for applications, and it really is one of the best ways currently to produce native applications for Windows which after all is still a rather huge market. These people see enough value in upgrading that there is still a market in there, although given the turbulent ownerships of Delphi, probably not a very good one. Meanwhile, Borland was bought by Micro Focus in May 2009.

I tend to object to the calls for something to be made free and open source simply because someone likes it. It simply ignores the masses of time and money that went into making it. However, in this case, I think if Embracadero would like to see any kind of growth, it should look at slashing the prices. Granted, they may be quite happy with the small market of dedicated customers and if they are able to strike a fiscal balance with that, all the best to them.

While cutting prices might make it more attractive, it still might not generate demand (which is probably why they won’t do this). By some standards, the web is now the platform of choice and native apps are in less demand. For corporate customers, there is probably far more demand for web applications for which there are better tools than Delphi. Since code re-usability was never a strong point of Delphi, the ability to leverage existing code is probably minimal, especially given the stateless nature of the web and the stateful nature of a client/server Delphi application.

Before we start getting to the interesting stuff, we have one more boring piece of configuration to perform specific to web services. We need to add the jersey servlet container to our web.xml file:

<servlet>
	<servlet-name>Jersey Web Application</servlet-name>
	<servlet-class>com.sun.jersey.spi.container.servlet.ServletContainer</servlet-class>
	<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
	<servlet-name>Jersey Web Application</servlet-name>
	<url-pattern>/rest/*</url-pattern>
</servlet-mapping>

This also tells Jersey to handle urls starting with /rest and pass it along to our web service methods.

Now we can dive right in an create a new server bean that will respond to requests for web services. For now we’ll just return a simple message from a POJO.

@Path("sample")
public class SimpleService {

	@Path("greet")
	@GET
	public String doGreet() {
		return "Hello Stranger, the time is "+ new Date();
	}
}

The path annotation on the class indicates that this is a root resource class and the path value given specifies the base URI for all the web service methods contained in the class.
On the doGreet method we have @Path which is used to specify the path template this method should match. The @GET annotation is used to differentiate between a sub-resource method that handles the actual web service request and a sub-resource locator method that returns an object that will instead be used to handle the request. In this case, the method has the @GET annotation which means this method handles the request and returns the result.
If you navigate to http://localhost:8080/restwebdemo/rest/sample/greet/ you should see a welcome message with the current date and time.

Now we’ll look at adding parameterized web services that extracts parameters from the request URL and uses them to form the output. Add the following method to the web service class :

@Path("sayHello/{name}")
@GET
public String doSayHello(@PathParam("name") String name) {
	return "Hello there "+name;
}

Again we have the path annotation to indicate what URLs this method will match, and this time we have have {name} added to the URL. This lets us extract a part of the url and give it a name. This name is used in the @PathParam annotation in the method signature to assign the URL fragment to the name parameter . To test our new method, redeploy the application and go to the URL http://localhost:8080/restwebdemo/rest/sample/sayHello/Andy to get the response Hello there Andy

We can also use request parameters to provide values to the method by using the @QueryParam annotation. We’ll create another method that is similar but uses a query parameter instead.

@Path("sayHello")
@GET
public String doSayHelloWithRequestParam(@QueryParam("name") String name) {
	return "Hi there "+name;
}

This time, the URL to use is http://localhost:8080/restwebdemo/rest/sample/sayHello?name=Andy to get the same message.

To make things more interesting, lets add a new page that lets us enter a name in a form and submit it to the web service. Add a new page called form.html with the following content :

<html>
<head>
<title>Insert title here</title>
</head>
<body>
<form action="rest/sample/sayHello" method="GET">
Name <input id="name" name="name"/> <input type="submit" />
</form>
</body>
</html>

Go to this page at http://localhost:8080/restwebdemo/form.html, enter your name and click submit and you should be greeted by name in the next page.

Notice that we had to set the form method to GET because our web service is only set up to respond to GET requests. If we change the form method to POST we can get the following error message :

HTTP Status 405 - Method Not Allowed
type Status report
message Method Not Allowed
description The specified HTTP method is not allowed for the requested resource (Method Not Allowed).

Remember, with REST, those actual verbs have meaning and adds meaning to the request so it is strict on how it matches the method to be called.

To solve this problem, we can add a new method to handle form POSTs like so :

@Path("sayHello")
@POST
public String doSayHelloWithFormParam(@FormParam("name") String name) {
	return "Hi there " + name;
}

Here we changed the @GET to a @POST to allow the different verb and changed the annotation on the name method parameter to @FormParam. The path remains the same because we can have service methods that match the same path, but for different request verbs. We can even have the same verb and path as long as the content type returned is different. The content type is used to specify the type of output the is returned from the method. It is set by adding a @javax.ws.rs.Produces (not to be confused with the CDI Produces annotation). The annotation takes a string parameter that indicates the type of media returned from the method. Common media types are defined as constants in the MediaType class so you can use :

@Path("sayHello")
@POST
@Produces(MediaType.APPLICATION_XML)
public String doSayHelloWithFormParam(@FormParam("name") String name) {
	return "<message>Hi there " + name+"</message>";
}

If you run your form again, and post it, you will get an xml response as follows :

<message>Hi there Andy</message>

Depending on your browser, if you return just the text, you will get an error because the plain text isn’t valid XML and the browser expects XML because that is the response type set on the response from the web service.

To finish up, we are going to do something a little more interesting, we will create a web service to return the name of a course from the database using the sandbox data built into the archetype. For various reasons, we will take the most direct route to getting data access which is to make the web service bean a stateless bean and inject a persistence context using the @PersistenceContext annotation.

1. Add the @Stateless annotation to the SimpleService class and an entity manager field annotated with @PersistenceContext along with the getters and setters.
2. Add a new method to return the course name for the given course id parameter. We will return it as text for the time being :

   @Path("courseName/{id}")
   @GET
   public String getCourseNameFromId(@PathParam("id") Long id) {
   	Course c = entityManager.find(Course.class, id);
   	if (c == null) {
   		return "Not Found, try the index <a href='/restwebdemo/'>page</a> and come back";
   	} else {
   		return c.getTitle();
   	}
   }
   

   Note that the automatic type conversion takes place and the value is converted to a Long automatically. If the course is not found, we suggest the user goes to the main page of the demo. We aren’t just being overly helpful, the test data is generated when you request one of the application pages for the first time. In the current persistence context, when you redeploy, the database is dropped and rebuilt so it will be empty. You need to go to the front page to automatically create the data and then go back to your page to view the course. An example URL is http://localhost:8080/restwebdemo/rest/sample/courseName/124.

Of course you could grab the course object and build your own XML or JSON response to send back to the client, or use a third party library like Jackson to build the JSON response. However, as we’ll see next time, Java EE 6 has all these goodies built in for us, and with a few annotations, we’ll be slinging objects back and forth in no time at all.

You can download the source code for the project from here. Simply unzip, build with maven (mvn clean package) and deploy to Glassfish.

]]> http://www.andygibson.net/blog/article/simple-restful-web-services-with-glassfish/feed/ 3 http://www.andygibson.net/blog/article/a-little-less-conversation/ http://www.andygibson.net/blog/article/a-little-less-conversation/#comments Wed, 02 Feb 2011 13:11:07 +0000 Andy Gibson http://www.andygibson.net/blog/?p=1718 One thing that I wrote that I haven’t really gotten around to examining and verifying in closer detail and validating my position on is the production of the conversational entity manager in the Knappsack archetypes. This article looks at this and re-evaluates my thinking on the use of conversational contexts in CDI.



Defaulting to Request Scoped

It’s one of those things that you write and it works, but something feels wrong with it, and I haven’t had time to go back and look at it. The entity manager is scoped to the conversation so that it will work with as both conversational and request scoped. When an object is scoped to the conversation and there is no long running conversation then the conversation itself is limited to the request so your data, although conversation scoped becomes request scoped. This was a handy way to default data that was mostly request scoped to a request scope while giving it the ability to partake in active conversations. In Seam, this was fairly standard practice since it allowed your model to live in a conversational entity manager without having to worry about detachment issues. However, CDI conversations are different from Seam conversations and their use needs to be a little more focused.

The problem is that CDI is supported in a number of environments within Java EE 6 while the conversation scope is not. To name a few, servlets and web services don’t have default support for conversations and Arquillian tests doesn’t handle conversations well. While we may be able to work around non-conversational servlets, web services and arquillian tests, the problem really goes deeper.

Logically we are thinking about using these beans as request scoped beans because there is no long running conversation. However, the conversational context still needs to be initialized and available to hold these beans. CDI doesn’t magically know to put the conversational beans in the request scope context when there’s no long running conversation, it always puts it in the conversational context.

So, the answer you say is to use request scoped beans and relegate a conversational scope to those cases where you really do need a conversational scope, and not use it everywhere you want request scoped but might need a conversation scoped bean. While this is true, our request scoped beans depend on business logic beans that in turn use the data layer beans that uses our entity manager to access the database. The problem is that the entity manager is conversation scoped so all our beans that depend on it are broken.

The end result is that using some of the tools and API’s with CDI has been rather frustrating since nearly every bean depends on the entity manager at the end of the day and without conversation support it typically breaks with an obscure error message.

The solution is to treat our entity manager like our beans, we only use conversations where absolutely necessary. The question you may be asking yourselves is how to deal with code that is both request and conversation scoped. For example, you load an entity at the start of a wizard into a conversation scoped bean using a conversation scoped entity manager because you want to keep this bean attached for the duration of the conversation. At the end of the conversation, you might want to use the standard request scoped entity Dao to save the entity. Will the request scoped Dao will use a different entity manager from the conversation scoped bean or not? The good news is that we can re-use the same entity manager sourced from the same place and offered up as a request scoped entity manager to get around this so they will use the same entity manager.

Additionally, the introduction of some of the new JSF 2.0 scopes helps out since we can use the flash or view scopes to pass objects from one page to the next or to maintain state between requests. The only problem here is that these scopes are in JSF and not compatible with CDI, or implemented in CDI by default. The Seam 3 faces module provides CDI compatible alternatives and I would put good money on those scopes making it into the next version of CDI.

Lesson Learned

One take away from this is to always make sure everything will play nice together before committing to a particular strategy or design. It would have been a shame to implement our data access layer and find out that we couldn’t use it in our web services or testing.

I’ll be trying to spend a little time working all this out and seeing what the best strategies are, but hopefully this will remove some of the barriers to demonstrating and adding third party integrations into the Knappsack archetypes. This will probably get changed for the next version of the Knappsack archetypes.

]]> http://www.andygibson.net/blog/article/a-little-less-conversation/feed/ 5