Sunday, October 11, 2015

Playing with Hazelcast on Payara

I have been reading a bit about Hazelcast, came up to chapter 5 in, but as I am a bit impatient and wanted to try out some stuff before reading the whole book and thinking about possibilities to use Hazelcast in my current work, this Weekend I set up to solve the following:

  • Use Hazelcast IMap in a Java EE container
  • Use MapLoader to load into a IMap with JPA
  • As far as possible, use CDI
Payara comes with a Hazelcast, but solving this tasks may not be so straightforward, and I will try to explain why.

As usual I use a simple blog Post RESTful service as an example.

Using Hazlecast in Payara

Even if Payara comes with an embedded Hazelcast, I will not use it by letting Payara start it, and the reason is what I found when playing around with EntryListener. I will however use the Hazelcast that is provided, but will not activate it as written here: but more with ideas as written here:

To start with, this is what we will need in the pom.xml,

I am using Hazelcast 3.5 since that is the one that comes with Payara 4.153.

To fire up Hazelcast we will use an annotation and a provider so we can use CDI where we want to use stuff from Hazelcast.

The reason for doing like this is that I noticed by playing around with EntryListener that by letting Payara firing up Hazelcast I cannot really add listeners, since Hazelcast then know nothing about my classes (resulting in ClassNotFoundException), so to resolve this we need to provide the class loader from our web-application to Hazelcast. To do this we need to start it "manually" and provide the class loader so Hazelcast knows about them. You can also see we configure Hazelcast with a MapLoader, more on that later.


I will not share the full code since you can find it on Bitbucket. In PostResource we use CDI to get hold of the Hazelcast, it will initialise on first use, so if no pre-warming occurs (like using a startup bean) it will take 5-10 seconds.

And use it

For the creation of a Post we can use a trick to load it in the map by trying to get it after the save. That is we don't put it in the map directly and use a MapStore to save it (we don't know the id until after the persist). But since this is about using MapLoader, we will use that and not put it (as indicated in the comments)

MapLoader using JPA

Actually, I am not using it directly from the MapLoader, but injecting a @Statless bean from it, that does the actual JPA stuff.
As the MapLoader lives in Hazelcast and is created by it, we cannot use @Inject or even make it a managed bean (well we can, but it will not help since it is not using the jave ee container to handle it). But since CDI 1.1 we can inject using the CDI-class.

This is how the map loader I create looks like:

Notice the code to inject the PostRepository (which is the bean using JPA with an EntityManager). This will work since Hazelcast is loaded from the container with our classes.

Some notes

I have implemented loadAllKeys() and loadAll(...), this is probably fine since I do not have so many posts, but for a huge database and if you do not want them all in memory, you may leave them empty and return null for keys or you will end up waiting for a while. I played with a criteria search on the map

and found out that by doing that, Hazelcast will try to load all keys from the database before it searcher memory.
However, this is done only once, if you add items to the database, it will not get loaded if you do not do anything to tell the map, as you have seen in the "@POST" or put it there yourself, subsequent searches on the map will not try to load items not there from the first loadAll.

Payara does not really matter in the context, other than having a Hazelcast and being a Java EE container. But I also use it since it have a default datasource for Derby, so I kind of used that to avoid setting up a database, and load a few posts to get started.If you use another container, you may have to change the hazelnuts dependency to be "compile" instead of "provided" if that container donate have it. You may also need to set up a datasource.

The code can be found here: []

Tuesday, May 19, 2015

Payara Micro, even easier

Just saw this post. []. It is not even nescessary to build a runner, using Payara Micro, it is as easy as this:

More here:

RESTful Service on an embedded Glassfish/Payara

Last posts were about making a RESTFul service and run it on Jersey with an embedded Jetty.
This time I will set up a more Java EE like solution with the same REST Resource, but instead run it on an embedded Glassfish (actually, I will go for Payara). I will take the same model as before. Next part I will also add a JSF 2.2 client to use the RESTful service.

I will create this as a maven multi module with a parent project and two subprojects. One will be a web-project and the other will be a "runner" for the embedded Glassfish. I will not use maven to run, but will create a class that will run the embedded Glassfish with the war-file from the other project.

As it is pretty easy I use NetBeans to create maven projects for me.

The structure will be like this:

  • embgf
    • task-web
    • gf-runner
    • pack-dist


To start with, instead of having to set up a Servlet on "/api" path, we will create a configuration class that extends JAX_RSs Application.

And this will be the class for the Task service.

The service will be available at [http://localhost:2001/task-web/api/tasks] (depending what you use as port and contextRoot)
Just to have some Tasks to start with since we have a simple cache in a HashMap, we create a startup bean to create some.


Embedded Payara

Trying to follow [] I ran in to some issues. The dependency on that page does not really work, it end up with the following message:

There is a bug-report on this. But to get on, I will download the jar and do a "quickie" and add it as a system dependency and get on.

The code to get up and running with the war-file from task-web on an embedded Payara is just a few lines:


As I am a bit lazy and want to avoid copy jars manually I created a pom-project just to copy dependencies. The needed jar file will end up in the root folders under ./dist/, I also added a bat file to start the embedded Payara with the following content:

I also tried the jersey-client from the previous post with s slight modification for the context-path and it still works. (or you can start the payara with "/" as context path)

In next part I will add a JSF client on top of this service to show some nice stuff in Java EE 7 and JSF 2.2.

[The full project can be found at:]

Saturday, May 2, 2015

REST with Jersey and Jetty part 3

REST with Jersey and Jetty part 3

Adding JSON support.

The first two parts  in this small series of posts were about setting up the server and be able to run it with Jersey. [REST with Jersey and Jetty part 1, REST with Jersey and Jetty part 2].

This time there will be a bit more work. And I will take it step by step.

The service we will implement will handle tasks. To start with, there will only be one task list where all tasks will go.

The api will be the following.
Task class:

To start with we add support for getting the list, there will be some hardcoding until we have the working JSON support, since the first thing we want is a working Jersey with JSON support, not to complicate things further. When we have that, we can start adding functionality. But in the end, we will try to support:

  • list all
  • show a single task
  • create a task
  • update a task
  • remove a task
  • show range of tasks
  • get task count

But starting with some hardcoded stuff, to get the server running with JSON, this will be the stating point for the TaskResource

If you start the server and try to surf to this [http://localhost:2001/api/tasks] will yield the following in the log.

so we need to add some stuff to have JSON support.

Well, just a shor Googling, and it was pretty easy to add. [] gives a hint. Just added moxy and it works to get JSON with the @GET.

So lets go for some real coding. We will add a simple cache, To avoid having a database for this simple example it will only contain a map with the tasks.

Lets start with some simple support of the cache:

Lets first add a method to create a task and one for getting a specific task.

To test this, we will need to also add a method to get a single task and a client to test it.

First, the client.

So far the client just adds a Task, gets the URI to the created Task and then gets it using the @GET for the methods added above.

Next step, fix the getAll().
The client cannot handle a List without wrapping it in a GenericType, but that is really all there is too it, we can still return List from the method.

The only thing we need to add now is update and delete. We will also add some code to test it in the client.

I also made some changes in the client:
Enjoy your Task microservice in REST using embedded Jetty with Jersey.

Read more about Jersey []

Friday, May 1, 2015

REST with Jersey and Jetty part 2

REST with Jersey and Jetty part 2

Getting Jersey into play

In this part, we will introduce Jetty as serving with rest. We will att a class serving a @GET request.

We will need an extra dependency for Jersey to work, and after getting a strange error under startup I ended up changing the dependency on Jetty from the previous post []. I got the following error:

When adding the dependency for Jersey 2.17 after th Jetty dependency. Actually I got it to work by moving the Jetty dependency to after the Jersey dependency. But reading the log you can see that 2.17 if Jersey used Jetty 9.1.1 so, updating Jetty dependency to 9.1.1.v20140108, the order does not matter.
This is the dependencies for this part.

We will also create a new statup-class, It will not be much more code than the one in the previous part, but some extra stuff is needed to get Jersey into play.

The difference here is that we use a ServletHolder with some init parameters to set Jersey up. We also set the path to serve to "/api/*" instead of plain root "/".
That brings us to REST, we need something to show that it works. To do this we have a class under "rest" package called HelloResource.

So now the only thing you have to do is to start upp JerseyServer and surf into [http://localhost:2001/api/hello] and you should see the hello message. And there you have your first little Microservice ;)

In future post will explore how to use more than @GET and also how to add JSON support to this.

Thursday, April 30, 2015

REST with Jersey and Jetty part 1

REST with Jersey and Jetty part 1

Running Jersy standalone with a Servlet.

A few days ago I started to look into how to run a REST service with an embedded container. Now a friend of Springframework will say, that is easy with Spring, but after looking at a tutorial [] I notice a couple of things. The annotations are not the standard JSR 331/339 ones, and there is a lot of other things from spring framework coming into play. Well, sorry Spring-guys, I don’t want that. I want to go with standard JSR annotations, and no specialities from Spring.

So my ide is to use Jersey which is the reference implementation och JSR 311/339 and run it on a server that can be embedded. What I want to do is to have the following support.

  • Ability to run with an embedded server (my choise: “jetty”)
  • Ability to serve REST calls (my choise: “Jersey”)
  • Ability to communicate wiht JSON. 
After some research I noticed that it is not easy to find any good resource on how to run Jersey with an embedded server. the bes I could find was [] , but I don’t like blogs saying “you only need to include the jars necessary or use maven” but leaving out the information of which the necessary jars are or the specific maven dependencies needed.. the documentation over Jersey is scarce in examples.

I will start this “journey” by building it up step by step. In this part, I will do only what is necessary to start an embedded server.

I used the above blog as a starting point. First step I will show is how to run a servlet in an embedded Jetty.

The first thing to do is to have a dependency to Netty.

The server will be started in a class with a main method, 

There will also be a simple servlet to run in it.

Next post is about how to create a REST service based on Jersey and run it in Jetty.
(Update: changed the version of Jetty dependency, since I in next post use Jersey 2.17 and there was some issues running with Jetty 9.0.2)

Sunday, December 29, 2013

Why I plan to leave RichFaces

Having recently worked with upgrading RichFaces 3.3 to 4.3.1 I have come to the conlusion.... "It basically s*cks". I will give some reasons why:

  • Huge makeover of tags
  • Removal of tags
  • Changes in attibutes
  • Too many attributes.
Maybe RF was good when it came, because there was not so much else. But the makeover from 3 to 4 made an upgrade a real pain in the a**.

Googling help for RF in most cases gives result for 3.3.x solutions. I have found it hard to find any useful information about 4 or later. This makes an upgrade hard since it is not easy to find the proper information how things are done with 4.3.x, specially how to replace stuff that is removed from 3.3.x since there is not a decent upgrade guide to be found either. Maybe I have missed some place where all this is written, but weeks of Googling without finding anything is another problem, the documentation s*cks when there is not easy to find what you need.

Makeover of Tags

Some examples: 

Removal of tags

rich:modalPanel dissapeared. Well WHY? I think a lot of people used it, now all that code have to be totally rewritten.
rich:layoutPanel was removed. Well now I have found nothing obvious to replace it so back to postitioning by div and css.

Changes in attributes

Take rich:dataTable as an example: some attributes removed, some new, and also changes from camel-case to all lower case attributes but not all. WTF? do you really want someone to use the framework after an upgrade, do not change EVERYTHING. All event-attributes was changed to lowercase ("onRowClick" to "onrowclick"), but not things like "rowClass".

rich:panel: attribute "header"changed meaning from label to space-separated list of styles (???)

Too many attributes

a4j:commandButton: 32 attributes
a4j:commandLing: 37 attributes
rich:dataTable: 34 attributes

This is just a few examples, there is a lot of headache upgrading from 3.3.x to 4.3.x, not only on the surface, if you are using classes in your backing code, be aware, the package structure is also changed, classes have dissapeared and things just stop working. Changing the tags may look hard enough, but when new ones are in place you still probably have strange bugs that need fixing since things that worked before does not work any more.

If I would choose next upgrade, I would not choose RF 5, but go for PrimeFaces instead.