1) Support specifying a different name or location for filters.xml within the classpath. Currently if you set a path in jspwiki.properties it always interprets it as an absolute path file system. What I want to suggest is to keep the order of search (WEB-INF then classpath then file system) even if there is an entry in the properties file.
This should be fine - I see no issues with this.
2) Make the scanWikiLinks method in WikiEngine public. That way it's easier to use this feature from outside the engine to generate lists of outgoing or incoming links
I am uncomfortable with this. I would rather remove methods from WikiEngine for now than to open new methods.
Using the JSPWikiMarkupParser directly is probably a better option until we have a better API.
3) Support disabling the creation of threads per wiki engine. In our case we may have hundredths of wiki engines (or more) at the same time and the lucene indexing is done else where anyway. So for performance reasons, it would be great to be able to avoid the creation of those threads.
This should be pretty easy to do - if you don't need Lucene, write your own SearchProvider which does not spawn any threads. You can even use the BasicSearchProvider, which does not index anything.
So Lucene should not be a problem - and for performance reasons you probably don't even want to enable it if you have multiple WikiEngines running anyway.
4) Allow creation of external PageProviders and SearchProviders that are not in the com.ecyrd.jspwiki packages. Although it's possible to use that package in external JARs it would be much cleaner to be able to specify your own package in the jspwiki.properties property.
Um. it is entirely possible already. You just put in the full class name (e.g. com.mycompany.jspwiki.ourextensions.OurPageProvider). If the class is not found, we'll append "com.ecyrd.jspwiki.providers" in front of it and try again.
You should never use com.ecyrd.jspwiki for your own packages. /Janne
