Ironic programmer

Sunday, October 11, 2015

Playing with Hazelcast on Payara

I have been reading a bit about Hazelcast, came up to chapter 5 in http://hazelcast.org/mastering-hazelcast/, 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.

#%RAML 0.8
title: Blog post service 
baseUri: http://localhost:8080/hazelblog/api
version: v1
/posts:   
   get:
      description: Gets a list of "Posts"
      queryParameters:
         author: 
            displayName: Author
            type: string
            description: Name of the author
            example: @ironic
      responses:
         200:
            body: 
               application/json:
                  example: |
                     [
                        {"author":"@ironic","content":"Nothing interesting","id":1,"title":"First post"},
                        {"author":"@ironic","content":"Again nothing interesting","id":2,"title":"Second post"}
                    ]
   post:
      description: Creates a post
      body: 
         application/json:
            example: |
               {"author":"@ironic","content":"Nothing interesting", "title":"Test post"}
   /{id}:
      get:
         description: View of a post
         responses:
            200:
               body: 
                  application/json:
                     example: |
                        {"author":"@ironic","content":"Nothing interesting","id":1,"title":"First post"}                     
      delete:  
         description: Deletes a post

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: https://github.com/payara/Payara/wiki/Hazelcast-%28Payara-4.1.153%29 but more with ideas as written here: http://blog.modernjava.info/2014/10/using-hazelcast-as-jcache-provider-with.html.

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.

package se.ironic.hazelblog;

import com.hazelcast.config.Config;
import com.hazelcast.config.MapStoreConfig;
import com.hazelcast.core.HazelcastInstance;
import javax.enterprise.context.ApplicationScoped;
import javax.enterprise.inject.Disposes;
import javax.enterprise.inject.Produces;
import javax.inject.Singleton;

@ApplicationScoped
public class HazelcastProvider {

@Produces
    @Singleton
    @Hazelcast
    public HazelcastInstance create() {
        System.out.println("Creating Hazelcast Instance");
        ClassLoader classLoader = Thread.currentThread().getContextClassLoader();
        Config config = new Config();

MapStoreConfig storeConfig = new MapStoreConfig();
        storeConfig.setEnabled(true);
        storeConfig.setClassName("se.ironic.hazelblog.PostLoader");
        config.getMapConfig("posts").setMapStoreConfig(storeConfig);
        HazelcastInstance newInst = com.hazelcast.core.Hazelcast.newHazelcastInstance(config);

return newInst;
    }

public void close(@Disposes @Hazelcast HazelcastInstance instance) {
        System.out.println("Shutting down Hazelcast....");
        instance.shutdown();
    }
}

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.

REST-resource

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:

package se.ironic.hazelblog;

import com.hazelcast.core.MapLoader;
import java.util.Collection;
import java.util.Collections;
import java.util.HashMap;
import java.util.List;
import java.util.Map;
import javax.enterprise.inject.spi.CDI;

public class PostLoader implements MapLoader<Long, Post> {

@Override
    public Post load(Long id) {
        PostRepository repo = CDI.current().select(PostRepository.class).get();
        Post post = repo.find(id);
        return post;
    }

@Override
    public Map<Long, Post> loadAll(Collection<long> ids) {
        Map<Long, Post> all = new HashMap<>();
        PostRepository repo = CDI.current().select(PostRepository.class).get();
        Map<String, Object> params = new HashMap<>();
        params.put("ids", ids);
        List<post> posts = repo.findByQuery("SELECT p FROM Post p WHERE p.id in :ids", params);
        for (Post post : posts) {
            all.put(post.getId(), post);
            System.out.println("Post: " + post);
        }
        return all;
    }

@Override
    public Iterable<long> loadAllKeys() {
        PostRepository repo = CDI.current().select(PostRepository.class).get();
        List<long> ids = repo.findByQuery("SELECT p.id FROM Post p", Collections.EMPTY_MAP);
        return ids;
    }

}

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: [https://bitbucket.org/pejomstd/hazelblog]

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

task-web

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.

package se.ironic.task.boundary;

import java.net.URI;
import java.util.List;
import java.util.Optional;
import javax.ws.rs.Consumes;
import javax.ws.rs.DELETE;
import javax.ws.rs.GET;
import javax.ws.rs.POST;
import javax.ws.rs.PUT;
import javax.ws.rs.Path;
import javax.ws.rs.PathParam;
import javax.ws.rs.Produces;
import javax.ws.rs.core.MediaType;
import javax.ws.rs.core.Response;
import se.ironic.task.model.Task;

/**
 *
 * @author Ironic
 */
@Path("tasks")
public class TaskResource {
    @GET
    @Produces(MediaType.APPLICATION_JSON)
    public List<task> getAll() {
        return TaskCache.INST.getTasks();
    }
    
    @POST
    @Consumes(MediaType.APPLICATION_JSON)
    public Response create(Task task) {
        TaskCache.INST.putTask(task);
        URI id = URI.create("tasks/" + task.getId());
        Response resp = Response.created(id).build();
        return resp;
    }

@GET
    @Produces(MediaType.APPLICATION_JSON)
    @Path("{id}")
    public Response getTask(@PathParam("id") String id) {
        Optional<task> task = TaskCache.INST.getTask(id);
        Response resp = null;
        if (task.isPresent()) {
            resp = Response.ok(task.get()).build();
        } else {
            resp = Response.noContent().build();
        }
        return resp;
    }
    
    @PUT @Consumes(MediaType.APPLICATION_JSON)
    @Path("{id}")
    public Response update(Task task) {
        // Just replace the one there
        TaskCache.INST.putTask(task);
        return Response.ok().build();
    }
    
    @DELETE
    @Path("{id}")
    public Response delete(@PathParam("id") String id) {
        System.out.println("Deleting task: " + id);
        TaskCache.INST.removeTask(id);
        return Response.ok().build();
    }
}

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.

gf-runner

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:

package se.ironic.gfrunner;

import java.io.File;
import org.glassfish.embeddable.BootstrapProperties;
import org.glassfish.embeddable.GlassFish;
import org.glassfish.embeddable.GlassFishException;
import org.glassfish.embeddable.GlassFishProperties;
import org.glassfish.embeddable.GlassFishRuntime;

public class EmbeddedGFRunner {

public static void main(String[] args) throws GlassFishException {
        if(args.length != 3) {
            System.out.println("Usage > EmbeddedGFRunner \"port\" \"deployable.war\" \"contextRoot\"");
            System.exit(1);
        }
        int port = Integer.parseInt(args[0]);
        BootstrapProperties bootstrap = new BootstrapProperties();
        GlassFishRuntime runtime = GlassFishRuntime.bootstrap();
        GlassFishProperties glassfishProperties = new GlassFishProperties();
        glassfishProperties.setPort("http-listener", port);
        GlassFish glassfish = runtime.newGlassFish(glassfishProperties);
        glassfish.start();
        glassfish.getDeployer().deploy(new File(args[1]), "--contextroot", args[2]);
    }
}

pack-dist

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

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:

package model;

import java.util.Date;
import java.util.UUID;
import javax.xml.bind.annotation.XmlAccessType;
import javax.xml.bind.annotation.XmlAccessorType;
import javax.xml.bind.annotation.XmlRootElement;

@XmlRootElement
@XmlAccessorType(XmlAccessType.FIELD)
public class Task {
    private String id;
    private String title;
    private String description;
    private Date dueDate;

public Task() {
    }
    
    public static Task of(String title, String description, Date dueDate) {
        UUID randomUUID = UUID.randomUUID();
        return new Task(randomUUID.toString(), title, description, dueDate);
    }

private Task(String id, String title, String description, Date dueDate) {
        this.id = id;
        this.title = title;
        this.description = description;
        this.dueDate = dueDate;
    }

// getters/setters

@Override
    public String toString() {
        return "Task{" + "id=" + id + ", title=" + title + ", description=" + description + ", dueDate=" + dueDate + '}';
    }
    
    
    
}

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.

package app;

import java.net.URI;
import java.util.Date;
import javax.ws.rs.client.Client;
import javax.ws.rs.client.ClientBuilder;
import javax.ws.rs.client.Entity;
import javax.ws.rs.client.WebTarget;
import javax.ws.rs.core.MediaType;
import javax.ws.rs.core.Response;
import model.Task;

public class JerseyClient {

public static void main(String[] args) {
        Client client = ClientBuilder.newClient();
        WebTarget postTarget = client.target("http://localhost:2001").path("api").path("tasks");
        Response postResponse = postTarget.request(MediaType.APPLICATION_JSON)
                .post(Entity.json(Task.of("Testclient", "Using test client to create", new Date())));
        
        System.out.println(postResponse.getStatus());
        URI location = postResponse.getLocation();
        
        System.out.println(location);
        
        WebTarget getTarget = client.target(location);
        Response getResponse = getTarget.request(MediaType.APPLICATION_JSON).get();
        
        System.out.println(getResponse.getStatus());
        System.out.println(getResponse.readEntity(Task.class));
    }
}

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:

public static void main(String[] args) {
    Client client = ClientBuilder.newClient();
    List<uri> locations = new ArrayList<>();
        
    WebTarget target = client.target("http://localhost:2001").path("api").path("tasks");
        
    Response postResponse = target.request(MediaType.APPLICATION_JSON)
            .post(Entity.json(Task.of("Testclient1", "Using test client to create", new Date())));
    locations.add(postResponse.getLocation());
        
    postResponse = target.request(MediaType.APPLICATION_JSON)
            .post(Entity.json(Task.of("Testclient2", "Using test client to create", new Date())));
    locations.add(postResponse.getLocation());
        
    postResponse = target.request(MediaType.APPLICATION_JSON)
            .post(Entity.json(Task.of("Testclient3", "Using test client to create", new Date())));
    locations.add(postResponse.getLocation());
        
        
    // Get first one
    WebTarget getTarget = client.target(locations.get(0));
    Response getResponse = getTarget.request(MediaType.APPLICATION_JSON).get();
    
    System.out.println(getResponse.getStatus());
    System.out.println(getResponse.readEntity(Task.class));
       
    // Change second one
    getTarget = client.target(locations.get(1));
    getResponse = getTarget.request(MediaType.APPLICATION_JSON).get();
    Task aTask = getResponse.readEntity(Task.class);
    aTask.setTitle("This title is changed");
    client.target(locations.get(1)).request(MediaType.APPLICATION_JSON).put(Entity.json(aTask));
        
    // Delete thirs one
    client.target(locations.get(2)).request().delete();
        
    WebTarget allTarget = client.target("http://localhost:2001").path("api").path("tasks");
        
    GenericType<List<task>> genericType = new GenericType<List<task>>() {};
        
    List<task> all = allTarget.request(MediaType.APPLICATION_JSON).get(genericType);
    for (Task task : all) {
        System.out.println(task);
    }
 }

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

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.

package app;

import java.util.logging.Level;
import java.util.logging.Logger;
import org.eclipse.jetty.server.Server;
import org.eclipse.jetty.servlet.ServletContextHandler;
import org.eclipse.jetty.servlet.ServletHolder;

public class JerseyServer {
    public static void main(String[] args) {
        int port = 2001;
        if(args.length == 1) {
            port = Integer.parseInt(args[0]);
        }
        Server server = new Server(port);
        
        ServletHolder servletHolder = new ServletHolder(org.glassfish.jersey.servlet.ServletContainer.class);
        servletHolder.setInitParameter("com.sun.jersey.config.property.resourceConfigClass", "com.sun.jersey.api.core.PackagesResourceConfig");
        servletHolder.setInitParameter("jersey.config.server.provider.packages", "rest");//Set the package where the services reside
        servletHolder.setInitParameter("com.sun.jersey.api.json.POJOMappingFeature", "true");
        ServletContextHandler contextHandler = new ServletContextHandler(ServletContextHandler.SESSIONS);
        server.setHandler(contextHandler);
        contextHandler.addServlet(servletHolder, "/api/*");
        
        try {
            server.start();
            server.join();
        } catch (Exception ex) {
            Logger.getLogger(JerseyServer.class.getName()).log(Level.SEVERE, null, ex);
            System.exit(1);
        }
    }
}

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

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.