Using VSCode Dev Container for Java server side development at the Oracle embedded JVM
This post is about using VSCode Dev Container extension for a controlled and secure development of Java at the Oracle Internal JVM (Java running inside your Oracle RDBMS, AKA OJVM), also it works for regular client side Java <-> RDBMs applications.
Why?
The Visual Studio Code Remote — Containers extension lets you use a Docker container as a full-featured development environment. It allows you to open any folder inside (or mounted into) a container and take advantage of Visual Studio Code’s full feature set. A devcontainer.json file in your project tells VS Code how to access (or create) a development container with a well-defined tool and runtime stack. This container can be used to run an application or to sandbox tools, libraries, or runtimes needed for working with a codebase.
If you are involved in a big Java server side development which includes a lot of Java code like Scotas Native Solr integration it will be a great time-saving machine.
Our dev environment example have two big dependencies:
- Oracle 18c/19c RDBMS (EE or XE)
- Apache Solr
Oracle 18c/19c RDBMS is the target system for which the Scotas OLS will be compiled and tested and Apache Lucene/Solr are the components to be integrated as search engine running inside the RDBMS as a new built-in domain index.
This article is continuation of my previous one post Using Docker for Java server-side development at the Oracle embedded JVM which depicts following container layers:
only green layer is our code to dev/test/build which is pulled from GitHub automatically, all the others are immutable layers which are part of the development environment, these are:
- Oracle Linux 7 — slim from Docker Hub repo (as part of Oracle 19c build process)
- 19c RDBMS Docker image build using Oracle’s official script
- Extra tool/libraries required for compiling such as Apache Ant, JUnit and IVY
- Extra packages for VSCode extensions such as docker-engine and aspnetcore-runtime-3.1
- Internal libraries such as ODCI (wrapped classes for Data Cartridge package)
- Apache Lucene/Solr from official SVN repository (patched)
a complete Dockerfile is available at GitHub.
Dev Container files explained
Our project has a few files:
most important are:
- devcontainer.json, defines our Development environment in VSCode extension format
- Dockerfile, steps to build above Docker image (our image development space)
- docker-compose.yml, our docker compose stack, Oracle 18c XE plus above developer image (two running container)
Before opening this project is necessary to have already built an Oracle 18c XE image, if you want to work with a 19c EE image a similar project can be implemented using a modified Dockerfile. Check the existence of the image by listing your local image repository (you can avoid that using images located in a company private registry):
oracle@pocho:~/github/docker-images$ docker image ls|grep xe
oracle/database 18.4.0-xe 6acb249d39ba 4 months ago 5.87GBthen checkout docker-images repo to begin started with VSCode Dev container functionality
oracle@pocho:~/github$ git clone https://github.com/scotas/docker-images.git
Cloning into 'docker-images'...
remote: Enumerating objects: 112, done.
remote: Counting objects: 100% (112/112), done.
remote: Compressing objects: 100% (81/81), done.
remote: Total 304 (delta 55), reused 84 (delta 31), pack-reused 192
Receiving objects: 100% (304/304), 51.62 KiB | 367.00 KiB/s, done.
Resolving deltas: 100% (162/162), done.
oracle@pocho:~/github$ cd docker-images/devcontainer-ols
oracle@pocho:~/github$ code .VSCode will ask you
If you choose Reopen in Container a build process will start but, before doing that please take a look at some customization in docker-compose.yml file:
I am using /home/data/db/xe-18c as a persistent directory for Oracle XE Datafiles, which means that my RDBMS state will survive across many start/stop docker container lifecycle, this directory should be empty and owned by 54321:54321 UID/GID Unix permissions. Beginning with an empty directory will cause the Oracle XE image Docker entrypoint creates a fresh image and finally apply /opt/oracle/scripts/setup/ post install scripts, post install scripts are defined by default to:
which installs Scotas OLS release v2.0.5 version for Oracle XE, if you don’t want that just comment above three lines.
A fresh Oracle XE instance will have a password for SYS/SYSTEM as is defined in:
For the Dev Container image you should take into account the values for:
- BRANCH is a tag on Scotas OLS repository (source code to work on it)
- ORACLE_PWD must be equal to above value
- DOCKER_GID must be equal to your local environment, please check using grep docker /etc/group, this is important in order to Docker extension for VSCode work
If you review the above configuration, you are ready to re-open the project directory as Dev Container using Reopen in Container button.
First run
During first run when you open this project in Dev Container a log process will shows something like:
A VSCode project is shown and is ready to start developing.
Extensions
Looking at devcontainer.json file, three extensions are included by default in our development environment:
- vscjava.vscode-java-pack, Java Extension Pack by Microsoft
- ms-azuretools.vscode-docker, Docker by Microsoft
- oracle.oracledevtools, Oracle Developer Tools for VS Code
this is why Dockerfile includes in our built image these packages:
- docker-engine
- aspnetcore-runtime-3.1
- OpenJDK11U-jdk_x64_linux_hotspot_11.0.9.1_1.tar.gz
with above extensions We can easily manager our Oracle XE container:
Pre-built some library on image build
If you want to pre-built some library once the image is built for the first time, you can uncomment the line postCreateCommand at devcontainer.json, for example:
"postCreateCommand": "cd /home/lucene;ant build-modules;cd ../solr;ant dist-core dist-solrj dist-contrib",Wrap Up
First, with simple project including a few files any developer gets a Dev Container environment up and running in minutes on any platform, Windows, Linux, Mac; second biggest goodness is that is a reproducible environment you can drop and build many times and you will get same result, third is freezed to an specific RDBMS, Solr and OLS code (using tagged branches), you could work on differents images changing BRANCH build argument, and finally you have all in one place to compile and build OLS.
