Repairing a corrupt eclipse workspace

I've had Eclipse crash on me many times in the past and left things in a state where I couldn't get the workspace to start back up properly. Eclipse would lock-up when restarting. I have always fixed it by simply creating a new workspace and then rechecking out my projects from SVN. But that is a tedious process, and can be a real hassle.

So this time I decided to find a better way. Victor Igumnov provided the solution in his blog. Thanks Victor!

This solved my problem for the most part, however, if you are using a multi-module maven project with eclipse and the m2eclipse plugin, a simple project import didn't get things set back up as they were.

Before eclipse crashed, I had checked out a maven project with subversive using the "Check out as Maven project" feature. When you do this, root-level eclipse projects are created for all maven modules and submodules that are being checked out.

After the crash, doing an "Import -> Existing projects into Workspace" would only create a root-level eclipse project for the parent maven project. Instead, to get back root-level eclipse projects for all maven submodules, you need to do an "Import -> Maven Projects".

After doing that, my workspace was back up and running as it had been before.

---

UPDATE: 2/4/2010

An alternative method that I discovered might work as well, but I still ran into some problems and had to resort to the method above. If it had worked, it would have enabled me to get back up and running even faster. I had problems even with the first method, so I'll try this method again next time this problem happens and see if I have any better luck.

A MyEclipse forum posting gave me the clue for this alternative method. Simply rename a directory called .projects and restart eclipe. Then, once it has started, shut it down, delete the newly created .projects folder and rename the original back to .projects. When Eclipse is started up again, everything seems to work properly. The .projects directory is located at:

%WORKSPACE%/.metadata/.plugins/org.eclipse.core.resources/.projects

When I tried this, Eclipse started up without problems. However, one of my projects was missing its pom.xml, which made it so that none of the source folders were showing up. All I did was right-click on the project and do a "Refresh" (or F5). It then attempted to rebuild the project. Unfortunately, it would finish the build and seemed to keep repeating going from 67% to 70% and then back again.

In the end, I restarted Eclipse, but then it froze on me again during startup. So I resorted to the first solution at the top of this posting. But even after doing it, the build would repeat over and over again. Eclipse had crashed when I was doing some refactoring, and my code was in an invalid state. Once I corrected it, then the build completed properly. So it is possible that this alternative method would have worked after all.

The fifth decade

Wow. The day is here. I've officially completed my fourth decade of life and have began my fifth. I guess I don't really have a whole lot to say about it. This big 4-0 birthday seems pretty much just like any other day. But it has arrived, and now I'm no longer a 30-something. So here's to a happy and prosperous fifth decade!

Tool for encoding XML/HTML tags

Here is a website that will convert all of your XML or HTML tags for display in a blogger post. Basically, it changes < to &lt; and > to &gt;. I'm sure it does a lot more than that too, but that is the most important things it does.

http://www.centricle.com/tools/html-entities/

Configuring virtual hosts in Jetty

I just figured out how to do virtual hosting in Jetty. I have a customer with two sites. The first site (I will call it webappsite.com) is running a java webapp on the root of the site and has a ROOT.war in the webapps directory. The second site (calling it staticsite.com) is currently just a static site. I wanted the site content for the static site to be easily accessible, so I put it into the user's home directory. Both sites need to run on the same IP number and port number, so it was necessary to use Jetty's virtual hosting features.

The webapp on webappsite.com is automatically deployed from the ROOT.war file. I didn't need to do anything extra in any configuration files for it to work. However, since I wanted a static file area on that site as well, I went ahead and added a configuration file to set that up. This wasn't necessary to make this site work and was only done to be able to serve static files stored outside of the ROOT.war file.

I also added a configuration file for staticsite.com. This was necessary for this site to work. Both of these configuration files were put into Jetty's contexts directory. The file for webappsite.com is called contexts/webappsite.xml (sorry for the horrid layout -- I need to figure out how to better post xml code in blogger):

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE Configure PUBLIC "-//Mort Bay Consulting//DTD Configure//EN" "http://jetty.mortbay.org/configure.dtd">

<configure class="org.mortbay.jetty.handler.ContextHandler">
<call class="org.mortbay.log.Log" name="debug"><arg>Configure webappsite.com site</arg></call>
<set name="contextPath">/web</set>
<set name="resourceBase"><systemproperty name="user.home" default=".">/sites/webappsite.com/web/</systemproperty>
<set name="handler">
<new class="org.mortbay.jetty.handler.ResourceHandler">
<set name="welcomeFiles">
<array type="String">
<item>index.html</item>
</array>
</set>
<set name="cacheControl">max-age=3600,public</set>
</new>
</set>
<set name="VirtualHosts">
<array type="java.lang.String">
<item>192.168.0.1</item>
<item>webappsite.com</item>
<item>www.webappsite.com</item>
<item>alternatedomainforsite.com</item>
<item>www.alternatedomainforsite.com</item>
</array>
</set>
</set>
</configure>

The static site's config file is called contexts/staticsite.xml:

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE Configure PUBLIC "-//Mort Bay Consulting//DTD Configure//EN" "http://jetty.mortbay.org/configure.dtd">

<configure class="org.mortbay.jetty.handler.ContextHandler">
<call class="org.mortbay.log.Log" name="debug"><arg>Configure staticsite.com site</arg></call>
<set name="contextPath">/</set>
<set name="resourceBase"><systemproperty name="user.home" default=".">/sites/staticsite.com/</systemproperty>
<set name="handler">
<new class="org.mortbay.jetty.handler.ResourceHandler">
<set name="welcomeFiles">
<array type="String">
<item>index.htm</item>
</array>
</set>
<set name="cacheControl">max-age=3600,public</set>
</new>
</set>
<set name="VirtualHosts">
<array type="java.lang.String">
<item>staticsite.com</item>
<item>www.staticsite.com</item>
<item>anotherdomainforstaticsite.com</item>
<item>www.anotherdomainforstaticsite.com</item>
</array>
</set>
</set>
</configure>

So the following mappings are now taking place:

webappsite.com/ --> jetty/webapps/ROOT.war
webappsite.com/web --> sites/webappsite.com/web
staticsite.com/ --> sites/staticsite.com/

This seems to have done the trick!

Configuring SSH for behind a firewall

My brother couldn't get connected to his websites in Fetch on his Mac and we figured out that the library he was at was blocking most ports except the most common ones. His VPS only allows connections via SSH/SCP/SFTP or HTTP. In the end, I configured sshd on his VPS to listen to port 21 (the standard FTP port) as well as port 22. Since FTP isn't running on his VPS, this worked fine. Then he configured Fetch to connect on port 21 and all was good.

To configure sshd on his VPS, I edited /etc/ssh/sshd_config and added the following lines:

Port 22
Port 21

Then I restarted sshd:

service sshd restart

That's all there was to it!