Application Container Cloud (ACCS) supports Java EE

This is my personal entry for the ODC appreciation day that was initiated once more by Tim Hall.


Oracle’s Application Container Cloud Service (ACCS) is a cloud native, container based runtime for applications and microservices implemented with Java, Node.js, Ruby, Python and PHP. It’s simplicity makes it most attractive. All you need to do is bundle and upload your code, and add a .json file to let ACCS know how to start your application.

Since a couple of days ACCS is now supporting Java EE as well – this is great news! Note, that there is still Java Cloud Service JCS, which gives you a fully fledged WebLogic domain. However, JCS is more complex to set up and to deploy to, so ACCS is a good option for those that only want to deploy and run a Java EE module.

ACCS with Java EE

The provisioning, as shown in the following screenshot, is PaaS-worthy, easy enough as with any other ACCS deployment type.

ACCS: Application Container Cloud Service with Java EE


ACCS with Java EE, Some Details

Here are some more facts as they are currently known:

  • You can simply upload a .war file. The .json manifest that is required to tell ACCS how to start a Java application is not mandatory for Java EE since the module is running in WebLogic.
  • The current versions used in ACCS when deploying a Java EE module are: WebLogic (which supports Java EE 7), running on Java 8.
  • ACCS with Java EE currently does not support clustering.
  • ACCS does not let you access the WebLogic admin console. This is fine. It’s PaaS!
  • ACCS with Java EE can make use of Java Flight Recorder. In continuous mode, all profiling and event data is captured. If Java Flight Recorder is not in continuous more, then 60 seconds of data is captured. You can download the files and use Java Mission Control to analyze the recordings.
  • The URL syntax to invoke a deployed web module is as follows:


  • Typically the URL to call a deployed application is shown in the ACCS service console. Note, that the DocRoot -even if required to call the deployment – is not shown.
  • A Java EE deployment is running across 2 instances as default which requires a load balancer to be provisioned by ACCS. Currently OTD is used.
  • If you feel brave enough, just give it a go and deploy the sample app.
  • If you are lost working with ACCS by yourself, then follow this tutorial, explaining how to deploy a Java EE module to ACCS. The instruction mentioned in the tutorial worked OOTB for me.

Possible Improvements

As you know, I usually write about features and showstoppers. A few minor things that should be improved in my opinion:

  • A few minor details are not visible in the console. E.g. the used Java version is not fully displayed.
  • Not sure if it is documented somewhere, but I would love to read more precisely about current restrictions for Java EE in ACCS. Actually I dropped the hint for some colleagues at Oracle to blog about it.

Is it Java EE or EE4J now?

You may have heard that Java EE went to the Eclipse foundation. The new name will be EE4J. Do you have to change all your slide decks and articles? Actually no. For some more details have a look at this article.


Many thanks to the team of Abhishek and Sriram for helping to clarify some questions and providing quick and precise feedback!

Purge / Empty / Drain a Kafka Topic in Oracle Event Hub Service (or any other Kafka broker)

I did not find this solution myself, but I am also not sure where I discovered it. Just a note to myself.

Actually it is becomes useful once you enabled client access to your Oracle Event Hub Cloud Service, since the web based console itself does not implement every functionality that is provided by Kafka.

# PURGE topic
# we drain the topic by expiring the messages

./kafka-topics --zookeeper ZKADR --alter --topic topic_name --config
./kafka-topics --zookeeper ZKADR --alter --topic topic_name --delete-config

On another thought: what if the Event Hub Console implemented draining a topic in the web console? And maybe it could also display the number of messages stored in topic.

Access Oracle Event Hub Kafka from External Kafka Client or Tool

Access Oracle Event Hub from external Tool or Command-Line Client

Oracle Event Hub provides a managed Kafka PaaS solution. To access it from an on-premises client you have to make sure to enable the ports to Event Hub Zookeeper and the Kafka broker.

Access to Kafka Broker

First lets enable access to Kafka broker. To do so, check the OPC Event Hub service for the connect string.

Create Event Hub Broker Access Rule

Then create a new access rule. Warning: In general you should not allow public access to access your Event Hub service! This is just for demo purposes to make the tool work. In case of doubt create a rule with your own IP address and talk your friendly security officer first of all.

The creation of the rule might take a few seconds:

Create Zookeeper Access Rule

Once the rule for the Kafka broker is created, we need to create a rule for Zookeeper which is using port 2181:

Explore Kafka Tool (or other)

Now lets start our Kafka tool (for demonstration purpose) only, configure the connection details for the Zookeeper IP and port, and then try to connect to Oracle Event Hub Service:

Voila, it is working 🙂 You can explore your topics or even create new ones. Note that  Oracle Event Hub uses a special naming convention for topics.

Cloud, Microservices and Container Workshop in South Africa!

Lot’s of people are talking about these topics nowadays. Heaps of slides and samples are available for download, lots of presentations can simply be streamed from youtube.

In Johannesburg we were working with these solutions hands-on: I delivered a 3 day Cloud, Microservices and Containers workshop on behalf of Oracle.

Find attached some impressions from the smart and fun group of devs and architects I was working with.



OSB 12c ( More Maven Issues and Solutions

Existing Bugs and Issues with Maven and OSB and How to Fix Them

It is a well known fact that Maven in OSB came with glitches that required manual fixes as described in Robert Patrick’s blog posting and in the Oracle support notes Doc ID 2186338.1. However, this article is centered around the latest OSB, its particular Maven issues and how to fix them. Same as version OSB also suffers from various maven glitches, however in a more subtle way.

[Note, that I usually don’t post references to MOS, since not everybody has access to it. Anyway, if you cannot access to Doc ID 2186338.1 don’t worry. It basically describes what Robert writes about in his blog. In addition it recommends actually not to fix it manually, but instead wait for a patch. I actually I agree. Also note that as of OSB this issue is not marked as fixed although the behavior of the newest version is different.]

The current situation with OSB and Maven is “interesting”, to put it mildly:

  • mvn with OSB and the maven push plugin only will not work out of the box. This means the official documentation won’t help you in this case. The good news – despite the fact that mvn with OSB is not working correctly – is that it is rather easy to fix manually (see below, Fix 1: Maven with OSB and the mvn push plugin).
  • Also mvn with OSB and will not work (as of Jan 7, 2017). Since the required .pom and .jar files are pulled over from and several of them are missing it is obviously not easy to fix it yourself.
  • Here comes the crazy part (well, crazy on an IT scale): if you configure both, i.e. first use the OSB Maven plugin to push from an OSB ORACLE_HOME into the .m2 repository, and then in addition configure the repository, then it is done twice. Yet then also both issues cancel each other out.


Here are the fixes, as promised

Fix 1:Maven with OSB and the mvn push plugin

a) easy manual fix, updating two lines in two files:

After usign the push plugin, in .m2 Repository, e.g. D:\Users\frank\.m2\repository\com\oracle\servicebus\sbar-system-common\12.2.1-2-0 change the file sbar-system-common- as follows:



change the version tag to <version>12.2.1-2-0</version>

also for the file sbar-project-common- in the directory
.m2\repository\com\oracle\servicebus\sbar-project-common\12.2.1-2-0 change the version number the same way.

b.) Install patch 22392646

This is the second, alternative option to fix the issue. Install patch 22392646 from My Oracle Support. After a lengthy and tiring discussion I had with support it is now also applicable to OSB – voilà! Depending on your provisioning approach this might be the easier fix, but actually you could just copy over the files (or even run sed on those two files).


Issue 2: Maven with OSB and the

There is no known fix at the moment, is missing a whole lot of files (again) and also some of those delivered are wrong again. Bug 23698828 describes a very similar issue, yet reports it as fixed for Oracle support knows about it, so let’s hope it will be fixed soon in I will keep you posted, promised.

Update: After the first round with support their “solution” did not work. The issue is still not fixed. If you think about it for a second, how hard can it be to push a patched .m2 repo to Stay tuned 🙂

To conclude

You are lucky if you simply retyped all the instructions available and configured both ways to use Maven with OSB (although I somehow guess you would have not read this article then).

As soon as you follow a clear path and either go for the push plugin on a machine with OSB installed, or on a build server without an OSB installation, you will run into issues. It is obvious that Oracle would do good with automatically testing this functionality for future releases. Not being able to browse the repo makes it more difficult for customers to debug those issues, so it might be a good idea to use a local proxy / cache.

Let me know your feedback!