July 11th, 2002 NiiloNeuvo#

Plugins identifying users#

A plugin has no way of knowing who the (authenticated) user is. http://www.google.com

JanneJalkanen: True. WikiContext should definitely have an UserProfile attached. WikiContext should have a lot of other things as well... But this is to be considered in 2.x. As a temporary fix, you can add getCurrentUser(), setCurrentUser() -methods to WikiContext, then set it in Wiki.jsp (example code is in LeftMenu.jsp).

ebu: Additional note - *CurrentUser() should probably support java.security.Principal to tie in neatly with container authentication systems. (Even that won't solve anipa's and my little problem - some custom wiki parts need to authenticate the user to a third party, thus retaining the password.)

JanneJalkanen: Perhaps UserProfile should implement Principal? We need to support four conditions: no authentication, cookie-based authentication, container-based authentication, and totally custom authentication.

Refactoring text: See DrawingPlugin

Inspired from http://snipsnap.org (wiki written in java), how about a plugin to show current month calendar, and with each date having a link. This link is configurable thro' parameters. Example

Just current month calendar, with each date pointing to recent changes of that particular date. [{INSERT Calendar}]

Of a specific month, [{INSERT Calendar month=11 year=2002}]

Each date, when clicked will automatically create a new page with that date as the page heading, very very nice for blogging. [{INSERT Calendar usage=AutoCreate}]

Other usage, parameters can be. [{INSERT Calendar usage=Traffic}] Can point to web log. [{INSERT Calendar usage=AutoCreate append=Todo}] Create with page heading as 'Todo 11-25-02'

Yes, is doable. I'll do it if I get the time, and if someone sends me a plugin, I won't say no :-). --JanneJalkanen

Would this help?

-- PaulDownes, 12/05/2002 (learning Java, still on Ch.2 of O'Reilly's "Java In A Nutshell" after 12 months)

As of today (08-Jan-2003), there is a (very simple) CalendarTag in JSPWiki. It's a tag because it is sort of more logical to be a tag, and since it's such a huge thing, you probably want to have a bit more control over its rendering and placement anyway. Also, doing things like switching a month is a bit awkward right from inside plugins.

Plugin pooling#

Hm.. scanning through the PluginManager code, looks like each Plugin is newInstance()'d. Is there any reason not to use a simple pool to speed this portion up?


Nope. No reason other than that I never imagined that some people would be using the plugins so extensively that there would be a need to do pooling... :-) Having said that, a generic object pool for plugins and TranslatorReaders might be cool to have.


See what happens when you let old Perl coders play on a JSPWiki? I wrote a very simple keyed pool singleton for other purposes; might as well include the sources in JSPWiki. (We could use the Jakarta commons pool, but it's sort of fancy for our simple needs here.)


This is actually dearly needed now in an another wiki, with over 200 plugins on one page. So I guess we need to do something about this soonish :-).


Sounds like some bigger undertaking both of you are thinking of. What's wrong with having a simple HashMap to store the instances and a strict rule of only one plugin-instance per WikiEngine, i.e. PluginManager? I can't think of a good reason to pool this like threads or DB-connections.

-- Torsten

Thread Safety. If Plugins are singletons, no params information should be ever stored in the instance, and the HashMap you speak about should pass the params in every request. Either this, or the execute method should be synchronized to avoid concurrency issues.


I changed the implementation of GoWiki, so there isn't that much of a pressure any more to pool plugins.

As long as none of the plugins use their own instance variables to use any persistent state, then it is quite possible for a plugin to be handled like TorstenH suggests. However, I would not like to bind the developer's hands in that respect - I've found that in certain cases having the plugin cache information can be a very good idea (for example, think about an RSSAggregatorPlugin, for example).

While the VariableManager could be used by plugins to store any information worth caching, then you get into some thread safety problems. The other problem related to caching is that VariableManager will keep the references indefinitely in memory, releasing the memory ONLY when the JVM exits, or someone explicitly deletes them. I would find it a far better solution if each plugin would handle their own caching (or perhaps through some kind of a cache helper system), so that, for example, when all instances of a plugin are purged, all of the information cached for them is purged as well.

'tis a complex issue.


An attempt to sum up the discussion from above. Hopefully not too heavily biased :-) --Torsten


  • avoid plugin-creation for each plugin invokation
  • how to preserve state between wiki runs

Relevant issues:#

  • performance/scalability
  • how to pass persistent state
  • ease of use (not having to worry about thread-safety)

Possible solutions#

New instance for each invokation (current solution)


  • no additional sync-issues when using instance variables for per-request state
  • no additional implementation needed


  • cost of creating a new object for each plugin-invokation
  • no defined way to pass data between plugin-calls/multiple instances
  • instance variables only usefull for transient state

Single instance with synchronized execute()-invokation


  • instance variables can be used to store transient (i. e. per-request) state or persistent state without additional sync-issues
  • easy to implement
  • additional runtime cost is just accuiring a lock
  • creates a bottle-neck for frequently used and/or long running plugins

Single instance per plugin and WikiEngine


  • easy to implement
  • runtime cost only a HashTable lookup
  • instance variables can be used to pass state between invokations
  • user can opt for synchronizing execute() if ease-of-use is more important to him than scalability


  • instance variables only useful to pass state between invokations (access requires synchronization)
Object Pooling


  • only a few plugin-instances exist
  • doesn't require a lock for very long


  • runtime cost to maintain the pool
  • no defined way to pass state between invokations

February 25th, 2003 -- MichaelGentry#

Add date/time format to RecentChanges plugin?#

Could we add dateFormat and timeFormat parameters to the RecentChanges plugin? Seems like this would be fairly easy to do instead of hard-code them into the plugin source code (still keep the default values, of course). What do you think?

PS. I really need to get the source code setup here so I can tinker ...

Wow, someone is reading my mind. I was just thinking the same thing earlier today. A good way to do this would be to use i18n for locale dependent date formats. Of course, all users would see dates in the locale of the server, so the next step after that would be to get the user's preferred locale and then display the dates in that format. (boy, would that be a lot of work to get working...authentication and an i18n framework). Hmm, can you guess the locale from looking at the http request? --KenLiu

ServletRequest provides the two methods getLocale() and getLocales() based on the Accept-Language header a client sends. -- Torsten, 2003-03-02

Would be a good user preference, as just I've noted in Ideas User Preferences.

Interface for Plugins with WikiMarkup output#

Looking at current Plugins some contain code to convert WikiMarkup (their actual format) to HTML before returning. This code should be moved to PluginManager and a Plugin producing WikiMarkup instead of HTML should be marked to implement some methodless interface to signal this. Any thoughts?

-- Torsten, 2003-03-02

There is already WikiEngine.textToHTML(). I don't know whether it would really make the code any easier or simpler to have the PluginManager do decisions based on the interfaces the plugin class implements.

AbstractReferralPlugin uses its own method to do the conversion so that it can manipulate it in a special way, so this interface would not be of much help anyway.

-- JanneJalkanen, 03-Mar-2003.

Main benefit would IMO be to allow Plugins independent of an output format.

-- Torsten, 2003-03-03

But wouldn't a plugin have to know anyway what kind of stuff it outputs? Why would you then need a plugin that can be output format independent?

-- JanneJalkanen, 04-Mar-2003

I'm thinking of plugins like ReferringPages or IndexPlugin. These could well live with the capabilities of WikiMarkup (especially if we can create custom div sections in WikiMarkup). A more fancy layout/ advanced features of course can't be done with it.

-- Torsten, 2003-03-04

2003-Mar-13: Templates for Plugins? (Originally: ListLocksPlugin is missing StyleSheet information)#

  • Apache Velocity

We use Apache Velocity for our plugins. All plugin classes do is call on the Velocity engine to render the appropriate template. If you want to find out more about how we do this, contact KrisRead or ThomasChau.

  • JSPWiki v2.0.29-cvs

The ListLocksPlugin doesn't specify the "wikitable" stylesheet for the TABLE tag, so if you use it on the information page (or another page with tables), it won't look the same as the rest of the tables (assuming you've modified the CSS like me). Should be an easy fix. :-)

I know, I really need to get setup to edit the code/etc ...



Um. Let me go back on this. It actually specifies a "listlocksplugin" table. You should probably set that one to look the same as a wikitable. The code it generates looks like this:

<table class="listlocksplugin">
-- JanneJalkanen

Hmmm ... I can certainly do that, but let me use that as a segue to another topic (which I can't remember if it has been brought up here before -- probably has). I prefer systems that use Model-View-Controller as much as possible. It seems to me that there is a fairly nice separation in the current system between the Model (the code in JAR), View (the templates), and the Controller (the top-level JSPs that load in the template). However, with regards to the plugins, the View and Model are combined. It seems to me it would be nicer if the plugins could somehow pull their view out of a JSP in the templates directory or something similar. I guess I just don't like Java generating HTML ...

This should probably be re-factored somewhere, but any comments?



I think PluginDevelopment would be the correct page for that...

May 8th, 2003 - non-unique plugin parameters?#

The capability to provide several values with one key is useful in some WikiPlugin applications. (Think of a Plugin that can be given e.g. several operation instructions:

 [{MyPlugin op='foo' op='bar' op='xyzzy'}] 
might chain operations bar and xyzzy to foo, providing something interesting and useful. The option, something like
 [{MyPlugin op.1='foo' op.2='bar' op.3='xyzzy'}] 
seems, to me, much more cumbersome from a user's perspective, prone to confusion ("When do I use dot-numbering?"), and errors ("Oops, forgot to decrease all numbers by one after I removed one parameter.").

A patcch providing this functionality exists, but you probably don't want to apply it, since it requires a change in the WikiPlugin interface.


12-Sep. 2006 - Plugin Cookbook#

I've set up a Plugin Cookbook

--Christoph Sauer

This was really helpful; thank you!

I'm doubtful about the instructions for creating a new wiki page programmatically; the WikiEngine requires a context, which it uses to identify the page. I think you have to create a new context and set the pagename and real pagename for the WikiEngine to be able to instantiate the new page via saveText(...). And if you do it directly, via the page manager, instead, you end up with a page the rest of the site doesn't know about. Given the dependence on constructing the context correctly, I'd really like to see the WikiEngine have a call in which you provide a pagename as well as a context, so new pages can be created or updated by old pages.

--Jerry Andrews

Constructing the context via new WikiContext() is fine.

If you already have a WikiContext, you can also call WikiContext.clone(), then call setPage() on the new WikiContext and then use that.

-- JanneJalkanen

Category Ideas

Plugin and new JSPWiki Version?#

Hey, i changed few Classes in the JSPWiki core (for example in the Blog-Plugins) for my internal wiki.

What should i do now, if i want to change to a new wiki Version?... i Know all my changes gone if i replace the old jspwiki.jar ... but i there any "best practice" how to make my changes persistent or how to add them easily again?

Thanks for AnswerMe!

- MartinU 11. Mai 2007 - 02:00 PM (GMT+1)

Don't change plugins: copy the code and make your own version (e.g. MartinUWeblogPlugin). You can also consider contributing the code back to us, if you think it would be useful to others as well.

-- JanneJalkanen

Thanks for your answer Janne, but what happens if a newer JSPWiki Version uses a newer Version of "WeblogPlugin" and my own Old "MartinUWeblogPlugin" dont runs with the newer JSPWiki-Version? Is there a possibility to "Patch" this .java Files easily?

-- MartinU 04. June 2007 - 06:50 AM

The ReferenceManager acquires a list of links to other pages, but as far as I can tell, there's no programmatic way to find out the list of plugin links (i.e. [{...}]) other than to parse the page yourself. I'll post code here for doing that, once I've written it, but wouldn't it be nice if the ReferenceManager could do it for us?

-- JerryAndrews

Well, it's an option. Could you file an idea for it?

(The easy way is of course to take the DOM tree and simply grab the plugin nodes off it using XPath...)

-- JanneJalkanen

I don't see any way to get the DOM tree without reparsing the whole document; am I missing something? The RenderingManager's method to retrieve the (possibly cached) tree is protected, and I can't see how to get the RenderingManager in any case.

-- JerryAndrews

You're correct, you do need to parse the page. But you can, after that, keep your own cache and subscribe to page change events.

--JanneJalkanen, 02-Jun-2007

Turns out, the existing PluginContent object which the JSPWiki parser puts in the DOM tree doesn't have any methods to query the object -- you can't find out what it is, only what its output is. So I'm back to writing my own parser. I added the suggested idea, though. And added a suggestion that PluginContent expose the plugin parameters.

-- JerryAndrews, 02-June-2007

Add new attachment

Only authorized users are allowed to upload new attachments.

List of attachments

Kind Attachment Name Size Version Date Modified Author Change note
calendar_on.gif 0.5 kB 1 07-Feb-2003 19:17
« This page (revision-42) was last changed on 05-Feb-2009 16:31 by