Tuesday, May 19, 2015

Payara Micro, even easier

Just saw this post. [http://java.dzone.com/articles/java-ee-embedded-and-micro]. It is not even nescessary to build a runner, using Payara Micro, it is as easy as this:

More here:http://www.payara.co.uk/introducing_payara_micro

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 [http://www.payara.co.uk/using_payara_embedded_and_payara_micro_with_mav] 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: https://bitbucket.org/pejomstd/embedded-gf-payara]

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. [http://stackoverflow.com/questions/25474223/jersey-rest-messagebodywriter-not-found-for-media-type-application-jso] 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 [https://jersey.java.net/documentation/latest/index.html]

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 [http://ironicprogrammer.blogspot.se/2015/04/rest-with-jersey-and-jetty-part-1.html]. 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 [http://spring.io/guides/tutorials/bookmarks/] 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 [http://jlunaquiroga.blogspot.se/2014/01/restful-web-services-with-jetty-and.html] , 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.

Wednesday, November 13, 2013

Designing a “modular” web application


I would like to separate functionality for a web application into separate jar-modules and include these in a war project.
The purpose for this is to separate development and deployment, that is, to develop functionality separately and include it in the war-packaging and it should automatically be usable with templates, menues etc.
Sorry if the code don't display so well. But putting codes with Generics is not so well handled by Bloggers editor, so until I have time to fix it you will have to live with it ;) and I will use [] instead of <>


To make it modular it is nescessary to have some common code (placed in “common-web”). The structure for this is basically:

  • common-web: will contain code common to modules and web-applications.
    • templates: for reuse in different modules, basic templates is put in a common module.
    • login: (out of scope, will not implement login in this example) for reuse of login-form etc. i.e. the same files and functionality applies to all web-applications that uses login.
    • resources: common css and images is placed to be reused.
    • menu: functionality to assemble n menu(es) from m modules so they will present in web-applications no matter in what module a page is used.
    • common code: code for hoding and generating menu(es), common utility code for JSF, ManagedBeans etc.
  • war: web-project with war-packaging that will use modules.
  • webmoduleA..X: functional parts that implement a function or group af functions that logically belong together.
    • as an example I will implement at “todo-webmodule” in a PoC to show the functionality.


Basic functionality for menu is placed in common-web.

What am I trying to solve here?

A module can have different kind of needs, to access parts of its functionality we need a menu with 1 or more items (even if a module can be without menu, for example common-web may not need one, even if it is also a kind of a module).

  • A menu sholud be able to present itself as a top-menu in a menubar
  • A menu should be able to present itself as a part of another menu (i.e. not on toplevel) but in another menu.
  • Should be able to order children of a node.
  • Support to up to 4 levels of menues (more level will not be displayed)

  • If a menu has no children it should have an action attached (=no expression needed)
  • If a menu has children, it has no action attatched to it.(=no expression needed)
  • Only SubMenus can be placed, not single menues (MenuItem). And they can only be placed in other SubMenus.

“/” is root, putting menues under “/” would put them in top menubar.
Take as an example; you have 3 top menus (Admin, Project, Help). These should all be placed under “/”

Further, say we want to capture this endresult for menues.
  • /
    • admin
      • add user
      • list users
    • project
      • add project
      • list projects
      • issues
        • add issue
        • list issues
    • help
      • about

/admin/add user
/admin/list users
/project/add project
/project/list projects

We have Issues under its own grouping and this should be inserted under project. (The reason behind this is that it may be developed in another module and we want to insert it under project in this application)


When it comes to ordering, I want to speify an order on all levels. The purpose of this is that when adding top menues dynamically I do not know which order they will appear, hence it is usefull to be able to define it on top-level.
Another purpose is, that since it is possible to insert a menu into another, this may disturb the order or we want the inserted menu group to in another position than it gets inserted to.

This solution for this is to sort all items alphabetically and then resort according to supplied ordering (which is allowed to just use the ones it wants to sort in from start)




I will describe the solution by taking my example project on bitbucket as an example.
The example project (on bitbucket) have the following structure:

In this example the only “working” code for a MenuGroup that I will implement is the TODO-functionality, and of course the supporting code to have it modular. As goes for the concept of menus I will add a couple of MenuGroups undermodule-web itself. (Do not be surprised if the code here differs from the one on bitbucket, because there may be improvements done in the real code.). There is also mockup code to add the menues as described above to get more than one menu.

To have a menu for “Todo”, the following code will give me that as a “MenuGroup”

To have it modular and generate modules, this is done by having the menu.xhtml and supporting classes in common-web. The most important are MenuBean (that assemble the menu for the view), MenuAssembler (that assembles a menu for MenuBean from the groups it is provided)

To get menu groups aswell as config of orderings and placement from other modules, a bit of CDI is used.

Since we do not know which MenuGroups will exist when developing common code, we inject any type in an Instance. The view will call getMenus() tha if empty will try to assemble the menu. The placement and ordering should be provided from outside aswell, not hardcoded as in this case.

The order we do this is:

  1. add MenuGroups
  2. add rules
    1. placement and/or ordering (defined in a WebMenuConfig implementation)
  3. call assemble()

The last call will assemble the menu and return a list of the top menus. These menus will after returning be rendered in the view.

The implementation of the WebMenuConfig in this case is defined like this:

This will give a menu that looks like: