I'm not sure if SVNKit is supposed to resolve the URLs completely or not. If not, I guess you could plunk each URL you get from the form into a java.net.URL, grab the host portion, resolve it fully, create a new URL and feed that to SVNKit...
On 1/25/07, Eric Crahen <eric.crahen.lists@xxxxxxxxx> wrote:
I think its not resolving the URL fully.
When I enter https://myserver.mydomain.org/svn/myproject
it works fine. When I use the preferred shorthand,
https://myserver/svn/myproject I get the error. The machine I run hudson in is also in domain.org, and if I were to drop to a shell and nslookup mysever it resolves just fine, so I don't think its a nameserver/default domain configuration issue on my workstation.
On 1/25/07, Eric Crahen <
eric.crahen.lists@xxxxxxxxx> wrote:
I get the same thing when I try a plain http:// based repo as well.
On 1/25/07, Eric Crahen <
eric.crahen.lists@xxxxxxxxx
> wrote:I expanded the show details link and I got this,
org.tmatesoft.svn.core.SVNException: svn: Unable to create SVNRepository object for '
https://myserver/svn/myproject'
at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:48)
at org.tmatesoft.svn.core.io.SVNRepositoryFactory.create(SVNRepositoryFactory.java:194)
at org.tmatesoft.svn.core.io.SVNRepositoryFactory.create(SVNRepositoryFactory.java:143)
at hudson.scm.SubversionSCM$DescriptorImpl$1.check(SubversionSCM.java:597)
at hudson.util.FormFieldValidator.process(FormFieldValidator.java
:33)
at hudson.scm.SubversionSCM$DescriptorImpl.doAuthenticationCheck(SubversionSCM.java:588)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java
:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.kohsuke.stapler.Function$InstanceFunction.invoke
(Function.java
:50)
at org.kohsuke.stapler.MetaClass$1.doDispatch(MetaClass.java:59)
at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:30)
at org.kohsuke.stapler.Stapler.invoke
(Stapler.java:224)
at org.kohsuke.stapler.MetaClass$9.doDispatch(MetaClass.java:207)
at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:30)
at org.kohsuke.stapler.Stapler.invoke(Stapler.java:224)
at org.kohsuke.stapler.Stapler.invoke
(Stapler.java:169)
at org.kohsuke.stapler.Stapler.service(Stapler.java:68)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java
:491)
at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:367)
at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:185)
at org.mortbay.jetty.servlet.SessionHandler.handle
(SessionHandler.java
:181)
at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:689)
at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:391)
at org.mortbay.jetty.handler.ContextHandlerCollection.handle
(ContextHandlerCollection.java:146)
at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
at
org.mortbay.jetty.Server.handle
(Server.java:285)
at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:457)
at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java
:751)
at org.mortbay.jetty.HttpParser.parseNext
(HttpParser.java:500)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:209)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java
:357)
at org.mortbay.io.nio.SelectChannelEndPoint.run
(SelectChannelEndPoint.java
:329)
at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:475)
On 1/25/07,
Kohsuke Kawaguchi <
Kohsuke.Kawaguchi@xxxxxxx> wrote:
Hi, I updated the issue 245. If you can try the latest snapshot and let
me know what error you get, that would be really helpful.
Eric Crahen wrote:
> I have some questions on the new SVNKit integration.
>
> #1) Connection Error?
>
> I upgraded from using an external svn binary in hudson
1.6.8, to hudson
> version 1.75 which uses SVNKit. When I create a new project and place my svn
> url in the field, I an given the following error.
>
> "Unable to access
http://myserver/svn/myproject : svn: Unable to create
> SVNRepository object for 'http://myserver/svn/myproject
' (Maybe you
> need to enter
> credential<
http://localhost:8080/hudson/scm/SubversionSCM/enterCredential?http://myserver/svn/myproject
>
> ?)"
>
> I was previously able to access this URL with my external client. I'm not
> sure what when wrong, I looked at stdout, I looked in my servlet container
> logs and I checked the "Manage Hudson" system log and I did not find any
> output that would help me understand the error. There is no credential
> required to check out of this respository, anonymous access is perfectly OK.
>
> What can I do to find the source of the error? Is there a way to make the
> real error more obvious to the user? (I think SVNKit must have produced some
> sort of useful error message we could use.)
>
> #2) Trust?
>
> Another thing I have a question about is how can I provide SVNKit with the
> set of certificates I trust? My repository requires an SSL login in order to
> perform updates, which I would want to do after the fact tagging. My
> repository uses a self-signed certificate which is not going to trusted
> without extra work. The way I told my svn binary to trust my servers
> certificate was by first using the user account I ran hudson as to do an:
>
> svn
https://myserver/svn/myproject
>
> This would cause the svn binary to prompt me that this server has a
> self-signed cert and asks me if I should trust it. I would select yes
> permanently and svn would save some info in ~/.subversion to say trust this
> certificate. Later when I used hudson, I ran svn as the user and svn
> remebered to trust this server because of the data in ~/.subversion
>
> With the SVNKit integration, its not immediately obvious to me how to
> associate a trusted certificate with an SVN connection. I suppose one method
> would be to manually create a jks trust store and run hudson with the
> correct -Djavax.net.ssl.trustStore, -Djavax.net.ssl.trustStorePasswordoptions
.
>
> Since I haven't gotten past my first problem I can't confirm this works, but
> it ought to.
>
>
> #3) Username / Password the only credential?
>
> I can also configure my subversion repository to use SSL client
> identification as a credential, instead of or along with user/name password.
> I'm not doing this, but it would be an interesting thing for the TODO list.
>
>
--
Kohsuke Kawaguchi
Sun Microsystems kohsuke.kawaguchi@xxxxxxx
- Eric
- Eric
- Eric
--
- Eric
| 