Using Java to Write to a Database – Part 2

Continuing from Part 1

In part 1 we created the simplest of databases, nothing more than a table with 2 columns.

There are two main ways to write an application in Java, in my opinion of course… the first is for native applications, those applications that run directly on your desktop or mobile device. The second is an application that runs on top of an application server, such as Tomcat. Tomcat would then, normally, provide a way to interface with the application through web pages or APIs.

Of course it is possible to run an application on an application server with no interfaces. This could be for tasks such as generating reports as a scheduled service and sending them via email. Therefore, no interaction and no interface.

So, in this part we will first focus on the most common use, Web Applications.

In this part we will use a JDBC connection so the data can be accessed in our applications.

For Connecting to a database with Tomcat <- use this link as it is the foundation for the rest of this post.

Now, hopefully, you have a database and a simple web application to pull data from that database. The next step is the purpose of this post, writing data back to the database.

In the same way you retrieved data, to write data back just takes a couple more steps.

public void getEntityTableName() {
EntityManagerFactory emf = Persistence.createEntityManagerFactory(“jdbc/myDatabase”);
EntityManager em = emf.createEntityManager();
try {
PetTable petTable = new PetTable();
EntityTransaction transaction = em.getTransaction();
} catch (Exception e) {
System.out.println(“e = ” + e);
} finally {

The difference is the need to start and end a transaction. When writing data to a transactional database you need to obtain exclusive rights to the table where you are writing data to, just so no one else can write or delete data that you are using. What this also allows is the rolling back of changes if something goes wrong.

EntityTransaction transaction = em.getTransaction();

Make some changes to the database


That’s it, lastly you need to close the connections to the database, otherwise you could spawn multiple connections and cause a denial of service.


Using Java to Write to a Database – Part 1

Writing to a database is one of the most important actions of any programme. Being able to store data independently of the application is useful for many reasons;

  • The data can be accessed by other applications, such as mobile
  • The application can be updated without affecting the data
  • Database server performance can be upgraded without affecting the application

And many more…

If you have read my other blogs you will know that I use Tomcat for my application servers, however an application server is not required for an application to run. Mobile application, for example, run (mostly) natively on the device. I also use NetBeans as my IDE.

What is needed? The main Library you will need is the vendor specific database driver. These are also known as JDBC (Java Database Connectivity) drivers when coding in Java.

In this example I will use MySQL which is a free and open source database. You can download it from  I will not go into the installation and setup of the database server in this blog. The packages are very easy to use, with a next, next, next type installer.

Once you have your server installed, from a command line, log into the database server.

mysql -u root -p

After you have logged into the database server, you will need to create a database.


Now tell the system you want to use the new database.

USE petstore;

A database is a collection of tables, views and other functions. You are going to need somewhere to put the data, a table.

CREATE TABLE pet (name VARCHAR(20), kind VARCHAR(20));

Have a look at your newly created table.


OK, you have a database, so let’s connect to it from your application! In part 2…

Configuring Contexts and Dependency Injection on Tomcat

Contexts and Dependency Injection? CDI? What’s that?

The most fundamental services provided by CDI are as follows:

  • Contexts: The ability to bind the lifecycle and interactions of stateful components to well-defined but extensible lifecycle contexts
  • Dependency injection: The ability to inject components into an application in a typesafe way, including the ability to choose at deployment time which implementation of a particular interface to inject

And in English? Contexts define how long a class will remain and will be usable in memory. This is defined by something called scope.

The most common scopes are:

  • Request
  • Session
  • Application

The javax.enterprise.context.RequestScoped scope means that the class is created at the start of your request and destroyed at the end. This can be used for a query from a database, like retrieving a list of values to populate a selection box, or maybe submitting a input text which only requires to write and forget.

The javax.enterprise.context.SessionScoped scope will cause any classes annotated to last for the length of the session. This means that if the class is called when you load the site then it will exist in memory until either the session timeout ends or you close the browser. You need to be careful with this one as you can run out of memory if too many classes exist as each will require memory while you use them. Session scopes are useful for holding variables that you would want for the whole session, like a login token.

The javax.enterprise.context.ApplicationScoped scope is a global scope, and it will last for as long as the application is running on the server and can be accessed by any session. If you store a variable in an application scoped class, then if one session writes to it another session, it can read from it, as in another user on another computer can read from it. This can be useful for information you may want to share without the need to have multiple calls to classes, such as the server status or logs.

Make sure you use the right javax.enterprise.context import as the faces one will not work with Weld.

Dependency injection is a really useful service, and I really mean useful. Before Dependency injection you would need to use creative ways of passing information between classes, without the classes being able to see each other.

It’s hard to explain how difficult it used to be before Dependency injection. You would have a class that returned some values, they would be displayed on a web page, and then you would need to use the web page to pass the values to the next class.

So if you had a class that was holding a login token and you wanted to see the user name that it was assigned to and then save that to a database log,  you would need to pass that value to the web page and then pass it back again on a user action. Very hard to work with when you compare how to do it with Dependency injection.

To use Dependency injection all you need to do is annotate a variable with @Inject

UserManager um;

This will create a shared instance of the class that can also be used in other classes, depending on the scope. Now you can set a variable like um.loginTime and then use the same variable data in another class that has the same injection to write to a database.

Tomcat does not have CDI “out of the box” and requires a little configuration of your application, namely the Weld Library.

There are 3 parts to enable CDI on Tomcat. The Weld Library needs to be included (pom.xml), a listener needs to be declared (web.xml) and a little magic file needs to be created (beans.xml).

Add the following to the dependencies section of your pom.xml (Maven):


Add the following to your WEB-INF/web.xml:


Create a new file called WEB-INF/beans.xml with the following:

<?xml version=”1.0″ encoding=”UTF-8″?>
<beans xmlns=”;

That’s it. You can now inject classes into other classes without the need for the new Class() declaration and also share the instance.

Well, again, I hope this has helped someone and I look forward to your comments.

Configuring JAX-RS to work on Tomcat (Microservices)

There is currently a buzz around microservices. When these services are served from an application server, JAX-RS is a good option as it has a well supported community and there are lots of books available on the technology.

However, again, Tomcat “out of the box” doesn’t support JAX-RS without a little configuration.

There are two parts needed for Tomcat to use JAX-RS in your application. One is the Jersey library.

Jersey RESTful Web Services framework is an open source, production quality, framework for developing RESTful Web Services in Java that provides support for JAX-RS APIs and serves as a JAX-RS (JSR 311 & JSR 339) Reference Implementation.

Jersey can be used as a library in your web application that is deployed to a Servlet container such as Tomcat. You should add the jersey-server, jersey-servlet and jersey-bundle as dependencies to your project’s pom.xml

The other part needed is to create a Class in your application that extends the Class. JAX-RS provides a deployment agnostic abstract class Application for declaring root resource and provider classes, and root resource and provider singleton instances.

This will allow you to configure the path for all the services you create by configuring the Class as an annotation.

public class JAXRSConfiguration extends Application {


That’s it for the configuration. Now all that’s left is to create a Class to act as an API for your service.

public class SomeWebService {

public String getSomething() {
return “Hello world!”;


Then it’s just a simple case of using it, http://localhost:8080/MyApp/resources/apathtouse

As you can see from the example above I used GET. However you can use any of the HTTP methods in your API

  • GET – normally used to query the records
  • POST – normally used to create a record
  • PUT – normally used to update a record
  • DELETE – normally used to delete a record

However, the actual implementation of your methods are completely up to you. You could use the DELETE method to create and the GET method to delete. I would not recommend that though…

Again, I hope this helps someone and I look forward to your comments.

Configuring JSF to work on Tomcat

This project is available on GitHub

I have been using Glassfish and Weblogic for many years and they have been very good to work with. They have lots of features and a comprehensive administration interface.

Glassfish – I noticed that the more Web applications I deployed, the slower the server became. I have one server that even after removing all of the applications and just leaving one it still took 2-3 minutes just to load the list of installed applications. Even clean installs are not as responsive and lean as I would like them to be with each instance taking 500mb of ram just to start up. No good for Microservices.

Weblogic – As with Glassfish, Weblogic has an administrative interface with lots of configurable features. And Weblogic, just like Glassfish,  can also be heavy on the resources, needing 500-1000mb ram just to start up!

So I started to look into other JavaEE application servers. There are lots of JavaEE servers, some of which are derivatives of the open source Glassfish, such as Payara, which is a commercially supported version of Glassfish with patches and updates.

I didn’t want to use just another version of Glassfish or Weblogic, then I came across Tomcat.

Tomcat is small, the install is only 15mb! and when running it only uses 140mb of ram to start up.

Tomcat is also fast, really fast, from the log file on a cold start “Server startup in 360 ms” compare this to the 1-2 minutes that Glassfish or Weblogic can take. And application deployment, again, fast! where Glassfish and Weblogic can take minutes, Tomcat will do the same deployment in seconds.

So, it’s fast, small, quick to deploy, what are the down sides?

Tomcat is lightweight… but this also means it doesn’t do a lot by itself. Tomcat runs on the JVM and doesn’t come with any extra’s.

What do I mean? Glassfish has built in support for Jax-RS and JSF, Weblogic has a suit of extra’s like ASF out of the box. All you do is tell your code that you want to use ASF components and deploy.

So when I tried to move applications over to Tomcat I found out very quickly the limitations of the out of the box server. However, with a little configuration of your web app, Tomcat can handle everything any JavaEE server can.

Now the background is out of the way, let’s get JSF working.

Java Server Faces, or JSF, is a Java specification for building component-based user interfaces for web applications. From your Classes/Beans you can dynamically work with methods from a web page. Working with input forms and buttons to control your methods allows you to create feature rich web apps.

Like I said before, Tomcat does not have a lot features out of the box and you have to configure your web app to use the JSF specification.

This is simple if you are using a Maven based project, a little harder if not, but not too hard. If you don’t use Maven then you will need to download the .jar files and add them to your library.

To start, create a new Maven project. Right click on the new project and go to Properties. Navigate to Frameworks and Add JavaServer Faces. This will configure the web.xml to use the JSF servlet filter but it also adds the following dependancy to your projects pom.xml that isn’t compatible with Tomcat.


Delete this dependancy and add the following dependancies so Maven downloads the required libraries for Tomcat.


You may have noticed the weld library, this is a helper servlet that will allow JSF to access your Classes.

Add the following to your web.xml file.


One more important configuration that I sometimes miss and it drives me crazy when troubleshooting is the requirement of a special file that serves no purposes other then enabling JSF to use your Classes. It’s called beans.xml.

To add beans.xml just right click on your project and New -> Other… and choose the category “Contexts and dependancies” you’ll find the Beans.xml in there, just add it to your project.

Create a new Class called SaySomething with the following contents

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

public class SaySomething {
public String getHello() {
return “Hello”;

There are 2 important parts to this class, @Named and @RequestScoped. @Named will make this a managed bean and usable by JSF, @RequestScoped defines the lifecycle of the bean, in this case it will only last in memory for the time of the request.

It is very important to use javax.enterprise.context.RequestScoped and not javax.faces.bean.RequestScoped as the latter will not work with Tomcat.

Now you can use the bean from a JSF page. Open the index.xhtml file that was created when you added the JavaServer Faces framework.

Put the following into the body area #{saySomething.hello}

That’s it, run the application and you should see a web page pop up with the word Hello.

Now you have a JSF configured web app you can add more classes and methods and use these inside JSF components like

<h:outputText value=”#{saySomething.hello}” />

I will be writing other blogs on how to use these components but for now this is a configured running application that is compatible with Tomcat.

I hope this has helped someone and I look forward to your comments.

Connecting to a database with Tomcat

Browsing the internet for instructions on how to connect to a database from my Java web app using Tomcat was a minefield.

I almost gave up on Tomcat as so many sites would give overly complex methods involving changing the configuration files of the Tomcat server itself. How could that be? I don’t have access to the configuration files of hosted services like Amazon, so there must be another way… and there is.

I discovered there are easy steps to allow your web app to connect to a database.

I am using Netbeans, so the following information is for Netbeans, however, you may be able to adapt it to whatever IDE you use. I will be discussing only how to create the connection in this post, but not how to use them, that will be in other posts.

Before you can use the database connection in your app you must first register the database connection with the IDE. Under the services tab, right click on the database element and select “New connection”. Follow the instruction to connect to your database. On the last step, where you are asked to set the JNDI name, do not go with the default. Instead try to follow the preferred naming convention of jdbc/myDatabase as this will help when connecting to it later.

You will need to use the correct driver for your database. Java has a lovely translation system that allows you to write SQL queries using a standard syntax called JPA. The drive will then convert this SQL into the vendor specific syntax to work with the database you are connecting to.

You can either add the .jar file from the vendors download page to your projects library, or use maven by adding the correct tags to your projects pom.xml file if you are using a maven project(a good idea).

Here is the MySql one;


And this one works with Microsoft Sql;


Now you have the correct driver and the IDE can connect to your database you can configure your web app to use the database.

Right click on your project, select New and then “Entity classes from database”. When you select the JNDI name you created earlier Netbeans will retrieve all of the Tables and Views (that have primary keys) from your database. Select the ones you want and next, next, finish. This will create the Entity classes for you.

As I said earlier, I wont go into detail in this post on how to use the Entity classes. Search my other posts for help with that.

So, you have your Entity’s. You have connected your IDE to your database. Can I just publish my app to Tomcat? Unfortunately, No.

Unlike other Java application servers, such as Glassfish, Payara or Weblogic, the war file does not create JDBC connections in the server.

However, it is rather easy to do in Tomcat once you know how.

To tell Tomcat how you want your web app to use the database you need to edit the WEB-INF/web.xml file and add the following tags.

<description>DB Connection</description>

Now you can use your database from your beans. I use the following code to do this.

public EntityManager getEntityManager() {
EntityManagerFactory emf = Persistence.createEntityManagerFactory(“jdbc/myDatabase”);
return emf.createEntityManager();

public List<EntityTableName> getEntityTableName() {
EntityManager em = getEntityManager();
List<EntityTableName> results = (EntityTableName) em.createNamedQuery(“EntityTableName.findAll”).getResults();
return results;

That’s it! I can now use the getEntityTableName() method to pull the results from the database and use them as needed.

I hope this helped someone and I look forward to your comments.