JBossForge Bootstrap via Asciinema

Just a short one today. Last week i stumbled upon Asciinema and when i saw it i instantly had to think of JBossForge. So here is my little example (it seems that i am not the best typer ;))

• Full JavaEE 7 CRUD project with Maven as build system
• With one JPA entity (validation inclusive) mapped to H2 database
• JAX-RS interface via JSON
• JSF UI

The generated project can be found on my GitHub account.

Nginx As Loadbalancer

In order to get NGINX working as load balancer the following steps are needed on a Mac:

1. Install NGINX via brew

brew install nginx

2. Create/Edit nginx.conf (default: /usr/local/etc/nginx/)

events {
    worker_connections  1024;
}


http {
  upstream customers {
    server localhost:8080 weight=3;
    server localhost:8081;
  }

  server {
    listen 80;
    location / {
      proxy_pass http://customers;
    }
  }
}

3. Update /etc/hosts (optional)

127.0.0.1       localhost,customers

Some Notes

nginx

nginx -s stop

A very interesting read: http://tenzer.dk/nginx-with-dynamic-upstreams/

Kumuluzee Maven Plugin

A couple of days ago I played a little bit with KumuluzEE, one of the hot Duke's Choice Award 2015 winners, to get a feeling what it is and what it does. So i took one of my JavaEE EJB sample projects and worked myself through the tutorial and got it running within 30 minutes. From my point of view (whatever this means ;)) there are no big differences to Wildfly Swarm considering basic Java EE development. Sure the fat-jar of the latter is almost twice as big but i think that is related to more configuration possibilities (which i do not know so far, probably something with subsystems).

But there is a difference which i find a bit odd and had cost me about 15 minutes because i overlook it in the tutorial ;(. In fact the directory structure differs to standard Java EE/Maven conventions in that way that the webapp folder has to be located under scr/main/resources. The reason for that is probably related to the way com.kumuluz.ee.EeApplication class is started.

java -cp target/classes:target/dependency/* com.kumuluz.ee.EeApplication

With the current state Maven copies everything under src/main/resources also into target/classes so that it is automatically in the right directory.

But isn't that a little bit strange? Sure the migration path is rather short. Just copy webapp to another folder and it works but what if you want to switch easily back to Java EE containers or like me want to have a profile for KumuluzEE or Wildfly-Swarm or whatever? (Happy copying ;))

For me it should be encapsulated because a runtime structure should not have influence of the development structure and i think it is always good to hide internals considering extensibility.

The following part introduces two approaches to let webapp at right place (src/main/webapp):

1. Maven Resource Plugin

Just simply copying via Maven.

 1 <plugin>
 2     <artifactId>maven-resources-plugin</artifactId>
 3     <version>2.7</version>
 4     <executions>
 5         <execution>
 6             <id>copy-resources</id>
 7             <phase>package</phase>
 8             <goals>
 9                 <goal>copy-resources</goal>
10             </goals>
11             <configuration>
12                 <outputDirectory>${basedir}/target/classes/webapp</outputDirectory>
13                 <resources>
14                     <resource>
15                         <directory>src/main/webapp</directory>
16                         <filtering>true</filtering>
17                     </resource>
18                 </resources>
19             </configuration>
20         </execution>
21     </executions>
22 </plugin>

2. KumuluzEE Maven Plugin

With the snippet above and the default maven-dependency-plugin your pom.xml has about 40 lines of xml more and i think that this is not going to increase readability or understandability. On top of that you have to remember internals of KumuluzEE which can be change in the future. So perfect time to encapsulate all this (and maybe more in the future) in a Maven plugin.

I am no Maven expert so please be gentle with the following KumuluzEE Maven Plugin. The usage is rather standard.

 1 <plugin>
 2     <groupId>de.bischinger</groupId>
 3     <artifactId>kumuluzee-maven-plugin</artifactId>
 4     <version>1.0</version>
 5     <executions>
 6         <execution>
 7             <id>copy-resources</id>
 8             <phase>package</phase>
 9             <goals>
10                 <goal>copy-dependencies</goal>
11             </goals>
12         </execution>
13     </executions>
14 </plugin>