AbstractCloudConfig imports classes from Spring data Redis, MongoDB and RabbitMQ about spring-cloud-connectors

[scottfrederick]

AbstractCloudConfig does import service-specific classes, but the dependencies on the libraries that provide these classes are marked optional in the build file. This means that these dependencies are not transitive, and apps or libraries that use Spring Cloud Connectors do not automatically have all these libraries as dependencies. See the Maven documentation for more details.

Does the fact that these dependencies are not transitive remove your concerns here?

[scottfrederick]

@gauthierj Any feedback on response above?

[davidehringer]

I think the problem is that because they are imported you get a NoClassDefFound if you don't include them as dependencies even if you aren't using them. If you have something like:

public class CloudConfig extends AbstractCloudConfig {

    // access some services, none of which are rabbit, redis, or mongo
}

You still have to include rabbit, redis, and mongo related dependencies even though you don't use them in your app.

        <dependency>
            <groupId>org.springframework.data</groupId>
            <artifactId>spring-data-mongodb</artifactId>
            <version>1.6.1.RELEASE</version>
        </dependency>
        <dependency>
            <groupId>org.springframework.amqp</groupId>
            <artifactId>spring-rabbit</artifactId>
            <version>1.2.2.RELEASE</version>
        </dependency>
        <dependency>
            <groupId>org.springframework.data</groupId>
            <artifactId>spring-data-redis</artifactId>
            <version>1.3.4.RELEASE</version>
        </dependency>

Otherwise you get NoClassDefFoundExceptions.

[gauthierj]

Thanks @davidehringer that's exactly my problem.

Sorry for the late answer @scottfrederick, but I'm not truly working on that currently.

[scottfrederick]

@davidehringer and @gauthierj Sorry for the back-and-forth on this, but I think we are seeing different things and I'm not sure what's causing the differences.

Here are several sample projects that use Spring Cloud Connectors, including AbstractCloudConfig, but only include the dependencies they actually use in the app:

Spring Music:

• several AbstractCloudConfig classes here: https://github.com/cloudfoundry-samples/spring-music/tree/master/src/main/java/org/cloudfoundry/samples/music/config/data
• only JPA, Mongo and Redis dependencies, no RabbitMQ/AMQP: https://github.com/cloudfoundry-samples/spring-music/blob/master/build.gradle#L54-L113

Spring Sendgrid:

• just one AbstractCloudConfig class for e-mail configuration: https://github.com/cloudfoundry-samples/spring-sendgrid/blob/master/src/main/java/org/cloudfoundry/samples/email/config/app/AppCloudConfig.java
• no Spring Data dependencies at all: https://github.com/cloudfoundry-samples/spring-sendgrid/blob/master/build.gradle#L49-L84

rabbitmq-cloudfoundry-samples:

• uses XML config to get a RabbitMQ connection: https://github.com/cloudfoundry-samples/rabbitmq-cloudfoundry-samples/blob/master/spring/src/main/webapp/WEB-INF/spring/servlet-context.xml#L16-L17
• only depends on Spring AMQP: https://github.com/cloudfoundry-samples/rabbitmq-cloudfoundry-samples/blob/master/spring/pom.xml#L29-L72

Can someone share a project that demonstrates the NoClassDefFoundException behavior so we can figure out what's different between these projects?

[davidehringer]

@scottfrederick not a problem.
Here is an example project that demonstrates the issue: https://github.com/davidehringer/spring-cloud-connector-dependency-issue

[ramnivas]

@davidehringer What's the version of JDK you are using?

[davidehringer]

1.7.0_67

[jhiemer]

Having exactly the same issue in three projects.

[scottfrederick]

Fixed in 625040c.

The reason that this problem was hard to nail down was that (per my testing anyway) the NoClassDefFoundException would only be triggered when the @Configuration class that extends AbstractCloudConfig was nested within a Spring Boot main class (or possibly nested in any @Configuration or @Component class). The exception would not get thrown if the @Configuration class was a top-level class. There may be other edge cases, but that explains why the problem didn't happen in all the (older, mostly non-Boot) projects listed in the comment above, but happened in many newer (I presume Boot) projects.

Moving the ServiceConnectionFactory class (which is where the DataSource, MongoDB, Redis, RabbitMQ dependencies come from) from an inner class of AbstractCloudConfig to a top-level class, and making AbstractCloudConfig depend on an interface instead of this concrete class, change the way Spring inspects these classes for configuration, and prevents the invocation of the Java refection API that was triggering the NoClassDefFoundException.