Suggestions to facilitate the integration of JSPWiki's engine

[Jorge Ferrer <jf...@liferay.com>]

Hi all,

As I've mentioned in another email, I've been working lately in
integrating JSPWiki's engine as the engine used in Liferay Portal. The
integration has already been done and is available in Liferay's svn at
sourceforge (in case someone is interested) and I'd like to make some
simple suggestions that could ease this type of integration for
others. I'll be glad to contribute with a patch for each of these if
JSPWiki's developers like the ideas:

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.

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

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.

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.

What do you guys think?

BTW, I have some notes that I've taken during the integration. I'd be
glad to copy them to the wiki so that they can be helpful for other
people wanting to integrate JSPWiki's engine. Do you think that would
be interesting?

Regards,
Jorge

-- 
Jorge Ferrer
Software Architect
Liferay, Inc.
Enterprise. Open Source. For Life.

Re: Suggestions to facilitate the integration of JSPWiki's engine

[Jorge Ferrer <jf...@liferay.com>]

Hi Janne,

I need them because I'm using the CreoleFilter which converts the
Creole type of links into JSPWiki type of links

Regards,
Jorge

On Feb 5, 2008 9:57 PM, Janne Jalkanen <Ja...@ecyrd.com> wrote:
> > That's a good point. Although using JSPWikiMarkupParser would force me
> > to copy the code to invoke the filters from WikiEngine. Isn't there a
> > middle term solution?
>
> Why would you need filters if all you're interested in are links?
>
> /Janne
>



-- 
Jorge Ferrer
Software Architect
Liferay, Inc.
Enterprise. Open Source. For Life.

Re: Suggestions to facilitate the integration of JSPWiki's engine

[Janne Jalkanen <Ja...@ecyrd.com>]

> That's a good point. Although using JSPWikiMarkupParser would force me
> to copy the code to invoke the filters from WikiEngine. Isn't there a
> middle term solution?

Why would you need filters if all you're interested in are links?

/Janne

Re: Suggestions to facilitate the integration of JSPWiki's engine

[Jorge Ferrer <jf...@liferay.com>]

Hi Janne,

Thanks for your answer. I've aded some comments below...

On Feb 4, 2008 9:49 PM, Janne Jalkanen <Ja...@ecyrd.com> wrote:
> > 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.

Ok. I'll send a patch through JIRA.

> > 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.

That's a good point. Although using JSPWikiMarkupParser would force me
to copy the code to invoke the filters from WikiEngine. Isn't there a
middle term solution?

> > 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.

Yeah, I already did that. I have my own SearchProvider that does
nothing. I was under the impression that it was still creating
threads, but I'm glad to know it's not :)

> > 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.

Great, the note in the jspwiki.properties file confused me. I've
changed the package and works. Thanks for the tip.

> /Janne


Regards,
Jorge

-- 
Jorge Ferrer
Software Architect
Liferay, Inc.
Enterprise. Open Source. For Life.

Re: Suggestions to facilitate the integration of JSPWiki's engine

[Jorge Ferrer <jf...@liferay.com>]

Hi Janne,

On Feb 4, 2008 9:49 PM, Janne Jalkanen <Ja...@ecyrd.com> wrote:
> > 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.

I've just submitted a patch to https://issues.apache.org/jira/browse/JSPWIKI-178

Regards,
Jorge

-- 
Jorge Ferrer
Software Architect
Liferay, Inc.
Enterprise. Open Source. For Life.

Re: Suggestions to facilitate the integration of JSPWiki's engine

[Janne Jalkanen <Ja...@ecyrd.com>]

> 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