Active development of JAMWiki has ceased, and bug fixes and support will be limited at best. If you are interested in taking over management of JAMWiki please send an email to the jamwiki-devel mailing list.

Tech comments:Plugin Interface

Redirected from Tech comments:addon

Plugin architecture

JAMWiki may eventually reach a point where it is best that some features be implemented as plugins (spellcheck, special parsing tags, etc). In this case some sort of generic plugin architecture will need to be designed.

Can I suggest looking into JSR 223 to make it possible to develop plugins in scripting languages like Groovy, Pnuts, JavaScript (Rhino), etc? That would probably make development of plugins significantly easier for busy developers. --Evan Prodromou 27-Jul-2006 18:41 PDT
Thanks! I've given zero thought to how plugins should be handled, but if there is a standard developing then that's definitely the way to go. I also like the idea that multiple languages could be supported. -- Ryan 27-Jul-2006 21:10 PDT
I'm no genius about the JSR 223 architecture, and I think there are a couple of competing standards (like the Jakarta BSF). One thing I've noticed about MediaWiki development is that there's a lot more energy going into the project now that we've got an extension mechanism half-working. Letting admins create their own functionality, sharing their plugins, and then cherry-picking the best of those plugins for inclusion into future releases of the core software seems like a great way to stimulate participation. So you might want to move pluggability into an earlier release. --Evan Prodromou 28-Jul-2006 07:46 PDT
The fact that plugins are an easier way for more developers to get involved is a key selling point, and I'll definitely give some thought to making plugins a higher priority. My biggest concern with implementing them is that I really want to make sure they're done right, since plugins mean supporting APIs, and at the moment I really like having the freedom to change and clean up code as improvements are made - the project is still very young, and the rate of change is extremely high. My thinking (now) is that items like a spam filter or block lists might be best implemented as plugins of some sort without advertising that JAMWiki has a plugin architecture, and with luck the experience gained from those implementations could eventually be generalized into something useful for other plugins.
Thanks for the feedback and encouragement, by the way. I'm hugely excited about this project, and it's pretty cool to see other people interested in it as well! -- Ryan 28-Jul-2006 11:05 PDT

For future reference, there are some plugin frmaeworks that might help:

  • Spring-IoC for which other modeuls are already used in JamWiki
  • The Java plugin framework is used by openQRM and Salomé
  • Plexus used by Maven
An simple (but ugly) attempt

For my installation I made an implementation for some kind of addons:

public class CustomJSPServlet extends JAMWikiServlet {
	private static final String SERVLET_MAPPING = "Special:JSP";
	private static final String JSP_FOLDER = "custom";
	protected ModelAndView handleJAMWikiRequest(HttpServletRequest request,
			HttpServletResponse response, ModelAndView next, WikiPageInfo pageInfo)
			throws Exception {
		String requestURI = request.getRequestURI();
		int pos = requestURI.indexOf(SERVLET_MAPPING);
		pos += SERVLET_MAPPING.length()+1;
		String jspName = requestURI.substring(pos) + ".jsp";
		pageInfo.setContentJsp(JSP_FOLDER + "/" + jspName);
		pageInfo.setPageTitle(new WikiMessage("topic.title", ""));
		return next;

By configuring this Controller in jamwiki-servlet.xml

 <property name="mappings">
     <prop key="/**/Special:JSP/*">CustomJSP</prop>


<bean id="CustomJSP" class="[packagename].CustomJSPServlet" />

I can easily call custom JSPs located in WEB-INF/jsp/custom, e.g. WEB-INF/jsp/custom/createuser.jsp is called via http://wikiserver/virtualwiki/Special:JSP/createuser with the advantage of displaying the content in wiki design and style.

I know that this is not that kind of plugin-achitecture discussed here, but it works perfect for me and perhaps anyone else can use it. --hp 08-Jan-2010 01:01 PST


Ryan we use to on mediawiki the goodies ( which allow us 'pretty print' c-shell via <bash></bash> tag, xml <xml></xml> tag, java via <java></java>

Do you plain to allow rendering extensions like this ?

This one seems a good candidate :

Or a javascript based ?

-- request originally submitted by Henri, copied here by Ryan

The Javascript-based highlighter looks like something that could be easily supported; I don't think it would ever become an official part of JAMWiki, but I could definitely make it easier to include external Javascript in JAMWiki pages if that would be sufficient. As to officially enabling rendering extensions, that is definitely something that will happen, but I'd like to make sure it's done well. Axel's Bliki project already offers syntax highlighting I think, so perhaps using his parser would be a way of getting the functionality you need until JAMWiki has evolved a bit more. -- Ryan 26-Sep-2006 09:38 PDT
Open extensions and plugin mechanism are what make Apache HTTP and Eclipse (and mediawiki) so successfull. You should keep them high in priority list Henri 26-Sep-2006 23:19 CET
I definitely understand the importance of having a good plugin / extension architecture, and would like to get something in place as soon as possible. The problem is trying to prioritize - I'd like to implement Mediawiki templates first, finer-grained user permissions also seem like a fairly critical feature, and a strong argument can be made that the ability to import/export to and from other Mediawiki sites would be of huge benefit. In addition, I don't have a strong background in writing plugin / extension frameworks, so I'll need suggestions from others on how they envision such a framework being done. Ideally someone who was sufficiently interested could take charge of this feature by soliciting feedback on the Feedback page, proposing a design, and then creating a branch in the Subversion repository and starting an implementation. Barring that, it will probably take a while for me to get to this item on the to-do list, although I'll try to get there as quickly as possible. -- Ryan 26-Sep-2006 14:55 PDT
In my opinion, now it is a high time to switch on mechanisms of additions. Besides, for the project, presence of the mechanism of additions (can be imperfect) better than its absence. The best, sometimes, the enemy of the good.--shar 10-May-2009 21:19 PDT