Andy Gibson » CDI

Implementing Spring MVC with CDI and Java EE 6 part 2

Andy Gibson — Wed, 01 Feb 2012 12:28:33 +0000

In this second article on implementing Spring MVC in Java EE 6 we’ll take the metadata we extracted in part one and use it to invoke request mapped controller methods in response to web requests and then direct the user to a web page based on the result of the method.

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.


  
    View Person
  
  
    View Person

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.


    
        Editing Person
    
    
        Editing Person
        
            Some Form Here

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.

Implementing Spring MVC with CDI and Java EE 6 part 1

Andy Gibson — Tue, 17 Jan 2012 12:30:36 +0000

One of the opinions I’ve had over the last couple of years is that Spring makes things look really easy, and CDI is a great dependency injection framework. Throw in this article suggesting you can build your own Java EE 7 and it sounds like a challenge, so for fun, I thought I might have a go at implementing a subset of Spring MVC on top of CDI with Java EE 6.

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 :

Prefix	Suffix	Request Methods	Method
`/somePath/`	`page1.do`	`GET,POST`	MyController.someMethod()
`/somePath/`	`page2.do`	`GET,POST`	MyController.someMethod()

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&lt;Controller&gt; CONTROLLER_LITERAL = new AnnotationLiteral&lt;Controller&gt;() {
        private static final long serialVersionUID = -3226395594698453241L;
    };

    @Inject
    private BeanManager beanManager;

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

    private void add(Class&lt;?&gt; 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&lt;?&gt; 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.

Announcing CDISource

Andy Gibson — Mon, 28 Mar 2011 13:38:01 +0000

In the last few weeks I have been rather busy working on a new project with Rick Hightower, who is fairly well known for his training and writings on Spring and JSF, and Rob WIlliams who is a blogger known as much for meddling in new technologies (and getting mad at them) as he is for intertwining various historical and literary references in his posts. The result of this is the CDISource project which aims to advocate and facilitate the use of the JSR 299 – Java Contexts and Dependency Injection framework across the Java landscape.

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.

Simple RESTful services in Glassfish Pt 2

Andy Gibson — Mon, 21 Mar 2011 12:39:13 +0000

In part 2 of this article, we are going to create a data driven web service that will return JSON and XML to the client, and then use jQuery to add a new item to the database and display it in our page.

In part 1, we looked at creating simple web services and now we’re going to look at making something more practical and interesting. We’ll start from where we left off with the source code as it was at the end of the part 1 which you can download from here (restwebdemo_pt1) if you want to follow along. If not, the final source can be downloaded from here (restwebdemo_pt2).

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.

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.

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.

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 students = new ArrayList();

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.

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 :



	2010-08-27T16:36:57.015-04:00
	1
	2010-08-27T16:36:57.015-04:00
	Computing for Beginners
	CS101

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.



Insert title here



Message Div


    
    	Create Course
    	
	        Title

    	    

    	
    	
        	Code

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.

JBoss Java EE 6 spec dependency in Maven

Andy Gibson — Fri, 04 Feb 2011 13:52:47 +0000

Adam Bien wrote about the Troubled with the crippled Java EE 6 APIs in Maven and a solution for them. Another solution has presented itself now that JBoss has finalized the Java EE 6 spec pom and added it to their public repositories as of early January 2011.

You can include the spec in your own project by adding the following to your pom.xml :


	org.jboss.spec
	jboss-javaee-6.0
	1.0.0.Final
	pom

You may also need to add the JBoss repository to your pom.xml which is defined as :


	
		repository.jboss.org
		JBoss Repository
		http://repository.jboss.org/nexus/content/groups/public-jboss/

I’ll be adding this pom to the Knappsack archetypes to resolve some of the issues people have been facing with the broken spec dependency.

A Little Less Conversation…

Andy Gibson — Wed, 02 Feb 2011 13:11:07 +0000

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.

Handling missing resources with CDI Events

Andy Gibson — Tue, 11 Jan 2011 14:18:04 +0000

In part 1, we created a simple application that made use of string resource bundles in JSF and in part 2 we extended it by using CDI to inject the resource provider into beans so we can re-use our code for accessing locale specific string based resources.

One benefit of using CDI to inject your beans instead of just creating them manually is the ability to utilize the event mechanism within those beans. In this example, we are going to fire an event when we discover a resource is missing.

Start by creating a MissingResourceInfo class that stores the info regarding the missing resource (key and locale). This will be passed along with the event so the observer has all the info when it receives the event.

public class MissingResourceInfo {

	private final String key;
	private final String locale;

	public MissingResourceInfo(String key, Locale locale) {
		this(key, locale.getDisplayName());
	}

	public MissingResourceInfo(String key, String locale) {
		super();
		this.key = key;
		this.locale = locale;
	}

	public String getKey() {
		return key;
	}

	public String getLocale() {
		return locale;
	}
}

We fire an event when we discover a resource key is missing from the locale specific properties file being used. In the MessageProvider class from part 2, we inject the Event instance in to a field and modify the getValue method to fire off the event when a key is missing.

@RequestScoped
public class MessageProvider {

	@Inject
	private Event event;
	....
	....
	public String getValue(String key) {
		String result = null;
		try {
			result = getBundle().getString(key);
		} catch (MissingResourceException e) {
			result = "???" + key + "??? not found";
			event.fire(new MissingResourceInfo(key, getBundle().getLocale()));
		}
		return result;
	}
}

Finally, we want to add an observer for that event that handles it when it is fired. To do this, we will add a new class for this purpose.

public class MissingResourceObserver {

	public void observeMissingResources(@Observes MissingResourceInfo info) {
		String template = "Oh noes! %s key is missing in locale %s";
		String msg = String.format(template, info.getKey(), info.getLocale());
		System.out.println(msg);
	}

}

Finally, to see it in action, we need to add bean getter to fetch a non-existing value from the bundle.

@Named
@RequestScoped
public class AnotherBean {

	public String getMissingResource() {
		return provider.getValue("ImNotHere");
	}
}

We can see this in action by adding to our JSF page a call to this property
```
#{anotherBean.missingResource}
```
Results in the following being displayed in the console :
```
Oh noes! 'ImNotHere' key is missing from locale English (United States)
```

Remember, you can have as many event observers as you want so you can have one that just logs it to the console or one that emails if missing text strings are urgent (i.e. production). You could have it write the missing values to the database so during development cycles, the missing strings can be exported and put into the properties files. This is especially useful if you have third parties handling the translation where you can send them a list of missing items to translate in one big batch.

What about EL?

This works great when we are accessing resource bundles from Java, but what about when we are using EL expressions to access the values. JSF channels those expressions straight to the resource bundle without the ability to intercept them. One way to fix this would be to write our own EL expression resolver and see if the root of the expression maps to a resource bundle and if so try to obtain the value from the bundle and fire the event if the item is not found. This would work, but it seems overkill since every EL expression would end up going through the resolver.
Remember that the syntax for accessing resource strings in EL is #{bundlename.key}, and Java Map classes can also be accessed using the same syntax. What we can do is create a named bean that (barely) implements the map interface and in the get method, it gets the value from the injected resource bundle. This means EL expressions will use our Map bean and we can delegate the call to the Message provider which will handle missing expressions.

Start by creating a new bean that implements the Map interface. Most of the methods will throw exceptions that they are not implemented, we only really care about the method to get values.

@Named("messages")
@RequestScoped
public class ResourceMap implements Map {

	@Inject
	private MessageProvider provider;

	@Override
	public int size() {
		return 0;
	}

	@Override
	public boolean isEmpty() {
		return false;
	}

	@Override
	public boolean containsKey(Object key) {
		return provider.getBundle().containsKey((String) key);
	}

	@Override
	public boolean containsValue(Object value) {
		throw new RuntimeException("Not implemented");
	}

	@Override
	public String get(Object key) {
		return provider.getValue((String) key);
	}

	@Override
	public String put(String key, String value) {
		throw new RuntimeException("Not implemented");
	}

	@Override
	public String remove(Object key) {
		throw new RuntimeException("Not implemented");
	}

       ....
       ....
       ....
}

If the interface method isn’t listed, assume it throws a “not implemented” exception. We inject the MessageProvider instance so we can re-use our message provider bean to fetch messages and fire the events.

We gave the bean the name messages so if we go to our web page and add the following to our page :
```
First name from map = #{messages.firstName}

Missing name from map = #{messages.missingValue}
```
When we run our application and refresh the page, we get the value displayed for messages.firstName, and a missing value for messages.missingValue. In our server log we get
```
Oh noes! missingValue key is missing in locale English (United States)
```
Since we re-used the MessageProvider bean, it fires the event when it cannot find a key value so even though we called it from the JSF page, it ended up being routed through to our message provider and the event being fired.

How you use this is up to you, but since the syntax is the same whether you use the Map or the JSF resource variable, you can switch between the two depending on whether it is a development or production environment. You may also use different event handlers depending on the deployment environment. Alternatively, you may be worried about performance in production, or the fact that you lose autocompletion if you use the map in development.
To switch implementations, just give either the JSF resource variable, in faces-config or the MessageProvider bean the name used for your resource string component. You can switch components without having to change either your code or your JSF pages.

Download the Maven source code for this project and run it locally by typing unzipping it and running mvn clean jetty:run in the command line, and going to http://localhost:8080/resourcedemo/.

Injecting String Resource Services with CDI

Andy Gibson — Tue, 23 Nov 2010 15:02:26 +0000

In this post we looked at adding String resource bundles to our JSF applications to move our string constants into external resources that we can define for different locales. Now I want to extend that example to show how you can expand on that by using injection to access those resources.

We finished off with a MessageProvider class that was responsible for fetching the resource bundle and had methods for fetching values from that bundle. We created this class manually and accessed the string resources from it. The problem here is that we need to keep on recreating the provider in each piece of code that needs it.

Doing things the CDI way

You could construct an instance of the MessageProvider each time you need it, but instead, we should look at how we can change our existing code to make it more CDI like. We can make the method that fetches the bundle a producer method and then inject the resource bundle where needed. If we give it a long enough scope, we can re-use it in the same request.

First we’ll write a new Qualifier for the bundle so we can uniquely identify this bundle in a type safe manner. We may want to produce and inject multiple resources that will all be of the same type (ResourceBundle) so using a qualifier is a probably a good idea.

@Qualifier
@Target({ TYPE, METHOD, PARAMETER, FIELD })
@Retention(RUNTIME)
@Documented
public @interface MessageBundle {

}

We’ll add a @Produces annotation to the getBundle() method.

public class MessageProvider {

     @Produces @MessageBundle
     public ResourceBundle getBundle() {
		if (bundle == null) {
			FacesContext context = FacesContext.getCurrentInstance();
			bundle = context.getApplication().getResourceBundle(context, "msgs");
		}
		return bundle;
	}
	...
        ...
        ...
}

Now we just need to inject this into our bean and use the injected bundle instead of constructing our own instance of the MessageProvider class.

@Named
@RequestScoped
public class SomeBean {

	@Inject @MessageBundle
	private ResourceBundle bundle;

	public String getMessage() {
		String msg = null;
		String key = "someMessage";
		try {
			msg = bundle.getString(key);
		} catch (MissingResourceException e) {
			msg = "??"+key+"?? is missing!";
		}
		return MessageFormat.format(msg, "SomeValue");
	}
}

While this is more CDI-ish, it does have the problem that it consists of more code since we re-produce the exception handling code each time. So we probably need to use something that consists of more than just the bundle, say maybe the whole MessageProvider class with the methods to fetch key values. The beauty here is that we we don’t need to do anything to achieve this except give the MessageProvider class a scope :

@RequestScoped
public class MessageProvider {
    ....
    ....
}

No we just add an injection point for the MessageProvider class in our bean. We’ll create a new bean for this called AnotherBean :

@Named
@RequestScoped
public class AnotherBean {

	@Inject
	private MessageProvider provider;

	public String getFirstNameCaption() {
		return provider.getValue("firstName");
	}
}

In our JSF page we add a reference to the property to display the value :

First Name Caption = #{anotherBean.firstNameCaption}

This results in the following text being displayed :

First Name Caption = First Name

You might notice that our old bean is still using the resource bundle from the producer method, and everything is still working. This is because beans can be injectable and still contain producer methods. You will also find that across the request, the injected instance of the bundle is always the same as the one in provider.getBundle(). This is because every time the bundle is produced, the MessageProvider is constructed and put into request scope and the bundle value is returned. This bundle value is retained in the MessageProvider instance. No matter how many times we inject the bundle, the same one is used, even though we didn’t give it a request scope. This is actually a useful thing because the resource bundle cannot be proxied by CDI so it cannot be put into request scope itself, but it can be put into request scope if it is contained in another bean (in this case, the MessageProvider).

This shows not only how flexible CDI is in making objects available to your applications, but how easy it is to tweak how those objects are made available, all without changing the underlying code.

Next time we’ll look at using event handling to notify us of missing resources.

You can download the Maven source code for this project and run it locally by unzipping it and running mvn clean jetty:run in the command line and going to http://localhost:8080/resourcedemo/.

CDI @Alternative Info

Andy Gibson — Thu, 28 Oct 2010 03:02:07 +0000

The @Alternative CDI annotation allows you to have multiple matching dependencies for a given injection point. This means you can define beans that provide implementations for the same interface without worrying about ambigious dependency errors. When you mark a class with the @Alternative annotation, it is effectively disabled and cannot be considered for injection. The only exception is for the class that is defined in the beans.xml configuration file.


	org.company.project.bean.SomeBean

Once this bean is identified, it is then used in any injection point that matches for this bean. No other beans for similar injection points can be declared as the ‘active’ alternative.

Alternative is really an odd name for it, but all it does is disable the bean while adding it to the beans.xml file enables it and makes it available to CDI.

JBoss 6.0.0 M5 Has Been Released

Andy Gibson — Sun, 26 Sep 2010 15:03:28 +0000

It looks like JBoss 6.0 milestone 5 has just been released. Not that anyone would know it since they haven’t announced it anywhere, I just saw Aslak Knutsen tweet it. Dan Allen also posted slides from his JavaOne presentation on Weld and the future of Seam.