Andy Gibson » JEE

JSTL 1.2 Missing From Maven Repositories

Andy Gibson — Thu, 23 Jun 2011 12:45:04 +0000

It seems in the last few weeks or so the Maven JSTL dependency has vanished from at least the central repository. This has caused a number of issues around the web.

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


    javax.servlet.jsp.jstl
    jstl-api
    1.2



    org.glassfish.web
    jstl-impl
    1.2

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

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


    org.jboss.spec
    jboss-javaee-6.0
    1.0.0.Final
    provided
    pom
    
        
            javax.servlet
            jstl
        
    




    javax.servlet.jsp.jstl
    jstl-api
    1.2
    provided

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

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.

Double the speed of (some of) your JSF pages (and dodge bugs too)

Andy Gibson — Thu, 17 Mar 2011 12:49:39 +0000

There was a thread on the JSF LinkedIn group about JSF performance and a number of people complained about the fact that as part of the restore view phase, JSF reconstructs the component tree including binding data to data tables causing unnecessary fetches of data from the database. This article looks at one way of avoiding the additional work to fetch the data.

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

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

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.

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 data;

	//returns the list of data by lazy loading it
	public List getData() {
		if (data == null) {
			data = generateData();
		}
		return data;
	}

	//generates the list of data, think of this as an expensive DB operation
	private List 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 results = new ArrayList();
		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.

Now we modify the existing home.xhtml page to show a table and add two buttons to move to the previous and next pages.
```
	
		
			Value
			#{v_value}
		
	
	
		
		Page #{dataBean.pageNumber}
		
		
	
```
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.
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 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.

Shrinkwrap DSLs Makes Building Config Files Easy

Andy Gibson — Mon, 07 Feb 2011 13:22:08 +0000

If you’ve used Shrinkwrap you might have noticed that creating configuration files can be a bit of a burden requiring you to manually build XML configuration files yourself as strings. This article shows how the DSLs being added to Shrinkwrap will make configuring your deployments far easier.

I’m not sure on the current status of the DSL project, but you can find it on GitHub on the shrinkwrap / descriptors page. These are still in development, but as they are fairly stand-alone, they work well enough to use. To get started, download the maven project from the GitHub page, build and install it.

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



    
        org.demo.beans.BillingProcessorDecorator
    
    
        org.demo.EventHandlers.EmailEventHandler
        org.demo.EventHandlers.LogEventHandler

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 :



    
        Default Persistence Unit
        java:/DefaultDS
        org.demo.model.Person
        org.demo.model.User

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.

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.

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

Considering Thick Client Javascript Applications

Andy Gibson — Wed, 10 Nov 2010 13:34:06 +0000

A post on Javalobby (Are Serverside Web Frameworks Becoming Irrelevant?) got me thinking again about javascript based web apps also called SOFEA or SOUI applications. While I don’t believe that the end is near for server side frameworks, (after all a similar post was written 3 years ago), I think it there is a growing interest in these development models.

Now and again I take a look at javascript based client side web development interacting with web services since the notion of a thick, rich client using distributed stateless reusable web services that can just be deployed off into the cloud can be very alluring.

In practice though, I generally find problems with the essential basics. Data binding is still immature, and I have doubts about using a single page interface for something more complex than Facebook, GMail or google search pages, not to mention having to code your own browser history.

In other examples, the list of items was rendered in the page, and upon completing some Ajaxy action, the HTML for the extra item was added to the list in a separate piece of code. Such practices, which I would imaging are fairly common in these kind of frameworks, are just begging to be a maintenance nightmare (DRY anyone?). You could write some javascript method to render the item in the page and use it in both places, but that seems to defy the syntactic sugar these frameworks target.

There still seems to be some debate as to whether the server side methods are supposed to return XML, JSON or plain HTML. If you return HTML, you may as well stick with a server side framework since that’s where the view layer is still coming from. JSON and XML could make for an interesting development model especially since there is already a lot of support for them. (I planning on a post about Java EE 6 web services returning XML and JSON soon).

I still believe server side component frameworks are the way to go for now. People don’t want to be hand coding moving data values around and micro-managing HTML any more than they want to be pushing values around in CPU registers in assembly language. *Something* (akin to the controller) needs to mediate between the back end and the UI layers, currently, that something resides at the front of the server side. Could it possibly reside on the client? Maybe.

Taking the quote “Google uses Bayesian filtering the way Microsoft uses the if statement” and applying it to frameworks, Component frameworks uses pagination controls the way other frameworks use page parameters. They just operate at a higher level of abstraction that makes development much faster without requiring the application framework generate most of the content (i.e. Rails, Grails).

Another (easily resolved) criticism is that the UI needs to know about the data model in order to know what data to fetch. For example, loading a person and knowing to include the phone and address as well for the person details page. Other times though, you will want just the person instance and their name to display them. This is also a problem for server side frameworks, but the logic to deal with it is on the server as well so it’s still able to load that data. Once it has shuttled off to the client, there’s no ability to lazily load.

On the other hand, this problem gives you the opportunity to introduce a more interesting way of dealing with the data model. You could have a very decoupled data model by using multiple data requests to fetch the data needed for the page. First you load the basic person instance, then make separate requests to fetch an address for a person and then their phone number as they are needed in the page. I remember an interview with Werner Vogels, CTO of Amazon.com claiming.

“If you hit one of Amazon’s pages, it goes out to between 250 and 300 services to build that page.”

The interview itself is quite an interesting read for those interested in SOA (Amazon CTO Werner Vogels). The notion of a very decoupled data model is again rather alluring.

One of my personal problems when looking at most of this technology is that I can’t help but think how much easier and less convoluted it is to do similar things with JSF and CDI or how lacking it is in terms of features. In the back of my mind, the specters of more complex use cases (i.e. multi-page state management, or pages using multiple pagination) cast doubts that these frameworks will be able to be as usable as other frameworks. This probably curtails my ability to experience the benefits of such frameworks and gain enough knowledge to tackle some of the thornier issues leaving me safely in my comfort zone. I also find most excitement over new technology misplaced as people mistake a compact and concise technology for one with a a lack of features.
In the end though, with the Google App Engine, Amazons Web Services, Spring’s cloud efforts, and the focus on cloud based solutions, it is a programming model that well supported and attractive enough to developers that it will probably mature well and is no doubt worth looking at.

Feel free to post in the comments which libraries you are using for the view and server side layers that might be worth taking a look at.

JSF Basics

Andy Gibson — Wed, 08 Sep 2010 12:51:19 +0000

This is a brief tutorial that takes a quick look at some of the very basics of JSF, how we define pages and hook them up to server side objects. Rather than cover the fundamentals of starting a new JSF application, I’m going to start from one of the Knappsack archetypes which can provide you with a JEE 6 application ready to roll. In this case, we are going to start with a servlet based example so you can run it using the embedded servlet containers.

To create the new project, we are going to use the following archetype GAV values. You can also read up on creating a new Knappsack application

groupId = org.fluttercode.knappsack
artifactId=jee6-servlet-basic
version=1.0.5

Once you have your project, just run mvn jetty:run in the command line and navigate to http://localhost:8080/jsfbasics/home.jsf. Ok, so now we are up and running, lets look at a JSF page and what it contains.

JSF uses a templating language called facelets. JSF 1 originally used JSP as its view language, but for JSF 2.0 Facelets became the defacto standards and was adopted as the standard view definition languages for JSF 2.0. In our application, we have a template file called WEB-INF/templates/template.xhtml. The template just has a lot of boilerplate view code but there are some ui:insert tags that mark places in the template where we should insert content. For example, the main content is inserted in a facelets area called content

Main Content

These are insertion points which are used by pages that base themselves on this template. One of the great features of facelets is that the template defines the content points, while the page itself is used to define the template used and then push the content into the content points. This is much better than having to include page fragments in a JSP page, using a page decorator or using a template to include the content page. Our main page home.xhtml is one such page that uses this template.

home.xhtml

At the very top, in the composition tag, we tell Facelets that we want to use the file template.xhtml as our template page. Next we have a ui:define tag that defines the content that is to be used in the template. Facelets works by having the page pull the template into the page and pushing its content into the slots provided by the template. This is much better than pulling content into the main page using includes, or specifying a template used everywhere and decorating the content with it. This is the best of both worlds. Each page defines which template page it uses and pushes the content into it.

Our first used component

In here you can see we have used our first JSF component :

This is a standard JSF component that is used to output text. We could have just written the text right in the page, but the goal of this page is to test that the JSF configuration is working and to do that, we need to see if the JSF component is rendered correctly. You can edit the text in the value and obviously it will change the text displayed on the page.

Our first backing bean

Displaying static text isn’t what web frameworks were built for, what we really want is to display something that comes from some java code. To do this, we will create a backing bean which is a java object that is part of the web application that JSF is aware of. To create backing bean, create a new class and call it PageBean.

import javax.enterprise.context.RequestScoped;
import javax.inject.Named;

@Named
@RequestScoped
public class PageBean {

	private String message = "Mighty apps from little java beans grow";

	public String getMessage() {
		return message;
	}

	public void setMessage(String message) {
		this.message = message;
	}
}

The code itself is pretty simple. One field with a default value and getters and setters. However, we have a couple of new annotations at the class level. First is the @Named annotation that tells CDI that this bean has a name that be used to refer to this bean using EL expressions. Since we didn’t supply a name the default name of pageBean is used. The @RequestScope annotation tells CDI that this bean is request scoped so when it is created, it should last till the end of the current request and then be destroyed. This means that the next time we call this page, this bean will be re-created and a fresh version used which again will be destroyed at the end of the request.

Now we are going to change our application to display this message instead.From now on, we will just be showing the code within the ui:define statements:

If we run the application now, you should see the message displayed on the main page:

Now let’s take look at a producer method that can be used to display the date and time the page was rendered. First, open up the template file and look for the footer panel at the bottom and change it to :

This page was rendered at #{currentSysDate}

What is currentSysDate value? Well, we need to go back to our PageBean and define it. We will add a new method that returns a new Date object and we’ll annotate it with @Named and @Produces.

@Produces @Named("currentSysDate")
public Date produceDate() {
	return new Date();
}

The Produces and Named annotation tells CDI that this method can be used to produce a value with the name currentSysDate. When our application is deployed, CDI makes a note that this value comes from this method so when our page is rendered and JSF is looking for the value currentSysDate, CDI calls the method and returns the value obtained from this method.

If we refresh the page we can see that our new timestamp function is on there.

This will come in handy later on when we start using AJAX and want to check that the full page has not updated (the timestamp will stay the same because that portion of the page won’t change). We’ve shown how we can pull data from the server onto the page so let’s take a look at how we send data back to the server.

In our home.xhtml page, we’ll add a text input to edit the message and a button to post it back.


	

	

	New Message :

First, we added the h:form tags which gives us an HTML form in which to put input controls. Any data entry in a JSF page needs to be enclosed in a JSF form tag in order to be passed back to the server. We defined an input text box that was bound to the same value as the message display and a command button that is used to post the values back. If we refresh the page, enter a new message and click the button our message changes.

However, this is the age of Web 2.0, and just posting back a form and displaying the results isn’t enough, we need to do it with AJAX. AJAX is a mechanism by which the browser makes an asynchronous request to the server and gets a response back. When the response is returned, the browser will call a javascript function that will update part of the page instead of all of it. Sounds complicated, but the nice folks that wrote JSF wrapped all that functionality up in one little tag called f:ajax

What we want to do is make our command button an AJAX button which we can do by placing the f:ajax tag as a child tag of the button. All we need to supply the AJAX tag with is the execute and render attributes. This indicates which parts of the page we want to post back to the server, and which parts we want to re-render when the response comes back. We want to execute the form and re-render the form, so we could use the component id (messageForm) for the attribute values. JSF also provides a couple of shortcuts that we can use. The value @form references the form the button is in so rather than hardcode the form id, the @form value will let us reference the form without doing so by name.

Notice that now you have an ajax button, the timestamp in the footer doesn’t change when you post the value back.

Performing Actions

So far we have covered displaying information from the server side bean and writing values back, but often we want some user action to execute some code on the server.

Start by adding a Integer attribute on to our PageBean class and two methods, one to increase it, and another to decrease it as well as getters and setters for the value.

	private int value = 0;

	public void increase() {
		value++;
	}

	public void decrease() {
		value--;
	}

In the view, we want to display the value and have a couple of buttons to increase and decrease the value. Add the following view code in home.jsf somewhere between the h:form tags :


     
     #{pageBean.value}

Refresh the page and click away, and you’ll notice something is wrong. Press the increase button and the value goes to 1, click it again and it…goes to 1. Click the decrease button and it will always go to -1. The problem is an issue of state. Each time we click the button, we post back to the server, and the server creates a new instance of the pageBean and calls the increase or decrease methods. The problem is that each time we create the bean, the value starts at zero and so is only ever increased to 1 or decreased to -1.
Now you may be wondering that since you are displaying the value on the page, isn’t that enough to post it back to the server, after all, we displayed the message in an input box and it got passed back to the server. The difference is that an input box is known as a JSF value holder, which means it actually holds the value it is bound to on the client and posts it back to the server when the form is posted back. We can see this demonstrated by changing the value text display component to an input text box component:

Now when you click the +/- buttons the value changes beyond -1 and 1. This is because when the page is rendered, the value is stored on the client. When the button is clicked and the form is posted back, the client side value is sent back to the server side attribute and then the increase/decrease method is called with the value that is set. This is fairly common with web forms, and one way of handling state by putting it in client side forms, even as hidden field values.

We can demonstrate this further by manually entering a value into the text input and then clicking a button. Enter 1000 in the input text box and click the increase button. The value should now be 1001.

When we manually enter a value, we are changing the value held on the client in the value holder represented by the input text box. When we click the increase button we are sending that value back to the server. On postback, the server creates an instance of our PageBean class, sets the value attribute to the value in our text box (1000) and then calls the increase method which increases the value to 1001. Once the method has finished, JSF then must render a response which includes taking the value from the pageBean.value attribute and putting it in our text box which is how the text box shows 1001 after clicking the button. At this point, once our request is complete, the page bean is destroyed as it is only request scoped.

Validating the value

If we only want the value to be between 0 and 10, we can add validation annotations onto the value field to enable it to be checked for correctness when we post back the values. In our PageBean class, we’ll add the annotations as follows :

@Min(value=0)
@Max(value=10)
private int value = 0;

We also need some way to display error messages if the user enters an invalid value so we’ll add a h:message tag. The message tag is used to associate a JSF message with a component and display it. We give the input text box a name and add the message for that component :

Now refresh the page and enter 1000 into the value text input and click the increase button. You should see an error message next to the text editor because the value is above 10. Try entering the value of -1000 and clicking a button.