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.

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:

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

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

WildFly Swarm on Oracle Application Container Cloud

UPDATED!

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

Über-jar approach

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 WildFly Swarm version of the manifest.json for CloudEE Duke is listed below.

You need to specify the port and host for WildFly Swarm in the startup command. This is done by using the $PORT and $HOSTNAME environment variables.

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

Hollow-jar approach

It is also possible to package the CloudEE Duke application as a hollow-jar using the WildFly Swarm Maven Plugin:

The command configuration in the manifest.json needs to be updated accordingly:

When using the hollow-jar approach, you will need to package both the hollow-jar and the application-war in the zip file together with the manifest.json file.

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

This will produce a file called cloudee-duke-oracle-swarm.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
# 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 14170.0

Running Eclipse MicroProfile on Oracle Cloud

Since I joined the Oracle Developer Champions, I have played around with running MicroProfile applications on Oracle Cloud. Specifically the Oracle Application Container Cloud which allows you to run applications on platforms such as Java™ SE, Java™ EE, Node.js, PHP, Python, Ruby, .NET Core or Go.

MicroProfile is based on Java EE technologies, so the core functionality of the service will run fine on the Java™ EE platform offered. But since WebLogic does not implement the MicroProfile APIs, such as Config, Health Check, Metrics, etc., running on the Java™ SE platform is a much better option.

I have created a simple application called CloudEE Duke to show the differences in configuration required for the various MicroProfile implementations in order to run them on Oracle Application Container Cloud. So far I have covered WildFly Swarm, Payara Micro, Liberty and Kumuluz EE. More may follow. I plan to describe each of them in a series of blog posts following this one. I will update the list below with links to the posts as soon as they are written.

WildFly Swarm on Oracle Application Container Cloud
Payara Micro on Oracle Application Container Cloud
Liberty on Oracle Application Container Cloud
Kumuluz EE on Oracle Application Container Cloud

My plan is to create similar blog series for the other cloud providers as well.

The Relationship Between Jakarta EE, EE4J and Java EE

The Jakarta EE name has been out for about a month, and even if Mike Milinkovich explained the names and concepts pretty well in his blog post And the Name Is…, there still is a bit confusion about how it all relates and I get questions around it whenever the topic comes up. I have tried to sum up some of it here. Hope it helps!

Java EE

Java EE, or Java™ Platform, Enterprise Edition, is the name of the current platform governed by the Java Community Process (JCP). The latest version is Java EE 8, which was released in September 2017.

Jakarta EE

Jakarta EE is the name of the platform governed by the Jakarta EE Working Group. The first version will be Jakarta EE 8 which will be based on the Java EE 8 technologies transferred from Oracle to the Eclipse Foundation.

EE4J

Eclipse Enterprise for Java (EE4J) is the top level project in the Eclipse Foundation for all the projects for creating the standards that will form the base for Jakarta EE. The EE4J Project Management Committee (PMC) is responsible for maintaining the overall vision for the top level project. It will set the standards and requirements for releases and help the projects communicate and cooperate.

Summing Up

Jakarta EE does not replace Java EE! It is the name for the platform evolving with Java EE 8 as a starting point. Java EE 8 will still exist, but there will not be any new versions of the platform.

Jakarta EE does not replace EE4J! It is the name of the platform based on the EE4J projects with Java EE 8 as a starting point.

Flying High with Oracle Cloud

I recently joined the Oracle Developer Champion Program, and one of the benefits is that I get free credits to try out the various services offered by Oracle Cloud. As you see in the picture below, the credits just poured down on me yesterday 🙂

Will this hurt my reputation of being unbiased and vendor neutral when I talk about technologies?

Well, I certainly hope not! In that case, it should probably have gone long time ago since I already get free credits from other vendors, such as AWS, Microsoft Azure, Google, and more. The way I see it, is that it is an excellent opportunity to try out the different solutions and give them a fair comparison.

Stay tuned for more…

 

Promoting EE4J at Jfokus

During the opening keynote of Jfokus, I was invited up on the big stage to be interviewed about the future of Java EE and my role in the Java community.

The video from the Keynote will probably be available shortly, so I will not repeat everything here word-for-word (even if I could…).

The first topic was the Java Community Process Executive Committe and we talked about how the EC guides the evolution of Java™ technology in the Java Community Process.

The next topic was about the Eclipse Enterprise for Java Project Management Committee and how to get involved in participating in the development of Java EE technologies within EE4J. I will encourage everyone that is interested in following what is going on there to join the ee4j-community mailing list.

My vote goes to Jakarta EE !

I could probably write a long post about why my vote goes to Jakarta EE in the vote for new brand name to take over after Java EE, but it feels much more appropriate to refer to David Blevin‘s excellent description of the process in his blog post Java EE to Jakarta EE.

It has been tough on us keeping these discussions secret since we are all working for an open community and want to share everything. But the importance of securing a name that we as a community can trademark through the Eclipse Foundation makes it well worth the efforts.

A particular think I like about the Jakarta EE name is the significance of Apache Software Foundation and Eclipse Foundation working together for the best of the community.

 

Summing up 2017

2017 was an amazing year for me with a lot of speaking engagements at conferences in four different continents!

Per Lilja joined me in leading Javaforum Malmö and we managed to meet out target of four meetups each year. We are always looking for speakers, so don’t hesitate contact us if you want to present at one of our meetups.

Toward the end of the year, the EE4J PMC started up the work. The most pressing issue right now is to find a brand name to replace Java EE. Hopefully, this will be finalized in near future.

Stay tuned…

 

 

MVC 1.0 goes to Eclipse Foundation

Last year when waiting for my flight home from JavaOne, I blogged Possible Ways forward for MVC 1.0. Now, I am sitting here at SFO again writing a follow-up on that article.

As we all now, the JSR was was transferred to me from Oracle to be completed as a standalone JSR. Since then, Christian Kaltepoth has joined me as specification lead. We never did anything about the actual IP, all in full agreement. After all, we are developers and not lawyers and just wanted to get going with the actual work.

It has never been my intention to capitalize on the IP, and I wanted to figure out a way to donate it all back to the community. As those of you who follow the EE4J Community Mailing List probably noticed, I announced the intention to transfer MVC 1.0 to Eclipse Foundation. Read the announcement here:

https://dev.eclipse.org/mhonarc/lists/ee4j-community/msg00106.html

This does not imply any changes to the current specification work, expert group or time plan. There may be some practical changes, such as a new mailing list and moving the repositories under the Eclipse GitHub Organization, but that is way in the future.

So why Eclipse and not Apache?
Well, it makes sense to follow the other Java EE technologies when they are transferred to the EE4J umbrella project in Eclipse Foundation. MVC would be a natural fit there, but the exact details will be handled by the EE4J PMC.

 

 

Welcome to the #javatrain

Usually, you would expect 10 to follow after 9. But in the world of Java™, things move a little faster. Or at least it will be if the proposed release model in Mark Reinhold’s blog post Moving Java Forward Faster is adopted.

The next version of Java™ will then be versioned as 18.3 and be delivered as soon as March 2018. Then we will get version 18.9 in September, and so on.

In my opinion, this is pretty cool. Having a time-based release cycle for Java™ allows for developers to get smaller features delivered faster without the need to wait for the bigger, more time consuming, features to be completed.

I am convinced this proposal will be discussed and commented a lot in the community, so be sure to follow the #javatrain hashtag on Twitter.