In fact, the problem, is buggy.
I will enumerate some posbile recipes, but i warn you, the list will never be complete, probably.
I studied some time this problem and, for me, seems to be more like a bug. In order to get rid of any headache, better install OHS and just use it without any trouble. If not, read above:
First, let's make sure the listener is listening:
sqlplus / as sysdba
Further, will consider the problem is not solved.
Virtually, one or more of the users that concern the apex instance (apex_0xxxxx, apex_public_user, anonymous, XDB) is expired or locked.
So, run, one by one (you can't in a row, i know you're tempted):
alter user xxxx identified by xxxx account unlock;
After these 4 commands, it can be possible the message be still there. From my experience, once i had to make the passwords exactly like the usernames. And after this, the message has gone.
Well, let's assume the problem is still there.
Change the level of debug for the embedded plsql gateway:
If you are lucky, will find the error in one of the tracking files from the BACKGROUND_DUMP_DEST.
Once, i have found one of the above users, i don't remember which one was experiencing a lack of grants on tablespace sysaux. I don't know what can be useful in having rights on that tablespace, but truth is, the .trc file was complaining about this. After the proper corection (grant tablespace etc.), the problem was solved.
Another time, the problem was this:
somewhere, in the response, i noticed:
That 127.0.0.1 part is not good, because you cannot connect remotely, in this case, hust locally, on the server.
This problem will disappear after
sqlplus / as sysdba
EXEC DBMS_XDB.SETHTTPPORT(8080) ;
and, if the 127.0.0.1 is still there, bounce the listener.
Sometime, you forgot to:
If you are in a hurry, and i know how it is, under critical circumstances, use a temporary workaround:
EXEC DBMS_XDB.SETHTTPPORT(8081) ;
Changing the port is the most easy, fast, and posible to succeed operation.
Could work and you can save your job for a day or two :)