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
