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 –
19 Comments
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.
I’m taking today off will try to catch up to this, tomorrow.
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.
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