The reference manager is the JSPWiki class responsible for keeping track of wikipages' references to each other. It divulges information such as the Referenced by list in the default JSPWiki left menu, and the orphaned page list.

The current implementation of class ReferenceManager is simplistic; it goes through all WikiPages (and WikiAttachments) at startup (that is, the first access to JSPWiki after its container has been started) and builds a hash-based cross-reference list, which may take dozens of seconds of time. WikiPages added during run-time are included in the RM's tables, but it does not notice pages deleted at file system level. Since 2.1.25 it will, however, correctly detect pages changed at file system level (or database, if you're using one).

A faster solution would be nice. Options that come to mind are

  • a non-real-time trickle implementation (which would leisurely collect references after startup - perhaps confusing for users coming in too soon after startup)
  • state storage at shutdown, and verification when starting (with the assumption that changes in page structure during downtime are usually minor)

I suppose that the latter doesn't really make sense as long as we are manipulating WikiPages outside the JSPWiki interface.


Hmm... It might be possible to combine the two, and have the ReferenceManager update the saved state list lazily at startup. This sounds to me as the least-user-confusing solution.


I read the stuff about Lucene search with great interest. The solution is not that near. I tested Lucene some time ago to create a search index on our jsp pages. I know some features of Lucene and I went on thinking.

Lucene creates an index on everything you give it to eat. Best choice is to give it plain text. When you give Lucene this piece to eat, it is handled as a document. In addition to the stuff that should be index you can add as much attributes (self defined) as you want. Lucene stores this data in its index. That is filesystem. Accessing the index is very fast, very likely to a database.

You can retrieve documents from the index by fulltext search plus search for matching attributes. If you store the page name as attribute, you can get the document with all information from Lucene. It's in filesystem and you can maintaine the index on a per document base. As the ReferenceManager is notified for changes, it could initiate all neccessary stuff. At least you get a universal solution for some problems:

  • the data nessecary for the ReferenceManager is stored in filesystem,
  • you don't need to implement a store for this yourself,
  • if the Lucene index is present, it is not nesseccary to recreate it, startup is allmost immediately,
  • all data for full text search is present as well,
  • additional page attributes can be stored as well in the index for fast access, but must be stores primarily by the PageProvider because the index shall be regarded as a redundant cache,
  • other runtime stuff, like authorization information can be stored there (if this is usefull for performance resons).

Cleaning the index directory must trigger a rebuild (at startup / initialisation).

I first want to investigate the implementation of the ReferenceManager before starting to implement a demo.


June 3, 2004

I'm working on a implementing my fast java object database as a page provider and will also tie it into the ReferenceManager to ease startup times (for ReferenceManager) and search times (page provider) on large wikis. I'll keep everyone posted on the progress!


August 22nd, 2004

The boot speed of wiki isn't that bad now that reference manager doesn't load plugins at boot (we are running wikis with 10k+ pages and each page containing 5 plugins).

But things get bad when you try to update pages inside a wiki:

  1. Page is written
  2. Reference manager does a refresh (All plugins get loaded)
  3. Page is shown to user (All plugins get loaded)

Currenlty the invocation of plugins is a WikiEngine level setting. Plugin invocation is disabled at boot while the reference manager is getting initialized. The running of plugins needs to be a WikiContext level setting.

WikiEngine.scanWikiLinks() should create a context that would have a flag disabling plugin loading. Then the PluginManager should check this flag and decide what to do.

Niilo Neuvo

How do I reference an attachment on another page on my page? Is there some syntax?

--AnonymousCoward, 27-May-2008

It's treated as a kind of sub page. Simply create a link in the form [page/attachment.ext].

--FlorianHoleczek, 28-May-2008

Add new attachment

Only authorized users are allowed to upload new attachments.
« This page (revision-21) was last changed on 27-May-2008 10:09 by FlorianHoleczek