On Jul 23, 2013, at 15:47 , Ignasi <ignasi.barr...@gmail.com> wrote: > Hi Nikola, > > You should be able to configure this by providing a custom Guice > module when creating the context, and binding there the > AsyncMultipartUploadStrategy interfaces to your custom > implementations. Something like: > > Module uploadModule = new AbstractModule() { > @Override > protected void configure() { > bind(AsyncMultipartUploadStrategy.class).to(YourImplementation.Class); > // Bind S3/Swift strategy too > } > }; > > ContextBuilder.newBuilder(provider) > .modules(ImmutableSet.<Module> of(uploadModule)) > (...) > .build();
Hi Ignasi, we've tried this suggestion, with slight modification (instead of AsyncMultipartUploadStrategy, we have MultipartUploadStrategy) as our strategy inherits from it. This is the error produced by 'mvn -P release test' on our codebase: Error message: Guice creation errors: 1) A binding to org.jclouds.aws.s3.blobstore.strategy.MultipartUploadStrategy was already configured at com.foobar.modules.multipartupload.config.FoobarMultipartUploadModule.configure(FoobarMultipartUploadModule.java:15). at org.jclouds.aws.s3.blobstore.config.AWSS3BlobStoreContextModule.configure(AWSS3BlobStoreContextModule.java:47) 1 error at com.foobar.ModuleUtils.buildModuleTree(ModuleUtils.java:121) at com.foobar.modules.FooStore.build(FooStore.java:177) at com.foobar.modules.FooBlobStore._init(FooBlobStore.java:55) at com.foobar.test.multipartupload.AWSS3BlobStoreConnectionIT.initTest(AWSS3BlobStoreConnectionIT.java:83) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:84) at org.testng.internal.Invoker.invokeConfigurationMethod(Invoker.java:564) at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:213) at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:138) at org.testng.TestRunner.beforeRun(TestRunner.java:641) at org.testng.TestRunner.run(TestRunner.java:609) at org.testng.SuiteRunner.runTest(SuiteRunner.java:334) at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:329) at org.testng.SuiteRunner.privateRun(SuiteRunner.java:291) at org.testng.SuiteRunner.run(SuiteRunner.java:240) at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52) at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86) at org.testng.TestNG.runSuitesSequentially(TestNG.java:1224) at org.testng.TestNG.runSuitesSequentially(TestNG.java:1220) at org.testng.TestNG.runSuitesLocally(TestNG.java:1149) at org.testng.TestNG.run(TestNG.java:1057) at org.apache.maven.surefire.testng.TestNGExecutor.run(TestNGExecutor.java:170) at org.apache.maven.surefire.testng.TestNGXmlTestSuite.execute(TestNGXmlTestSuite.java:84) at org.apache.maven.surefire.testng.TestNGProvider.invoke(TestNGProvider.java:92) at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200) at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103) I know that the stack trace is useless w/o the code, but I just want to include the error in its entirety. Best, Nikola