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 
That’s not going to work anymore.

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.

Pictures and words, living together!

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 –

Look for things, quickly open them.

OpenAPI Spec Import – quick demo

The quickest, easiest way to build our your API templates/handlers?

PLSQL Editor quick look –

Yes, you can open files now!

I'm a Distinguished Product Manager at Oracle. My mission is to help you and your company be more efficient with our database tools.


  1. Hello Jeff,

    I used to do URL rewrites defined in a jetty-http.xml file under a folder etc located under the old standalone folder. It’s not clear to me where I’ve to put this in the new structure. I tried several options, but the settings are not picked up. This is quite important as my users are used to their old, simplified URL’s.

    I also used this config file to setup access logs, but that now seems possible through the standalone.access.log setting.

    • Another major problem I’m encountering since updating to ORDS 22.1 is that I now get ERR_TOO_MANY_REDIRECTS errors for every single application in every single browser, even when opening the APEX development environment. Clearing the cookies temporarily helps, till the next time.

      I think this is actually more due to being forced to update the JDK, which seems to give problems with my SSL (HTTPS only) setting. Up till now, we used Java 8. This worked fine, even with the most recent APEX version 22.1. But moving to ORDS 22.1, forced us to upgrade our Java as well. We moved to Java 11. I don’t see how I can fix this. I found a couple of mentions of this error on Oracle Support (Doc ID 2755592.1 and Doc ID 2818038.1), but the only solution it seems they can come up with, is to use Java 8 or 9 again… which of course is no longer an option with ORDS 22.1? :s

    • Please open a SR with MOS.

      Please include the complete error stack from ORDS when you get those APEX errors.

  2. 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.

  3. 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.

  4. 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

  5. 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

    • 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:
      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

Write A Comment