[
https://issues.apache.org/jira/browse/JSPWIKI-566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14292442#comment-14292442
]
David Vittor commented on JSPWIKI-566:
--------------------------------------
Thanks for sharing the code fragments. I have been thinking about doing this
rewrite to use the Mootools library, as I agree with you that the error
handling needs to be better, and the "post" method with parameters is much
safer for core JSPWiki (although being a fan of open source REST GET requests
are more transparent, and easier to debug :) ). I've also been wondering if I
should use some sort of URI parser, e.g..
*
http://stackoverflow.com/questions/17840512/java-better-way-to-parse-a-restful-resource-url
With the code you've provided all I need to do is read the method param in the
WikiAjaxDispatchServlet, split it based on the "." and then invoke the right
servlet / method based on the function name, passing in the parameters. I've
been looking at the *ClassUtils* and the *SimpleMBean.findGetterSetter()* which
might be able to do the necessary reflection for us.
The other option would be to use custom java annotations like this tutorial, to
register which methods could be called.
http://www.mkyong.com/java/java-custom-annotations-example/
But all this will take a little time, and so has to be done incrementally, one
bit at a time.
> AJAX server-side rewrite
> ------------------------
>
> Key: JSPWIKI-566
> URL: https://issues.apache.org/jira/browse/JSPWIKI-566
> Project: JSPWiki
> Issue Type: Improvement
> Components: Core & storage
> Affects Versions: 2.10.1
> Reporter: Janne Jalkanen
> Assignee: David Vittor
> Attachments: ajaxDispatchServlet.patch, ajaxFunctions.patch,
> ajaxFunctions.patch, ajaxFunctions.patch, ajaxFunctions.patch, test.html
>
>
> The AJAX library we're currently using is a bit problematic, as it stores
> non-serializable stuff in the HttpSession (causing all sorts of nasty
> exception reports in default configurations of Tomcat, and preventing
> clustering). It does provide a very nice, reflection-based interface so that
> we can expose any class/method as a JSON endpoint, but this does not really
> work well with our auth system.
> We should replace the jabsorb stuff with a Stripes-native solution (possibly
> with some extensions to allow particular beans to expose methods as if we
> were using jabsorb).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
