Java EE (and Microservice) Quickstart

  1. Create Thin WAR project with: mvn archetype:generate -Dfilter=com.airhacks:javaee7-essentials-archetype. (see: Setting Up Java EE 7 Projects With Maven 3)

    Result: 24 lines of pom.xml. The pom.xml only conatins a single dependency to Java EE 7 API. In real world projects you will only need to add test dependencies like JUnit or Mockito. The file beans.xml (one tag), was created to enable Depenency Injection (DI) everywhere and the annotated class JAXRSConfiguration activates JAX-RS under the resources uri. The generated Thin WAR project is a production ready template for Java EE / Microservices / Thin WARs.
  2. Create a JAX-RS resource, like .e.g.
        public class HelloResource {
            public String message() {
                return "works!";
  3. Perform mvn package and copy the Thin WAR ./target/[NAME].war (~4 kB) into the autodeploy / deploy folder of Java EE 6 / 7 / 8 application server of your choice.
  4. ...or download NetBeans "Java EE Edition", open the project, and click "run".
  5. Open the browser with: http://localhost:8080/[NAME]/resources/message

Use a full profile Java EE application servers (Payara, WildFly, TomEE, WebLogic, Websphere Liberty Profile). The download size varies between 55 MB and 200 MB. The runtime overhead is around 50 MB RAM (see live memory profiling: "The (RAM) Overhead Of Java EE Application Servers").

For mainstream (microservices) projects there is no further tuning, configuration or optimization required.

See you at Java EE Workshops at Munich Airport, Terminal 2 or Virtual Dedicated Workshops / consulting. Is Munich's airport too far? Learn from home:


It is better to use MicroProfile releases with JEE and MicroServices.

The MicroProfile project in a nutshell, is CDI, JAX-RS, and JSR109.
For complete injection solutions I have always found it better to use Guice, especially when it comes round to an automated testing cycle. You can always link your CDI to Guice via the BeanManager.

I do believe using a full JEE profile with MicroServices destroys the MicroServices concept, and reduces your application back to simple SOA purely based on environment architecture.

The idea is a single micro profile EE for a concept of work, spread across multiple nodes with your choice of JCache implementation.
E.G. the Login MicroProfile would consist of at least 4 Wars: Login Email, Login Static, Logout, Login Cloud. These four would be placed in a MicroProfile instance most likely called "LoginProfileEE".
You would spin up a separate EE instance for each application concept, freely up to a usual of 70 profiles for server.

I feel this article highlights a lack of understanding in the separation of SOA and Micro Services.

Posted by Marc on May 12, 2017 at 11:41 PM CEST #

Post a Comment:
  • HTML Syntax: NOT allowed
...the last 150 posts
...the last 10 comments