[
https://issues.apache.org/jira/browse/JSPWIKI-566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14142807#comment-14142807
]
David Vittor commented on JSPWIKI-566:
--------------------------------------
I've thought about my patch here more, and there is more work to be done - as
always....
* 1. I've implemented my patch using the META-INF/services framework, but I've
just noticed that the framework used by JSPWiki is it's own
resources/ini/jspwiki_module.xml. I'm thinking I should update this patch to
use a consistent framework. This means plugins just need a new parameter in the
jspwiki_module.xml to state that they are ajax_enabled (i.e. extend
HttpServlet).
* 2. However this then means that the AJAX framework is only available to
plugins. However core wiki functionality still has need of ajax, so I need to
add a "global" set of HttpServlets, configured, somewhere (maybe in
jspwiki.properties).
* 3. Then I get to the same challenge in the original RPC framework, do I give
plugins access to the "global" ajax functions or not? Do I create two ajax
service "lists" (bridges), one for global, and one for all plugins? Or do I
create one for global, and a unique one per plugin, so there is no "cross ajax"
from one plugin to another? Tricky... I'm thinking I'll go with the one global,
and one for all plugins.
> 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: 3.0
> Reporter: Janne Jalkanen
> Attachments: ajaxDispatchServlet.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)
