jspwiki.workDir = ${catalina.base}/work/Catalina/localhost/JSPWiki
so yes, it's cleaned when in run the script.
the script does the following
from jspwiki, mvn clean install -DskipTests=true
rd /s /q tomcat/webapps/JSPWIki
rd /s /q tomcat/webapps/temp
rd /s /q tomcat/webapps/work
copy jspwiki war to tomcat webapps directory
rd is the windows equivalent to rm -rf
here's the config file
jspwiki.applicationName = Help wiki
jspwiki.fileSystemProvider.pageDir = ${catalina.base}/wikistorage
jspwiki.workDir = ${catalina.base}/work/Catalina/localhost/JSPWiki
jspwiki.basicAttachmentProvider.storageDir = ${catalina.base}/wikistorage
jspwiki.pageProvider = VersioningFileProvider
jspwiki.usePageCache = false
jspwiki.renderingManager.useCache = false
jspwiki-x.adminui.enable=true
jspwiki-x.securityconfig.enable=true
jspwiki.cache.enable=false
and the problem persists
On Sun, Sep 8, 2024 at 12:02 PM Juan Pablo Santos Rodríguez <
juanpablo.san...@gmail.com> wrote:
> Hi Alex,
>
> yes that's the behaviour, caching is turned on by default; also, IIRC,
> it's filled on demand, although Lucene starts indexing all pages on
> init and that ends up requesting all pages. To rule out the cache,
> would you mind starting your jspwiki instance passing
> jspwiki.cache.enable = false to your jspwiki-custom.properties and see
> if the issue persists? Also, how many pages wiki pages do you
> initially have? do the pages not showing up correspond with those
> files not following the case sensitive pattern?
>
> oh now that I think of it, one more thing, does jspwiki.workDir get
> cleaned by your script (I suspect yes, but just in case)?
> ReferenceManager files live there so may be those are the ones messing
> up?
>
> best regards,
> juan pablo
>
> On Sun, Sep 8, 2024 at 5:32 PM Alex O'Ree <alexo...@apache.org> wrote:
> >
> > If i'm understanding correctly, the cache file lives in the tmp
> directory.
> > If it's not in the cache, it won't show up
> > Correct?
> >
> > I have a script that blows out the tmp and work directory of tomcat. Some
> > (preloaded) wiki pages show up and others do not. maybe i'll record a
> video
> > of it. to more clearly demonstrate because i'm at a loss for the
> > inconsistent behavior
> >
> > and this is all on windows. i have no cache settings in the
> > jspwiki-custom.properties file either. Is the default cache on or cache
> off?
> >
> > I would expect the cache to either populate on start up or to populate on
> > demand (i.e. the first request for a page hits disk, is then cached, and
> > then we are up and running.
> >
> >
> > On Sun, Sep 8, 2024 at 10:32 AM Juan Pablo Santos Rodríguez <
> > juanpablo.san...@gmail.com> wrote:
> >
> > > Hi!
> > >
> > > the default ehcache config file is located at [#1], by default ehcache
> > > files are stored at ${java.io.tmpdir}. The link to non-existent ->
> > > open to edit page -> save -> normal is usually due to pages not being
> > > in the cache, where the save puts them in.
> > >
> > > Said that, the default page / attachment manager relies on direct
> > > calls to the IO API, except for the mangleName method, where the page
> > > name is the same as the file name. I don't recall the internals of the
> > > page manager right now so it could be possible that, on case
> > > unsensitive file systems, you could end up in a situation like you
> > > described, if the pages come from outside. Also, I'm not completely
> > > sure, but there's the possibility that by saving the page you are
> > > ending up with different "pages" (About, about, aBouT), that are
> > > backed to the same file, but for JSPWiki may still be referred as 3
> > > different pages, i.e About with 3 referring pages, about with 2, aBouT
> > > with 4. A quick check to the output of the Index plugin would confirm
> > > this end, and if that's the case, I'm not sure lower-casing the file
> > > would fix it.
> > >
> > > Coming with a custom predefined set of pages shouldn't be an issue, we
> > > ship an initial set of pages to get up and running ASAP, but there
> > > isn't any special about it, is just a bunch of txt files. Any other
> > > bunch of txt files should behave the same way.
> > >
> > > Finally, regarding those two pages you mention, they seem like pages
> > > created from links. The second one gets shown if you don't have
> > > defined that wiki variable on the jspwiki logo on the top left corner
> > > of every page. As for the first one, maybe #$% is referenced somewhere
> > > in your pages?
> > >
> > > HTH,
> > > juan pablo
> > >
> > >
> > > [#1]:
> > >
> https://github.com/apache/jspwiki/blob/master/jspwiki-cache/src/main/resources/ehcache-jspwiki.xml
> > >
> > > On Mon, Sep 2, 2024 at 7:45 PM Alex O'Ree <alexo...@apache.org> wrote:
> > > >
> > > > Only thing that was logged that seemed out of the ordinary is the
> > > following
> > > > G:\jspwiki-test\apache-tomcat-9.0.86\wikistorage\%23%24%25.txt
> > > >
> > >
> G:\jspwiki-test\apache-tomcat-9.0.86\wikistorage\No+such+variable%3A+No+variable+jspwiki.frontPage+defined..txt
> > > >
> > > >
> > > > not entirely sure where these are coming from.
> > > >
> > > >
> > > > On Mon, Sep 2, 2024 at 9:32 AM Alex O'Ree <alexo...@apache.org>
> wrote:
> > > >
> > > > > I searched and couldn't find any file named ehcache. Where abouts
> > > should
> > > > > it be located?
> > > > >
> > > > > I also edited the source to log every time page exists is called.
> For
> > > the
> > > > > specific file in question (UnusedPages.txt) it prints that it
> exists. I
> > > > > also stepped through the code and it looks like it's loading the
> > > content
> > > > > just fine and calling the renderer. I'm baffled with this one
> > > > >
> > > > > I also tried searching for the page not found error message and
> trying
> > > to
> > > > > determine why but still couldn't locate the reason why.
> > > > >
> > > > > On Thu, Aug 22, 2024 at 6:32 PM Alex O'Ree <alexo...@apache.org>
> > > wrote:
> > > > >
> > > > >> This happens at first bootup with no cache files.
> > > > >>
> > > > >> Nothing in the logs to indicate a problem on debug level.
> > > > >>
> > > > >> I noticed that JSPWiki does some calculations based on the
> requested
> > > page
> > > > >> to try and find a file on disk. Looks like this happens somewhere
> > > around
> > > > >> AbstractFileProvider#mangleName but there doesn't seem to be any
> > > check for
> > > > >> case insensitivity. In this case, the files were created on
> windows,
> > > but
> > > > >> served up on linux.
> > > > >>
> > > > >> I can PR a case for this to normalize to lower case or something
> like
> > > > >> that if you want
> > > > >>
> > > > >> On Thu, Aug 22, 2024, 7:36 AM Juan Pablo Santos Rodríguez <
> > > > >> juanpablo.san...@gmail.com> wrote:
> > > > >>
> > > > >>> Hi!
> > > > >>>
> > > > >>> As for the 1st issue, most probably is due to caching being
> turned
> > > on.
> > > > >>> Deleting the ehcache files prior to starting tomcat up should
> fix the
> > > > >>> issue.
> > > > >>>
> > > > >>> As for the 2nd issue, sounds like a very probable cause, log
> should
> > > > >>> clarify
> > > > >>> that.
> > > > >>>
> > > > >>> Cheers,
> > > > >>> juan pablo
> > > > >>>
> > > > >>> El jue, 22 ago 2024, 1:43, Alex O'Ree <alexo...@apache.org>
> > > escribió:
> > > > >>>
> > > > >>> > Is there anything special i need to know when creating files
> > > outside of
> > > > >>> > jspwiki and then copying them into the wiki storage location?
> > > > >>> >
> > > > >>> > i'm seeing some strange behavior. If i link to the page that
> > > exists on
> > > > >>> > disk, the link will show as a non-existent article. If i click
> the
> > > edit
> > > > >>> > button, i'll get the content of the file on disk. If i press
> save
> > > (no
> > > > >>> > changes), it will still register as a non-existent file. If i
> > > attempt
> > > > >>> to
> > > > >>> > create/edit it again, then change the file slightly, then save,
> > > > >>> everything
> > > > >>> > works as normal.
> > > > >>> >
> > > > >>> > I'm also seeing some strange issues with files loading with
> > > jspwiki on
> > > > >>> > windows and not loading on jspwiki on linux. This might be the
> fact
> > > > >>> that
> > > > >>> > the file system is not case sensitive on windows.
> > > > >>> >
> > > > >>> > are any of these known issues?
> > > > >>> >
> > > > >>>
> > > > >>
> > >
>
