You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@jspwiki.apache.org by Ethan Larson <et...@ethanlarson.net> on 2008/01/01 23:08:21 UTC
Re: Embedding JSPWiki 2.6
The exception I pasted in was the first one. I tried changing the page
name to "test" with the same result. 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?
Thanks,
Ethan
Janne Jalkanen wrote:
>
> Look at any earlier exception. My guess is that you have not defined
> a valid page directory.
>
> Also, an empty string is not a valid page name.
>
> /Janne
>
> On 31 Dec 2007, at 03:18, Ethan Larson wrote:
>
>> Hi all,
>>
>> I'm trying to use JSPWiki within a Grails application to add wiki
>> markup to content within my site. I tried following the "Embedding
>> JSP Wiki" instructions (http://jspwiki.org/wiki/EmbeddingJSPWiki) and
>> looking at the javadocs
>> (http://www.ecyrd.com/~jalkanen/JSPWiki/javadoc/) but neither is up
>> to date with JSPWiki 2.6.
>>
>> Basically, I just want to turn some wiki markup into html and
>> possibly run my own plugins at a later date. Here's what I've got so
>> far:
>>
>> Properties props = new Properties();
>> WikiEngine engine = new WikiEngine(props);
>>
>> WikiContext context = new WikiContext(engine, new
>> WikiPage(engine, ""));
>> JSPWikiMarkupParser parser = new JSPWikiMarkupParser(context,
>> new StringReader("This is a test string"));
>>
>> System.out.println(parser.parse().toString());
>>
>> But when I run it, I get this message when creating the WikiEngine:
>>
>> Exception in thread "main" com.ecyrd.jspwiki.WikiException: Failed to
>> instantiate class com.ecyrd.jspwiki.PageManager
>> at
>> com.ecyrd.jspwiki.util.ClassUtil.getMappedObject(ClassUtil.java:312)
>> at
>> com.ecyrd.jspwiki.util.ClassUtil.getMappedObject(ClassUtil.java:228)
>> at com.ecyrd.jspwiki.WikiEngine.initialize(WikiEngine.java:509)
>> at com.ecyrd.jspwiki.WikiEngine.<init>(WikiEngine.java:359)
>>
>> I'd appreciate any help. If I can get this working, I may turn it in
>> to a Grails plugin and release it to the wider community.
>>
>> Thanks and happy new year,
>> Ethan
>
Re: Embedding JSPWiki 2.6
Posted by Janne Jalkanen <Ja...@ecyrd.com>.
Might be a good idea to add these limitations to the javadocs...
Thanks for letting us know!
/Janne
On 6 Aug 2008, at 00:45, andreak wrote:
>
> Found the error. It turned out I had to return a non-null String from
> getProviderInfo() and non-null Collection from getAllPages().
> Usage of the class is:
> String wikiMarkup = "my __wiki-markup__";
> String html = SimpleWikiRenderer.render(wikiMarkup);
>
> The class I use is this:
>
> import com.ecyrd.jspwiki.WikiContext;
> import com.ecyrd.jspwiki.WikiEngine;
> import com.ecyrd.jspwiki.WikiPage;
> import com.ecyrd.jspwiki.WikiException;
> import com.ecyrd.jspwiki.PageManager;
> import com.ecyrd.jspwiki.WikiSession;
> import com.ecyrd.jspwiki.QueryItem;
> import com.ecyrd.jspwiki.NoRequiredPropertyException;
> import com.ecyrd.jspwiki.diff.DifferenceManager;
> import com.ecyrd.jspwiki.diff.TraditionalDiffProvider;
> import com.ecyrd.jspwiki.diff.DiffProvider;
> import com.ecyrd.jspwiki.providers.WikiPageProvider;
> import com.ecyrd.jspwiki.providers.ProviderException;
> import com.ecyrd.jspwiki.parser.MarkupParser;
> import com.ecyrd.jspwiki.parser.JSPWikiMarkupParser;
> import com.ecyrd.jspwiki.parser.WikiDocument;
> import com.ecyrd.jspwiki.render.WikiRenderer;
> import com.ecyrd.jspwiki.render.XHTMLRenderer;
> import com.ecyrd.jspwiki.auth.AuthenticationManager;
> import com.ecyrd.jspwiki.auth.AuthorizationManager;
> import com.ecyrd.jspwiki.auth.Authorizer;
> import com.ecyrd.jspwiki.auth.WikiSecurityException;
>
> import java.util.Properties;
> import java.util.Collection;
> import java.util.Date;
> import java.util.List;
> import java.util.Collections;
> import java.io.StringReader;
> import java.io.IOException;
> import java.security.Principal;
>
> public class SimpleWikiRenderer {
>
> protected static WikiEngine sEngine;
> protected static WikiContext sContext;
>
> static {
> Properties props = new Properties();
> props.setProperty(PageManager.PROP_PAGEPROVIDER,
> DummyPageProvider.class.getName());
> props.setProperty(AuthenticationManager.PROP_SECURITY, "off");
>
> try {
> sEngine = new WikiEngine(props);
> sContext = new WikiContext(sEngine, new WikiPage(sEngine,
> "dummy"));
> }
> catch (WikiException e) {
> e.printStackTrace();
> }
> }
>
> public static String render(String wikiMarkup) throws IOException {
> // Create new parser and parse the content into a WikiDocument
> MarkupParser parser = new JSPWikiMarkupParser(sContext, new
> StringReader(wikiMarkup));
> WikiDocument doc = parser.parse();
>
> // We now create a new WikiRenderer
> WikiRenderer rend = new XHTMLRenderer(sContext, doc);
>
> // Now, do the rendering.
> return rend.getString();
> }
>
> public static class DummyPageProvider implements WikiPageProvider {
> public void putPageText(WikiPage wikiPage, String s) throws
> ProviderException {
> }
>
> public boolean pageExists(String s) {
> return false; //To change body of implemented methods use File |
> Settings | File Templates.
> }
>
> public Collection findPages(QueryItem[] queryItems) {
> return null; //To change body of implemented methods use File |
> Settings
> | File Templates.
> }
>
> public WikiPage getPageInfo(String s, int i) throws
> ProviderException {
> return null; //To change body of implemented methods use File |
> Settings
> | File Templates.
> }
>
> public Collection getAllPages() throws ProviderException {
> return Collections.EMPTY_LIST;
> }
>
> public Collection getAllChangedSince(Date date) {
> return null; //To change body of implemented methods use File |
> Settings
> | File Templates.
> }
>
> public int getPageCount() throws ProviderException {
> return 0; //To change body of implemented methods use File |
> Settings |
> File Templates.
> }
>
> public List getVersionHistory(String s) throws ProviderException {
> return null; //To change body of implemented methods use File |
> Settings
> | File Templates.
> }
>
> public String getPageText(String s, int i) throws
> ProviderException {
> return null; //To change body of implemented methods use File |
> Settings
> | File Templates.
> }
>
> public void deleteVersion(String s, int i) throws
> ProviderException {
> }
>
> public void deletePage(String s) throws ProviderException {
> }
>
> public void movePage(String s, String s1) throws ProviderException {
> }
>
> public void initialize(WikiEngine wikiEngine, Properties properties)
> throws NoRequiredPropertyException, IOException {
> }
>
> public String getProviderInfo() {
> return DummyPageProvider.class.getName();
> }
> }
>
> }
>
>
> andreak wrote:
>>
>> I'm not having any luck with embedding JSPWiki. I've created a
>> class like
>> Ethan suggests, with dummy (empty stubs) of DummyAuthorizer
>> (implements
>> com.ecyrd.jspwiki.auth.Authorizer) and DummyPageProvider (implements
>> WikiPageProvider). After running a test I'm getting:
>> - *******************************************
>> - JSPWiki 2.6.1 starting. Whee!
>> - JSPWiki working directory is '/tmp/JSPWiki-'
>> - Registering plugins
>> - Using difference provider: TraditionalDiffProvider
>> - No attachment provider defined - disabling attachment support.
>> - Lucene enabled, cache will be in: /tmp/JSPWiki-/lucene
>> Starting up background thread: JSPWiki Lucene Indexer.
>> Starting up background thread: WatchDog for 'JSPWiki'.
>> - Files found in Lucene directory, not reindexing.
>> - Registering editor modules
>> - Attempting to load group database class
>> com.ecyrd.jspwiki.auth.authorize.XMLGroupDatabase
>> - XML group database property jspwiki.xmlGroupDatabaseFile not found;
>> trying /home/andreak/dev/uno/trunk/IDEAProject/WEB-INF/
>> groupdatabase.xml
>> - XML group database at
>> /home/andreak/dev/uno/trunk/IDEAProject/WEB-INF/groupdatabase.xml
>> - Group database not found; creating from scratch...
>> - Group database initialized.
>> - Group database not found; creating from scratch...
>> - Authorizer GroupManager initialized successfully; loaded 0 group
>> (s).
>> - Using JDK 1.5 Platform MBeanServer
>> - com.sun.jmx.mbeanserver.JmxMBeanServer
>> - DefaultDomain
>> - Registered new admin bean Core bean
>> - Registered new admin bean User administration
>> - Registered new admin bean Search manager
>> - Registered new admin bean Plugins
>> - Registered new admin bean WikiWizard
>> - Registered new admin bean Plain editor
>> - Registering filters
>> - Cannot find property file for filters (this is okay, expected to
>> find it
>> as: '/WEB-INF/filters.xml')
>> - Rendering content with com.ecyrd.jspwiki.render.XHTMLRenderer.
>> - Failed to start managers.
>> java.lang.NullPointerException
>> at java.util.ArrayList.addAll(ArrayList.java:472)
>> at com.ecyrd.jspwiki.WikiEngine.initReferenceManager
>> (WikiEngine.java:659)
>> at com.ecyrd.jspwiki.WikiEngine.initialize(WikiEngine.java:569)
>> at com.ecyrd.jspwiki.WikiEngine.<init>(WikiEngine.java:359)
>> at
>> no.officenet.uno.util.SimpleWikiRenderer.<clinit>
>> (SimpleWikiRenderer.java:48)
>> at
>> no.officenet.uno.util.SimpleWikiRendererTest.testWiki
>> (SimpleWikiRendererTest.java:8)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at
>> sun.reflect.NativeMethodAccessorImpl.invoke
>> (NativeMethodAccessorImpl.java:39)
>> at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke
>> (DelegatingMethodAccessorImpl.java:25)
>> at java.lang.reflect.Method.invoke(Method.java:597)
>> at junit.framework.TestCase.runTest(TestCase.java:154)
>> at junit.framework.TestCase.runBare(TestCase.java:127)
>> at junit.framework.TestResult$1.protect(TestResult.java:106)
>> at junit.framework.TestResult.runProtected(TestResult.java:124)
>> at junit.framework.TestResult.run(TestResult.java:109)
>> at junit.framework.TestCase.run(TestCase.java:118)
>> at junit.textui.TestRunner.doRun(TestRunner.java:116)
>> at
>> com.intellij.rt.execution.junit.IdeaTestRunner.doRun
>> (IdeaTestRunner.java:65)
>> at junit.textui.TestRunner.doRun(TestRunner.java:109)
>> at
>> com.intellij.rt.execution.junit.IdeaTestRunner.startRunnerWithArgs
>> (IdeaTestRunner.java:24)
>> com.ecyrd.jspwiki.WikiException: Failed to start managers: null
>> at com.ecyrd.jspwiki.WikiEngine.initialize(WikiEngine.java:582)
>> at com.ecyrd.jspwiki.WikiEngine.<init>(WikiEngine.java:359)
>> at
>> no.officenet.uno.util.SimpleWikiRenderer.<clinit>
>> (SimpleWikiRenderer.java:48)
>> at
>> no.officenet.uno.util.SimpleWikiRendererTest.testWiki
>> (SimpleWikiRendererTest.java:8)
>>
>>
>> Janne Jalkanen wrote:
>>>
>>>
>>> Aside from the fact that the PageFilter interface has changed (minor
>>> modifications necessary, you will see when you compile it), you
>>> should be fine. If you are not, please let us know so those can be
>>> documented.
>>>
>>> /Janne
>>>
>>> On 5 Jan 2008, at 22:41, Ethan Larson wrote:
>>>
>>>> Thanks again - that worked. Just one other question: will there be
>>>> anything different about my filter/plugin setup, or can I follow
>>>> the same setup outlined in the documentation?
>>>>
>>>> Cheers,
>>>> Ethan
>>>>
>>>> P.S. - Here's my code in case anyone else wants to get this
>>>> working. If anyone sees something wrong or a way to optimize it,
>>>> please let me know:
>>>>
>>>> public class SimpleJSPWikiRenderer {
>>>>
>>>> protected static WikiEngine sEngine;
>>>> protected static WikiContext sContext;
>>>>
>>>> static {
>>>> Properties props = new Properties();
>>>> props.setProperty(PageManager.PROP_PAGEPROVIDER,
>>>> DummyPageProvider.class.getName());
>>>> props.setProperty(AuthorizationManager.PROP_AUTHORIZER,
>>>> DummyAuthorizer.class.getName());
>>>> props.setProperty(AuthenticationManager.PROP_SECURITY,
>>>> "off");
>>>>
>>>> try {
>>>> sEngine = new WikiEngine(props);
>>>> sContext = new WikiContext(sEngine, new WikiPage
>>>> (sEngine, "dummy"));
>>>> }
>>>> catch (WikiException e) {
>>>> e.printStackTrace();
>>>> }
>>>> }
>>>>
>>>> public static String render(String wikiMarkup) throws
>>>> IOException {
>>>> // Create new parser and parse the content into a
>>>> WikiDocument
>>>> MarkupParser parser = new JSPWikiMarkupParser(sContext, new
>>>> StringReader(wikiMarkup));
>>>> WikiDocument doc = parser.parse();
>>>>
>>>> // We now create a new WikiRenderer
>>>> WikiRenderer rend = new XHTMLRenderer(sContext, doc);
>>>>
>>>> // Now, do the rendering.
>>>> return rend.getString();
>>>> }
>>>> }
>>>>
>>>> Janne Jalkanen wrote:
>>>>>
>>>>> Oh, and by the way, it's cleaner to directly hit the
>>>>> RenderingManager. See the following article for details:
>>>>>
>>>>> http://www.jspwiki.org/wiki/MarkupParser
>>>>>
>>>>> /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:
>>>>>>>> http://www.jspwiki.org/wiki/MemoryPageProvider
>>>>>>>>
>>>>>>>> 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: http://www.nabble.com/Embedding-
> JSPWiki-2.6-tp14553249p18840560.html
> Sent from the JspWiki - User mailing list archive at Nabble.com.
Re: Embedding JSPWiki 2.6
Posted by andreak <an...@officenet.no>.
Found the error. It turned out I had to return a non-null String from
getProviderInfo() and non-null Collection from getAllPages().
Usage of the class is:
String wikiMarkup = "my __wiki-markup__";
String html = SimpleWikiRenderer.render(wikiMarkup);
The class I use is this:
import com.ecyrd.jspwiki.WikiContext;
import com.ecyrd.jspwiki.WikiEngine;
import com.ecyrd.jspwiki.WikiPage;
import com.ecyrd.jspwiki.WikiException;
import com.ecyrd.jspwiki.PageManager;
import com.ecyrd.jspwiki.WikiSession;
import com.ecyrd.jspwiki.QueryItem;
import com.ecyrd.jspwiki.NoRequiredPropertyException;
import com.ecyrd.jspwiki.diff.DifferenceManager;
import com.ecyrd.jspwiki.diff.TraditionalDiffProvider;
import com.ecyrd.jspwiki.diff.DiffProvider;
import com.ecyrd.jspwiki.providers.WikiPageProvider;
import com.ecyrd.jspwiki.providers.ProviderException;
import com.ecyrd.jspwiki.parser.MarkupParser;
import com.ecyrd.jspwiki.parser.JSPWikiMarkupParser;
import com.ecyrd.jspwiki.parser.WikiDocument;
import com.ecyrd.jspwiki.render.WikiRenderer;
import com.ecyrd.jspwiki.render.XHTMLRenderer;
import com.ecyrd.jspwiki.auth.AuthenticationManager;
import com.ecyrd.jspwiki.auth.AuthorizationManager;
import com.ecyrd.jspwiki.auth.Authorizer;
import com.ecyrd.jspwiki.auth.WikiSecurityException;
import java.util.Properties;
import java.util.Collection;
import java.util.Date;
import java.util.List;
import java.util.Collections;
import java.io.StringReader;
import java.io.IOException;
import java.security.Principal;
public class SimpleWikiRenderer {
protected static WikiEngine sEngine;
protected static WikiContext sContext;
static {
Properties props = new Properties();
props.setProperty(PageManager.PROP_PAGEPROVIDER,
DummyPageProvider.class.getName());
props.setProperty(AuthenticationManager.PROP_SECURITY, "off");
try {
sEngine = new WikiEngine(props);
sContext = new WikiContext(sEngine, new WikiPage(sEngine,
"dummy"));
}
catch (WikiException e) {
e.printStackTrace();
}
}
public static String render(String wikiMarkup) throws IOException {
// Create new parser and parse the content into a WikiDocument
MarkupParser parser = new JSPWikiMarkupParser(sContext, new
StringReader(wikiMarkup));
WikiDocument doc = parser.parse();
// We now create a new WikiRenderer
WikiRenderer rend = new XHTMLRenderer(sContext, doc);
// Now, do the rendering.
return rend.getString();
}
public static class DummyPageProvider implements WikiPageProvider {
public void putPageText(WikiPage wikiPage, String s) throws
ProviderException {
}
public boolean pageExists(String s) {
return false; //To change body of implemented methods use File |
Settings | File Templates.
}
public Collection findPages(QueryItem[] queryItems) {
return null; //To change body of implemented methods use File | Settings
| File Templates.
}
public WikiPage getPageInfo(String s, int i) throws ProviderException {
return null; //To change body of implemented methods use File | Settings
| File Templates.
}
public Collection getAllPages() throws ProviderException {
return Collections.EMPTY_LIST;
}
public Collection getAllChangedSince(Date date) {
return null; //To change body of implemented methods use File | Settings
| File Templates.
}
public int getPageCount() throws ProviderException {
return 0; //To change body of implemented methods use File | Settings |
File Templates.
}
public List getVersionHistory(String s) throws ProviderException {
return null; //To change body of implemented methods use File | Settings
| File Templates.
}
public String getPageText(String s, int i) throws ProviderException {
return null; //To change body of implemented methods use File | Settings
| File Templates.
}
public void deleteVersion(String s, int i) throws ProviderException {
}
public void deletePage(String s) throws ProviderException {
}
public void movePage(String s, String s1) throws ProviderException {
}
public void initialize(WikiEngine wikiEngine, Properties properties)
throws NoRequiredPropertyException, IOException {
}
public String getProviderInfo() {
return DummyPageProvider.class.getName();
}
}
}
andreak wrote:
>
> I'm not having any luck with embedding JSPWiki. I've created a class like
> Ethan suggests, with dummy (empty stubs) of DummyAuthorizer (implements
> com.ecyrd.jspwiki.auth.Authorizer) and DummyPageProvider (implements
> WikiPageProvider). After running a test I'm getting:
> - *******************************************
> - JSPWiki 2.6.1 starting. Whee!
> - JSPWiki working directory is '/tmp/JSPWiki-'
> - Registering plugins
> - Using difference provider: TraditionalDiffProvider
> - No attachment provider defined - disabling attachment support.
> - Lucene enabled, cache will be in: /tmp/JSPWiki-/lucene
> Starting up background thread: JSPWiki Lucene Indexer.
> Starting up background thread: WatchDog for 'JSPWiki'.
> - Files found in Lucene directory, not reindexing.
> - Registering editor modules
> - Attempting to load group database class
> com.ecyrd.jspwiki.auth.authorize.XMLGroupDatabase
> - XML group database property jspwiki.xmlGroupDatabaseFile not found;
> trying /home/andreak/dev/uno/trunk/IDEAProject/WEB-INF/groupdatabase.xml
> - XML group database at
> /home/andreak/dev/uno/trunk/IDEAProject/WEB-INF/groupdatabase.xml
> - Group database not found; creating from scratch...
> - Group database initialized.
> - Group database not found; creating from scratch...
> - Authorizer GroupManager initialized successfully; loaded 0 group(s).
> - Using JDK 1.5 Platform MBeanServer
> - com.sun.jmx.mbeanserver.JmxMBeanServer
> - DefaultDomain
> - Registered new admin bean Core bean
> - Registered new admin bean User administration
> - Registered new admin bean Search manager
> - Registered new admin bean Plugins
> - Registered new admin bean WikiWizard
> - Registered new admin bean Plain editor
> - Registering filters
> - Cannot find property file for filters (this is okay, expected to find it
> as: '/WEB-INF/filters.xml')
> - Rendering content with com.ecyrd.jspwiki.render.XHTMLRenderer.
> - Failed to start managers.
> java.lang.NullPointerException
> at java.util.ArrayList.addAll(ArrayList.java:472)
> at com.ecyrd.jspwiki.WikiEngine.initReferenceManager(WikiEngine.java:659)
> at com.ecyrd.jspwiki.WikiEngine.initialize(WikiEngine.java:569)
> at com.ecyrd.jspwiki.WikiEngine.<init>(WikiEngine.java:359)
> at
> no.officenet.uno.util.SimpleWikiRenderer.<clinit>(SimpleWikiRenderer.java:48)
> at
> no.officenet.uno.util.SimpleWikiRendererTest.testWiki(SimpleWikiRendererTest.java:8)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at junit.framework.TestCase.runTest(TestCase.java:154)
> at junit.framework.TestCase.runBare(TestCase.java:127)
> at junit.framework.TestResult$1.protect(TestResult.java:106)
> at junit.framework.TestResult.runProtected(TestResult.java:124)
> at junit.framework.TestResult.run(TestResult.java:109)
> at junit.framework.TestCase.run(TestCase.java:118)
> at junit.textui.TestRunner.doRun(TestRunner.java:116)
> at
> com.intellij.rt.execution.junit.IdeaTestRunner.doRun(IdeaTestRunner.java:65)
> at junit.textui.TestRunner.doRun(TestRunner.java:109)
> at
> com.intellij.rt.execution.junit.IdeaTestRunner.startRunnerWithArgs(IdeaTestRunner.java:24)
> com.ecyrd.jspwiki.WikiException: Failed to start managers: null
> at com.ecyrd.jspwiki.WikiEngine.initialize(WikiEngine.java:582)
> at com.ecyrd.jspwiki.WikiEngine.<init>(WikiEngine.java:359)
> at
> no.officenet.uno.util.SimpleWikiRenderer.<clinit>(SimpleWikiRenderer.java:48)
> at
> no.officenet.uno.util.SimpleWikiRendererTest.testWiki(SimpleWikiRendererTest.java:8)
>
>
> Janne Jalkanen wrote:
>>
>>
>> Aside from the fact that the PageFilter interface has changed (minor
>> modifications necessary, you will see when you compile it), you
>> should be fine. If you are not, please let us know so those can be
>> documented.
>>
>> /Janne
>>
>> On 5 Jan 2008, at 22:41, Ethan Larson wrote:
>>
>>> Thanks again - that worked. Just one other question: will there be
>>> anything different about my filter/plugin setup, or can I follow
>>> the same setup outlined in the documentation?
>>>
>>> Cheers,
>>> Ethan
>>>
>>> P.S. - Here's my code in case anyone else wants to get this
>>> working. If anyone sees something wrong or a way to optimize it,
>>> please let me know:
>>>
>>> public class SimpleJSPWikiRenderer {
>>>
>>> protected static WikiEngine sEngine;
>>> protected static WikiContext sContext;
>>>
>>> static {
>>> Properties props = new Properties();
>>> props.setProperty(PageManager.PROP_PAGEPROVIDER,
>>> DummyPageProvider.class.getName());
>>> props.setProperty(AuthorizationManager.PROP_AUTHORIZER,
>>> DummyAuthorizer.class.getName());
>>> props.setProperty(AuthenticationManager.PROP_SECURITY, "off");
>>>
>>> try {
>>> sEngine = new WikiEngine(props);
>>> sContext = new WikiContext(sEngine, new WikiPage
>>> (sEngine, "dummy"));
>>> }
>>> catch (WikiException e) {
>>> e.printStackTrace();
>>> }
>>> }
>>>
>>> public static String render(String wikiMarkup) throws IOException {
>>> // Create new parser and parse the content into a WikiDocument
>>> MarkupParser parser = new JSPWikiMarkupParser(sContext, new
>>> StringReader(wikiMarkup));
>>> WikiDocument doc = parser.parse();
>>>
>>> // We now create a new WikiRenderer
>>> WikiRenderer rend = new XHTMLRenderer(sContext, doc);
>>>
>>> // Now, do the rendering.
>>> return rend.getString();
>>> }
>>> }
>>>
>>> Janne Jalkanen wrote:
>>>>
>>>> Oh, and by the way, it's cleaner to directly hit the
>>>> RenderingManager. See the following article for details:
>>>>
>>>> http://www.jspwiki.org/wiki/MarkupParser
>>>>
>>>> /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:
>>>>>>> http://www.jspwiki.org/wiki/MemoryPageProvider
>>>>>>>
>>>>>>> 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: http://www.nabble.com/Embedding-JSPWiki-2.6-tp14553249p18840560.html
Sent from the JspWiki - User mailing list archive at Nabble.com.
Re: Embedding JSPWiki 2.6
Posted by andreak <an...@officenet.no>.
I'm not having any luck with embedding JSPWiki. I've created a class like
Ethan suggests, with dummy (empty stubs) of DummyAuthorizer (implements
com.ecyrd.jspwiki.auth.Authorizer) and DummyPageProvider (implements
WikiPageProvider). After running a test I'm getting:
- *******************************************
- JSPWiki 2.6.1 starting. Whee!
- JSPWiki working directory is '/tmp/JSPWiki-'
- Registering plugins
- Using difference provider: TraditionalDiffProvider
- No attachment provider defined - disabling attachment support.
- Lucene enabled, cache will be in: /tmp/JSPWiki-/lucene
Starting up background thread: JSPWiki Lucene Indexer.
Starting up background thread: WatchDog for 'JSPWiki'.
- Files found in Lucene directory, not reindexing.
- Registering editor modules
- Attempting to load group database class
com.ecyrd.jspwiki.auth.authorize.XMLGroupDatabase
- XML group database property jspwiki.xmlGroupDatabaseFile not found; trying
/home/andreak/dev/uno/trunk/IDEAProject/WEB-INF/groupdatabase.xml
- XML group database at
/home/andreak/dev/uno/trunk/IDEAProject/WEB-INF/groupdatabase.xml
- Group database not found; creating from scratch...
- Group database initialized.
- Group database not found; creating from scratch...
- Authorizer GroupManager initialized successfully; loaded 0 group(s).
- Using JDK 1.5 Platform MBeanServer
- com.sun.jmx.mbeanserver.JmxMBeanServer
- DefaultDomain
- Registered new admin bean Core bean
- Registered new admin bean User administration
- Registered new admin bean Search manager
- Registered new admin bean Plugins
- Registered new admin bean WikiWizard
- Registered new admin bean Plain editor
- Registering filters
- Cannot find property file for filters (this is okay, expected to find it
as: '/WEB-INF/filters.xml')
- Rendering content with com.ecyrd.jspwiki.render.XHTMLRenderer.
- Failed to start managers.
java.lang.NullPointerException
at java.util.ArrayList.addAll(ArrayList.java:472)
at com.ecyrd.jspwiki.WikiEngine.initReferenceManager(WikiEngine.java:659)
at com.ecyrd.jspwiki.WikiEngine.initialize(WikiEngine.java:569)
at com.ecyrd.jspwiki.WikiEngine.<init>(WikiEngine.java:359)
at
no.officenet.uno.util.SimpleWikiRenderer.<clinit>(SimpleWikiRenderer.java:48)
at
no.officenet.uno.util.SimpleWikiRendererTest.testWiki(SimpleWikiRendererTest.java:8)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at junit.framework.TestCase.runTest(TestCase.java:154)
at junit.framework.TestCase.runBare(TestCase.java:127)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at junit.textui.TestRunner.doRun(TestRunner.java:116)
at
com.intellij.rt.execution.junit.IdeaTestRunner.doRun(IdeaTestRunner.java:65)
at junit.textui.TestRunner.doRun(TestRunner.java:109)
at
com.intellij.rt.execution.junit.IdeaTestRunner.startRunnerWithArgs(IdeaTestRunner.java:24)
com.ecyrd.jspwiki.WikiException: Failed to start managers: null
at com.ecyrd.jspwiki.WikiEngine.initialize(WikiEngine.java:582)
at com.ecyrd.jspwiki.WikiEngine.<init>(WikiEngine.java:359)
at
no.officenet.uno.util.SimpleWikiRenderer.<clinit>(SimpleWikiRenderer.java:48)
at
no.officenet.uno.util.SimpleWikiRendererTest.testWiki(SimpleWikiRendererTest.java:8)
Janne Jalkanen wrote:
>
>
> Aside from the fact that the PageFilter interface has changed (minor
> modifications necessary, you will see when you compile it), you
> should be fine. If you are not, please let us know so those can be
> documented.
>
> /Janne
>
> On 5 Jan 2008, at 22:41, Ethan Larson wrote:
>
>> Thanks again - that worked. Just one other question: will there be
>> anything different about my filter/plugin setup, or can I follow
>> the same setup outlined in the documentation?
>>
>> Cheers,
>> Ethan
>>
>> P.S. - Here's my code in case anyone else wants to get this
>> working. If anyone sees something wrong or a way to optimize it,
>> please let me know:
>>
>> public class SimpleJSPWikiRenderer {
>>
>> protected static WikiEngine sEngine;
>> protected static WikiContext sContext;
>>
>> static {
>> Properties props = new Properties();
>> props.setProperty(PageManager.PROP_PAGEPROVIDER,
>> DummyPageProvider.class.getName());
>> props.setProperty(AuthorizationManager.PROP_AUTHORIZER,
>> DummyAuthorizer.class.getName());
>> props.setProperty(AuthenticationManager.PROP_SECURITY, "off");
>>
>> try {
>> sEngine = new WikiEngine(props);
>> sContext = new WikiContext(sEngine, new WikiPage
>> (sEngine, "dummy"));
>> }
>> catch (WikiException e) {
>> e.printStackTrace();
>> }
>> }
>>
>> public static String render(String wikiMarkup) throws IOException {
>> // Create new parser and parse the content into a WikiDocument
>> MarkupParser parser = new JSPWikiMarkupParser(sContext, new
>> StringReader(wikiMarkup));
>> WikiDocument doc = parser.parse();
>>
>> // We now create a new WikiRenderer
>> WikiRenderer rend = new XHTMLRenderer(sContext, doc);
>>
>> // Now, do the rendering.
>> return rend.getString();
>> }
>> }
>>
>> Janne Jalkanen wrote:
>>>
>>> Oh, and by the way, it's cleaner to directly hit the
>>> RenderingManager. See the following article for details:
>>>
>>> http://www.jspwiki.org/wiki/MarkupParser
>>>
>>> /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:
>>>>>> http://www.jspwiki.org/wiki/MemoryPageProvider
>>>>>>
>>>>>> 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: http://www.nabble.com/Embedding-JSPWiki-2.6-tp14553249p18840232.html
Sent from the JspWiki - User mailing list archive at Nabble.com.
Re: Embedding JSPWiki 2.6
Posted by Janne Jalkanen <Ja...@ecyrd.com>.
Aside from the fact that the PageFilter interface has changed (minor
modifications necessary, you will see when you compile it), you
should be fine. If you are not, please let us know so those can be
documented.
/Janne
On 5 Jan 2008, at 22:41, Ethan Larson wrote:
> Thanks again - that worked. Just one other question: will there be
> anything different about my filter/plugin setup, or can I follow
> the same setup outlined in the documentation?
>
> Cheers,
> Ethan
>
> P.S. - Here's my code in case anyone else wants to get this
> working. If anyone sees something wrong or a way to optimize it,
> please let me know:
>
> public class SimpleJSPWikiRenderer {
>
> protected static WikiEngine sEngine;
> protected static WikiContext sContext;
>
> static {
> Properties props = new Properties();
> props.setProperty(PageManager.PROP_PAGEPROVIDER,
> DummyPageProvider.class.getName());
> props.setProperty(AuthorizationManager.PROP_AUTHORIZER,
> DummyAuthorizer.class.getName());
> props.setProperty(AuthenticationManager.PROP_SECURITY, "off");
>
> try {
> sEngine = new WikiEngine(props);
> sContext = new WikiContext(sEngine, new WikiPage
> (sEngine, "dummy"));
> }
> catch (WikiException e) {
> e.printStackTrace();
> }
> }
>
> public static String render(String wikiMarkup) throws IOException {
> // Create new parser and parse the content into a WikiDocument
> MarkupParser parser = new JSPWikiMarkupParser(sContext, new
> StringReader(wikiMarkup));
> WikiDocument doc = parser.parse();
>
> // We now create a new WikiRenderer
> WikiRenderer rend = new XHTMLRenderer(sContext, doc);
>
> // Now, do the rendering.
> return rend.getString();
> }
> }
>
> Janne Jalkanen wrote:
>>
>> Oh, and by the way, it's cleaner to directly hit the
>> RenderingManager. See the following article for details:
>>
>> http://www.jspwiki.org/wiki/MarkupParser
>>
>> /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:
>>>>> http://www.jspwiki.org/wiki/MemoryPageProvider
>>>>>
>>>>> 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?
>>>>>
>>>>
>>
>>
Re: Embedding JSPWiki 2.6
Posted by Ethan Larson <et...@ethanlarson.net>.
Thanks again - that worked. Just one other question: will there be
anything different about my filter/plugin setup, or can I follow the
same setup outlined in the documentation?
Cheers,
Ethan
P.S. - Here's my code in case anyone else wants to get this working. If
anyone sees something wrong or a way to optimize it, please let me know:
public class SimpleJSPWikiRenderer {
protected static WikiEngine sEngine;
protected static WikiContext sContext;
static {
Properties props = new Properties();
props.setProperty(PageManager.PROP_PAGEPROVIDER,
DummyPageProvider.class.getName());
props.setProperty(AuthorizationManager.PROP_AUTHORIZER,
DummyAuthorizer.class.getName());
props.setProperty(AuthenticationManager.PROP_SECURITY, "off");
try {
sEngine = new WikiEngine(props);
sContext = new WikiContext(sEngine, new WikiPage(sEngine,
"dummy"));
}
catch (WikiException e) {
e.printStackTrace();
}
}
public static String render(String wikiMarkup) throws IOException {
// Create new parser and parse the content into a WikiDocument
MarkupParser parser = new JSPWikiMarkupParser(sContext, new
StringReader(wikiMarkup));
WikiDocument doc = parser.parse();
// We now create a new WikiRenderer
WikiRenderer rend = new XHTMLRenderer(sContext, doc);
// Now, do the rendering.
return rend.getString();
}
}
Janne Jalkanen wrote:
>
> Oh, and by the way, it's cleaner to directly hit the
> RenderingManager. See the following article for details:
>
> http://www.jspwiki.org/wiki/MarkupParser
>
> /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:
>>>> http://www.jspwiki.org/wiki/MemoryPageProvider
>>>>
>>>> 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?
>>>>
>>>
>
>
Re: Embedding JSPWiki 2.6
Posted by Janne Jalkanen <Ja...@ecyrd.com>.
Oh, and by the way, it's cleaner to directly hit the
RenderingManager. See the following article for details:
http://www.jspwiki.org/wiki/MarkupParser
/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:
>>> http://www.jspwiki.org/wiki/MemoryPageProvider
>>>
>>> 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?
>>>
>>
Re: Embedding JSPWiki 2.6 [into a spring web app]
Posted by dexterz <de...@hotmail.com>.
I finally resolved this issue.
Just in case if somebody else runs into the same issue, I had to simply
change the encoding of web.xml file to "ISO-8859-1". It was earlier UTF-8.
dexterz wrote:
>
> I had earlier used a similar stub but I was getting the error that I
> resolved by commenting out jspwiki.security and jspwiki.authorizer
> property.
>
> So any idea at what location web.xml is expected by JspWiki when
> integrated with spring?
>
>
> Alexey Kakunin-3 wrote:
>>
>> You can check
>> http://www.emforge.org/fileviewer/EmForge/trunk/EmForge/src/main/java/ru/emdev/EmForge/wiki/security/AuthorizerImpl.java
>>
>> It is our own implementation (actually simple stub) for JspWiki
>> Authorizer.
>> Since anyway you will need to interate your authorization based on Acegi
>> -
>> it seems you will need to use it as start point and then
>> implement all methods with using Acegi.
>>
>> To use this authorizer we used followed properties in wikiEngine bean:
>>
>> <prop key="jspwiki.security">jaas</prop>
>> <prop key="jspwiki.authorizer">
>> ru.emdev.EmForge.wiki.security.AuthorizerImpl</prop>
>>
>>
>> I do not remember why - but we also met same problem with looking for
>> WEB-INF/web.xml in standard JspWiki authorizer... it seems because
>> JspWiki
>> is not created in it's native way (with initializing with
>> jspwiki.properties)
>> - but from Spring
>>
>> 2008/2/1, dexterz <de...@hotmail.com>:
>>>
>>>
>>> Thanks for the response.
>>> Indeed I had to comment out some security related properties to get rid
>>> of
>>> eariler error.
>>> Now I am getting
>>> =======================
>>> ERROR - AuthenticationManager.initialize(158) | Could not configure
>>> JAAS:
>>> URL for JAAS configuration cannot be null.
>>> ERROR - WebContainerAuthorizer.initialize(119) | Initialization failed:
>>> java.io.IOException: Unable to find web.xml for processing.
>>> at
>>> com.ecyrd.jspwiki.auth.authorize.WebContainerAuthorizer.getWebXml(
>>> WebContainerAuthorizer.java:386)
>>> =======================
>>>
>>> I think the first couple of errors are ok. However, I am a bit confused
>>> about the web.xml error. There is already a web.xml file present for my
>>> spring web app!
>>>
>>>
>>> Alexey Kakunin-3 wrote:
>>> >
>>> > Hello, Dexter
>>> >
>>> > 2008/2/1, dexterz <sa...@techlogix.com>:
>>> >>
>>> >>
>>> >> 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 .
>>> >
>>> >
>>> > If you are creating JspWiki engine via Factory bean - you should take
>>> into
>>> > account that jspwiki.properties are not used at all - WikiEngine is
>>> > initialzed with properties set, specified in the bean.
>>> >
>>> > So, you need to specify correct values for security configuration bean
>>> > properties.
>>> >
>>> > But - be sure there WikiEngine is initialized (just put breakpoint
>>> into
>>> > WikiEngine intialization function to see how it is called).
>>> >
>>> >
>>> > 3) Added relevant java implementation files for the engine and page
>>> >> providers.
>>> >> 4) Put jspwiki.properties 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 java.security.policy
>>> 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 java.security.policy
>>> variable.
>>> >> at
>>> >> com.ecyrd.jspwiki.auth.AuthorizationManager.initialize(
>>> >> AuthorizationManager.java:423)
>>> >> ==============================================
>>> >>
>>> >> 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.
>>> >>
>>> >> #java.security.auth.login.config=jspwiki.jass
>>> >> #java.security.policy=jspwiki.policy
>>> >>
>>> >> Any idea what I need to do to get it going?
>>> >>
>>> >>
>>> >> Janne Jalkanen wrote:
>>> >> >
>>> >> >
>>> >> > Yup. You can
>>> >> >
>>> >> > a) either set "jspwiki.security=off" (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:
>>> >> >>>> http://www.jspwiki.org/wiki/MemoryPageProvider
>>> >> >>>>
>>> >> >>>> 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:
>>> >> http://www.nabble.com/Embedding-JSPWiki-2.6-tp14553249p15225248.html
>>> >> Sent from the JspWiki - User mailing list archive at Nabble.com.
>>> >>
>>> >>
>>> >
>>> >
>>> > --
>>> > With best regards,
>>> > Alexey Kakunin
>>> >
>>> >
>>>
>>> --
>>> View this message in context:
>>> http://www.nabble.com/Embedding-JSPWiki-2.6-tp14553249p15226254.html
>>> Sent from the JspWiki - User mailing list archive at Nabble.com.
>>>
>>>
>>
>>
>> --
>> With best regards,
>> Alexey Kakunin
>>
>>
>
>
--
View this message in context: http://www.nabble.com/Embedding-JSPWiki-2.6-tp14553249p15262831.html
Sent from the JspWiki - User mailing list archive at Nabble.com.
Re: Embedding JSPWiki 2.6 [into a spring web app]
Posted by dexterz <de...@hotmail.com>.
I had earlier used a similar stub but I was getting the error that I resolved
by commenting out jspwiki.security and jspwiki.authorizer property.
So any idea at what location web.xml is expected by JspWiki when integrated
with spring?
Alexey Kakunin-3 wrote:
>
> You can check
> http://www.emforge.org/fileviewer/EmForge/trunk/EmForge/src/main/java/ru/emdev/EmForge/wiki/security/AuthorizerImpl.java
>
> It is our own implementation (actually simple stub) for JspWiki
> Authorizer.
> Since anyway you will need to interate your authorization based on Acegi -
> it seems you will need to use it as start point and then
> implement all methods with using Acegi.
>
> To use this authorizer we used followed properties in wikiEngine bean:
>
> <prop key="jspwiki.security">jaas</prop>
> <prop key="jspwiki.authorizer">
> ru.emdev.EmForge.wiki.security.AuthorizerImpl</prop>
>
>
> I do not remember why - but we also met same problem with looking for
> WEB-INF/web.xml in standard JspWiki authorizer... it seems because JspWiki
> is not created in it's native way (with initializing with
> jspwiki.properties)
> - but from Spring
>
> 2008/2/1, dexterz <de...@hotmail.com>:
>>
>>
>> Thanks for the response.
>> Indeed I had to comment out some security related properties to get rid
>> of
>> eariler error.
>> Now I am getting
>> =======================
>> ERROR - AuthenticationManager.initialize(158) | Could not configure JAAS:
>> URL for JAAS configuration cannot be null.
>> ERROR - WebContainerAuthorizer.initialize(119) | Initialization failed:
>> java.io.IOException: Unable to find web.xml for processing.
>> at
>> com.ecyrd.jspwiki.auth.authorize.WebContainerAuthorizer.getWebXml(
>> WebContainerAuthorizer.java:386)
>> =======================
>>
>> I think the first couple of errors are ok. However, I am a bit confused
>> about the web.xml error. There is already a web.xml file present for my
>> spring web app!
>>
>>
>> Alexey Kakunin-3 wrote:
>> >
>> > Hello, Dexter
>> >
>> > 2008/2/1, dexterz <sa...@techlogix.com>:
>> >>
>> >>
>> >> 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 .
>> >
>> >
>> > If you are creating JspWiki engine via Factory bean - you should take
>> into
>> > account that jspwiki.properties are not used at all - WikiEngine is
>> > initialzed with properties set, specified in the bean.
>> >
>> > So, you need to specify correct values for security configuration bean
>> > properties.
>> >
>> > But - be sure there WikiEngine is initialized (just put breakpoint into
>> > WikiEngine intialization function to see how it is called).
>> >
>> >
>> > 3) Added relevant java implementation files for the engine and page
>> >> providers.
>> >> 4) Put jspwiki.properties 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 java.security.policy 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 java.security.policy variable.
>> >> at
>> >> com.ecyrd.jspwiki.auth.AuthorizationManager.initialize(
>> >> AuthorizationManager.java:423)
>> >> ==============================================
>> >>
>> >> 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.
>> >>
>> >> #java.security.auth.login.config=jspwiki.jass
>> >> #java.security.policy=jspwiki.policy
>> >>
>> >> Any idea what I need to do to get it going?
>> >>
>> >>
>> >> Janne Jalkanen wrote:
>> >> >
>> >> >
>> >> > Yup. You can
>> >> >
>> >> > a) either set "jspwiki.security=off" (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:
>> >> >>>> http://www.jspwiki.org/wiki/MemoryPageProvider
>> >> >>>>
>> >> >>>> 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:
>> >> http://www.nabble.com/Embedding-JSPWiki-2.6-tp14553249p15225248.html
>> >> Sent from the JspWiki - User mailing list archive at Nabble.com.
>> >>
>> >>
>> >
>> >
>> > --
>> > With best regards,
>> > Alexey Kakunin
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Embedding-JSPWiki-2.6-tp14553249p15226254.html
>> Sent from the JspWiki - User mailing list archive at Nabble.com.
>>
>>
>
>
> --
> With best regards,
> Alexey Kakunin
>
>
--
View this message in context: http://www.nabble.com/Embedding-JSPWiki-2.6-tp14553249p15242476.html
Sent from the JspWiki - User mailing list archive at Nabble.com.
Re: Embedding JSPWiki 2.6 [into a spring web app]
Posted by Alexey Kakunin <ak...@emdev.ru>.
You can check
http://www.emforge.org/fileviewer/EmForge/trunk/EmForge/src/main/java/ru/emdev/EmForge/wiki/security/AuthorizerImpl.java
It is our own implementation (actually simple stub) for JspWiki Authorizer.
Since anyway you will need to interate your authorization based on Acegi -
it seems you will need to use it as start point and then
implement all methods with using Acegi.
To use this authorizer we used followed properties in wikiEngine bean:
<prop key="jspwiki.security">jaas</prop>
<prop key="jspwiki.authorizer">
ru.emdev.EmForge.wiki.security.AuthorizerImpl</prop>
I do not remember why - but we also met same problem with looking for
WEB-INF/web.xml in standard JspWiki authorizer... it seems because JspWiki
is not created in it's native way (with initializing with jspwiki.properties)
- but from Spring
2008/2/1, dexterz <de...@hotmail.com>:
>
>
> Thanks for the response.
> Indeed I had to comment out some security related properties to get rid of
> eariler error.
> Now I am getting
> =======================
> ERROR - AuthenticationManager.initialize(158) | Could not configure JAAS:
> URL for JAAS configuration cannot be null.
> ERROR - WebContainerAuthorizer.initialize(119) | Initialization failed:
> java.io.IOException: Unable to find web.xml for processing.
> at
> com.ecyrd.jspwiki.auth.authorize.WebContainerAuthorizer.getWebXml(
> WebContainerAuthorizer.java:386)
> =======================
>
> I think the first couple of errors are ok. However, I am a bit confused
> about the web.xml error. There is already a web.xml file present for my
> spring web app!
>
>
> Alexey Kakunin-3 wrote:
> >
> > Hello, Dexter
> >
> > 2008/2/1, dexterz <sa...@techlogix.com>:
> >>
> >>
> >> 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 .
> >
> >
> > If you are creating JspWiki engine via Factory bean - you should take
> into
> > account that jspwiki.properties are not used at all - WikiEngine is
> > initialzed with properties set, specified in the bean.
> >
> > So, you need to specify correct values for security configuration bean
> > properties.
> >
> > But - be sure there WikiEngine is initialized (just put breakpoint into
> > WikiEngine intialization function to see how it is called).
> >
> >
> > 3) Added relevant java implementation files for the engine and page
> >> providers.
> >> 4) Put jspwiki.properties 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 java.security.policy 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 java.security.policy variable.
> >> at
> >> com.ecyrd.jspwiki.auth.AuthorizationManager.initialize(
> >> AuthorizationManager.java:423)
> >> ==============================================
> >>
> >> 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.
> >>
> >> #java.security.auth.login.config=jspwiki.jass
> >> #java.security.policy=jspwiki.policy
> >>
> >> Any idea what I need to do to get it going?
> >>
> >>
> >> Janne Jalkanen wrote:
> >> >
> >> >
> >> > Yup. You can
> >> >
> >> > a) either set "jspwiki.security=off" (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:
> >> >>>> http://www.jspwiki.org/wiki/MemoryPageProvider
> >> >>>>
> >> >>>> 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:
> >> http://www.nabble.com/Embedding-JSPWiki-2.6-tp14553249p15225248.html
> >> Sent from the JspWiki - User mailing list archive at Nabble.com.
> >>
> >>
> >
> >
> > --
> > With best regards,
> > Alexey Kakunin
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/Embedding-JSPWiki-2.6-tp14553249p15226254.html
> Sent from the JspWiki - User mailing list archive at Nabble.com.
>
>
--
With best regards,
Alexey Kakunin
Re: Embedding JSPWiki 2.6 [into a spring web app]
Posted by dexterz <de...@hotmail.com>.
Thanks for the response.
Indeed I had to comment out some security related properties to get rid of
eariler error.
Now I am getting
=======================
ERROR - AuthenticationManager.initialize(158) | Could not configure JAAS:
URL for JAAS configuration cannot be null.
ERROR - WebContainerAuthorizer.initialize(119) | Initialization failed:
java.io.IOException: Unable to find web.xml for processing.
at
com.ecyrd.jspwiki.auth.authorize.WebContainerAuthorizer.getWebXml(WebContainerAuthorizer.java:386)
=======================
I think the first couple of errors are ok. However, I am a bit confused
about the web.xml error. There is already a web.xml file present for my
spring web app!
Alexey Kakunin-3 wrote:
>
> Hello, Dexter
>
> 2008/2/1, dexterz <sa...@techlogix.com>:
>>
>>
>> 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 .
>
>
> If you are creating JspWiki engine via Factory bean - you should take into
> account that jspwiki.properties are not used at all - WikiEngine is
> initialzed with properties set, specified in the bean.
>
> So, you need to specify correct values for security configuration bean
> properties.
>
> But - be sure there WikiEngine is initialized (just put breakpoint into
> WikiEngine intialization function to see how it is called).
>
>
> 3) Added relevant java implementation files for the engine and page
>> providers.
>> 4) Put jspwiki.properties 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 java.security.policy 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 java.security.policy variable.
>> at
>> com.ecyrd.jspwiki.auth.AuthorizationManager.initialize(
>> AuthorizationManager.java:423)
>> ==============================================
>>
>> 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.
>>
>> #java.security.auth.login.config=jspwiki.jass
>> #java.security.policy=jspwiki.policy
>>
>> Any idea what I need to do to get it going?
>>
>>
>> Janne Jalkanen wrote:
>> >
>> >
>> > Yup. You can
>> >
>> > a) either set "jspwiki.security=off" (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:
>> >>>> http://www.jspwiki.org/wiki/MemoryPageProvider
>> >>>>
>> >>>> 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:
>> http://www.nabble.com/Embedding-JSPWiki-2.6-tp14553249p15225248.html
>> Sent from the JspWiki - User mailing list archive at Nabble.com.
>>
>>
>
>
> --
> With best regards,
> Alexey Kakunin
>
>
--
View this message in context: http://www.nabble.com/Embedding-JSPWiki-2.6-tp14553249p15226254.html
Sent from the JspWiki - User mailing list archive at Nabble.com.
Re: Embedding JSPWiki 2.6 [into a spring web app]
Posted by Alexey Kakunin <ak...@emdev.ru>.
Hello, Dexter
2008/2/1, dexterz <sa...@techlogix.com>:
>
>
> 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 .
If you are creating JspWiki engine via Factory bean - you should take into
account that jspwiki.properties are not used at all - WikiEngine is
initialzed with properties set, specified in the bean.
So, you need to specify correct values for security configuration bean
properties.
But - be sure there WikiEngine is initialized (just put breakpoint into
WikiEngine intialization function to see how it is called).
3) Added relevant java implementation files for the engine and page
> providers.
> 4) Put jspwiki.properties 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 java.security.policy 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 java.security.policy variable.
> at
> com.ecyrd.jspwiki.auth.AuthorizationManager.initialize(
> AuthorizationManager.java:423)
> ==============================================
>
> 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.
>
> #java.security.auth.login.config=jspwiki.jass
> #java.security.policy=jspwiki.policy
>
> Any idea what I need to do to get it going?
>
>
> Janne Jalkanen wrote:
> >
> >
> > Yup. You can
> >
> > a) either set "jspwiki.security=off" (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:
> >>>> http://www.jspwiki.org/wiki/MemoryPageProvider
> >>>>
> >>>> 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:
> http://www.nabble.com/Embedding-JSPWiki-2.6-tp14553249p15225248.html
> Sent from the JspWiki - User mailing list archive at Nabble.com.
>
>
--
With best regards,
Alexey Kakunin
Re: Embedding JSPWiki 2.6 [into a spring web app]
Posted by dexterz <sa...@techlogix.com>.
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
providers.
4) Put jspwiki.properties 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 java.security.policy 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 java.security.policy variable.
at
com.ecyrd.jspwiki.auth.AuthorizationManager.initialize(AuthorizationManager.java:423)
==============================================
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.
#java.security.auth.login.config=jspwiki.jass
#java.security.policy=jspwiki.policy
Any idea what I need to do to get it going?
Janne Jalkanen wrote:
>
>
> Yup. You can
>
> a) either set "jspwiki.security=off" (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:
>>>> http://www.jspwiki.org/wiki/MemoryPageProvider
>>>>
>>>> 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: http://www.nabble.com/Embedding-JSPWiki-2.6-tp14553249p15225248.html
Sent from the JspWiki - User mailing list archive at Nabble.com.
Re: Embedding JSPWiki 2.6
Posted by Janne Jalkanen <Ja...@ecyrd.com>.
Yup. You can
a) either set "jspwiki.security=off" (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:
>>> http://www.jspwiki.org/wiki/MemoryPageProvider
>>>
>>> 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?
>>>
>>
Re: Embedding JSPWiki 2.6
Posted by Ethan Larson <et...@ethanlarson.net>.
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:
>> http://www.jspwiki.org/wiki/MemoryPageProvider
>>
>> 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?
>>
>
Re: Re[2]: Embedding JSPWiki 2.6
Posted by Janne Jalkanen <Ja...@ecyrd.com>.
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:
> http://www.jspwiki.org/wiki/MemoryPageProvider
>
> 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?
>
Re[2]: Embedding JSPWiki 2.6
Posted by Florian Holeczek <fl...@holeczek.de>.
Hi Ethan,
maybe this can help you:
http://www.jspwiki.org/wiki/MemoryPageProvider
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?