jspwiki-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From dexterz <dexterz_laborat...@hotmail.com>
Subject Re: Embedding JSPWiki 2.6 [into a spring web app]
Date Mon, 04 Feb 2008 06:36:03 GMT

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 <dexterz_laboratory@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 <salam@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.


Mime
View raw message