EBS 11i -- Could not initialize class oracle.apps.fnd.common.Guest / a different kind of a problem and an easy fix.

Nowadays, I'm dealing with an EBS 11i-EXADATA migration. I have solved some pretty interesting issues during the way and wanted to share one of them with you.

It was encounted while we were migrating the TEST environment to Exadata.

The issue was started at the point, where the Dba applied 11i.ATG_PF.H.RUP7 (as a prereq for the migration)

Not only the Jserv logs (In EBS 11i, we have Jserv) and Oacore logs, but even the login page was complaining about the Guest class.

The error that we saw, was "Could not initialize class oracle.apps.fnd.common.Guest" and no matter what we did, we could not fix it. ( The error was documented in MOS, but the solution documented there didn't fix the problem)

So this issue was a a little different and that's why made me to jump to the code and analyze the Guest class.

The error text made me think that, there could be a classpath problem or there can be a class-permission problem , but the actual problem was suprisingly weird :)

I saw that, Guest class was written to execute fnd_web_sec.get_guest_username_pwd (it was enclosed with a begin-end).

So I checked the database and saw that the fnd_web_sec package had no function named get_guest_username_pwd.

The get_guest_username_pwd function seemed to be delivered with 11i.ATG_PF.H.RUP7(or any other patches along the way) and I concluded that there was sychronization problem between the apps code and the db code..

Apps code was expecting the get_guest_username_pwd but db code had no function named  get_guest_username_pwd .

At this time, I concluded that this was a db level problem and I also concluded that "could not initialize class" and "java.lang.NoClassDefFoundError" errors were misleading.. (they were the results, not the cause)

When I analyzed the issue and investigated the issue by asking the DBA, I found out that, after the patch application, they recreated this fnd_web_sec package with its former code. 

They said "we did it, because we had another custom plsql which was dependent on fnd_web_sec and that custom plsql could not work with the new version of the fnd_web_sec."

At this point, I recreated the fnd_web_sec by taking its code from another RUP7 environment and -told them to not to modify standard codes..  The missing function was there...

I told them to modify their custom code to be aligned with the changes in standard codes.

At the end of the day, we have dealed with a basic problem, but its reason could not be found easily. (a hard to solve basic problem, isn't it :)

The lesson  learned for the customer and that dba was;

• Never touch the standard code.
• Analyze patches to be applied before the applying them and test your customizations if you suspect that your customizations can be affected.
• Document your customizations and check them after applying any patches.
• Modify your custom code when a standard code that it is dependent on, changes.