p2 likes its 404s straight up

Setting up p2 to work with a repository that is behind HTTPS has been quite challenging. First I ran into this Java bug which was affecting ECF, the underlying transport for p2.

After moving past that problem, I was getting a lot of "No repository found at.." error messages, even though I knew damn well there was a repository hosted at the URL I was specifying.

After digging through the p2 code with the debugger turned on, I found the problem. You can deploy your repository metadata in two formats, compressed (JAR) or uncompressed (XML). When the repository manager goes out to a URL to look for the repository contents, it tries to find the JAR version first. If that fails with a 404, then it looks for the XML version.

I was deploying the XML version, and the fallback behavior wasn't working. It was pulling in an empty artifacts file, and trying to parse it, which of course failed. Turns out the web server was sending a 302 redirect with a user friendly page explaining that the page had moved. I found this by intentionally hitting a bad URL with Firefox, using Firebug to examine the response headers:



You can see that the 404 is coming AFTER the 302, which is too late. ECF was relying on the 404 to cause a FileNotFoundException, which translates into a known failure status in the p2 repository manager code, from which it can recover and try again with a different filename.

After tweaking the web server to return a 404 immediately, I was able to refresh the repository in the Software Updates dialog without any errors.