summaryrefslogtreecommitdiffstats
path: root/org.eclipse.jgit.http.server/resources
Commit message (Collapse)AuthorAgeFilesLines
* smart HTTP: Return errors inside payloadShawn O. Pearce2011-04-011-0/+2
| | | | | | | | | | | | | | | | When the client is clearly making a smart HTTP request to our smart HTTP server, return any errors like RepositoryNotFoundException or ServiceNotEnabledException inside of the payload as a Git level ERR message, rather than an HTTP error code. This prevents the C Git command line client from retrying a failed "$URL/info/refs?service=git-upload-pack" request without the smart service URL, only to fail again with "403 Forbidden" when the dumb as-is service has been disabled by the server configuration, or is unavailable because the repository is not on the local filesystem. Change-Id: I57e8756d5026e885e0ca615979bfcd729703be6c Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* daemon: Use HTTP's resolver and factory patternShawn O. Pearce2011-02-141-2/+0
| | | | | | | | | | | | | | | | | | | Using a resolver and factory pattern for the anonymous git:// Daemon class makes transport.Daemon more useful on non-file storage systems, or in embedded applications where the caller wants more precise control over the work tasks constructed within the daemon. Rather than defining new interfaces, move the existing HTTP ones into transport.resolver and make them generic on the connection handle type. For HTTP, continue to use HttpServletRequest, and for transport.Daemon use DaemonClient. To remain compatible with transport.Daemon, FileResolver needs to learn how to use multiple base directories, and how to export any Repository instance at a fixed name. Change-Id: I1efa6b2bd7c6567e983fbbf346947238ea2e847e Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* Externalize strings from JGitSasa Zivkov2010-05-191-0/+21
The strings are externalized into the root resource bundles. The resource bundles are stored under the new "resources" source folder to get proper maven build. Strings from tests are, in general, not externalized. Only in cases where it was necessary to make the test pass the strings were externalized. This was typically necessary in cases where e.getMessage() was used in assert and the exception message was slightly changed due to reuse of the externalized strings. Change-Id: Ic0f29c80b9a54fcec8320d8539a3e112852a1f7b Signed-off-by: Sasa Zivkov <sasa.zivkov@sap.com>