[
https://issues.apache.org/jira/browse/DEFT-142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13073033#comment-13073033
]
Michele Zuccalà commented on DEFT-142:
--------------------------------------
I've problems to apply the patch, but I think that is very cool.
My only suggestion is to modify the RequestHandlerFactory#cloneHandler method
with something like that:
if (handler != null) && !(handler instanceof ISomeInterface) {
try {
return (T) handler.clone();
} catch (CloneNotSupportedException e) {
logger.error("Could not clone RequestHandler", e);
return null;
}
}
return handler;
in this way, the developer can choose if the RequestHandler object must be
cloned, or can be safely always the same, simply adding an interface to its
implementation of a RequestHandler.
> 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
>
>
> 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
