Hi Caleb/all, On 6 Feb 2014 at 01:24:38, Caleb James DeLisle (cjd@hyperboria.ca(mailto:cjd@hyperboria.ca)) wrote: It’s never been a requirement of the action module itself. However, and maybe this is what you mean, some Action implementations will be dependent on the environment (to write to the servlet output stream for example). Said differently: * xwiki-platform-action is a standalone module with just a dependency on xwiki-platform-resource * the Action implementation components will be scattered in the various modules that require them ** Right now all old type Actions are in oldcore so we'll need to decide if we continue putting the new ones there or elsewhere). ** I’ll use a new action to add support for webjars (a “webjars” action) which will be located in the new xwiki-platform-webjars module I’m working on. Right now, my first step is to have the action framework committed and a first action done in webjars. A second step will be to try rewriting an existing XWikiAction to the new framework. This is where we’ll start having the debate of whether to go through the Container module or not and the consequences… :) Does that sound alright to you? Actions are independent of URLs. The way I’ve designed it so far is: URL comes in —> ResourceFactory generates a Resource our of it —> ActionManager finds the right Action to execute it. Technically the ResourceFactory is just an interface and the ResourceFactory implementation that accepts a URL and generates a Resource is located in the xwiki-platform-url module, itself delegating to xwiki-platform-url-standard which implements the “standard” URL scheme (and it’s possible to implement other URL schemes and the scheme used is configurable in xwiki.properties). I’ll need to do a nice diagram for all this to make it simpler to read and post it on xwiki.org ;) Thus, from the Action module POV, it can handle any type of Resource, be them REST, Entity, Skin resources, Template resources, etc. It’s up to the URL module to know how to generate a Resource object from all URLs. Well, right now we have the Struts Servlet and all our mappings in web.xml go through it. I’d rather not invent a new mapping and have to change all the URL parsing code. ATM having a new servlet would be the only way I know of making it independent. However there are 2 additional issues: - issue 1: we need servlet 3.0 first to be able to install new Servlet just by dropping a JAR in WEB-INF/lib - issue 2 (the most important one): servlet 3.0 are not dynamic so they wouldn’t be able to be installed as XWiki extensions. Thus the best answer is still to have a single XWiki Servlet and from then on, only use XWiki components which makes everything else installable from EM. I need to research it a bit more but maybe what we could do is this: - introduce a new servlet and make the current mapping go through it (instead of the struts servlet) - handle new actions in this new servlet - whenever an action hasn’t been handled, forward to the struts servlet I need to try this out. Simple is Servlets for me. This is what everybody knows in the Java world and can deploy to. It would do a lot of harm to not provide it IMO. Regarding node.js I don’t see how we would run our Java code in it ;) Servlet is really the simplest of the Java EE specs. I don’t feel that they are too heavyweight. In any case, if in the future another technology arises in the Java world we could easily switch if we make sure to go through our Container code... Yep, let me push a first impl in a branch and we can talk more about the details. I’m keen to ensure that my first design covers the maximum of use cases and I’ll need your help to verify this! Thanks Caleb -Vincent