[
https://issues.apache.org/jira/browse/SHINDIG-641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12637110#action_12637110
]
Adam Winer commented on SHINDIG-641:
------------------------------------
I'll add the "what to do after you sync" to this issue.
You already don't need to subclass to configure: see the provider that adds
SampleContainerHandler. There's no subclass of DefaultHandlerDispatcher.
On the numbered comments:
1. Will do, Standard is a more accurate description.
2. The default constructor cannot be a helper static - it needs to be an
@Inject so that it can be used as a default implementation. I can change the
existing private constructor taking the map to public, though the class hardly
does much when used that way.
3. There's already addHandler(String, Provider)
4. Woo-hoo!
I agree that SampleContainerHandler should not be depended on by
SocialApiGuiceModule. Looks like a separate issue, though - the dependency was
already there.
I'm not that enthused with exposing Provider in the HandlerDispatcher API, as
it makes the API less minimal, and anyone that wanted to be really lazy about
getting the handler can just be lazy about calling the HandlerDispatcher.
> Simplify DataRequestHandler dispatching
> ---------------------------------------
>
> Key: SHINDIG-641
> URL: https://issues.apache.org/jira/browse/SHINDIG-641
> Project: Shindig
> Issue Type: Improvement
> Components: RESTful API (Java)
> Reporter: Adam Winer
> Priority: Minor
> Attachments: shindig-641.patch
>
>
> SHINDIG-638 cleaned up DataRequestHandler creation, but still left us with a
> HandleProvider API that you need to subclass to manipulate, and that also
> codifies a service-name-to-handler Map as the dispatching mechanism.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
