Friday, December 14, 2012

Oracle Application Express 4.2.1 now available

Oracle Application Express 4.2.1 is now released and available for download.  If you wish to download the full release of Oracle Application Express 4.2.1, you can get it from the Downloads page on OTN.  If you have Application Express 4.2 already installed, then you need to download the APEX 4.2.1 patch set from My Oracle Support.  Look up patch number 14732511.

As is stated in the patch set note that accompanies the Oracle Application Express 4.2.1 patch set:

  • If you have Oracle Application Express release 4.2 installed, download the Oracle Application Express 4.2.1 patch set from My Oracle Support and apply it.  Remember - patch number 14732511.
  • If you have Oracle Application Express release 4.1.1 or earlier installed (including Oracle HTML DB release 1.5), download and install the entire Oracle Application Express 4.2.1 release from the Oracle Technology Network (OTN).
  • If you do not have Oracle Application Express installed, download and install the entire Oracle Application Express 4.2.1 release from the Oracle Technology Network (OTN).

As usual, there are a large number of issues corrected in the Application Express 4.2.1 patch set.  You can see the full list in the patch set note.

P.S.  Don't be alarmed when the patch set note refers to file and the file you actually download from My Oracle Support is  These are the same file and this version number will be corrected over the weekend.


Noons said...

Pssst... Don't look now, but bug
"APEX_LDAP.IS_MEMBER does not work with anonymous bind"
which is in the list of fixed problems in 4.2.1 somehow has evaded inclusion in the full release 4.2.1 available here:
I mean the second file in that list.

Installed it on top of our existing 4.0, fixed the ACLs and the LDAP authentication stopped working.
Ran again the patch that fixes that bug - manually, patch script won't run in anything other than 4.0! - and LDAP auth promptly started working again.
Someone at Oracle's release QA needs their head thumped.
Repeatedly, and with alacrity...

Joel R. Kallman said...

Hi Noons,

Before anyone gets thumped, can you please clarify what situation you're encountering? We're having trouble understanding it. Let's take this one step at a time, if I may.

1) You say "Installed it on top of our existing 4.0", but what is it you installed? The APEX 4.2.1 patch set? If so, then are you asserting that you *upgraded* to APEX 4.2.1? How did you "install it"?

2) "Ran again the patch that fixes that bug" - what does this mean? What patch did you run, and against what version of APEX?

3) The fix for bug 15836959 would not impact LDAP authentication whatsoever.

4) You seem to allude to an SR in this forum:,21. Can you please let me know what the SR # is?



Noons said...

Sure. SR 3-6626786761.
I'd appreciate if you can let me know *where* in that SR did *I* ever mention I was running OLAP...

Anyways, to answer your question 1:

I installed 4.2.1 full release (the second download in the URL I added, like I wrote above) over an existing 4.0 where LDAP authentication was working perfectly well.

The authentication stopped working after that install.

Yes, I am fully aware that I have to authorize the new owner - APEX_040200 - for network acls, I have read the install manual and it's been done!

Even with that, no LDAP authorization.

But once I install the patch that is available from MOS for bug 15836959, LDAP starts working perfectly well again.

Now, I hear your comment that the fix for that bug would not affect the authentication.

Can you please understand I *installed* the fix and it fixed the problem?

Therefore, to claim as you do that the fix for the bug would not impact LDAP authentication amounts to you confirming exactly and precisely what I said?

One installs a patch to fix the problem, not to create it!

What created the problem was the install of 4.2.1 full release, where that patch is supposed to be already - and obviously it isn't!

Why is this so hard to understand for you folks, still mystifies me.

And how on Earth can anyone confuse OLAP and LDAP is beyond anything I can imagine...

Joel R. Kallman said...

Hi Noons,

1) In that SR, it seems that the Support Analyst had a typo of OLAP when they meant LDAP. I make typos too. I'm not perfect. They apologized. Time to move on.

2) I tried to reproduce this tonight and could not. Here are the steps I performed:

a) Created a new database with no APEX in it.
b) Installed APEX in it.
c) Provisioned myself a workspace, created an application, created an LDAP authentication scheme in it, and tested it against our internal LDAP server. it functioned correctly.
d) I then downloaded and installed APEX 4.2.1 (from the second link on the download page that you specified).
e) APEX 4.2.1 was correctly installed and upgraded.
f) I logged into the workspace I created in (c) above, ran my application. No issues whatsoever. The LDAP authentication worked just as before with no alteration from my end.

3) At one point, you say "Even with that, no LDAP authorization." Did you mean *authentication* and not authorization? I just simply want to confirm that we're not confusing authentication schemes with authorization schemes.

4) The code for LDAP authentication is in custom_auth_ldap.* (PL/SQL package wwv_flow_custom_auth_ldap). The code for the LDAP utility functions (like APEX_LDAP.IS_MEMBER) is in file ldap.* (PL/SQL package wwv_flow_ldap). There are no dependencies between the two packages. The PSE for Bug 15836959 contains file ldap.plb. I just don't see a way that this could even directly impact LDAP authentication.

Thus - I hear you, when you say you have empirical evidence that applying this PSE corrects this functionality. But unless we can reproduce the issue, it's going to be difficult to pursue this further. Additionally, I have confirmed that the bug fix for 15836959 is in both the patch set and the re-release, and more importantly, from a code perspective, I don't see how the bug fix for 15836959 impacts LDAP authentication whatsoever.

Sorry I don't have better news for you.


Noons said...

Yeah, no worries. Using 4.2 upgrade over 4.0 and then patching it to 4.2.1 fixed all problems here and I've got all Apex instances up to scratch now.

One of the things that is extremely confusing in all this is the lack of consistency between patch file naming and actual Apex release and owner naming.

For example:
- patch/release apex_4.2 installs to an owner APEX_040200.
- patch/release apex_4.2.1 installs as well to APEX_040200 owner, but patches it up to 4.2.1.

Ie: the owner doesn't change, but the actual release level does.

Another example:

- you tested installing 4.0.2 (resulting in an owner of APEX_040200) and then upgrading.

- my initial problem was when I had 4.0.0 (not 4.0.2, the owner user was APEX_040000) and upgraded using the full 4.2.1 release.

Have not re-tried re-downloading the patch file just in case something got corrupted. Will still do it later in Feb, but right now I'm flat out with a few other projects.
Will report on my findings, likely through linked-in as I go there more often.

Joel R. Kallman said...

Hi Noons,

I don't believe there is any inconsistency.

A new product schema is created for major releases but not for patch sets. New releases contain new features and new UI, patch sets do not.

APEX 4.2 was a major release. The APEX 4.2.1 patch set, which can be applied to an APEX 4.2 instance, does not contain new features or UI. The schema doesn't change.

In general, if the major version number or the first minor version number changes, that signifies a new release and will be associated with a new product schema.

One thing you said was incorrect - "you tested installing 4.0.2 (resulting in an owner of APEX_040200)". That's not true. An APEX 4.0, 4.0.1, 4.0.2 installation would all have a product schema of APEX_040000.

Maybe we do a poor job of explaining it, but I don't believe it's inconsistent.


P.S. Oracle Support asked us to abandon the bug that was filed on your behalf, as you found a work around. I'm still suspect if there is a product defect or product integration problem, as you asserted. To this end, I would appreciate if you could send your application export to Oracle Support so we could investigate this reported issue. Thanks.