Eclipse GlassFish Release Plan

UPDATED!

Yesterday, the release plan for Eclipse GlassFish was announced on the EE4J mailing list. For convenience, I have repeated the plan here:

September 18
All code required for GF build contributed.

September 23
Eclipse GlassFish builds.

October 1
Java EE 8 CTS testing. We are able to run CTS tests on Eclipse GlassFish.

October 22 ⚡
CI/CD release pipelines completed.

October 22
Eclipse GlassFish 5.1-RC1 milestone release.

November 5 ⚡
Dependencies updated. All projects are released to OSSRH and have dependencies to Eclipse version of other components.

November 30 ⚡
Release Review completed.

December 14 ⚡
Eclipse GlassFish 5.1 release. All CTS tests are passed.

There is a lot of work to do, so every contribution is appreciated, especially regarding setting up the CI/CD pipelines for all the EE4J projects. Take a look at our status sheet and sign up where you think you can contribute.

Ozark becomes Eclipse Krazo

One of the requirements for Eclipse Projects is that the name is not associated with any trademarks or potential trademarks. When we created the project proposal for Ozark, this turned out to be the case here. The name Ozark is simply used too many places for it to be a valid Eclipse project name.

So, how did we come up with the new name? First of all, we asked for input on the Ozark developer mailing list. We also wrote a small program that generated all permutations of ‘ozark’ to see if something cool came out of that.

public static void main(String[] args) {
    new Permutations().permutations("ozark").stream()
            .forEach(System.out::println);
}

Then we started filtering, discussion and voting until we ended up with Krazo, which turns out to be Ozark spelled backward. We are really excited about the new name and hope you all will join us in spreading the word that the reference implementation of MVC 1.0 that was previously known as Ozark is now called Eclipse Krazo.

Setting sails for Jakarta EE!

The future of Cloud Native Java with Jakarta EE is here! The Jakarta EE website was launched today with lots of information, news and resources, including the new results of the 2018 Developer Survey.I even got my blog posts about the relationship between Jakarta EE, EE4J and Java EE listed in FAQ section. The website even features the new Jakarta EE logo.

I should be honest and say that it wasn’t my first choice when I voted, but when I see it in use with different colors and backgrounds, I must admit that it looks pretty good.

The initial strategic and participating members of the Jakarta EE working group are also listed on the website.

It is pretty awesome to see this list of companies participating and supporting Jakarta EE! And the list is likely to expand as more companies join. The future of Cloud Native Java is Jakarta EE, and the future looks bright. Let’s set the sails and sail towards the future (finally got the logo, I think…).

https://jakarta.ee

 

JavaOne becomes Oracle Code One

My first JavaOne was in 1999 and I have attended almost every one since then, first as an attendee and since 2013 as a speaker. Attending JavaOne has always been one of the highlights of the year. This is where the community meets, announcements are being made and plans laid. I don’t think this will change even if the JavaOne name is replaced by Oracle Code One as was announced yesterday.

https://blogs.oracle.com/developers/javaone-event-expands-with-more-tracks-languages-and-communities-and-new-name

The most important aspect of JavaOne has always been the community and the people. It is kind of sad that the name goes away, but I am confident that we will be able to embrace Oracle Code One with the same community spirit as we did with JavaOne.

Running Eclipse MicroProfile on IBM Cloud

In this post, I am following up on the post series about Running Eclipse MicroProfile applications in Oracle Cloud by showing how to do it in IBM Cloud Foundry, which includes runtimes for Java, Node.js, ASP.NET Core, PHP, Python, Ruby, Swift and Go.

I am using the same simple application called CloudEE Duke as in the previous posts and will show how to deploy it in the Liberty for Java™ runtime. Since the liberty  profile is it is already configured to build using the Liberty Maven Plugin, the only thing you need to do is to activate this profile:

mvn clean package -Pliberty

See the complete pom.xml to see the complete configuration.

Since CloudEE Duke is an Eclipse MicroProfile application, you need to use the packaged server deployment option in order to activate the required features of Liberty. This is done by running the server package  command from the Liberty server directory produced by the Liberty Maven Plugin.

target/liberty/wlp/bin/server package defaultServer --include=usr

The server package  command produces a .zip file that can be pushed to IBM Cloud with the Cloud Foundry CLI as shown here:

cf push cloudee-duke -p target/liberty/wlp/usr/servers/defaultServer/defaultServer.zip

When your application is deployed, you should be able to access the hello endpoint

https://cloudee-duke.eu-gb.mybluemix.net/hello
Duke says Hello!

As ususal, you will also have the health and metrics endpoints provided by the MicroProfile implementation

https://cloudee-duke.eu-gb.mybluemix.net/health
{
outcome: “UP”,
checks: [ ]
}

https://cloudee-duke.eu-gb.mybluemix.net/metrics
# TYPE base:classloader_total_loaded_class_count counter
# HELP base:classloader_total_loaded_class_count Displays the total number of classes that have been loaded since the Java virtual machine has started execution.
base:classloader_total_loaded_class_count 10744
# TYPE base:gc_global_count counter

Run and Debug a WildFly Swarm application from NetBeans

Java EE developers using NetBeans are used to be able to run and debug their thin-war applications in their application server of choice directly from NetBeans. When developing microservices packaged as über-or hollow-jars, you expect the same effortless way of running and debugging. The good news is that you can. In this post, I show step-by-step how to run and debug the WildFly Swarm version of CloudEE Duke in NetBeans.

Run WildFly Swarm application

The easiest way of running CloudEE Duke in NetBeans is to edit the Run project action for the project. Right click on CloudEE Duke, select properties and Actions as shown below.

Configure the Execute Goals to package wildfly-swarm:run, remove all the default properties and your’re all set. Run Project (F6 ) will start the application using the WildFly Swarm Maven Plugin.

Debug WildFly Swarm Appliction

To enable debugging, you follow the same steps as described above, but in this case it is the Debug Project action you select.

Execute Goals is configured the same way as for Run, but in the Set Properties, you need to configure a debug port for WildFly Swarm. This is done by setting the swarm.debug.port property, e.g. to 9000.

Debug Project Ctrl-F5 will start the application in debug mode. Note that the execution will halt while waiting for the debugger to attach. See the screenshot below for how it will look in the log.

Select Debug->Attach Debugger from the menu in NetBeans. Change the value for Port to 9000 (or the value you chose in the previous step) and click OK.

To verify the setup, set a breakpoint at line 16 in the class HelloWorldEndpoint.

Then navigate to http://localhost:8080/hello. The execution will stop at the breakpoint at line 16 in HelloWorldEndpoint.

Running Eclipse MicroProfile on Microsoft Azure

In this post, I am following up on the post series about Running Eclipse MicroProfile applications in Oracle Cloud by showing how to do it in Microsoft Azure Web Apps for Containers.

I am using the same simple application called CloudEE Duke as in the previous posts. The only difference is that I now package the applications as Docker Images. In this example, I show how to use the fabric8 Maven Plugin to produce a docker image for WildFly Swarm.

<plugin>
    <groupId>io.fabric8</groupId>
    <artifactId>docker-maven-plugin</artifactId>
    <version>${version.docker-maven-plugin}</version>
    <configuration>
        <images>
            <image>
                <alias>${project.artifactid}</alias>
                <name>ivargrimstad/${project.artifactId}:swarm</name>
                <build>
                    <maintainer>Ivar Grimstad (ivar.grimstad@gmail.com)</maintainer>
                    <from>jboss/base-jdk:8</from>
                    <assembly>
                        <basedir>/</basedir>
                        <inline>
                            <files>
                                <file>
                                    <source>${project.build.directory}/${project.build.finalName}-hollow-swarm.jar</source>
                                    <outputDirectory>/opt</outputDirectory>
                                </file>
                                <file>
                                    <source>${project.build.directory}/${project.build.finalName}.war</source>
                                    <outputDirectory>/opt</outputDirectory>
                                </file>
                            </files>
                        </inline>                                   
                    </assembly>       
                    <entryPoint>
                        <arg>java</arg>
                        <arg>-Djava.net.preferIPv4Stack=true</arg>
                        <arg>-jar</arg>
                        <arg>/opt/${project.build.finalName}-hollow-swarm.jar</arg>  
                        <arg>/opt/${project.build.finalName}.war</arg>  
                    </entryPoint>
                </build>
            </image>
        </images>
    </configuration>
    <executions>
        <execution>
            <phase>package</phase>
            <goals>
                <goal>build</goal>
            </goals>
        </execution>
    </executions>
</plugin>

The configuration is similar for the other Eclipse MicroProfile implementations. See the full pom.xml for examples. To produce the docker image for the WildFly Swarm implementation of CloudEE Duke, use the following command:

mvn clean package docker:build -Pswarm

Once the image is produced, you need to publish it to a container registry. In my case I simply push it to my public Docker Hub.

In order to deploy the CloudEE Duke application in Microsoft Azure, log in to your Azure Portal and create a new Web App for Containers as shown below.

Since WildFly Swarm runs on port 8080 by default (and I am using all defaults here), the port number for the application needs to be configured. This can be done either in the UI, or using Cloud Shell as shown here:

When your application is deployed, you should be able to access the hello endpoint.

https://cloudee-duke-swarm.azurewebsites.net/hello
Duke says Hello!

https://cloudee-duke-swarm.azurewebsites.net/health
{
outcome: “UP”,
checks: [ ]
}

https://cloudee-duke-swarm.azurewebsites.net/metrics
# HELP base:classloader_total_loaded_class_count Displays the total number of classes that have been loaded since the Java virtual machine has started execution.
# TYPE base:classloader_total_loaded_class_count counter
base:classloader_total_loaded_class_count 13697.0

KumuluzEE on Oracle Application Container Cloud

In this blog post, I will describe how to deploy the CloudEE Duke application packaged in a Kumuluz EE über-jar to Oracle Application Container Cloud.

The deployment artifact required for deployment in Oracle Application Container Cloud is a ZIP archive containing the application über-jar and a manifest file (manifest.json). The Kumuluz EE version of the manifest.json for CloudEE Duke is listed below.

{
    "runtime": {
        "majorVersion": "8"
    },
    "command": "java -Dkumuluzee.server.http.port=$PORT -jar cloudee-duke.jar",
    "release": {
        "version": "1.0",
        "build": "1",
        "commit": "123"
    },
    "notes": "Dukes says hello from Kumuluz EE"
}

You need to specify the port for Kumuluz EE in the startup command. This is done by using the $PORT environment variable.

The über-jar is produced by using the Kumuluz Maven Plugin:

<plugin>
    <groupId>com.kumuluz.ee</groupId>
    <artifactId>kumuluzee-maven-plugin</artifactId>
    <version>${version.kumuluz}</version>
    <executions>
        <execution>
            <id>package</id>
            <goals>
                <goal>repackage</goal>
            </goals>
        </execution>
    </executions>
</plugin>

See the complete pom.xml for an example on how to produce the deployable ZIP archive with the maven command:

mvn clean package assembly:single -Pkumuluz

This will produce a file called cloudee-duke-oracle-kumuluz.zip  in the target folder. This is the ZIP archive you will deploy to Oracle Application Container Cloud as shown in the screenshot below.

When your application is deployed, you should be able to access the hello endpoint

https://<dependsonyouraccount>.oraclecloud.com/hello
Duke says Hello!

You will also have the health and metrics endpoints provided by the MicroProfile implementation

https://<dependsonyouraccount>.oraclecloud.com/health
{
outcome: “UP”,
checks: [ ]
}

https://<dependsonyouraccount>.oraclecloud.com/metrics
# TYPE base:gc_ps_mark_sweep_count counter
# HELP base:gc_ps_mark_sweep_count Displays the total number of collections that have occurred. This attribute lists -1 if the collection count is undefined for this collector.
base:gc_ps_mark_sweep_count{serviceVersion=”1.0.0″,environment=”dev”,instanceId=”110cd814-3d12-4198-80eb-694196f58993″,serviceName=”UNKNOWN”} 2
# TYPE base:classloader_total_loaded_class_count counter

Liberty on Oracle Application Container Cloud

In this blog post, I will describe how to deploy the CloudEE Duke application packaged in a Liberty über-jar to Oracle Application Container Cloud.

The deployment artifact required for deployment in Oracle Application Container Cloud is a ZIP archive containing the application über-jar and a manifest file (manifest.json). The Liberty version of the manifest.json for CloudEE Duke is listed below.

{
    "runtime": {
        "majorVersion": "8"
    },
    "command": "java -jar cloudee-duke.jar",
    "release": {
        "version": "1.0",
        "build": "1",
        "commit": "123"
    },
    "notes": "Dukes says hello from Liberty"
}

You need to specify the port for Liberty to use. This cam be done by configuring it in the server.xml using the environment variable ${env.PORT}  as shown here:

<server description="Sample Liberty server">
    <featureManager>
        <feature>microprofile-1.2</feature>
    </featureManager>

    <httpEndpoint  httpPort="${env.PORT}" 
                   httpsPort="9443"
                   id="defaultHttpEndpoint" 
                   host="*" />

    <quickStartSecurity userName="duke" userPassword="duke"/>

    <keyStore id="defaultKeyStore" password="Liberty"/>
</server>

The über-jar is produced by using a combination of the Maven Resources Plugin as well as the Liberty Maven Plugin:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-resources-plugin</artifactId>
    <version>3.0.2</version>
    <executions>
        <execution>
            <id>copy-app</id>
            <phase>package</phase>
            <goals>
                <goal>copy-resources</goal>
            </goals>
            <configuration>
                <outputDirectory>${project.build.directory}/liberty/wlp/usr/servers/defaultServer/dropins</outputDirectory>
                <resources>
                    <resource>
                        <directory>${project.build.directory}</directory>
                        <includes>
                            <include>${project.build.finalName}.war</include>
                        </includes>
                    </resource>
                </resources>
            </configuration>
        </execution>
    </executions>
</plugin>
<plugin>
    <groupId>net.wasdev.wlp.maven.plugins</groupId>
    <artifactId>liberty-maven-plugin</artifactId>
    <version>2.2</version>
    <extensions>true</extensions>
    <configuration>
        <install>
            <type>webProfile7</type>
            <version>2018.+</version>
        </install>
        <configFile>${basedir}/src/main/liberty/config/server.xml</configFile>
        <serverEnv>${basedir}/src/main/liberty/config/server.env</serverEnv>
        <jvmOptionsFile>${basedir}/src/main/liberty/config/jvm.options</jvmOptionsFile>
        <packageFile>${project.build.directory}/${project.build.finalName}.jar</packageFile>
        <include>runnable</include>
    </configuration>     
    <executions>
        <execution>
            <id>install-liberty</id>
            <phase>prepare-package</phase>
            <goals>
                <goal>install-server</goal>
            </goals>
        </execution>
        <execution>
            <id>package-app</id>
            <phase>package</phase>
            <goals>
                <goal>package-server</goal>
            </goals>
        </execution>
    </executions>               
</plugin>

See the complete pom.xml for an example on how to produce the deployable ZIP archive with the maven command:

mvn clean package assembly:single -Pliberty

This will produce a file called cloudee-duke-oracle-liberty.zip  in the target folder. This is the ZIP archive you will deploy to Oracle Application Container Cloud as shown in the screenshot below.

When your application is deployed, you should be able to access the hello endpoint

https://<dependsonyouraccount>.oraclecloud.com/hello
Duke says Hello!

You will also have the health and metrics endpoints provided by the MicroProfile implementation

https://<dependsonyouraccount>.oraclecloud.com/health
{
outcome: “UP”,
checks: [ ]
}

https://<dependsonyouraccount>.oraclecloud.com/metrics
# TYPE base:classloader_total_loaded_class_count counter
# HELP base:classloader_total_loaded_class_count Displays the total number of classes that have been loaded since the Java virtual machine has started execution.
base:classloader_total_loaded_class_count 9430
# TYPE base:cpu_system_load_average gauge

 

Payara Micro on Oracle Application Container Cloud

In this blog post, I will describe how to deploy the CloudEE Duke application packaged in a Payara Micro über-jar to Oracle Application Container Cloud.

The deployment artifact required for deployment in Oracle Application Container Cloud is a ZIP archive containing the application über-jar and a manifest file (manifest.json). The Payara Micro version of the manifest.json for CloudEE Duke is listed below.

{
    "runtime": {
        "majorVersion": "8"
    },
    "command": "java -jar cloudee-duke-microbundle.jar --port $PORT",
    "release": {
        "version": "1.0",
        "build": "1",
        "commit": "123"
    },
    "notes": "Dukes says hello from Payara"
}

You need to specify the port for Payara Micro in the startup command. This is done by using the $PORT environment variable.

The über-jar is produced by using the Payara Micro Maven Plugin:

<plugin>
    <groupId>fish.payara.maven.plugins</groupId>
    <artifactId>payara-micro-maven-plugin</artifactId>
    <version>1.0.1-SNAPSHOT</version>
    <executions>
        <execution>
            <goals>
                <goal>bundle</goal>
            </goals>
        </execution>
    </executions>
    <configuration>
        <payaraVersion>${version.payara.micro}</payaraVersion>
        <autoDeployEmptyContextRoot>true</autoDeployEmptyContextRoot>
    </configuration>
</plugin>                

See the complete pom.xml for an example on how to produce the deployable ZIP archive with the maven command:

mvn clean package payara-micro:bundle assembly:single -Ppayara

This will produce a file called cloudee-duke-oracle-payara.zip  in the target folder. This is the ZIP archive you will deploy to Oracle Application Container Cloud as shown in the screenshot below.

When your application is deployed, you should be able to access the hello endpoint

https://<dependsonyouraccount>.oraclecloud.com/hello
Duke says Hello!

You will also have the health and metrics endpoints provided by the MicroProfile implementation

https://<dependsonyouraccount>.oraclecloud.com/health
{
outcome: “UP”,
checks: [ ]
}

https://<dependsonyouraccount>.oraclecloud.com/metrics
# TYPE vendor:system_cpu_load gauge
# HELP vendor:system_cpu_load Display the “recent cpu usage” for the whole system. This value is a double in the [0.0,1.0] interval. A value of 0.0 means that all CPUs were idle during the recent period of time observed, while a value of 1.0 means that all CPUs were actively running 100% of the time during the recent period being observed. All values betweens 0.0 and 1.0 are possible depending of the activities going on in the system. If the system recent cpu usage is not available, the method returns a negative value.
vendor:system_cpu_load 0.005405405405405406