We are currently using the ViPR SDK ('s3-client-2.0.3.jar'), which depends on following dependencies:
We had to exclude the last three dependencies to get our application deployed on the WildFly 8.2 application server. The conflicting class is 'javax.ws.rs.core.Response'.
My question is, if excluding the dependencies mentioned above might lead to problems, especially if we want to use the client based load balancing feature provided by the API in production?
Unfortunately you do need those libraries to use the s3-client. The load balancer (Ribbon) depends on that specific version of Jersey (1.11). Without it, you will likely see NoClassDefFound exceptions.
If you're not using any ViPR-specific extensions, you can optionally use a different S3 client (i.e. AWS SDK for Java - for which we have a quick start guide), but as you say, you will loose the client-side load balancing provided by our library. However, you can mitigate this by putting a load balancer in front of your data services nodes.
I googled a bit and unfortunately I can't see any easy way around your problem. You may be able to alter the class loader hierarchy or exclude the resteasy module
via the deployment structure file, but I have not tested this.
Thanks for the fast response - albeit it is bad news for us 😉
I'll try to modify the WildFly configuration and keep you informed.
I've put together a small project to test the use of our S3 client within the WildFly 8.2 container and, using a very basic set of dependencies, the client seems to work. Basically, I just have servlet 3 and s3-client 2.0.3. You can modify the credentials in EcsTestServlet.java for your environment. ./gradlew war will produce a war file you can deploy for testing. The resource path is /wildfly-test-1.0.war/nodes. If this returns a response, you know the client is loading properly.
I'm sure there are some additional details about your environment or your application that are missing here, but perhaps this can be a good starting point to track down the problem. If you do get it working, it would be great if you could share your solution.
I have to admit that we were not able to reproduce the deployment problem we had a few weeks ago.
I reordered the dependencies in the Maven pom.xml, so that the JavaEE7 libs come first (org.jboss.spec:jboss-javaee-all-7.0), which resolved the compile time issues we had (conflicts due to JAX-RS 1.x vs. JAX-RS 2.x).
It looks like we are now able to use the client-side load balancing feature of the ViPR API.
Thank you, for providing the sample project and for your support.