What's the best way to change or override the @RequestMapping URL for ProviderSignInController or ConnectController? They seems to default to "/connect" and "/signin", but I would like to use a different path (e.g., "/social/connect" and "/social/signin").
I tried extending these classes and defining a new @RequestMapping, and this works -- however, the old URL's still resolve (e.g., "/connect" still resolves).
I read your first paragraph and thought immediately of what you tried in your second paragraph. Sounds like that works, but you'd like for the default @RequestMapping to not work in that case.
Unfortunately, there's not an easy answer for that right now. I can't speak to the details of it, but I've heard whispers of something coming in Spring 3.2 that might make it possible to change it more easily, but I've not had a chance to explore it yet. And, of course, that'd be a Spring 3.2 feature and wouldn't work with Spring 3.0 or 3.1.
One thing you *could* do, although it would probably be more trouble than it's worth, is to create a custom handler mapping adapter that allows you to override what's defined in @RequestMapping...but again, that may not be worth the effort.
Another option is to create your own ConnectController and ProviderSignInController that is a fork of the existing ones, and just change the @RequestMapping. I fully agree that is not the ideal choice, but it is one that is available.
You might want to vote for https://jira.springsource.org/browse/SOCIAL-195. We created this issue a long time ago to track this exact improvement. But we never came up with any solid reason why anybody would want to change the path (and haven't heard too much about it since then until today). Would you mind following up on that issue with a comment explaining your motivation for customizing the URL? I can't say when/if I'll address it, but your comments there might help us understand the use case that demands it.
Thanks, I posted a comment in https://jira.springsource.org/browse/SOCIAL-195
I've got the same requirements for the very same reason as stated in David's comment to #SOCIAL-195.
Regarding a solution, maybe it's possible to split the actual implementation of the controllers from the mapping? So the implementation could easily be extended with a custom request mapping which simply delegates to the actual implementation.
For me it would be enough to control the URl-prefix (e.g. "/connect/"), hence another option may be to keep the method-level RequestMappings but configure the class-level mapping via a SimpleUrlHandlerMapping or BeanNameUrlHandlerMapping. But this may be impossible with the new RequestMappingHandlerMapping of Spring 3.1 if I understand it right (see section 16.3.2.1 of the documentation) - bummer!
The bulk of ConnectController and ProviderSignInController's main functionality is already extracted into ConnectionSupport. So you could always write your own controller with its own mappings.
That said, there's still a lot of controller-specific code in both of those controllers. I suppose both of the controllers could be extracted into an annotation-less form of themselves with a new very thin annotated controller class delegating. Then you'd only need to create a custom annotated controller class to change the mapping. That's something worth considering.
I'd also want to consider what Spring 3.2 offers that might address this. I'll consider both options and see what I can come up with (probably in the 1.1.0.M3 timeframe, although I've not yet planned out the details of M2 or M3).
I ended up with a custom version of both controllers since my requirements are too different as it seems, especially with the ConnectController. Maybe those two controllers should be seen as pure examples and not as a part of the API. But then the question arises, what parts of the spring-social-web module _are_ part of the API?
For example, there's no method to add a ProviderSignInAttempt to the session and ProviderSignInAttempt.SESSION_ATTRIBUTE is package private, so I had to duplicate this constant and hope that it doesn't change in further releases. Other issues are the handling of unknown provider-IDs in the controllers or the error handling in ConnectSupport (e.g. NPE if oauth_token is not found), so if those classes are part of the API I would create JIRA issues but if not I would create custom implementations and don't use the spring-social-web module at all.