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