Feedback requested: Simplified configuration

It has been mentioned already in a few other threads that there is some new stuff in the latest snapshot builds to support simpler configuration for Spring Social. Today, I'm soliciting feedback on that work as I push toward a 1.1.0.M1 release.

Background: Spring Social is not overly burdensome to configure, either in Java configuration or in XML. But it can be a bit confusing. The design decisions that led to the two separate connection repositories (UsersConnectionRepository and the request-scoped ConnectionRepository), while solid from a design standpoint, are not easily configured nor clearly understood. And it's easy to get them wrong simply by failing to scope them properly.

Moreover, the flexibility in configuring the ConnectionRepository bean such that it is not coupled to Spring Security (and thus allows you to use whatever security mechanism you want to determine who the current user is) makes that bean particularly tricky to configure in XML. That's why many of Spring Social's examples are configured using Spring's Java-based configuration.

Therefore, I sought out a way to abstract Spring Social configuration, as much as possible and necessary, to be simpler. The latest snapshot builds include that simpler configuration option and it is reflected in the latest Spring Social Showcase example for JavaConfig (https://github.com/SpringSource/spri...ocial-showcase) and for XML (https://github.com/SpringSource/spri...l-showcase-xml).

Please take a moment to look at those sample applications and provide feedback (on this thread). Note that while I consider feedback and some of my own thoughts, the configuration is subject to change. My aim is to have this new configuration style reasonably stable in time for 1.1.0.M1 (targeting Nov 19th, 2012) and concretely settled upon in time for 1.1.0.RC1 (date TBD).

Hi Craig

I've only had chance to look at the JavaConfig version of the new configuration , but it looks great! Many thanks for this - I've tried the new annotations in a number of my projects and the work really well.

Regarding the ConnectionRepository annotations, I wanted to see how it would work with alternative versions of ConnectionRepository other than JDBC - I've played around with create annotations for a number of other implementations with the spring-social-config-extensions project on my GitHub - including InMemory, Jpa, Roo, and Hibernate. The structure of the annotation code required is easy to understand and allows implementations to be swapped just by changing the annotation (as long as other dependencies are present). I wanted to ask, are there plans to allow a connection signup to be configurable on the UserConnectionRepository through this config?

I had a question on ConnectInterceptor registration for providers : I've often needed to register provider-specific connect interceptors (usually the same abstract interceptor, but subclassed for the specific provider to allow detection), and I've needed to register these with ConnectController.

In such a use-case, where do you see the responsibility lying for the configuration and registration of these interceptors? Could there perhaps at some point in the future be a ConnectInterceptorRegistry that could be wired into ConnectController? - if so it may be really useful for the provider-specific annotations such as EnableTwitter to have a handle on this registry and allow configuration of a provider-specific interceptor as part of the annotation. This was just a thought I had - it may be that you see the Interceptors as decoupled from the main provider config and instead part of ConnectController config, but it would be great to find a way to configure all provider-specific elements in a single place.

I'll try to take a look at the xml versions of the config when I get the chance.

Thanks again for this feature and for inviting feedback.

Cheers,

Michael Lavelle