Where did you put the code to change the security provider, in build.gradle or settings.gradle? If it was settings.gradle, that would make sense because buildSrc classes are not accessible from settings.gradle. If it was build.gradle, it's possible that the Security framework is using the SystemClassLoader which also does not contain the buildSrc classes (those are referenced from a special URLClassLoader). Lastly, it's possible that the Security framework is using the thread's current context ClassLoader (which is the correct thing to do). In this case, maybe Gradle should be setting the buildSrc ClassLoader as the current thread's context class loader before executing the build script. You could try this in the Gradle.java class, in method loadAndConfigure(). After the call to settings.createClassLoader(), just set that class loader as the current thread's context class loader.
On Wed, Aug 5, 2009 at 3:27 PM, Pfau, Matthias <[email protected]> wrote: > Hi, > I just tried to connect to a SSL secured website with an untrusted > certificate. This is only possible, if you import the certificate or change > the security provider to a dummy implementation. > > I tried to change the security provider: > Security.setProperty("ssl.SocketFactory.provider", > "sslsecurity.DummySSLSocketFactory"); > > The class sslsecurity.DummySSLSocketFactory is part of the buildSrc. > > Unfortunately, it does not work. I just get the following output from > gradle: > > 20:55:57.676 [main] WARN org.gradle.api.logging.LogLevel - Server > access Error: java.lang.ClassNotFoundException: > sslsecurity.DummySSLSocketFactory url=https://[...] > > I do not know what happened here. I know from other tests, that the > classpath for IVY includes the classes from the buildSrc directory. Has > anyone else tried to change the provider or an idea what is going on there? > > Kind regards > Matthias > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > > -- John Murph Automated Logic Research Team
