[
https://issues.apache.org/jira/browse/DEFT-142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13072800#comment-13072800
]
Johnathan Meehan commented on DEFT-142:
---------------------------------------
> In other words, if the developer map, a certain type of RequestHandler, Deft
> creates new clone of that, otherwise use the same.
Right. What I was thinking was along the lines of providing a genric
"StatusRequestHandler" that would replace the current concrete, internal
request handlers. I create a Map of HTTP status codes (from an enumeration) and
associated request handlers and populate during startup. Then I extend the
factory we have with a new method that pulls from the Map - where null, create
a new instance of the generic handler with the status code passed to it; where
available, return the set handler. Seems to be working okay so far, so I think
I will complete that work as part of this requirement and we'll see what the
thoughts are when it's finished.
> Dynamic creation of RequestHandlers
> -----------------------------------
>
> Key: DEFT-142
> URL: https://issues.apache.org/jira/browse/DEFT-142
> Project: Deft
> Issue Type: New Feature
> Assignee: Johnathan Meehan
> Attachments: deft-142_clone.patch, deft_142_reflection.patch
>
>
> The outcome after a discussion with github.com/inferno-:
> (In the current design) it's volatile to have fields in user defined
> RequestHandlers in conjunction with asynchronous calls. (intermediate request
> (to same RH) could change the state of the RH)
> We should investigate the performance impact for dynamic creation of RH.
> Proposed solution:
> 1, Map<String, RequestHandler> => Map<String, Class<RequestHandler>>
> 2, Application.getHandler should create the appropriate RequestHandler using
> reflection.
> 3, UT / benchmark
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
