Add configuration and jars to middle tier jar or web app files

Just trying to figure out where I should put my configuration(s) for Spring Social.

Main thing is that we have a jar that includes our domain objects and our Spring Security UserDetails implementation. That jar is included in our core jar which are our middle tier beans, as well as our Spring Security UserDetailsService implementation. And then of course that is included in our war web apps modules/project.

So if I want my UserDetails to implement SocialUserDetails and my UserDetailsService to use, well not sure what it needs. I am also sure to use the Social filter that integrates with Spring Security.

Then there is the controllers which need to be in the web module.

Some of the beans will be in the parent middle tier ApplicationContext and the controllers in the WebApplicationContext.

So in the end, I guess I could add the Spring Social Core jar in my db and core modules. Leaving out any provider specific stufff. And then include core, provider specific stuff, web, etc in my web app war dependencies.

Then for the xml configuration, I will have to put Spring social xml config like

Code:

---

    <util:property-placeholder location="classpath:META-INF/spring/social.properties"/>

    <facebook:config app-id="${facebook.clientId}" app-secret="${facebook.clientSecret}" app-namespace="socialshowcase" />
    <twitter:config app-id="${twitter.consumerKey}" app-secret="${twitter.consumerSecret}"/>

    <social:jdbc-connection-repository data-source-ref="dataSource"/>
    <bean id="userIdSource" class="org.springframework.social.config.xml.SpringSecurityAuthenticationNameUserIdSource" />

    <bean id="psc" class="org.springframework.social.connect.web.ProviderSignInController" autowire="constructor" />

---

in my applicationContext.xml or my servletName-servlet.xml? Or do I have do put some in one and some in the other. I mean there is no reason to define beans of type Controller in the applicationContext.xml since that is the parent ApplicationContext.

Thanks for your help

Mark

I applaud your attempts to properly modularize your app, but I admit that I haven't given this particular problem nearly as much thought as you have. Therefore, I'm not prepared to give you an authoritative answer. What I will offer, however, is my thoughts on the problem. You can take them, leave them, or use them as seed for discussion.

In my simpler view of the problem, I tend to think of Spring Social (esp core and web) as fitting in the web layer. And I tend to put everything else with it there, too. I think that way because the most important thing that Spring Social does is work through the connection process and that's largely a web-level activity.

The problem is approaching this with a "box-arrow-box-arrow-cylinder" view. In such a linear view, we feel we must put certain things in either the web layer, the service layer, or the database layer. But in fact, some things span multiple layers.

The domain, for example truly fits in all three of those layers to some degree. But if we feel we must place them in one layer, then it usually falls into the DB layer by default. Security is another case where the problem spans multiple levels, especially if you're taking advantage of method-level security (and you really should be).

Social integration is another thing that conceptually spans many layers. The API bindings are more of an integration activity and thus best fit in the "cylinder" or DB layer (where "DB" really is just a generic term for integration points where a relational DB is just a common form of integration). But the connection process is certain a web-layer activity, so it fits in the web layer. The lines here are clear, right? Well, no, not really because you configure Spring Social in one place (otherwise, you'd end up duplicating configuration). Therefore, we arrive at your question: Where does the configuration go?

When faced with something that spans multiple layers, I tend to remember that many architecture diagrams aren't as cut-n-dried as "box-arrow-box-arrow-cylinder" and that sometimes there are boxes sitting to the side that are taller and span multiple layers. In other words, I place that layer-spanning concern in its own "box". I would capture the social pieces of my app together as a separate "layer".

However, if I felt strongly compelled (or bound) to the 3-layers, I'd probably configure ConnectController and ProviderSignInController at the web level and everything else in the DB level. I could also argue for it to go to the service level, but that doesn't seem quite right to me, either.

But then again, as I said from the outset, I've not troubled myself too greatly in the context of Spring Social so don't take my thoughts/opinion as authoritative. I'm willing to continue this conversation to see if we can arrive at something more authoritative.

Thanks for the long detailed response.

Yeah, I had the exact same thought process. While for us there is really just two layers. Since the DB/Repo and Service layers all go into the same ApplicationContext instance. Personally, I would love for it all to be in one web project and such. But we have 3 web apps and 3-4 vert.x apps that will all have to reuse the same domain objects, then some share the same service and repositories, and only by splitting them up into separate jars can we make that manageable.

I am more compelled to keep the Social Web components on the web side and everything else in the all middle tier. Meaning db and service/repo combined.

By the way the video from SpringOne on the subject looks great. I know you speak a lot. I do too, but you have a much better style and approach to speaking than I do.

Thanks again.

Mark

Following the Spring Social Showcase. Well actually straight copy/paste. SimpleSignOnAdapter and DisconnectController will not import. I have Spring Social Web - which brings in core, and Spring Social Twitter and Facebook in my pom file.

Thanks

Mark

So I had to create my own implementation of SignOnAdapter. But I still cannot find DisconnectController. It do not find in it the JavaDocs for Spring Social either. in 1.0.x and not in 1.1.x javadocs.

Where is it?

Thanks

Mark

DisconnectController is part of Spring Social Facebook Web. That's because (as far as I know), Facebook is the only provider that offers a callback to a custom app when a user severs a connection on Facebook. It's also only available in Spring Social Facebook Web 1.1.0.M1 and the latest snapshots.

Thanks. Also just realized that I don't really need that functionality here.

Thanks

Mark