manual creation of template (overhead?)

[yonimoses]

Hi,

Does explicity creating a new Facebook/Linkedin/Twitter/Google template instead of using Connection<?> (provided by the repository) have certain overheads which I am not aware of?

I'm almost never use the request scope (beside login action) and I prefer to work with a more "stateless" approach (e.g - read the creadentials from the db and create a template when needed)

Cheers,
Yoni

[habuma]

If you happen to have the access token (and, if needed, the token secret) handy, you can always create the templates yourself. The only thing you miss out on is the automatic handling of the connection and creation of the API binding. You could also use the UsersConnectionRepository to give you a ConnectionRepository and from that fetch the API binding you need. It's just more work for you that way.

I can appreciate the desire to be stateless, but a request-scoped bean doesn't necessarily imply state. In fact, that's one benefit of being request-scoped instead of session-scoped, is that you get a per-user bean that doesn't survive between requests. It's not much different than if you had created that connection repository bean yourself on each request and then used it to create the API binding. The only real difference is that you didn't have to create it...Spring created it for you. Yes, it gets carried around in the request, but it only lives in the current request, not between requests. Therefore, it doesn't break the stateless approach you desire. Of course, it will create that bean on every request, even if that request doesn't need it. Maybe that's what you're striving for.

[yonimoses]

Hi,

First, thanks for the prompt reply.

I had to re-think the entire issue before I could write an answer..

regarding the request scope issue, though I think the design is pretty awesome, I hardly use them ,in-fact I use the only for social.

what happens when you inject a request scope to controller in the constructor? does spring creates a new controller upon each request? (or perhaps using some proxied object for the requested-scope bean?)

Your last sentence is what's bothering me.. creating objects upon each request is something I usually try to avoid.

that being said - you're right about the "more work" stuff, but when working in stateless mode, attempting to reduce session objects (for obvious cluster/serialization issues) the less objects you create, the merrier.

[habuma]

When you inject a request-scoped bean (or session-scoped bean) into the singleton controller bean, you are really injecting a proxy. Attempting to use that bean outside of the scope of a request will give you an error (I forget the specifics of the exception, but the message says something along the lines of "You can't do that because you're not in the scope of a request.)

If you don't want to create a connection repository on each request (or have Spring do it for you), that's your call. You are fully welcome to somehow determine who the user is and from that determine that connection they have and from that create an API binding object (e.g., FacebookTemplate). But that becomes *your* responsibility and as I said, it's more work. Because you're not maintaining state, there'll be nothing hanging around between requests to help you with that.

Again, none of the Spring Social stuff is in session. It's a mix of singletons and request-scoped objects. In that sense, it is stateless. The only thing that's maintained in session in any of the examples is the user (and that's because Spring Security's SecurityContextPersistenceFilter puts the current user context in session by default).

But, I do see your point: Perhaps there could be a singleton-scoped connection repository that could be used to retrieve the connection. Indeed, very very early Spring Social code had such a thing, but it pushed a *LOT* more work on the developer to manage the connections and retrieve the API binding. By pushing some things into request scope, it enabled the framework to handle a lot of the grunt work for you (which, is what frameworks are supposed to do).