Developing a Web Tutoring Service using Java EE 7
by Vasilis Souvatzis
Table of Contents
Chapter 2 - Introduction to Java EE
Enterprise Information System tier
Annotations and Deployment Descriptors
Chapter 3 - Specifications Overview
Management, Security and Other Specifications
Related Technologies in Java SE 7
Presentation-Oriented Web Applications
Service-Oriented Web Applications
Structure of a JSF Application
Chapter 6 - Contexts and Dependency Injection
Chapter 7 - Java Persistence API
Chapter 8 - Enterprise JavaBeans
Preface
The World Wide Web has helped people communicate and exchange information in a great degree. Companies and organisations with their own local information systems, have connected themselves into small networks and share information faster than ever.
Companies with subsidiaries all over the world, communicate with each other through a central system and have access to the same data at any given moment. The biggest commercial giants automatically update their product stocks in all of their warehouses, banking organisations transfer money with little to no error tolerance and with great safety rules, while users demand fast service. This software that helps companies achieve their market goals, is called enterprise software.
Java EE is one of the platforms used to develop enterprise applications. It consists of many technologies that create the Java EE stack. From the first version of the platform, it has seen many changes and simplifications which lead to an easier-than-ever application development.
Due to the range and amount of the technologies, it isn’t easy to study in depth all of the APIs and how they’re used. For this reason, this paper deals with the most commonly-used technologies while it delivers a full working application at the end.
Abstract
The topic of this paper is to develop a web application using Java EE 7.
In the first chapter a small report is made around the Java platform and its versions.
In the second chapter, we're slowly entering the Java EE domain, what enterprise applications are, what they consist of and how they operate.
The third chapter is the last of the introductory ones since it refers to the platform specifications and the Java Community Process, the people governing and developing the specifications.
With the introduction to the fourth chapter, a differentiation between presentation-oriented and service-oriented applications is made, along with how they're used.
The fifth chapter is the grand entrance to the programming part of the paper, since it talks about JavaServer Faces, the Java EE API to build the UI of the application.
In the sixth chapter, there's a small reference to the CDI, the API that drastically reduces the development time and injects objects in the lifecycle of others.
Databases are a crucial part of any enterprise application so in the seventh chapter we talk about the JPA API, how Java EE operates with databases and runs CRUD methods.
The business logic of an application is encapsulated in the eighth chapter, where enterprise javabeans hide the "serious" code.
The tenth chapter makes a flashback to the past via the Servlets, they may have been the first Java EE technology to build dynamic content, they're still strongly used.
Chapter 1 - About Java
Introduction
Starting a paper about developing applications with Java EE 7, it’s essential to talk a bit about Java in general. Thus, a small mention will be made about the reasons it was created and how Java isn’t just a programming language.
Necessary Information
The Java language was created by James Gosling of Sun Microsystems with the “write-once, run-everywhere” notion. This means that the source code doesn’t need to be recompiled in order to run on different systems. Sun Microsystems added the Java language to the Java Platform back in 1995 and through the Java Virtual Machine, applications are executed on different systems.
It’s a high-level programming language, object oriented, secure, dynamic and with a strict syntax. The source code is written in plain text files with a .java extension and when it’s compiled, it creates .class files that contain the Java Virtual Machine bytecode. These .class files give Java the “write-once, run-everywhere” aspect.
In the introduction, it was mentioned that Java isn’t just a programming language. Truthfully, the Java Virtual Machine and language APIs combination, make Java a programming platform and not just a programming language. For this matter, Java has four platform versions that are used in different situations.
Java Platforms
Java SE (Standard Edition)
Java SE contains the core APIs of the language. It defines all the basic types and objects and specifies all the rest classes that connect to databases, handle files, network, create GUIs etc. This edition’s field is desktop systems.
Java EE (Enterprise Edition)
Java EE is built on-top of SE, consisting of its own independent APIs but can use all the SE ones as well. Its field is enterprise software; applications that demand networking, security and easy scaling when it’s needed.
Java ME (Micro Edition)
ME’s field is devices with limited (or specific) capabilities, such as mobile phones, handheld devices, sensors etc. These devices have limited hardware (CPU, RAM etc) because they perform specific tasks. They need a small footprint on the hardware power and that’s the reason ME is a sub-set of SE.
JavaFX
JavaFX was created to deliver Rich Internet Applications (RIA), having a modern look and feel, using CSS and Drag’n’Drop actions, building graphics and animations. Now it was been added to the SE platform and eventually will replace the Swing framework.
Summary
This first chapter made an introduction to Java and was made clear that it’s a programming platform and not just a programming language. A brief mention to its history and how it was created. Finally, it explains the different versions of the platform along with their respective fields. One of these platforms is Java EE; the topic of this paper.
Chapter 2 - Introduction to Java EE
Introduction
JavaEE was created in 1999 to fulfill certain needs of that time. Many things have changed since then its target remains the same. In this chapter we’ll see why Java EE was introduced, what its applications consist of and what conveniences it gives to the developers.
Enterprise Applications
During the last two decades, due to globalisation and development of the Web, companies managed to grow and expand much easier than before. Subsidiaries and departments were created in other countries and parts of the world, while their business plan was being moved online. This led to reaching a lot more customers from different parts of the world, having different needs and culture.
Certain applications were needed though, ones that would keep the communication between the scattererd company departments, their customers and the management. Moreover, the ever growing business plan and accumulation of revenue. All this along with keeping the data safe and the application itself easy to scale.
These are the enterprise applications, divided into all over the world, secure and easy to scale when delivering services to a great number of customers.
Multi-tiered Applications
The functionality of an enterprise application is structured into different tiers, which can be deployed physically on machines everywhere in the world.
A typical Java EE application is a 3-tier one, it consists of the client-tier, the server-tier (a.k.a. web-tier) and the enterprise-information-system-tier.
Client tier
The client is the one that will connect to the Java EE server and make requests. Usually it’s on a different machine than the server and it isn’t mandatory that they’re written in Java. The clients can be programmed in any language that can connect to the server; applets, JavaFX, Swing even Ruby, Python etc. Even a command line application can be a client, or a browser, or another server. Web browsers usually communicate with the web-tier, while standalone GUI applications directly to the business-tier.
Server tier
The server tier consists of the web tier and the business tier. The web tier assumes the communication between the client (when it’s a web browser) and the business tier, requesting the server for data and dynamically presenting the results. It’s needed though to keep the data status for each session, so it temporarily saves them in JavaBeans.
Briefly, some of the technologies that are used in the web tier are the Servlets; dynamically processing the requests and constructing the results, JavaServer Pages; adding dynamic content in static web pages, and the JavaServer Faces framework which offers a user interface to the web application. JavaBeans are objects that temporarily save data in the pages of the application.
The business tier consists of those components which are responsible for the business logic of the application, whether it’s a banking system or an e-shop etc. The business tier has the enterprise beans that act as a temporary storage between the client and the database.
A couple of the technologies used in the business tier are the aforementioned enterprise beans and the RESTful web services for the client-server communication.
Enterprise Information System tier
This tier deals with the data storage. Whether it’s a database server, an ERP system, a mainframe or another legacy system, it provides the data storage the application needs to operate on. Even a simple text file can be used as data storage; albeit with lots of shortcomings.
Architecture
The architecture of a Java EE application consists of smaller software components that interact with each other. These components are responsible for certain functionalities and are deployed in their specific environments, called containers. The containers provide standard services to their components regarding their interactions. The image below shows such architecture.
Components & Containers
In the previous section, it was mentioned that containers are the execution environments of the components, providing them with certain services.
The containers that must be supported are four; the applet container is executed on the client with the Java plugin, the application container on the client but has GUI components (Swing or JavaFX for Java applications).
The web container is responsible for the execution of the web components such as Servlets, JSF pages, JSPs etc. In the meantime, the web components can contact the web client through HTTP(S) requests provided by the container.
The EJB container contains the enterprise javabeans and sets their lifecycle, along with security, synchronisation and transaction services.
Services
In the last two sections, there’s a constant mention on the standard services that containers provide to their components. That enables the developer to focus on the task at hand and ignore standard problems such as how components will communicate with each other. A short list follows with default services provided by Java EE.
- Persistence: A way of connecting the Object-Oriented model and a Relational database.
- Transaction: After each interaction with the database, all the applications that access the same data, can see their new values.
- Mail: Send and receive emails.
- XML & JSON processing: For the applications that need to process these files or send/receive such messages.
- Security: There are default methods for authenticating users and other needs.
Network Protocols
The network protocols that Java EE supports are HTTP, HTTPS and RMI-IIOP. The HTTP is the default protocol of the Web and is used in all modern applications. The HTTPS is a combination of HTTP and SSL, while the RMI-IIOP is a way of invoking remote objects disregarding the communication protocol.
Packaging
All these components must be packaged into files in order to be deployed on their containers. In Java SE for example, a jar file is created that contains all the class files of the application, along with resources (images, text files, etc), external libraries and the deployment descriptor. Something similar happens to Java EE applications.
The EJBs of the application are packaged in a jar with the optional deployment descriptor (ejb-jar.xml).
The web part of the application - contains JSF, JSP, (X)HTML, CSS files - is packaged in a war file, that except the aforementioned files may contain the optional deployment descriptor, which is simply called web.xml.
The enterprise part of the application (meaning all of the above) is packaged in an ear package that contains all the parts (war, ejb jars etc). With this way of packaging, all of the components will be deployed on the server when the application itself is deployed.
Naturally, this way of packaging isn’t standard and is heavily dependent on how the application is structured, the Java EE version, etc.
Annotations and Deployment Descriptors
Deployment descriptors and annotations are metadata that define and set the services of a container. They also help to connect these services with the underlying Java classes. Both are optional but at least one is certainly needed.
The annotations don’t exist on a separate file (like *.xml for the deployment descriptors) but are part of the Java class and connect the fields with the services. If both annotations and deployment descriptors are present in an application, the settings of the descriptor are of greater weight so it’s them that are used.
In modern development annotations are preferred. It’s easy to imagine why, it’s much easier to use just Java instead of Java and XML. Moreover, the annotations are written in the same file as the source code which makes it easier to see, debug and overall develop.
Summary
In this chapter, we saw that enterprise applications target the business world and solve business problems, for example managing banking transactions, handling online sales for a bookstore or reserve tickets and seats for an airplane.
We also saw that an enterprise application is typically divided into three tiers, the client, server and database tier. Java EE mainly focuses on the server tier, besides the client tier can be built with non-Java technologies and the database is a different technical section on it’s own.
A brief mention on the architecture of enterprise applications was made, and the components it consists of. These components are executed in their own environments with the latter providing them default services so as to minimise the development time.
The components need to be packaged prior to be deployed on the application server, but after that they utilise various services with the help of their metadata.
In the next chapter, we’ll see how these services, environments, updates, processes, etc are added into Java EE and which people are responsible for this.
Chapter 3 - Specifications Overview
Introduction
Java EE like any other Java version, consists of specifications. These are individual technologies that focus on a specific issue, for example JSON processing or a new way to deploy the application on the server.
Brief History
Java EE was announced back in 1998 but it was named “Java Professional Edition”. The first release to the public was made by Sun in 1999, named J2EE 1.2 and it contained 10 specifications that covered the enterprise needs of that time.
J2EE 1.3 that was released in 2001, was developed by the Java Community Process and it happens ever since. Regarding J2EE 1.4, it was thought that it would be greatly engaged in the market but it turned out that version was too complicated and difficult to use.
Java EE 5 was a milestone to the platform because it brought back the POJO programming model, introduced the annotations while making deployment descriptors optional.
At the end of 2009, Java EE 6 came in with lots of improvements and new technologies. It allowed annotations to be used almost anywhere along with a specification for RESTful support. Huge revisions were made to the existing specifications as well.
Java Community Process
It’s an open organisation, founded by Sun in 1998 and has members from all over the world. Companies, organisations, universities and individuals take part in evolving the Java platform.
When someone wants to introduce or change a feature of the platform, they submit a Java Specification Request. They are declared Specification Lead of that JSR and they submit its grounding components with that request.
If the JSR is approved by the Executive Committee, it’s then handed to the community for implementation.
EE 7 Specifications
Web Services Specifications[3]
JAX-WS | JAXB | Web Services |
Web Services Metadata | JAX-RS | JSON-P |
Web Specifications
JSF | JSP | Debugging Support for other Languages |
JSTL | Servlet | WebSocket |
Expression Language |
Enterprise Specifications
EJB | Interceptors | JavaMail |
JCA | JMS | JPA |
JTA |
Management, Security and Other Specifications
JACC | Bean Validation | Contexts and Dependency Injection |
Dependency Injection for Java | Batch | Concurrency Utilities for Java EE |
Java EE Management | JASPIC |
Related Technologies in Java SE 7
Common Annotations | JDBC | JNDI |
JAXP | StAX | JAAS |
JMX | JAXB | JAF |
SAAJ |
Web Profile 7 Specifications
Profiles were created to limit the size of the platform depending the needs of the applications. Java EE 7 with its 33 specifications, may be “too much” for some applications.
The Web Profile 7 is the only profile offered by Java EE 7 for developing web applications. Others may be introduced later to cover different needs. The following table shows the specifications of this profile.
JSF | JSP | JSTL |
Servlet | WebSocket | Expression Language |
EJB Lite | JPA | JTA |
Bean Validation | Managed Beans | Interceptors |
CDI | Dependency Injection for Java | Debugging Support for other Languages |
JAX-RS | JSON-P |
Summary
Java EE has changed a lot since its first version in the ‘90s. From a complicated and demanding platform, it managed to come to the front of the enterprise application development.
The JCP has introduced more than 30 technologies that meet the needs of the enterprise applications and continuously adds new and updates older ones.
Chapter 4 - Web Applications
Introduction
Web applications built with Java EE have little to no difference than web applications built with other programming languages.
The application is executed on an application server and it has access to some database. The user can either be a person or another machine/service, besides transferring data happens not only between a person and a machine but also between two machines.
There will be a brief comparison between the two types of web applications which are Presentation-Oriented and Service-Oriented ones.
Presentation-Oriented Web Applications
Whenever data must be moved between a machine and a human being, presentation-oriented web applications are used. They create dynamic content and present it to the user through a user interface, most times a markup language is used (HTML, XHTML or XML) and a web browser.
The technologies used in presentation-oriented applications are JavaServer Faces, JavaServer Pages, Facelets, Expression Language and Servlets.
Service-Oriented Web Applications
Respectively, service-oriented application are involved in transferring data among machines. For example, a presentation-oriented application can use a service-oriented one that simply retrieves data from a database and shares them to other applications.
The technologies used for developing service-oriented applications are JAX-WS and JAX-RS, the first uses XML messages while the second uses the REST methodology.
It’s worth mentioning that while Servlets can be used in presentation-oriented applications, they’re most fit in service-oriented ones since a service can be implemented as a Servlet.
Summary
While in brief extent, this chapter mentioned the differences between Presentation-Oriented and Service-Oriented applications.
The first are suitable to present content to a human through a web browser, while the second send data to other applications.
Chapter 5 - JavaServer Faces
Introduction
When developing a web application, it needs to present the user with data that comes from the back-end. The use of an interface is mandatory, the type of it though varies.
It is possible to have a desktop application with a GUI, a web application that runs on a browser, a mobile one running on a mobile device, even a command line application that provides a simple user interface.
JavaServer Faces is a server-side framework of Java EE and was added in 2004. It provides APIs for assigning components to tags, handling events and converting data to other forms, setting navigation between web pages etc. The tags are used to put components inside pages and connect them to server-side objects (dynamic content).
Structure of a JSF Application
Typically, a JSF application consists of the web pages and the tags that will construct them, the managed beans that dynamically create the components set properties, and a web deployment descriptor (web.xml).
XHTML
For building web pages, HTML is the default markup language of the Web, JSF though prefers XHTML.It follows a stricter structure than HTML since it’s based on XML, and it provides validation through XML tools (XSL, XSLT etc).
Facelets
Initially, JSF declared pages using the JSP language. The needs of web applications changed though, and JSP became cumbersome. To change that, the Facelets language was created and now is the default page declaration language in JSF. Also, it adds its own tag libraries enriching the page content.
Backing Beans
While they were previously mentioned as Managed Beans, it’s better to name them Backing Beans. They’re the connection between the web page and the back-end. If we need to dynamically create a component (or create our custom ones) or present data or navigate between pages, we’ll use backing beans with such functionality.
Expression Language
The Expression Language is the one that connects the JSF page with the properties of a backing bean. We can retrieve the values of those properties and execute methods that may interact with enterprise javabeans.
Sample Code and Explanation
In the picture below, we see two JSF projects. The first one is build with Maven while the second with Ant and Ivy. The build tools like the IDEs change the structure of the project at some degree, but the standard similarities are clearly visible.
We can see that both projects have a Web Pages Node and a Source Packages one. The first one naturally houses the web pages and the second the Java source code.
Login.xhtml
This page begins with the namespaces that JSF and Facelets support.
xmlns:h="http://xmlns.jcp.org/jsf/html
The h tag gives access to the basic JSF components that will be converted to HTML elements when the page is rendered.
<h:inputText id="j_username" value="#{authenticationJSFBean.username}"/>
The code snippet above has already the basic functionality of the JSF technologies. The h:inputText will be converted to an HTML element with “j_username” id and will show a textbox for the user to write in. The #{authenticationJSFBean.username} connects the value of that inputText with a String property in the backing bean, named username.
<h:commandButton id="login" action="#{authenticationJSFBean.login()}" value="Login"/>
This tag adds a HTML button of Submit type for when the form is submitted. In the action attribute it calls the login() method from the backing bean, while the value attribute is simply the title of the button. In case there’s a String in the action, the commandButton navigates to that page.
The namespace ui adds the templates that Facelets supports, giving us the ability to have similar looking pages based on a single template.
<div id="top">
<ui:insert name="top">Top</ui:insert>
</div>
<div>
<div id="left">
<ui:insert name="left">Left</ui:insert>
</div>
</div>
</div>
If we check the basicTemplate.xhtml on which the login page is built, we’ll find div tags that are used as placeholders to create the header, left, right and content places.
With the ui namespace, we can define those places and add our own content like below.
<ui:define name="top">
<h1>Please enter your credentials</h1>
</ui:define>
AuthenticationController.java
As it was expected, the backing bean has a username property and a login() method.
private String username;
public String login() {
//Processing
if (…) {
…
return "users/main.xhtml";
} else {
…
return "loginerror";
}
}
In order to use properties with EL, they must have a getProperty() method, otherwise they’re not visible. Consequently, we’re not allowing access to all of the bean’s properties, just the ones that we want.
The login() method returns a String. If the user is authenticated, the main.xhtml is returned whereas if they aren’t, the loginerror is. Both Strings are web page names on which the application will navigate according to the result.
So far, there isn’t any reason as to why this bean is called backing. By looking at the source code, it’s just a POJO with its properties and methods. What does make it a backing bean is the @Named annotation.
By using the @Named annotation, the objects management and lifecycle move over to the container. It’s the container that will create the backing when we navigate to that web page and keep it depending on its scope (request, session, etc).
Summary
Even though it was a brief description, we saw the basic features of JSF and its technologies. It was mentioned how JSF objects are organised in a web page and how they’re linked to backing beans via the EL.
Next chapter we deal with Contexts and Dependency Injection and how beans are used in the lifecycle of many web pages.
Chapter 6 - Contexts and Dependency Injection
Introduction
The CDI API is one of those that greatly upgraded and simplified the development of enterprise applications. It helps in the correct and effective connection of the web tier with the business tier, offering the developer an easy way to use any Java class in a web page’s lifecycle.
About CDI
The idea behind CDI is to easily connect the JSF part of an application and the enterprise beans that implement the business logic. It uses beans called CDI Beans, and they’re nothing more than Java classes which follow certain rules regarding their properties, methods and interfaces.
Although there are many variations of a bean (managed, enterprise, pojo), all of them follow rules according to their field.
The lifecycle of a web page is set by the user when they interact with the application. The moment the server needs to load a page, that’s a request. The CDI bean that will be linked to run upon the request, needs only the request scope.
For example, when the user chooses to logout from the application, there’s a request to the server to terminate the connection. So the CDI bean that will transfer the user’s credentials for the logout, will have the lifecycle of a single request.
In case many requests are needed, may be because the user fills a form that spans in two or more pages, the scope of the bean that saves the data must be broader, namely view, session or application.
Usage of CDI
The way to use a CDI bean is extremely simple and most times it’s no more than a couple of annotations. Prior to showing code snippets it’s essential to describe the business logic of this use case, which is adding items in a shopping cart.
The user can see all of the available items (courses in this case) and whichever appeals to them, is added to the shopping cart by pressing the appropriate button.
This whole process has many navigations from page to page, so many requests are made to the server. The CDI bean that implements the shopping cart must keep the user’s data for many interactions with the application. If we used the “new” keyword to create a shopping cart each time the user pressed the “Add” button, we’d end up with different shopping cart objects in every web page which would be destroyed whenever the user navigated to another page. So it’s essential to use a single object that is called whenever it’s needed.
Let’s see some specific parts of the ShoppingCart class (the full code is in the Appendix).
@Named("shoppingCart")
@SessionScoped
public class ShoppingCart implements Serializable {...
The @Named annotation defines that this class is a CDI bean and in any part of the application’s source code, we can refer to the class by the name in the parenthesis. This String name isn’t mandatory and in fact we can name it anything, for example “abc” instead of “shoppingCart”. But if it’s absent, the CDI bean is called by using the class name.
The @SessionScoped annotation sets the CDI bean’s lifespan for any requests to the server when the user interacts with the application. This means of course that each user has their own instance of this object, it isn’t a single universal one.
The properties of the class are private and have the appropriate accessor methods, the constructor of the class is the default one and the class implements the Serializable interface, therefore qualifies to be a CDI bean.
Since it’s a CDI bean, it can be used in many occasions. In this application, it’s used both in the page that the user adds courses but also in the checkout screen.
The JSF backing beans of those pages won’t use the “new” keyword to create the shoppingCart object. Instead they’ll use injection to access it like so
@Inject
private ShoppingCart shoppingCart;
and if we want to clear the contents of the shopping cart, the checkoutBean will execute the following method
private void clearShoppingCart() {
shoppingCart.clearCart();
}
Summary
With the addition of CDI in Java EE 6, connecting JSF and business logic was simplified dramatically. It’s indeed fine not to use the CDI methodology to develop an application, the drawbacks of doing so though are many. Besides only a couple annotations are needed to use the CDI API.
Next chapter deals with entities and how Java EE manages a database’s tables. The JPA is another great API that simplifies the application development process.
Chapter 7 - Java Persistence API
Introduction
In the second chapter of the paper, we saw the parts that an enterprise application typically consists of. It also became known that Java EE focuses mainly on the web tier, assuming the data processing from the database and sending them to the client. To perform these CRUD operations on the databases (usually they’re RDBMS), there must be an appropriate way of translating the relations between tables of a database to the object oriented programming model of Java.
Entities
It’s known that data in a RDBMS are organised in tables (Employees, Department, etc) and each table has many records of the entity it describes. The relations among the entities are defined as foreign keys in other tables, making the one-to-many etc relations. The de facto query language is SQL.
Java is an object oriented language though and it handles objects a lot easier than database tables. This is why the JPA defines the entity. It’s any POJO with some annotations that relate the object’s properties to the database tables.
A simple example of an entity is the following
@Entity
public class User {
@Id
@GeneratedValue
private Long id;
private String username;
private String password;
public User(){}
//Getters, setters
}
The @Entity annotation is the one that makes the POJO into an entity. It doesn’t necessarily mean that by simply using the @Entity we’re correctly mapping to the appropriate table, we need some more annotations for effective mapping.
@Entity
@Table(name = "USERS")
public class User implements Serializable {
private static final long serialVersionUID = 1L;
@Id
@Basic(optional = false)
@NotNull
@Column(name = "ID")
private Integer id;
@Basic(optional = false)
@NotNull
@Size(min = 1, max = 255)
@Column(name = "USERNAME")
private String username;
@JoinTable(name = "USERCOURSES", joinColumns = {
@JoinColumn(name = "USERID", referencedColumnName = "ID")}, inverseJoinColumns = {
@JoinColumn(name = "COURSEID", referencedColumnName = "IDCOURSE")})
@ManyToMany
private List<Course> courses;
}
Now all properties are correctly mapped to the database table. The @Table annotation refers to the table that the entity will map to, we can see it’s the “USERS” one. The properties are defined as basic types, not allowing null values, the Strings are of size 1 to 255 characters and are mapped to the table’s columns with the @Column annotation.
The List<...> field with its @ManyToMany and @JoinTable annotations is creating the relation between the User entity the Course. The first annotation means that a single User entity can have many Course entities and the opposite, a Course entity can relate to many User entities. The intermediate table “USERCOURSES” is used to hold the Many-To-Many relation and the @JoinColumn annotations point to which column of the first entity is the column in the intermediate table.
Looking at the class name more closely, we see that it isn’t the same as the table it maps to. The class defines a single entity while the database table holds many entities. Regardless of that, the class name could be anything and it would still map correctly provided that the table name is unchanged.
Following up is a diagram showing the relations between the entities in my project.
Managing Entities
Responsible to manage the entities in an application is the Entity Manager. The entity manager is defined in a specific context, meaning the entities it will handle and the database it will operate on.
The entity manager is usually used inside enterprise javabeans that work on the business logic and need access to the database, in order to save a new or to retrieve and calculate the total earnings of a company.
Querying Entities
The JPA offers two ways of querying entities, one is Java Persistence Query Language (JPQL) and the other the Criteria API.
JPQL is a simple query languages for entities similar to SQL, with the queries being Strings. The Criteria API constructs objects and relates them programmatically. This results to more code written and more objects created before executing the query, but the String based JPQL is prone to errors such as spelling.
Some examples are following. To retrieve all table records using SQL we would write
select * from Users
The JPQL equivalent is
select u from User u
Using the Criteria API the code[5] turns to
CriteriaBuilder cb = em.getCriteriaBuilder();
CriteriaQuery<ConfigurationEntry> cq = cb.createQuery(ConfigurationEntry.class);
Root<ConfigurationEntry> rootEntry = cq.from(ConfigurationEntry.class);
CriteriaQuery<ConfigurationEntry> all = cq.select(rootEntry);
TypedQuery<ConfigurationEntry> allQuery = em.createQuery(all);
return allQuery.getResultList();
More Query Types
JPA offers more ways to query entities. It can create dynamic queries, named queries, native ones in SQL but also stored procedures.
Dynamic queries consist of an initial String in JPQL form with String concatenations according to conditions. For example
String jpqlQ = "SELECT u FROM User u";
if(sth-happens)
jpqlQ += " WHERE u.name = 'Vasilis'";
Query query = em.createQuery(jpqlQ);
List<User> users = query.getResultList();
Named queries are static and cannot be changed. They’re faster to execute since the database connection directly translates them to SQL queries from the beginning, not any time the query is ran. They’re defined as annotations in the entity classes such as
@Entity
@Table(name = "USERS")
@NamedQueries({
@NamedQuery(name = "Users.findById", query = "SELECT u FROM Users u WHERE u.id = :id"),
@NamedQuery(name = "Users.findByUsername", query = "SELECT u FROM Users u WHERE u.username = :username"),
@NamedQuery(name = "Users.findByPassword", query = "SELECT u FROM Users u WHERE u.password = :password"),
@NamedQuery(name = "Users.findByName", query = "SELECT u FROM Users u WHERE u.name = :name"),
@NamedQuery(name = "Users.findByEmail", query = "SELECT u FROM Users u WHERE u.email = :email")})
@NamedQuery(name = "Users.findAllUsers", query = "SELECT u FROM USERS u")})
public class User implements Serializable {
This way, the createNamedQuery() method is called having the appropriate name argument. Each query parameter can be passed using the setParameter() method.
Persistence Unit
To query the database though we need access to it. The JDBC driver must be set for the specific database (Derby, Oracle, MySQL, etc), the database name etc.
There needs to be a settings file that holds such definitions. This file is called persistence.xml and among other settings it links the entity managers to the databases along with all related settings.
A complete persistence file [6]is following
<?xml version="1.0" encoding="UTF-8"?>
<persistence xmlns="http://xmlns.jcp.org/xml/ns/persistence"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/persistence http://xmlns.jcp.org/xml/ns/persistence/persistence_2_1.xsd"
version="2.1">
<persistence-unit name="chapter04PU" transaction-type="RESOURCE_LOCAL">
<provider>org.eclipse.persistence.jpa.PersistenceProvider</provider>
<class>org.agoncal.book.javaee7.chapter04.Book</class>
<properties>
<property name="javax.persistence.schema-generation.database.action" value="drop-and-create"/>
<property name="javax.persistence.jdbc.driver" value="org.apache.derby.jdbc.ClientDriver"/>
<property name="javax.persistence.jdbc.url" value="jdbc:derby://localhost:1527/chapter04DB;create=true"/>
<property name="javax.persistence.jdbc.user" value="APP"/>
<property name="javax.persistence.jdbc.password" value="APP"/>
<property name="javax.persistence.sql-load-script-source" value="insert.sql"/>
<property name="eclipselink.logging.level" value="INFO"/>
</properties>
</persistence-unit>
</persistence>
The needed settings, include the persistence unit name (chapter04PU) and the client driver (JDBC for Derby). Also, the URL property defines the location of the database and its name, in this sample it runs on localhost:1527. The user’s credentials to connect to the database are “APP” both for the username and password. Finally, the class tag defines that the Book class will have persistence on the database.
Summary
This chapter simply grazes the surface of JPA. It contains much more than what’s mentioned but everything else surpasses the scope of this paper. We saw how the tables of a database are related to class objects, along with the entity managers that access them and queries them with many ways.
Next chapter will mention how entity managers are used in enterprise javabeans.
Chapter 8 - Enterprise JavaBeans
Introduction
So far, two great mechanisms were described for creating enterprise applications. JSF is responsible for the user interface of the application and JPA handles the database transactions. The core features of the application though are its business logic.
It’s evident that the business logic shouldn’t be implemented in the UI, the UI could be in any programming language, be it an Android one or a JavaScript-backed application. In order to have the “separation of concerns” (each component handles specific functionality), the business logic is handled with enterprise javabeans.
About EJB
EJBs are components that implement the business logic of an application. They’re the ones that will check to see if a customer is eligible for loan, or automatically order new products to renew the stock of a warehouse. It’s an EJB that will complete the online purchase of a customer, and it’s a different EJB that will handle their payment methods.
A big advantage on using EJBs is it minimises the development time and reuses the code. Developers don’t have to deal with how the EJB communicates with the application server’s services, the server through the EJB container handles such functions.
Moreover, the same EJBs that are used in an application can be used in another one. Since they perform specific tasks, they can be used in many occasions that want that functionality. Depending on the client, it can communicate directly with the EJBs if it’s needed. A web client interacts with the EJBs through backing beans or the REST API, but a command line client may use the EJBs directly.
Types of EJBs
There are two types of EJBs, the session beans and the message-driven beans. The latter are used as listeners to transmit messages via the Java Message Service API and won’t be a topic in the paper.
Session beans though are the ones that implement the business logic and perform actions for the client. These separate into three other types, stateful, stateless and singleton session beans.
Stateful session beans keep their state for many interactions between the client and the server. For example when completing an online purchase, there are some steps that need to be performed, such as to check if the bank account has adequate balance. An EJB must keep the user’s data through all steps till persisting to the database.
On the other hand, stateless session beans do not keep their state for more than one request. At the last step of completing the purchase, the session bean that will call the entity manager and persist on the database will be stateless; only once this part happens.
Singleton beans are available to all users of the application and they’re single for the whole scope of it, unlike stateful and stateless beans that can be as many as we need. Moreover, they support concurrency since many users have access to them. For example, singleton beans could be used on online collaboration tools where many users have access to the same document.
Structure and Use of an EJB
It would be expected that creating an EJB is complicated, since it has so many abilities. On the contrary, an annotation is all that’s needed. The following examples demonstrate how easy it is to create EJBs.
@Stateless
public class AccountSessionBean {
private float amount = 0;
public String withdraw(float amount) {
this.amount -= amount;
return "Withdrawn: " + amount;
}
public String deposit(float amount) {
this.amount += amount;
return "Deposited: " + amount;
}
public float getAmount() {
return this.amount;
}
}[7]
In this example, we see that the class AccountSessionBean implements the business logic, that is to withdraw money, deposit money and show the amount. Regardless of the fact the code is simple, the business logic is implemented therefore it presents the idea of the EJB.
The following code (full at the Appendix), is from my project and shows how the session bean uses JPA and the entity manager to relate the user to the courses they’ve purchased.
@Stateless
public class CourseFacade extends AbstractFacade<Course> {
@PersistenceContext(unitName = "vasouvPU")
private EntityManager em;
public void setCourseUser(User u, int courseID) {
Course c = (Course)em.createNamedQuery("Courses.findByIdcourse").setParameter("idcourse", courseID).getSingleResult();
c.getUsers().add(u);
em.merge(c);
}
}
The use of the @PersistenceContext is the one that informs the EJB of which entity manager to use for database queries.
In order to use EJBs in other parts of the application, the injection mechanism is used much like the CDI beans. The difference is that instead of @Inject we write @EJB.
@EJB
private AuthenticationEJB auth;
Nothing more is needed to use a session bean in the code of another class. In the case we need to retrieve the user’s name we simply write
username = auth.getUser().getUsername();
Exactly like CDI beans, there’s immediate access to the properties and methods of the injected object.
Summary
Finishing this chapter, it’s clear that the contribution of the EJB API has upgraded drastically the Java EE stack and how enterprise applications are developed. Layering the code and “separating the concerns” in an application minimises its development process and eases its scalability.
From a simple EJB that adds two numbers to a more complicated one that uses JPA to access the database, its use is through the CDI injection. A single annotation is enough to create and use an EJB.
With so many advantages, EJBs aren’t limited to web applications that present data to users. They’re also used in web services with SOAP or REST methodologies, where data is transferred between machines.
Chapter 9 - Web Services
Introduction
The term “web service” means that “something” is accessible on the “web” delivering a “service”[8]. They’re client and server applications that communicate with the HTTP; the servers offering the service and the clients consume it. Due to the fact that web services transmit their messages using XML, the interoperability that’s achieved is great. The client can be built in any language, be it Python, Ruby, C++, etc as long as it can parse XML messages. In Java EE, the development of said services is done with the SOAP and RESTful methodologies.
SOAP and RESTful Web Services
The SOAP methodology uses the homonymous coding protocol to transmit messages (Simple Object Access Protocol) and the WSDL language (Web Services Definition Language, based on XML), while it doesn’t limit itself to the HTTP protocol but can use other ones such as SMTP or JMS. WSDL is used to create the official contract of the service’s functionality. It has the functions, data types, messages but also the location of the service. Moreover, it describes certain requirements for security and transactions with a database.
Due to the SOAP architecture, it’s the default methodology for “big” web services that demand high Quality of Service, meaning great security, extremely low downtime and little to no errors, such as banking systems.
For simpler scenarios, the REST methodology is prefered. Based on the HTTP protocol and by using it to the fullest, REST is simpler to use and more widespread. Any information exposed by REST is a different resource with its own location. This way, REST uses the web structure by providing each resource with a unique URI. It doesn’t require XML messages or WSDL contracts, although messages in REST are usually JSON ones. The absence of contracts though means that the message should describe its entire content.
Due to the great adoption of REST, its intended use is for web applications that serve to many clients. It provides easy scalability with a simple architecture while most clients can consume REST resources.
Example using JAX-WS
To better understand the JAX-WS API, the following example shows how easy it to create a web service.
@WebService
public class Calculator {
@WebMethod
public int add(int first, int second) {
return first + second;
}
@WebMethod
public int sub(int first, int second) {
return first - second;
}
}[9]
The Calculator class is exposed as a web service with the @WebService annotation. Its public methods are automatically exposed so the @WebMethod annotation is optional.
After compiling, packaging and deploying the application onto Glassfish, if we open the server’s admin console and go to the application's node and then press View Waypoint, we see the following
The Tester link allows us to test the service and its methods, presenting the following screen
By entering numbers as arguments in the add() method, the service’s response follows
Part of the WSDL contract that was created and defines the service functionality is presented below
At the beginning, it was mentioned that web services are client and server applications. In the use case of the aforementioned application, the browser is the client and the response is retrieved after visiting the Test link.
Example using JAX-RS
The REST methodology is closely linked to the HTTP protocol and that’s the reason RESTful web services must support at least one of the HTTP methods, GET, POST, PUT and DELETE. Again, JAX-RS uses annotations to define which class method will be triggered according to the corresponding HTTP method.
The following code was created automatically with NetBeans.
@Stateless
@Path("vasouv.javaee7thesis.courses.course")
public class CourseFacadeREST extends AbstractFacade<Course> {
@PersistenceContext(unitName = "vasouvPU")
private EntityManager em;
@POST
@Override
@Consumes({"application/xml", "application/json"})
public void create(Course entity) {
super.create(entity);
}
@PUT
@Path("{id}")
@Consumes({"application/xml", "application/json"})
public void edit(@PathParam("id") Integer id, Course entity) {
super.edit(entity);
}
@DELETE
@Path("{id}")
public void remove(@PathParam("id") Integer id) {
super.remove(super.find(id));
}
@GET
@Override
@Produces({"application/xml", "application/json"})
public List<Course> findAll() {
return super.findAll();
}
In the CourseFacadeREST class we notice the following; it’s a stateless EJB with all its methods responding to some HTTP method. The @Path annotation describes the class URI which is unique. The findAll() method responds to the GET method and is called by default when the URI is visited for the first time. The create() method is called to enter a new resource through the POST method. Respectively, the edit() and remove() methods update and remove resources from the database.
But setting the resources path is needed, meaning where they’re accessible from. Therefore, a class that extends the Application class (javax.ws.rs.core) and annotated with @ApplicationPath(“webresources”) is enough to name the path.
So by visiting the link <...>/webresources/<package>/.course/ we have the following
XML message that presents what the findAll() method returns. The rest of the methods are easier to visualise if the links created by Netbeans are used.
The picture above shows the initial GET request and presents the method’s contents. When clicking the Create button the following frame appears
and after pressing Save the POST method is called and saves the data.
Summary
After adding the two web services APIs to the Java EE stack, developing web services or converting existing applications to use web services was greatly simplified. It’s evident that with a small number of code we have ready-to-work web services according each methodology. Whether it’s SOAP or REST services, developing them is just about the business logic and not how they should be implemented in an application.
Although the web services have acquired vast adoption over the years, Java EE has the Servlet API that was the first step in presenting dynamic content in enterprise applications.
Chapter 10 - Servlets
Introduction
The Servlet API is the first mechanism Sun added to Java EE in order to develop dynamic web applications. Frameworks like JSF and JSP convert their code to servlets, they’re built onto it and work according to it without the developer noticing it.
About Servlets
Servlets are Java classes that are deployed on the application server and run various processes responding to HTTP methods. When the client requests something, the servlet container locates the servlet that must run and it calls the appropriate doGet(), doPost(), doPut() or doDelete() method. These are the most usual although many more can be called. Since they’re Java classes, servlets have all the characteristics of them and can run any valid Java code. This results to interacting with other objects and handle data, access databases or use the server’s default security mechanism.
Example using Servlets
@WebServlet("/report")
public class MoodServlet extends HttpServlet {
protected void processRequest(HttpServletRequest request,
HttpServletResponse response)
throws ServletException, IOException {
response.setContentType("text/html;charset=UTF-8");
try (PrintWriter out = response.getWriter()) {
//code
}
}
@Override
protected void doGet(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
response.setContentType("text/html;charset=UTF-8");
processRequest(request, response);
}
@Override
protected void doPost(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
processRequest(request, response);
}
}[10]
This Servlet class presents the following, the @WebServlet annotation defines the class as a servlet so it doesn’t have to be defined in the configuration descriptor (web.xml) and sets the servlet’s path. The class implements the doGet() and doPost() methods that are called to the corresponding HTTP methods. The processRequest() method is called in both methods, although the method called could be different.
Through the request parameter data can be retrieved from the HTTP request. If there’s an HTML form and the user tries to login, the request parameter contains their credentials according to the HTTP protocol. With a hypothetical database search, the response parameter would navigate the user to their account provided their credentials were correct, if not they would see an error page.
Summary
Even though the example above is very simple, it explains how servlets work; responding to HTTP methods. With a much different programming model than the JSF, it was the first API that added dynamic content to the Java EE stack. After many changes and updates, it’s still used today being the underlying model that JSF is built on.
References
http://www.itcuties.com/j2ee/jsf-2-download-file/
http://stackoverflow.com/questions/9391838/how-to-stream-a-file-download-in-a-jsf-backing-bean
http://alextretyakov.blogspot.gr/2013/07/jpa-many-to-many-mappings.html
http://www.java2s.com/Code/Java/JPA/ManyToManyJoinedTable.htm
http://stackoverflow.com/questions/2439594/how-do-i-set-the-value-of-htmloutputtag-in-jsf
http://stackoverflow.com/questions/15345349/create-inputtext-dynamically
http://stackoverflow.com/questions/15787053/how-to-bind-value-of-dynamically-created-htmlinputtext-component-to-bean-propert
http://stackoverflow.com/questions/11558379/jsf-binding-with-setvalueexpression-read-only
https://rahulganesh.wordpress.com/2011/07/06/jsfdynamicadditionofcomponents/
http://www.javadomain.in/dynamically-addremove-jsf-components-example/
http://stackoverflow.com/questions/3409053/jsf2-can-i-add-jsf-components-dynamically
http://java.dzone.com/articles/creating-jsf-pages-pure-java
http://www.codejava.net/java-ee/servlet/java-file-upload-example-with-servlet-30-api
http://www.coderanch.com/t/523364/JSF/java/Dynamic-JSF-programatically-adding-components
http://stackoverflow.com/questions/16022319/how-to-add-create-a-primefaces-progressbar-component-from-a-managed-bean
http://blog.c2b2.co.uk/2014/03/writing-and-deploying-simple-web.html
http://forum.primefaces.org/viewtopic.php?f=3&t=38525&p=121826&hilit=component+binding#p121826
http://forum.primefaces.org/viewtopic.php?f=3&t=35259&p=112698&hilit=component+binding#p112698
http://stackoverflow.com/questions/22502255/on-primeface-tab-view
http://www.coreservlets.com/JSF-Tutorial/primefaces/
http://www.coreservlets.com/JSF-Tutorial/jsf2/
http://forum.primefaces.org/viewtopic.php?f=3&t=39981
http://stackoverflow.com/questions/19064274/how-to-insert-a-primefaces-input-text-dynamically
http://stackoverflow.com/questions/7308535/how-to-dynamically-add-and-remove-a-tab-in-ptabview-component
http://stackoverflow.com/questions/15819137/dynamically-add-and-remove-panels-primeface
http://www.beyondjava.net/blog/how-to-write-a-dynamic-jsf-2-x-component/
http://www.oio.de/public/java/jsf-best-practices-javaserver-faces-session-tips.htm
http://en.wikibooks.org/wiki/Java_Persistence/JPQL
http://blog.jbaysolutions.com/2014/10/16/jpa-2-tutorial-queries-on-the-model/
http://blog.jbaysolutions.com/2012/12/17/jpa-2-relationships-many-to-many/
http://blog.jbaysolutions.com/2011/09/19/jpa-2-relationships-onetomany/
http://stackoverflow.com/questions/13485752/jpql-and-join-table
http://www.thejavageek.com/jpa-tutorials/
http://www.oracle.com/technetwork/articles/vasiliev-jpql-087123.html
http://stackoverflow.com/questions/7979382/how-to-create-join-table-with-jpa-annotations
http://javarevisited.blogspot.gr/2014/08/how-to-send-email-from-java-program-example.html
http://stackoverflow.com/questions/2422468/how-to-upload-files-to-server-using-jsp-servlet
https://netbeans.org/kb/docs/javaee/ecommerce/security.html#formBased
http://blog.eisele.net/2013/01/jdbc-realm-glassfish312-primefaces342.html
http://stackoverflow.com/questions/14758429/accessing-user-details-after-logging-in-with-java-ee-form-authentication
http://stackoverflow.com/questions/15022473/how-to-trigger-bean-after-j-security-check-complete-authentication-in-java
http://stackoverflow.com/questions/2206911/performing-user-authentication-in-java-ee-jsf-using-j-security-check
http://jj-blogger.blogspot.gr/2014/03/resource-library-contracts-with.html
http://stackoverflow.com/questions/22293708/how-to-add-tabs-in-tabview-in-primefaces-dynamically-on-click-of-a-command-but
http://stackoverflow.com/questions/7146625/how-to-group-radio-buttons-in-hdatatable-jsf2-0
https://github.com/jirkapinkas/example-contact-form
http://threadbarecanvas.azurewebsites.net/java-web/creating-a-javaweb-email-contact-form/
http://www.codejava.net/java-ee/jsp/sending-e-mail-with-jsp-servlet-and-javamail
http://www.javacodegeeks.com/2011/10/sending-emails-with-java.html
https://www.youtube.com/watch?v=GLvVnhFAvSY&ab_channel=JosephBernabeBagnes
https://www.youtube.com/watch?v=_zW27Y2boCo&ab_channel=JosephBernabeBagnes
http://www.javacodegeeks.com/2014/08/ejb-3-x-lifecycle-and-concurrency-models-part-1.html
https://netbeans.org/kb/docs/javaee/ecommerce/entity-session.html
http://www.adam-bien.com/roller/abien/entry/the_return_of_jsps_in
http://ramanathbhongalejsf.blogspot.gr/2013/04/create-login-page-with-jsf.html
https://www.youtube.com/watch?v=1xsU6juUZd0&ab_channel=JimLombardo
http://jugojava.blogspot.gr/2011/02/jdbc-security-realm-with-glassfish-and.html
http://java.dzone.com/articles/java-web-application-security
https://www.nabisoft.com/tutorials/glassfish/securing-java-ee-6-web-applications-on-glassfish-using-jaas
https://www.youtube.com/playlist?list=PLS1QulWo1RIbAiu7-bY4FpgYe3kzpC9tx
http://stackoverflow.com/questions/15055968/java-ee-simple-login
http://blog.mueller-bruehl.de/tutorial-web-development/
http://vladmihalcea.com/2014/07/30/a-beginners-guide-to-jpahibernate-entity-state-transitions/
http://ensode.net/roller/dheffelfinger/entry/javaserver_faces_jsf_in_a
https://www.youtube.com/user/koushks?&ab_channel=JavaBrains
http://javaknowledge.info/authentication-based-secure-login-logout-using-jsf-2-0-and-primefaces-3-4-1/
https://www.youtube.com/watch?v=vuwXxuCjOm0&ab_channel=SparkyGlassFish
http://opendevelopmentnotes.blogspot.gr/2014/07/javaee-from-zero-to-app-in-minutes.html
https://speakerdeck.com/ppapapetrou76/introduction-to-jee
http://www.javacodegeeks.com/2013/02/jdbc-realm-and-form-based-authentication-with-glassfish-3-1-2-2-and-primefaces-3-4.html
http://www.oracle.com/technetwork/articles/java/java-primefaces-2191907.html
http://zeroturnaround.com/rebellabs/how-to-use-jpa-correctly-to-avoid-complaints-of-a-slow-application/
https://code.google.com/p/javaee6-crud-example/
https://javaserverfaces.java.net/
http://java.dzone.com/articles/java-ee-7-whats-new
http://www.javacodegeeks.com/2013/05/java-ee-cdi-dependency-injection-inject-tutorial.html
http://www.reddit.com/r/java/comments/1ufagh/what_framework_do_you_recommend_to_build_web/
http://www.saltwebsites.com/2014/java-ee-notes
http://www.coreservlets.com/
http://en.wikipedia.org/wiki/JavaServer_Pages
http://en.wikipedia.org/wiki/JavaServer_Faces
http://en.wikipedia.org/wiki/Facelets
http://en.wikipedia.org/wiki/Comparison_of_web_application_frameworks
http://en.wikipedia.org/wiki/Comparison_of_application_servers
https://netbeans.org/features/java-on-server/java-ee.html
http://en.wikibooks.org/wiki/Java_EE_Programming
http://www.oracle.com/technetwork/java/javaee/tech/index.html
http://www.javacodegeeks.com/2014/02/wildfly-8-vs-glassfish-4-which-application-server-to-choose.html
http://www.javacodegeeks.com/2014/03/java-enterprise-software-versus-what-it-should-be.html
http://www.javacodegeeks.com/2014/03/java-ee-7-whats-new.html
http://www.javacodegeeks.com/2014/03/java-ee-the-basics.html
http://www.javacodegeeks.com/2013/07/java-ee-ejb-interceptors-tutorial-and-example.html
http://www.javacodegeeks.com/2013/08/file-upload-example-in-servlet-and-jsp.html
http://www.javacodegeeks.com/2013/11/what-is-your-structure-of-jee-based-web-projects.html
http://www.slideshare.net/arungupta1/java-ee7-webinar
http://en.wikipedia.org/wiki/Java_Platform,_Enterprise_Edition
http://programming-simplified.com/java_ee_6_video_training.html
http://www.javacodegeeks.com/2013/02/introduction-to-javaee-concepts.html
Bibliography
Civici, C. (2014), Primefaces 5.1 User Guide, http://www.primefaces.org
Evans, I. (2013), Your First Cup: An Introduction to the Java EE Platform, Volume 1, Release 7 for Java Platform, Enterprise Edition, Oracle.
Goncalves, A. (2013), Beginning Java EE 7, Apress, New York, USA.
Heffelfinger, D. (2014), Java EE 7 with Glassfish 4 Application Server, Packt Publishing, Birmingham, UK.
Jendrock, E., Cervera-Navarro, R., Evans, I., Haase, K., Markito, W. (2014), The Java EE 7 Tutorial, Oracle.
Juneau, J. (2013), Java EE 7 Recipes, Apress, New York, USA.
Keith, M., Schincariol, M., (2013) Pro JPA 2, Apress, New York, USA.
Leonard, A. (2014), Mastering JavaServer Faces 2.2, Packt Publishing, Birmingham, UK.
Wetherbee, J., Rathod, C., Kodali, R., Zadrozny, P. (2013), Beginning EJB 3, Apress, New York, USA.
Software Guide
GitHub repository
https://github.com/vasouv/JavaEE7Thesis
Needed software
- Java 8
- JavaDB 10.10.2.0
- Java EE 7
- Glassfish 4.1 Full
- NetBeans 8.0.2
Setup the project
- Default installation for all mentioned software
- Download and unzip my pre-configured Glassfish version and place it in C:
- Download and unzip my database in C:\Users\<user>\.netbeans-derby
- Download a copy of the project and unzip it in NetBeansProjects
- Register Glassfish inside NetBeans and start it. If JavaDB asks for username and password, they’re ‘thesis’ and ‘1234’
- Build and run
Video demonstration
[1] www.javacodegeeks.com/2014/03/java-ee-the-basics.html
[2] www.javacodegeeks.com/2014/03/java-ee-the-basics.html
[3] Taken from the pages 18 and 19 of the book Beginning Java EE 7 (bibliography)
[4] JSF project structure
[5] http://www.adam-bien.com/roller/abien/entry/selecting_all_jpa_entities_as
[6] Beginning with JavaEE 7, p.110 - 111
[7] https://github.com/javaee-samples/javaee7-samples/blob/master/ejb/stateless/src/main/java/org/javaee7/ejb/stateless/AccountSessionBean.java
[8] Beginning JavaEE 7, p. 455
[9] Java EE 7 with Glassfish 4 Application Server, chapter 10
[10] Java EE 7 Tutorial, 17.15