Usually when a new version of your favorite software comes out, you download it, and give it a go. Exactly like that, in that order.
But, for version 22.1 of ORDS, I recommend you break that habit.
However, I know you will ignore this advice and go to start/upgrade ORDS like you’ve always done, a la
java -jar ords.war standalone

So what’s the new command to run, Jeff? (Yes, I hear your voices in my head) I’m not going to tell you the new command right now, because I want you to read the README and the Docs.
I guess you can still cheat and see the slides below for some hints. I try to be firm, but not mean!
So, I will now do as Inigo Montoya might say, let me sum up.
What’s new & what you need to know, in a nutshell
- The standard java command line interface is gone
- There’s now a bin/ords program/shell script available to working with ORDS
- The configdir is no longer burned into the WAR file
- You’ll need to set a OS environment var or use a -config flag to tell ORDS where it can find it’s configuration files
- The way we store ORDS configuration files is completely different now – you’ll be migrating your old configdir to a new one
- We no longer support Oracle Java 8
- We now support both Oracle Java 11 and 17
- ORDS no longer supports APEX based REST APIs – you MUST migrate those to the ORDS side of the universe (btw, APEX no longer supports them as well)
I’ll have deep-dive details on most of these points going forward over the next few days, weeks, and months, but in the meantime, I put these slides together to give you an idea what this all really means.
What about SQL Developer Web?
Yes, HUGE updates there! I’ll be talking about those new features as well. A dedicated editing environment for PL/SQL, create/edit/delete scheduler jobs, schedules, notifications, importing OpenAPI (2 or 3) specs as new REST Modules, ability to open/save local files from the worksheet and procedure editor, and a new OmniSearch feature for finding/opening things in your database.
Search quick look –

OpenAPI Spec Import – quick demo

PLSQL Editor quick look –

15 Comments
I see that the other three APEX users are not migrated to the new config directory when doing the upgrade (ords –config install -i –legacy-config –log-folder ), only the ORDS_PUBLIC_USER (apex_pu.xml) is migrated and is the default user. What about APEX_PUBLIC_USER (apex.xml), APEX_REST_PUBLIC_USER (apex_rt.xml) and APEX_LISTENER (apex_al.xml)?
Everything runs through ORDS_PUBLIC_USER now.
And remember, apex based rest no longer supported at all, by ords or apex now.
Is there any memory requirement , it look like i can’t install it on 1G any more !
We have a bug open where the required memory footprint has doubled or more since 21.4 – we’ll have a patch available next week, 22.1.1 that will fix this.
Is there more info regarding this bullet?
ORDS no longer supports APEX based REST APIs – you MUST migrate those to the ORDS side of the universe (btw, APEX no longer supports them as well)
Sure thing.
They’ve been deprecated for several years now. APEX users have been instructed to migrate their APEX based REST APIs to ORDS. The current versions of both APEX and ORDS now no longer support these APIs – you MUST migrate them to ORDS to continue using them.
Does this mean that we should not use any PL/SQL packages that start with APEX. for Ex: APEX_JSON
All of the APEX_ helper. packages are still fair game.
Did you fixed issue with install command?
In previous versions when I run java -jar ords.war install simple
it does install actions and then immideately begin to serve requests and never exit, until I press ^C.
So, this behaviour adds a lot of problems in Kubernetes
The process ends after the installer is one, then you call it again with the Serve command to start it.
Does this mean that we should not use any PL/SQL packages that start with APEX. for Ex: APEX_JSON
Sorry for asking in a wrong thread kindly ignore
“We no longer support Oracle Java 8 , We now support both Oracle Java 11 and 17”
but install ords from http://yum.oracle.com/repo/OracleLinux/OL8/oracle/software/x86_64 require java 8
The yum repo is still serving up ords 21.4 which still depends on 8. As soon as that gets refreshed to 22.1, you’ll see that go to 11..just like Spinal Tap.
yum deplist ords-22.1.0-6.el8
Last metadata expiration check: 0:01:31 ago on Sun 08 May 2022 12:24:36 PM CET.
package: ords-22.1.0-6.el8.noarch
dependency: /bin/sh
provider: bash-4.4.20-2.el8.x86_64
provider: bash-4.4.20-2.el8.x86_64
dependency: jre
provider: java-1.8.0-openjdk-1:1.8.0.332.b09-1.el8_5.x86_64
dependency: lsof
provider: lsof-4.93.2-1.el8.src
provider: lsof-4.93.2-1.el8.x86_64
provider: lsof-4.93.2-1.el8.x86_64
dependency: shadow-utils
provider: shadow-utils-2:4.6-14.el8.src
provider: shadow-utils-2:4.6-14.el8.x86_64
provider: shadow-utils-2:4.6-14.el8.x86_64