Announcement Announcement Module
No announcement yet.
ConnectionFactoryRegistry woes Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • ConnectionFactoryRegistry woes

    Hi all,

    I'm POCing some functionality in our Spring 3.0.2 based app against Spring Social and running into issues with the ConnectionFactoryRegistry. In this block:

    public void addConnectionFactory(ConnectionFactory<?> connectionFactory) {
    		if (connectionFactories.containsKey(connectionFactory.getProviderId())) {
    			throw new IllegalArgumentException("A ConnectionFactory for provider '" + connectionFactory.getProviderId() + "' has already been registered");
    		Class<?> apiType = GenericTypeResolver.resolveTypeArgument(connectionFactory.getClass(), ConnectionFactory.class);
    		if (apiTypeIndex.containsKey(apiType)) {
    			throw new IllegalArgumentException("A ConnectionFactory for API [" + apiType.getName() + "] has already been registered");
    		connectionFactories.put(connectionFactory.getProviderId(), connectionFactory);
    		apiTypeIndex.put(apiType, connectionFactory.getProviderId());
    the line calling GenericTypeResolver.resolveTypeArgument is consistently returning null for both the FacebookTemplate and TwitterTemplate instances passed to them.

    GenericTypeResolver doesn't look like it has changed in quite a while, so the only thing that I can think of is that our AspectJ LTW step is somehow messing with the generics info?

    Any ideas are appreciated.


  • #2
    It looks like the doResolveTypeArguments method changed somewhere after 3.0.2, so that this works as expected in 3.0.5 but doesn't in 3.0.2.

    As much as I'd love to upgrade us to Spring 3.0.5 this may end up being a non-starter if I end up having to do extensive patching to get it to work with 3.0.2


    • #3
      Well that's not good. You might want to consider writing your own ConnectionFactoryLocator implementation that suits your needs, adapting code from (or extending from) the default implementation. That's one reason we provide well-defined extension points like these. In general, we won't be seeking to workaround bugs in 3.0.x versions unless absolutely necessary (though if you do come up with something you feel would benefit the community overall, I encourage you to submit a pull request).

      Now that I think about it, we can also consider refactoring our implementation to isolate the generic call by delegating to a addConnectionFactory(Class<?>, ConnectionFactory) hook after the type has been resolved. If you get started on that before we do, please do submit a pull request with the change to the existing impl you need. Github empowers you to get what you want out of the code, which is really liberating and a lot better than the old days where all we had for collaboration was JIRA.

      Last edited by Keith Donald; Jun 27th, 2011, 07:04 PM.


      • #4
        Thanks Keith! At the end of the day we'll probably do the work to upgrade to 3.0.5 if we go further. For now I'm just patching GenericTypeResolver.