incubator-jspwiki-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From dexterz <>
Subject Re: Embedding JSPWiki 2.6 [into a spring web app]
Date Fri, 01 Feb 2008 12:09:39 GMT

I am trying to embed JSPWiki into my spring web app. What I want to achieve
is to be able to do something similar to EmForge. At the moment I am just
doing a simple integration.
I started following EmForge strategy as is. I...
1) Included all the relevant libs for JSPWiki in my web app's lib folder.
2) Defined a bean in spring application context xml . 
3) Added relevant java implementation files for the engine and page
4) Put file in my web app's WEB-INF folder.

When I try to bring my web app up with Tomcat I get the following error
Starting up background thread: JSPWiki Lucene Indexer.
Starting up background thread: WatchDog for 'EmForge'.
ERROR - AuthenticationManager.initialize(158) | Could not configure JAAS:
URL for JAAS configuration cannot be null.
FATAL - AuthorizationManager.initialize(424) | JSPWiki was unable to
initialize the default security policy (WEB-INF/jspwiki.policy) file. Please
ensure that the jspwiki.policy file exists in the default location. This
file should exist regardless of the existance of a global policy file. The
global policy file is identified by the variable. 
com.ecyrd.jspwiki.auth.WikiSecurityException: JSPWiki was unable to
initialize the default security policy (WEB-INF/jspwiki.policy) file. Please
ensure that the jspwiki.policy file exists in the default location. This
file should exist regardless of the existance of a global policy file. The
global policy file is identified by the variable. 

It does not matter whether I put jspwiki.policy file in the WEB-INF
directory or not. I still get the same error. In my properties file the
following properties are commented out.

Any idea what I need to do to get it going?

Janne Jalkanen wrote:
> Yup.  You can
> a) either set "" (turning off the entire security)
> b) replace AuthorizationManager with your own implementation by setting
>    <mapping>
>      <requestedClass>com.ecyrd.jspwiki.auth.AuthorizationManager</ 
> requestedClass>
>      <mappedClass>com.mycompany.mypackage.MyAuthorizationManager</ 
> mappedClass>
>    </mapping>
> in your ini/classmappings.xml.
> The latter is a largely undocumented feature, which was introduced in  
> 2.6.  It can be used to break JSPWiki very efficiently :-)
> the ini/classmappings.xml can be anywhere in your classpath, just as  
> long as it is before JSPWiki.jar (which ships with the default  
> implementation).  Check out the built-in classmappings.xml for more  
> information.
> Note that MyAuthorizationManager needs to either extend (if the  
> original file is a class) or implement (if the original is an  
> interface).  There are no real checks as to the integrity of the class.
> I have some ideas on how to make this integration process easier, but  
> haven't gotten around to experimenting with them yet.
> /Janne
> On Jan 4, 2008, at 08:21 , Ethan Larson wrote:
>> Ok, I created a dummy page provider and a dummy authorizer and I  
>> got a lot farther. I don't even need a MemoryPageProvider since I  
>> all I need is the output (thanks just the same Florian - it was  
>> instructive).  I actually got translated output.  The problem is  
>> that I had to modify the source code to do it.  I had to comment  
>> out line 532 of WikiEngine:
>> //m_authorizationManager.initialize( this, props );
>> As near as I can tell, there's no way to create an authorization  
>> manager that doesn't involve a jspwiki.policy under WEB-INF.   
>> However, since I'm running it as a standalone app, I don't have a  
>> web container and therefore no WEB-INF.  I could create this under  
>> the working directory, but I really don't want to put blank, unused  
>> metadata in my app.  Is there any way to configure this such that I  
>> can start the authorization manager without a jspwiki.policy?
>> On a broader note, I'd be over the moon if this were an easier  
>> process.  JSPWiki seems to be the most actively developed and  
>> feature-rich Java wiki there is, and has support for plugins and  
>> filters which I will eventually need.  If there were an easy way to  
>> run the wiki translation, complete with plugins and filters, that  
>> didn't involve a web container and any extra memory/disk usage, it  
>> could broaden the usage quite a bit.  I've looked at other java  
>> wiki translators out there, and none of them are doing a good job  
>> of the features/active development/ease of standalone combo  
>> (Radeox, Bliki, VQWiki to name a few).  Other forum/mailing list  
>> posts confirm there is a demand.
>> Thanks for all your help,
>> Ethan
>> P.S. -- Here's my current code for anyone reading this in the future:
>> Properties props = new Properties();
>> props.setProperty(PageManager.PROP_PAGEPROVIDER,  
>> MyPageProvider.class.getName());
>> props.setProperty(AuthorizationManager.PROP_AUTHORIZER,  
>> MyAuthorizer.class.getName());
>> WikiEngine engine = new WikiEngine(props);
>> WikiContext context = new WikiContext(engine, new WikiPage(engine,  
>> "test"));
>> System.out.println("output: \n" + engine.textToHTML(context, "this  
>> is a test\n\n* more stuff"));
>> MyPageProvider and MyAuthorizer are both empty implentations of the  
>> interfaces.  Just return an empty List for MyPageProvider.getAllPages.
>> Janne Jalkanen wrote:
>>> Yup, the problem is that there needs to be *some* kind of a page  
>>> provider, because the system needs to check if e.g. a page exists  
>>> or not when it encounters a link.  The generated HTML differs in  
>>> each case.
>>> A dummy provider will do just fine, e.g. the MemoryPageProvider.
>>> /Janne
>>> On Jan 2, 2008, at 00:23 , Florian Holeczek wrote:
>>>> Hi Ethan,
>>>> maybe this can help you:
>>>> Regards,
>>>>  Florian
>>>>> The problem with the page directory is that I don't want one. I  
>>>>> will
>>>>> be managing the input/output of the text myself. I really just want
>>>>> to give some wiki markup to the parser and get back html. Is there
>>>>> currently a way to do this?

View this message in context:
Sent from the JspWiki - User mailing list archive at

View raw message