David R. Heffelfinger

  Ensode Technology, LLC

 

JavaServer Faces (JSF) in a Hurry


Need to learn JSF in a hurry? I'm here to help!

Assuming you already have some Java experience, as well as some HTML experience, there is nothing to JSF, you can learn the basics in a few minutes. I also assume that you are familiar with packaging and deploying Java code to an application server such as GlassFish, WildFly, JBoss, Weblogic or Websphere, or to a servlet container such as Tomcat or Jetty.


JSF has evolved over the years, this blog post covers the best practices in JSF 2.0 or newer, specifically, Facelets is used to develop the front end (as opposed to JSP) and CDI Named beans are used to develop the server side code (as opposed to managed beans).


Step 1: Develop Java class(es) that will hold information (the Model in the MVC pattern)

Your Java class will be a Plain Old Java Object (POJO), it will consist of private properties public setters and getters.

package com.ensode.jsfinahurry.model;
import javax.enterprise.context.RequestScoped;
import javax.inject.Named;

@Named
@RequestScoped
public class Person {

    private String firstName;
    private String lastName;
    private Short age;

    public String getFirstName() {
        return firstName;
    }

    public void setFirstName(String firstName) {
        this.firstName = firstName;
    }

    public String getLastName() {
        return lastName;
    }

    public void setLastName(String lastName) {
        this.lastName = lastName;
    }

    public Short getAge() {
        return age;
    }

    public void setAge(Short age) {
        this.age = age;
    }

}

The @Named annotation designates the class as a CDI managed bean, gives it a name, which by default is the class name with its first character switched to lowercase (“person”, in our case). This annotation allows JSF pages to access our Java class.

The @RequestScoped annotation gives our CDI bean a scope of request. If you have developed web applications in Java before you should be familiar with bean scopes by now.

The following table shows the most commonly used scopes for CDI named beans:

 Annotation Scope
 @RequestScoped Request
 @SessionScoped Session
 @ApplicationScoped Application
 @ConversationScoped Conversation
 @FlowScoped Flow
 @Dependent Dependent pseudo scope

The first three should be self-explanatory, the last two (@ConversationScoped and @FlowScoped) are both meant for the bean to live throughout two or more requests, but not last through the whole session. Since we're in a hurry, I can't explain these in detail, but suffice to say that @FlowScoped was introduced in JSF 2.2 as part of Java EE 7 and is the preferred way to achieve this functionality if you are using JSF 2.2 or newer. @Dependent just means that the bean will be created as needed.

Step 2: Develop a controller class

This is the controller in the Model-View-Controller (MVC) design pattern. As far as plumbing, there is not much to do for controllers, just use the @Named annotation and an appropriate annotation.
package com.ensode.jsfinahurry.controller;

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

@Named
@RequestScoped
public class PersonController {
    public String processData(){
        
        //in a real application, we would process user-input here
        //more than likely saving data to a database
       
        return "confirmation";
    }
}

Our JSF pages will invoke the processData() method when the user clicks on a button, via a method binding expression (next section). By convention, the next page to render in the browser will match the return value of the invoked method (processData(), in our case). For our example, we will develop a page named confirmation.xhtml (matching the return value of “confirmation”) that will be rendered after our processData() method is invoked.
Step 3: Develop the pages
Now that we have our Java code in place, we need to develop the user interface. JSF pages are developed using Facelets, a JSF specific view technology. Facelets pages are nothing but standard XHTML pages using some JSF specific name pages.
A page used to allow the user to enter person data (to be stored in our Person class) may look like this:

<?xml version='1.0' encoding='UTF-8' ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
      xmlns:h="http://xmlns.jcp.org/jsf/html">
    <h:head>
        <title>Enter Person Data</title>
    </h:head>
    <h:body>
        <h3>Enter Person Data</h3>
        <h:form id=”personForm”>
            <h:panelGrid columns="2">
                <h:outputLabel for="firstName" value="First Name"/>
                <h:inputText id="firstName" label="First Name" value="#{person.firstName}"/>
                <h:outputLabel for="lastName" value="Last Name"/>
                <h:inputText id="lastName" label="Last Name" value="#{person.lastName}"/>
                <h:outputLabel for="age" value="Age"/>
                <h:inputText id="age" label="Age" value="#{person.age}"/>
                <h:panelGroup/>
                <h:commandButton value="Submit" action="#{personController.processData()}"/>
            </h:panelGrid>
        </h:form>
    </h:body>
</html>

If you know even basic HTML, you should have a pretty good idea of how the above Facelets markup works. Before explaining the markup, notice that most JSF specific tags on the page have an id attribute. This attribute is optional, but it is a good idea to set it, for starters, it allows us to link labels to input fields (explained below), but also, when things don't work as expected it is much easier to identify which tag is causing trouble, as most JSF error messages will display the id of the component (if we don't set it, JSF will assign one, that will be meaningless to us).

The <h:head> and <h:body> tags are drop-in replacements for HTML <head> and <body> tags.
<h:form> is equivalent to the HTML <form> tag, notice that for JSF we don't need to specify the method and action attributes (method will always be “post” and the action will always point to the JSF servlet, which is automatically used when developing with JSF).


The <h:panelGrid> component lays out JSF tags on the page, similar to using a table to lay out HTML tags. Its column attribute specifies how many tags will be placed in each column.
<h:outputLabel> renders an HTML <label> tag, its “for” attribute must match the id attribute of the input component the label is meant for.

<h:inputText> is equivalent to an HTML <input> tag with a type of “text”. A nice thing about JSF is that it automatically converts user-entered values to the appropriate type in the corresponding CDI named bean. The value of the value attribute is what is known as a value binding expression, we can recognize these since they are encapsulated in curly braces and preceded by a hash (i.e. #{..}). Value binding expressions are used to automatically populate the corresponding attribute in a CDI named bean with the user-entered value for the corresponding input text. Remember the @Named annotation? “person” inside each value attribute corresponds to the name of our Person bean. The value after the dot corresponds to the corresponding property in the Person bean. For example,  #{person.firstName} corresponds to the firstName property of the Person bean.

<h:panelGroup> is used to group JSF tags together in a single cell. In our case, all we wanted to do was have an empty cell so that our button would vertically align with the rest of the input fields, so we placed an empty <h:panelGroup> tag at the appropriate location in our <h:panelGrid>.


Finally, <h:commandButton> submits our form, its value attribute sets the label for the button, its action attribute indicates which CDI named bean method to execute when the button is clicked (processData(), in our case). This is what is called a method binding expression. The method must be public, return a String and take no arguments. What we implemented here is what is referred to as dynamic navigation, although our simple example always returns the same String, there is nothing stopping us from returning different values depending on some conditions, we can then take the user to different pages depending on these conditions (picture a switch statement or if/then/else, with different return values for different conditions).
If we don't need to do any processing after the user clicks the button and we always will display the same page, we can use static navigation, in which case the value of the action attribute can be hardcoded, like this:


<h:commandButton value=”Submit” action=”somepage”/>

We know that the value is hardcoded and not an expression since it is not surrounded by curly braces preceded by a pound sign (“#{...}”). In this case a page named somepage.xhtml would be rendered on the browser every time the user clicks on the button.
The markup for our confirmation page simply displays the values the user entered on the previous page.

<?xml version='1.0' encoding='UTF-8' ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
      xmlns:h="http://xmlns.jcp.org/jsf/html">
    <h:head>
        <title>Confirmation Page</title>
    </h:head>
    <h:body>
        <h3>You entered the following data</h3>
        <b>First Name:</b> ${person.firstName}<br/>
        <b>Last Name:</b>${person.lastName}<br/>
        <b>Age:</b>${person.age}
    </h:body>
</html>


The only thing new on this page is the use of curly braces preceded by a dollar sign (“${...}”) to retrieve a named bean's properties. When the page is displayed the value of the corresponding property is displayed on the page.

Our application in action

Once we package our application in a WAR file and deploy it to our application server of choice (I'm using GlassFish), our input page will be rendered. Here is what it would look like after a user entered some data:

Notice that we didn't have to specify any mappings in web.xml (as a matter of fact, web.xml is optional in modern JSF applications). By default, JSF pages are mapped to the /faces prefix.
When the user clicks on the Submit button, the processData() method on our PersonController class is executed, which takes us to the confirmation screen.

What I left out

This post is meant as a quick introduction to JSF, so I obviously did not cover every JSF nook and cranny. There are lots of additional JSF tags that I didn't cover, there are JSF specific equivalents to every HTML input tag.

JSF also has input validation built-in, we can make fields required and also accept only specific formats, for example. For application specific cases, we can develop our own custom validators.

JSF has built-in data conversion, we saw this in action by adding a property of type short and having the user-entered value automatically converted to the appropriate type. JSF also allows us to develop custom data converters.

JSF also has Ajax integration built in, a topic that I obviously didn't cover.
Finally, almost nobody develops “raw” JSF applications, the beauty of JSF is that allows the creation of component libraries. Most JSF applications employ one of these component libraries. Some of the most popular include PrimeFaces, RichFaces and IceFaces.

Where to go from here

After reading this short blog post, you should have a pretty good idea of the basic mechanics of JSF. To learn more about it, I'd be very grateful if you purchased one my books, Java EE 7 Development With GlassFish 4 or Java EE 6 Development With NetBeans, or, if you need personalized training, I can help you with that as well, just head over to my company web site: http://www.ensode.com for my contact information.
Of course, there is a ton of free information on the web as well, now that you know the basics other tutorials out there that assume basic knowledge should make more sense, just use your favorite search engine to find out more.

 The source code for the example shown in this post can be downloaded here.


 
 
 
 

Java Lingo for Non-Java People



This post is meant for managers, business analysts, recruiters, and anyone else who needs to interact with Java developers but is not a Java developer him/herself.
Just like any other discipline, Java development is full with lingo that may be intimidating to those not in the field.

Java
Java itself is a programming language that is platform independent, which means that Java code can run unmodified on a variety of operating systems such as Windows, Linux/Unix, and Mac OS. Traditionally source code needs to be compiled for each specific platform, this is not the case for Java.

The Java Virtual Machine
But Java is not only a programming language, it is also a platform. Java code runs on the Java Virtual Machine (JVM), which translates Java bytecode (compiled Java code) into native code for each platform. There are several other languages that run in the JVM, such as JRuby, Clojure, Groovy, Ceylon and many others.

Eclipse, NetBeans, IDEA
Java applications are typically developed using an Integrated Development Environment (IDE), the three most popular IDEs are Eclipse, NetBeans and IntelliJ IDEA.

ANT, Maven, Gradle
Java applications also typically use a build tool to help compile, build and deploy applications, the three most popular build tools are ANT, Maven and Gradle.

Java EE, JEE, J2EE
Java is extremely popular for developing enterprise server side applications, these types of applications typically use a web based user interface, with the business logic running on a server. Java Enterprise Edition (Java EE) is a set of Application Programming Interfaces (APIs) used to develop server side applications. Sometimes Java EE is referred to as JEE, however the officially sanctioned name is Java EE and the use of the term JEE is discouraged by Oracle, the company behind the Java platform (Oracle bought Sun Microsystems, the original company behind Java, back in 2010). Java EE was formerly known as J2EE, the J2EE term was so popular that it is still commonly used to refer to Java EE.

Spring
The Spring framework is an alternate set of APIs used to develop server side applications. In general, server side Java developers belong to either the Java EE or Spring camps, rare is the developer that is a fan of both.

GlassFish, Weblogic, Websphere, JBoss, Tomcat, etc
Server side Java applications are deployed to an application server. Application servers provide functionality that is common to all enterprise applications so that application developers don't have to concern themselves with implementing this functionality. For example, application servers take care of transaction management, security and scalability. Some examples of application servers include GlassFish, JBoss, WildFly, Weblogic and Websphere. Tomcat can be thought of as an application server as well, however strictly speaking, it is a servlet container, that is, it provides less functionality out of the box than full fledged application servers. Java applications written using Spring typically don't require a full fledged application server and can be deployed to Tomcat. Another popular servlet container is Jetty.

JSF, Struts, GWT, Etc
There are several Java web frameworks that are used to ease and accelerate the development of web based applications. JavaServer Faces (JSF) is the standard Java EE framework for web development. There are several JSF component libraries that run on top of JSF, these libraries make it easy to develop nice looking JSF based web applications. Some examples of these libraries include PrimeFaces, RichFaces and IceFaces. In addition to JSF, there are several other Java web frameworks such as Struts (considered by many to be a legacy framework), the Google Web Toolkit (GWT), Struts Web MVC and Wicket.

EJB
On the server side, Enterprise JavaBeans (EJBs) provide transactions, security and scalability out of the box. This frees Java developer from having to implement this functionality and allows them to focus on implementing the business logic.

JPA, Hibernate, MyBatis
There are Java APIs (Application Programming Interfaces) that help developers write code to interact with a database, the Java Persistence API (JPA) is the standard Java EE API used for this purpose. Hibernate and MyBatis (formerly known as iBatis) are two other popular libraries used for this purpose.


So there you have it, my friend, after reading this post you'll have some idea of what the heck those Java guys are talking about or what it is that is needed for that Java developer position your company is hiring for.

Anything I missed? Leave a comment.

 
 
 
 

So you want to become an independent consultant?


I have been an independent consultant for almost 7 years. Last month I had the opportunity to speak at the JavaOne conference, I identified myself as an independent consultant, after my talks a few attendees approached me to ask how to go about becoming one.

The other day a former coworker found my LinkedIn profile, saw that I'm independent now and gave me a call asking for advice and guidance on going on his own.

Since there seems to be a lot of interest in finding out how to strike it out on your own, I'll write down about my experiences here, then in the future direct people to this blog post.

The first thing I'd like to clarify is that I live in an area where most software development work is contract work anyway. Another thing that I'd like to point out is that by the time I decided to go out on my own I was already a published author, that fact helped me market my services and obtain work fairly easily. Your mileage, as they say, may vary.

When doing contract work, there are three ways to go about it.

W2, 1099 or C2C?

When hired as a W2, you become a temporary employee of the company hiring you. The client (your temporary employer) takes care of your tax deductions. There are also 1099 contracts, in which the company hires you as an individual, but you are not their employee, you are responsible for deducting your own taxes. The third way to do it is a Corp to Corp contract, commonly abbreviated as C2C. When doing C2C contracts, you need to incorporate a company, in this case the clients hires your company, not you directly.

Before I incorporated Ensode Technology, LLC, I was doing a lot of W2 contracts, since like I mentioned before the majority of software development work in my area is contract work . W2 contracts usually lasts from 6 months to a year, in rare occasions it can go beyond that. Since I had no job security anyway I figured that I may as well go all the way, start my own company and incorporate.

How do I incorporate my own company?

Incorporating a company is very easy. First come up with a name, google it to make sure it is not taken (by the way Ensode stands for Enterprise Software Development). I incorporated Ensode Technology online and didn't even had to get up from my seat, if I remember correctly it cost me about $100 USD.

Getting a Business Bank Account

You need to get a business bank account primarily so that you can get paid. Your clients will be writing checks to your company, not to you personally. Any bank will be more than happy to help you open an account with them.

Getting Insurance

After incorporating, the next step was to get insurance, a lot of clients won't do business with you unless you are insured. I have liability insurance covering up to $1,000,000, it costs me about $500 a year.

Taking care of tax deductions

Lastly, I hired a payroll service to take care of my tax deductions, that sets me back around $85 USD a month or so.

Once you have incorporated your company, gotten liability insurance and hired a payroll service (this third step is optional, but I highly recommend it), you are ready to strike it out on your own, so the next question get asked a lot is:

How do you get projects?

When your company has only one employee, getting contracts is not much different from the way most other people find regular jobs. You post your resume on a job board, and wait for companies to contact you, once you start talking about a potential job, you should let them know that you are only looking for C2C contracts.

So there you have it, as you can see striking it out on your own is not really that hard. Good luck in your new venture.

 
 
 
 

So you want to become a technical author?


Last month at the JavaOne conference I had the opportunity to participate in a birds of a feather session titled "So you want to be a published technical author?". I was glad to share my experiences as a published book author, unfortunately the session was only 45 minutes and we had  5 people plus the moderator in the panel, so we didn't have time to cover everything we wanted to. Here are some things we covered during the session, plus a few more things that were left unsaid.

How do I get noticed?

The easiest way to get noticed is to blog about the topic you are interested in writing. Personally, the way I got discovered was when one of the articles I wrote for my own web site was linked to from The Server Side. My advice to aspiring authors would be to blog about your topic of choice then submit your own blog posts to Reddit, Hacker News and other popular technology sites.

Is it profitable?

Not directly. Yes, you'll get some extra cash, but not enough to live on. However, the fact that you are a published author will increase your demand as a programmer a lot, allowing you to charge higher rates. Also, being published opens the door to other opportunities that further increase your exposure, such as speaking engagements and invitations to write articles for high profile publications. A quote I read somewhere that deeply resonates with me: "You don't write books for the royalties, you write books for the consulting fees".

How do you find the time to write?

Very few technical authors write books for a living, for most of us that is something we do on the side. Since we have a full time job we have to write on nights and weekends. Personally, I have a home office in my basement where I go on the evenings to work on my books.

What topics should I write about?

Something you are passionate about. Personally, I tend to pick open source projects such as NetBeans and GlassFish and write about versions that are still in development and have not been officially released yet. I try to time the book publication to match the official release of the project in question. This approach has the risk that things I write about may change in the final version of the product, however the trade off is that your book will cover the latest version of the technology in question.


Why is it so hard to find Java talent?


One common complaint that I hear from my clients and recruiter friends is that it is very hard to find good Java talent.

I am fortunate enough to be on the other side of the coin, I have been working with Java for several years now, I have authored several books on Java and have been a speaker at Oracle's JavaOne conference on more than one occasion, so I'd like to think I'm one of those hard to find good Java developers.

Being on the other side of the coin, I am bombarded every day with emails from recruiters interested in my services, I am fortunate enough to be able to be selective about the projects I work with. In my experience there are three things that drive me away from accepting a project. Here are my suggestions on things you can do to attract top Java talent.

Make it easy to apply

It is mind boggling to me the number of companies that require me to go fill out some long, convoluted form just so that I can apply for a job with them. I have several other companies that are dying to hire me, don't make it a hassle for me to apply for a job for you. On a similar note, many companies require me to fill out some form made in Word that duplicates all the information that already exists in my resume.

If you want me to work for you, don't make it a hassle for me to apply.

Be flexible with your tax terms

For quite a few years now, I've been an independent consultant, in order to do this, I had to incorporate, hire a payroll service, and get insurance for my business. I already have an infrastructure in place to run my business, therefore I only take Corp-to-Corp (C2C) contracts. A lot of companies do W2 only, or want a permanent employee only. Again, I have several potential clients that want to hire me and agree to my terms, your chances of hiring me are slim to none if you are unwilling or unable to do a C2C contract.

Your project has to be interesting

I'm not going to pull any punches here, a lot of the Java projects out there just suck, plain and simple. If what you want me to do is maintain an old J2EE application using Struts 1 and Spring 1 or 2, I'm not going to be very interested in your project. You need to modernize your infrastructure if you want to attract top Java talent. I have actually researched the topic on modernizing legacy server side Java web applications, and wrote a series of articles for the Oracle Technology Network (OTN) a while back on the topic. The articles focus on Spring to Java EE migration, but the same concepts apply to J2EE to Java EE migration. If you need help modernizing a legacy project, drop me a note, this will certainly be an interesting project and I'll be happy to help.



 
 
 
 

Screencast and Code for my JavaOne Java EE 7 / HTML 5 Presentation


Earlier this week I had the pleasure and the privilege to give a talk at the 2013 JavaOne conference. The session was very well attended and liked.

In the session I gave a demo on how to develop JSF applications using HTML 5 friendly markup, that is, no JSF specific tags, instead using regular HTML 5 input fields with JSF attributes to bind user input to a CDI managed bean. I started the application using a sample Websocket application included with NetBeans as a base.

Then I finished the demo by adding developing a Java EE Websocket server endpoint that returned a JSON containing data to populate the JSF/HTML5 page, and finally added some Javascript to the page to parse the JSON and populate the page.

After the talk was over, a number of attendees asked for the source code to the demo. I wasn't expecting to be asked for the source code, so I hadn't uploaded it anywhere, but since there was demand for it, I just uploaded a zip file containing all of the demo source code. Feel free to download it and use it as you please.

Additionally, if you weren't able to make it to the talk, I just uploaded a screencast of the demo to Youtube, you can find it here, or, even easier, embedded below.

If you would like to learn more about Java EE development with NetBeans, please check out my Java EE Development with NetBeans video course.


 

 
 
 
 

My New Java EE Development With NetBeans Video Course is now available


For the past several months I've been diligently working on developing a Java EE Development with NetBeans video course.

 The course has just been published by Packt Publishing and is available for download at http://www.packtpub.com/java-ee-development-with-netbeans-7/video.

It covers all of the most popular Java EE Technologies and APIs including JSF, Facelets, EJB, and JPA, as well as many NetBeans specific tips and tricks to boost productivity.

 
 
 
 

NetBeans Tip: Quickly opening windows without memorizing keyboard shortcuts


When working with NetBeans, sometimes I need to open a window to look at some information (breakpoints, output, etc). Windows can be accessed by going to the "Windows" pull down menu, then selecting the appropriate window, or, most windows have a keyboard shortcut (ctrl+1 for projects, for example).

The "Window" menu has several submenus, and it is not always entirely obvious where a specific window may be (the "Terminal" window, for example, is under "Output").

 NetBeans Window Menu

 Sometimes I would like to open a window, but I'm not sure exactly where it is located, and I don't know it's keyboard shortcut.

Fortunately NetBeans has a "Quick Search" text field at the top right, and typing the name of the window makes it appear in the search results, therefore, if I want to open the "Breakpoints" window, for example, all I have to do is type "Breakpoints" in the quick search

NetBeans search window


 
 
 
 

Java One JSF with NetBeans BOF Demo


I had the pleasure of being a speaker at this year's JavaOne conference. One of the sessions I participated was a Birds of a Feather (BOF) session on JSF development with the NetBeans IDE.

During the demo I showed how a complete, nice looking application can be developed in only a few minutes using NetBeans.

For the benefit of those that couldn't attend the session, here is a video of said demonstration.

For those that want to learn more, I wrote a book on NetBeans and Java EE.

 


 
 
 
 

Trying to keep an open mind in the Spring Vs Java EE Debacle


One common criticism of my Spring to Java EE Migration article series (see part 1, part 2, part 3 and part 4) is that the article uses an old version of Spring against a modern version of Java EE. There's a reason for that, since project using older versions of Spring are the most likely ones to be looking to migrate to a newer technology stack, be it a newer version of the Spring Framework, Java EE or something else.

Nevertheless, truth be told, I've been focusing on Java EE projects for the last few years, and the times I've used Spring have been when maintaining legacy applications that don't use modern versions of the Spring framework.

Trying to keep an open mind, I bought Just Spring by Madhusudhan Konda for my Kindle Fire. The book uses Spring 3.0, versus Spring 2.5 in my article series. I decided to go for this book since it is a quick read (just over 60 pages), I didn't want to have to go through a 300+ behemoth of a book just to see if my opinion of Spring was outdated.

Quite frankly, the book did little to change my opinion in the Java EE vs Spring debacle. Although annotations get a brief mention in Konda's book, most of the examples still use XML configuration, and the seemingly endless XML needed to do anything nontrivial in Spring is one of the main reasons I'm not a fan of the framework.

 

To learn more about Java EE development, please check out my own books, Java EE 6 with GlassFish 3 Application Server and  Java EE 6 Development with NetBeans 7.

 

 
 
 
 

tar failing with error message "file changed as we read it"


Today I'm upgrading my laptop to the recently released Ubuntu 12.04 Precise Pangolin.

Even though I have my /home directory in it's own partition and the installer shouldn't wipe it out, I'm erring on the side of caution and backing up my home directory before beginning the installation.

I'm using the Linux tar command to compress and back up my home directory, but for some reason after waiting for several minutes the command kept failing with the following error message:

"file changed as we read it"

After googling for a bit I found the solution to the problem, using the --ignore-failed-read flag for tar took care of the issue.

tar --ignore-failed-read -ztvf backup.tar.gz /home/myhomedir

did the trick. 

Spring to Java EE Migration Article, Part 4


The fourth and final part of my Spring to Java EE migration article series has been published.

Spring to Java EE Migration, Part 4 

Part 4 compares equivalent functionality in Java EE and Spring, covering topics such as MVC design pattern implementation, data access, transaction management, and dependency injection. 

 
 
 
 

Spring to Java EE Migration Article, Part 3


Part 3 of my Spring to Java EE migration article series has been published.

This part covers how to tweak the NetBeans-generated JSF user interface and compares the Spring and Java EE versions of the Pet Clinic application. 

 
 
 
 

Spring to Java EE Migration, Part 2


Part 2 of my Spring to Java EE migration series has been published. 

This part of the article shows off NetBeans Java EE capabilities, such as automatically generating JSF pages, JSF managed beans and Data Access Objects (DAO's) implemented as EJB session Beans. 

 
 
 
 

New Spring to Java EE Migration Article Series


For the past few weeks I've been working on a new article series for the Oracle Technology Network. The topic of the series is Spring to Java EE migration using the NetBeans IDE. 

Part 1 of the series was just published. In this part we begin migrating Spring's sample Pet Clinic application to standard Java EE APIs such as JavaServer Faces (JSF) and the Java Persistence API (JPA), while showcasing time saving NetBeans features such as JPA entity generation.

 
 
 
 
 

« April 2014
SunMonTueWedThuFriSat
  
1
2
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today

 
© David R. Heffelfinger