Java EE + MongoDb with Apache TomEE and Jongo Starter Project

Know MongoDB and Java EE, but you don't know exactly how to integrate both of them? Do you read a lot about the topic but you have not found a solution which fits this purpose? This starter project is for you:

You will learn how to use MongoDB and Java EE in a fashion way without having to depend on Spring Data MongoDB framework but with "similar" basic features.

The only thing better than a Maven archetype is a repository you can fork with everything already setup. Skip the documentation and just fork-and-code. This starter project contains:

• Jongo as MongoDB Mapper (www.jongo.org).
• Apache TomEE as application service and integration. (tomee.apache.org)
• Arquillian for tests. (www.arquillian.org)

The example is pretty simple, we want to store colors inside a MongoDB collection.

Our POJO is like:

Note that we are using @ObjectId annotation provided by Jongo to set this field as MongoDB id. Moreover because it is called _id, the id will be set automatically.

Then the service layer:

Note that there isn't a lot of code, but some points are really interesting stuff. Let's analyze them.

@Singleton is used to define an EJB as singleton, it works with @Stateless as well, for Java EE users no news here.

The class is abstract. Why? Because it allows us to not implement all methods but define them.

Also implements java.lang.reflect.InvocationHandler. This is because we want to use one really interesting feature which allows us to create a fallback method called invoke. For any method defined but not implemented this method is called.

We have a MongoCollection class (from Jongo project) that it is injected. MongoCollection represents a collection in MongoDB. Because we need to set which collection we want to work with, an annotation called @JongoCollection is created so you can pass the name of the backend collection. Note that MongoCollection is produced by CDI container by using our custom producer. Again no news here for CDI users.

Then there is a lot of methods which represents CRUD operations. Note that they are not implemented, they are only annotated with @Insert, @Find, @Remove, ... to set which is the purpose of the method we want to execute. Some of them like finders or removers can receive Jongo-like query to be executed. And also a method called countColors which as you can see you can implement as custom method without relying to logic implemented within invoke method.

And finally the invoke method. This method will be called for all abstract methods, and simply sends to PersistenceHandler class, which in fact is a util class against Jongo to execute the required operation.

And that's all, quite simple, and if you want to add new abstract operations, you only need to implement them inside PersistenceHandler class.

Some of you may wonder why I use annotations and not the typical Spring Data approach where the name of the method indicates the operation. You can implement this approach as well, it is a simple matter of creating a regular expression inside PersistenceHandler class instead of if/else with annotations, but I prefer annotations approach. Faster in execution time, clean, and for example you can refactor the annotation name from @Find to @Buscar (Spanish equivalent) without worrying if you are breaking some regular expression.

And finally the test:

This is an Arquillian test that has nothing special apart from one line:

.addAsManifestResource(new StringAsset(MONGODB_RESOURCE), "resources.xml")

Because we are using Apache TomEE we use the way it has to configure elements to be used as javax.annotation.Resource in our code.

The META-INF/resources.xml content will be:

and then we use in our MongoClient producer to create the MongoClient instance to be used inside code. Note that we are using @Resource as any standard resource like DataSource, but in fact MongoClientURI is injected:

so in fact Mongo connection is configured in META-INF/resources.xml file and thanks of TomEE we can refer it as any standard resource.

If you are going to use other application server you can change this approach to the one provided by it, or if you want you can use DeltaSpike extensions or your own method. Also because MongoClient database is get from a method annotated with @Produces  you can be injected it wherever you want on your code, so you can skip the abstract services layer if you want.

What are the benefits of this approach?

First that it is Java EE solution, you can use it without depending on Spring framework or any other library. You implement what you need, you do not download a bunch of libraries simply for accessing a MongoDB with some kind of object mapping.

Also as you may see, the code is quite simple and there is no magic behind it, you can debug it without any problem, or even improve or change depending on your needs. The code is yours and is waiting to be modified. Do you want to use native MongoDB objects instead of Jongo? No problem, you can implement it. Moreover there aren't much layers, in fact only one (the PersistenceHandler) so the solution is pretty fast in terms of execution.

Of course this do not mean that you can't use Spring Data MongoDB. It is a really interesting framework, so if you are already using Spring, go ahead with it, but if you plan to use a full Java EE solution, then clone this project and start using MongoDB without having to make some research on the net about how to integrate both of them.

You can clone the project from https://github.com/lordofthejars/tomee-mongodb-starter-project

We keep learning,
Alex.

I'm driving down to the barrio, Going 15 miles an hour cause I'm already stoned, Give the guy a twenty and wait in the car, He tosses me a baggie then he runs real far (Mota - The Offspring)

Music: https://www.youtube.com/watch?v=xS5_TO8lyF8