It happened to me two times over the last couple of months. In the morning, when I fired up JDeveloper (184.108.40.206.0) to work on the ADF project at my current client, JDeveloper suddenly “forgot” which project workspaces were open and lots of other settings were lost. Apparently, some settings files are corrupted for whatever reason. In this state, it is not possible to do my normal work with JDeveloper. As I don’t want to spend half the day with re-installing JDeveloper and all plugins and re-doing all my settings, I figured out a way to “repair” the JDeveloper settings. I thought I’d share this, so if you ever encounter a similar situation, you can safe yourself a lot of work by just repeating what I did.
On my Windows XP workstation, JDeveloper itself is installed to D:OFM111130Middleware. Since 11g, JDeveloper has an installer and puts all settings in a different location, in my case C:Documents and Settingsbart.kummelApplication DataJDevelopersystem220.127.116.11.37.56.60 Inside this directory -with an already pretty long name- resides a rediculously large (> 400MB!) and deep (nearly 7000 files, > 200 directories) directory structure. This directory tree not only contains the settings for the IDE, but also a complete WebLogic domain.
A simple solution to get a good working JDeveloper again, would be to remove the entire system18.104.22.168.37.56.60 directory. At startup, JDeveloper will just create a new directory with all default contents. However, that way I would lose all my settings: not only the changes I made to the IDE defaults, but also the settings of the default domain of the embedded WebLogic server. This includes JDBC datasources and LDAP directory connections. I definetely do not want to set those up again.
So let’s go for a more subtle approach. Let’s rename our settings folder, e.g. to system22.214.171.124.37.56.60.old. (Of course, this can only be done if JDeveloper is not running.) Then start JDeveloper. As expected, it creates a new system126.96.36.199.37.56.60 directory, with default contents. Now we have to exit JDeveloper again, so we can copy some stuff from the old directory to the new one. Let’s start with the WebLogic domain. Assuming nothing is corrupt within that domain, we can just delete the DefaultDomain directory from the new system188.8.131.52.37.56.60 and copy the DefaultDomain directory from the system184.108.40.206.37.56.60.old directory. In my case, this was not as trivial as it sounds. As I mentioned before, the directory structure inside system220.127.116.11.37.56.60 is very deep. As a result, some paths get too long for Windows to handle. This results in Windows refusing to copy the files that have a path that’s too long. Fortunately, there’s a simple way to work around this. I just gave some directories a (temporary) shorter name. There are two DefaultDomain directories in the system18.104.22.168.37.56.60 tree and there’s also a DefaultServer directory. I renamed those to DD and DS, respectively. Then I copied the DD directory from the system22.214.171.124.37.56.60.old directory to the system126.96.36.199.37.56.60 directory. And of course, after copying, I renamed the directories to their original names.
Well, I saved myself a lot of configuration work on my embedded WebLogic server. I can also copy some IDE settings: those are located in the o.ide directory in the system188.8.131.52.37.56.60 tree. I just replaced the o.ide directory in the system184.108.40.206.37.56.60 folder with a copy of o.ide from the system220.127.116.11.37.56.60.old directory. (No name-shortening was needed in this case.) After that I just restarted JDeveloper and it was just working again. I was only missing the my projects in the Application Navigator, but that’s fixed easily by just opening the .jws files again.
I hope this will never happen to you. But if it does, now you know how to solve it without losing all your settings.