Have you reviewed the samples and the reference documentation? There you'll see that when Spring is used to instantiate and wire the ConnectController, it will automatically construct a javax.inject.Provider for the current user's ConnectionRepository. This is part of the Java @Inject standard (JSR-330). You can see the javax.inject dependency included in the spring-social-showcase pom.xml.
We inject a javax.inject.Provider<ConnectionRepository> instead of a direct reference to a ConnectionRepository because the current user's ConnectionRepository is a request-scoped bean, not a traditional singleton bean.
Even though Spring Social has just a few dependencies on other libraries, in general, we need to be a lot more specific about what dependencies Spring Social does require (and optionally supports) in the reference manual. The reference manual doesn't spell this out yet and it should. We'll make sure to address this in the next release (watch https://jira.springsource.org/browse/SOCIAL-150).
We're also generally evaluating the reusability and flexibility of ConnectController, since we've also had requests for tapping into it from another environments besides Spring MVC e.g. via a filter.
As far as not persisting the connection--if you're ok with having the user authorize each time, then you could write your own little ConnectController implementation that does what you need. Alternatively, you could consider injecting a ConnectionRepository implementation that doesn't do anything. We could consider adding support for such non-persistent web-client-driven connections, but I'm not sure how generally useful this is. It would be a pain if users have to connect each time they wish to share something on Twitter or Facebook.
Last edited by Keith Donald; May 8th, 2011 at 06:22 PM.
Core Spring Development Team