Hi! regarding tomcat/lib, it's just a place on classpath outside the jspwiki war. that way you can upgrade your JSPWiki version without needing any war surgery. But really, any place on classpath is fine to get your jspwiki-custom.properties file read,
As for themes, JSPWiki has the notion of "templates", a group of JSP files that render JSPWiki appereance. There is a default template, and there are some JSP files to be expected on your template; if they aren't found, they're read from the default template. Tipically you provide some styles on customheader.jsp (or something like that, don't recall the exact name now and don't have the code at hand), and usually that's enough to customize the overall appeareance, although you can completely modify the UI. As for the default template, it supports changing appearance (light/dark), but also "themes", f.ex., Dark [#1] or clean blue [#2] themes. They're another way to change (overall) styling, but they don't require a property on your jspwiki-custom file. Search for theme at jspwiki-wiki.a.o and you'll get some more info and additional themes there. HTH, juan pablo [#1] https://jspwiki-wiki.apache.org/Wiki.jsp?page=Dark%20Theme [#2] https://jspwiki-wiki.apache.org/Wiki.jsp?page=Clean%20Blue%20Theme On Mon, Mar 18, 2024 at 1:43 AM Alex O'Ree <alexo...@apache.org> wrote: > > great info, thanks > > is there a reason for using the tomcat/lib folder for storing config file? > I feel like it should be in the war/WEB-INF/classes location instead. > > i see that there's different themes available, but it's not clear to use > them within the webapp beside light/dark mode. The docs for changing themes > doesn't seem to correlate with the latest version. Ref > https://jspwiki-wiki.apache.org/Wiki.jsp?page=CustomUserPreferences > > On Sun, Mar 17, 2024 at 7:06 PM Juan Pablo Santos Rodríguez < > juanpablo.san...@gmail.com> wrote: > > > Hi! > > > > Regarding using the database, yup, It doesn't matter, your instances should > > share db, wiki working dir and cache. The important bit is the working dir, > > there's were the index files are. > > > > Regarding the cache, latest master brings support for custom events > > listeners [#1], which should be the entry point you're looking for. Bear on > > mind that you'll have to code it. And it'll be GA on upcoming 2.12.2. > > > > Also, Ehcache can be configured to have a shared cache, using a multicast > > address, so perhaps that's easier to set upthan going through the messaging > > route? > > > > > > Best regards, > > juan pablo > > > > > > > > [#1] > > > > https://jspwiki-wiki.apache.org/Wiki.jsp?page=HowToWriteACustomWikiEventListener > > > > El dom, 17 mar 2024, 23:31, Alex O'Ree <spyhunte...@gmail.com> escribió: > > > > > > they should be possible as long as you shared your "wiki work dir" > > > > > > Is this true, even when a database storage solution? > > > > > > > Also, by default there's a caching layer in front of the file system > > > access to pages > > > and attachments, ehcache based. > > > > > > Is there perhaps a server side API that i can use to detect a change? > > > And to trigger the cache invalidation? > > > I have a kafka setup in the environment and...in theory...if i can detect > > > the change, i can send a kafka topic message trigger the invalidation for > > > all of the instances > > > > > > > > > On Sun, Mar 17, 2024 at 5:43 PM Juan Pablo Santos Rodríguez < > > > juanpablo.san...@gmail.com> wrote: > > > > > > > Hi Alex! > > > > > > > > regarding rolling upgrades / load balancing, they should be possible > > > > as long as you shared your "wiki work dir" (containing f.ex., lucene > > > > indexes) and your wiki pages/attachment filesystem. Also, by default > > > > there's a caching layer in front of the file system access to pages > > > > and attachments, ehcache based. That should be tuned too in order to > > > > share the cache among your wiki instances. > > > > > > > > As for the wiki installation, the wiki page dir you note on the > > > > installation is the path were the wiki pages should be extracted. I > > > > don't have the installation page on my head now, so perhaps the > > > > behaviour is different.. Also, I noticed you opened a ticket a few > > > > days ago regarding installation, so there's also that (I'll try to > > > > look at it thie week btw). > > > > > > > > Last, regarding container based authentication, it's definitely > > > > possible. We have some integration tests [#2] that run through several > > > > JSPWiki instances. The "-cma-" ones are those configured to use > > > > container managed authentication. > > > > > > > > > > > > HTH, > > > > juan pablo > > > > > > > > [#2] https://github.com/apache/jspwiki/tree/master/jspwiki-it-tests > > > > > > > > On Sun, Mar 17, 2024 at 9:35 PM Alex O'Ree <alexo...@apache.org> > > wrote: > > > > > > > > > > I think that my issue was during installation, the default pages did > > > not > > > > > install, so i left with a blank wiki. I checked out the sources and > > > > copied > > > > > the default wiki page set and now things are a bit more put together > > > and > > > > > featureful. > > > > > > > > > > is there a way to use servlet container based authentication or just > > > use > > > > > the container provided servlet request user principle? > > > > > > > > > > > > > > > On Sun, Mar 17, 2024 at 10:46 AM Alex O'Ree <alexo...@apache.org> > > > wrote: > > > > > > > > > > > thanks for the info. looks like plugin installation is more > > developer > > > > > > oriented, not really an easy administrative task. i was hoping for > > > > > > something like a jenkins plugin setup where it's a one click > > install > > > > type > > > > > > of thing. not really a problem. > > > > > > > > > > > > using file system based storage (or database), and there's more > > than > > > > one > > > > > > instance of jsp wiki, say for rolling upgrades or load balancing, > > is > > > > there > > > > > > a way to notify other instances of changed content and/or index > > needs > > > > to be > > > > > > updated? > > > > > > > > > > > > On Tue, Mar 12, 2024 at 3:38 PM Juan Pablo Santos Rodríguez < > > > > > > juanpablo.san...@gmail.com> wrote: > > > > > > > > > > > >> Hi Alex! > > > > > >> > > > > > >> thanks for your interest in JSPWiki! :-) As for your questions: > > > > > >> > > > > > >> Are there any administrative capabilities? like pages to see how > > > much > > > > > >> stuff exists in the wiki? > > > > > >> for the latter, that can be accomplished via plugin [#1]. IIRC, > > The > > > > > >> default set of wiki pages contains pages for page index, recent > > and > > > > > >> changes / full history and a system info page with a some more > > wiki > > > > > >> information. You can see all of them at jspwiki-wiki.apache.org, > > on > > > > > >> the left menu, inside the special pages box. Don't know if you're > > > > > >> looking for something else though > > > > > >> > > > > > >> Ability to preload content? backup/restore? > > > > > >> Pages/Attachment by default are stored on files inside a > > directory. > > > > > >> The initial page load consists on unzipping a file inside a > > folder, > > > so > > > > > >> nothing stops you from putting there more pages. For new pages to > > be > > > > > >> picked up you should restart your jspwiki instance, so they get > > > picked > > > > > >> up by the indexer. There aren't any in-built capabilities to > > > > > >> import/export pages or backup/restore, you have to take care of > > that > > > > > >> outside JSPWiki. Also, I've said pages are stored on disk (the > > page > > > > > >> and attachment providers), but you can provide your own > > > > > >> page/attachment provider implementation > > > > > >> > > > > > >> User management and permissions setup? > > > > > >> Please see [#2] all related to Identity management, groups, ACLs > > > > > >> (application-wide or per page), authentication, etc. > > > > > >> > > > > > >> I'd also add the things that I like most from JSPWiki: > > > > > >> * very, very easy to use and setup > > > > > >> * almost every moving part of JSPWiki is customisable and can be > > > > > >> replaced with another implementation, 3rd party or not (2 page > > > > > >> providers, 3 search indexers, two wiki syntaxis, plugins, filters) > > > > > >> * deployment options (war, portable binaries, docker images) > > > > > >> * comprehensive security options > > > > > >> > > > > > >> > > > > > >> HTH, > > > > > >> juan pablo > > > > > >> > > > > > >> > > > > > >> [#1] > > https://jspwiki-wiki.apache.org/Wiki.jsp?page=Category.Plugins > > > > > >> [#2 < > > > > https://jspwiki-wiki.apache.org/Wiki.jsp?page=Category.Plugins[#2>] > > > > > >> https://jspwiki-wiki.apache.org/Wiki.jsp?page=Wiki.Admin.Security > > > > > >> > > > > > >> On Tue, Mar 12, 2024 at 12:14 AM Alex O'Ree <alexo...@apache.org> > > > > wrote: > > > > > >> > > > > > > >> > I'm shopping around for a java based wiki solution. I've found > > > > xwiki and > > > > > >> > seems pretty capable, but i've always been a fan of asf projects > > > so > > > > i'm > > > > > >> > digging deep into jspwiki. > > > > > >> > > > > > > >> > Are there any administrative capabilities? like pages to see how > > > > much > > > > > >> stuff > > > > > >> > exists in the wiki? > > > > > >> > Ability to preload content? backup/restore? > > > > > >> > User management and permissions setup? > > > > > >> > > > > > > > > > > > > > > >
