Re: [External] Re: Search not working on unmodified files
I found this one:
https://jar-download.com/artifacts/org.apache.jspwiki/jspwiki-war/2.10.1/source-code/ehcache.xml
--
-jim
Jim Willeke
On Thu, Apr 21, 2022 at 6:41 AM Andrew Ducker <
andrew_duc...@thephoenixgroup.com> wrote:
> Is there an example ehcache file somewhere? It doesn’t get created
> anywhere automatically that I can see, and it’s not in the
> https://jspwiki-wiki.apache.org/Wiki.jsp?page=Configuration documentation.
>
> Cheers,
>
> Andy
>
> From: Jim Willeke [mailto:j...@willeke.com]
> Sent: 20 April 2022 21:35
> To: user@jspwiki.apache.org
> Subject: Re: [External] Re: Search not working on unmodified files
>
> Alert! This is an external email sent from j...@willeke.com.
>
> I have observed something similar.
>
> Active Sessions 51
> Uptime 0d, 18h 30m 39s
> Number of pages 16390FYI: I too am seeing similar issues on 2.11.0-M8.
>
> I have NOT observed the issues on 2.10.1.
>
> The instance on version 2.10.1 (https://ldapwiki.com/wiki/SystemInfo<
> https://ldapwiki.com/wiki/SystemInfo>) is
> busy
> and the 2.11.0-M8 instance on has very low traffic.
>
> On the version 2.11.0-M8, Cleared the Lucene and work directory and
> restarted:
>
> Active Sessions 1
> Uptime 0d, 9h 11m 7s
> Number of pages 16499
>
> And one day later is shows:
> Active Sessions 1
> Uptime 1d, 10h 15m 43s
> Number of pages 46
>
> Then after using for a few minutes it now says:
> Active Sessions 1
> Uptime 1d, 10h 35m 52s
> Number of pages 16500
> (And yes one page was really added over the day)
>
> Where Number of pages is the [{$totalpages}]
>
> On the version 2.10.1 below is typical:
>
> Active Sessions 51
> Uptime 0d, 18h 30m 39s
> Number of pages 16390
>
> The ability to perform a search appears to be related to the
> [{$totalpages}] variable. That is when it shows 46 almost nothing can be
> found.
>
> I do see in the log:
> 2022-04-20 10:12:22,050 [main] WARN
> org.apache.wiki.providers.CachingProvider - seems
> Ldapwiki.jspwiki.pageCache can't hold all pages from your page repository,
> so we're delegating on the underlying provider instead. Please consider
> increasing your cache sizes on ehcache.xml to avoid this behaviour
>
> Which led to the finding the entry in
>
> https://github.com/apache/jspwiki/blob/master/jspwiki-main/src/main/resources/ini/jspwiki.properties
> <
> https://github.com/apache/jspwiki/blob/master/jspwiki-main/src/main/resources/ini/jspwiki.properties
> >
>
> "
> *# By default, JSPWiki caches will hold up to 1.000 elements, except the
> RSS cache, which will hold up to 250
> elementsjspwiki.cache.custom-config-file = jspwiki-ehcache.xml*"
>
> Both are behind nginx.
>
> --
> -jim
> Jim Willeke
>
>
> On Mon, Apr 18, 2022 at 3:40 PM Juan Pablo Santos Rodríguez <
> juanpablo.san...@gmail.com> wrote:
>
> > Hi!
> >
> > Looking at the source code, at jspwiki init, a full reindex is triggered.
> > The full reindex is only performed if the Lucene dir is empty. As this is
> > not the case, the initial full reindex isn't executed, and that's why you
> > are not seeing anything on searches. Pages saves do trigger a partial
> > reindex, though, so that explains the other side of the behaviour you're
> > seeing.
> >
> > What files are inside the Lucene dir? If there are Lucene index files,
> can
> > you open then with Luke to see where they came from, or the Lucene index
> > version, or any other information? Is there any chance other jspwiki
> > instance is using the same workDir?
> >
> > Last, emptying the lucene dir will enforce a full reindex next time the
> > background thread responsible of performing Lucene reindexes runs, but it
> > would be better to know why some files are getting created there outside
> > your jspwiki instance.
> >
> >
> > HTH,
> > juan pablo
> >
> > El lun., 18 abr. 2022 12:32, Andrew Ducker <
> > andrew_duc...@thephoenixgroup.com> escribió:
> >
> > > Hi,
> > >
> > > Thanks for the reply.
> > >
> > > We completely cleared the WorkDir, to be on the safe side, and that
> > didn’t
> > > help.
> > >
> > > It has access to the Work and wikipages folders, as it can create them
> > > from scratch, and you can edit the Wiki files.
> > >
> > > No mentions of “unable to index” in the logs.
> > >
> > > In the jspwiki-custom.properties file there’s the following:
> > > jspwiki.applicationName =IS Wiki
> > > jspwiki.baseURL =
> > > jspwiki.frontPa
Re: [External] Re: Search not working on unmodified files
I have observed something similar.
Active Sessions 51
Uptime 0d, 18h 30m 39s
Number of pages 16390FYI: I too am seeing similar issues on 2.11.0-M8.
I have NOT observed the issues on 2.10.1.
The instance on version 2.10.1 (https://ldapwiki.com/wiki/SystemInfo) is
busy
and the 2.11.0-M8 instance on has very low traffic.
On the version 2.11.0-M8, Cleared the Lucene and work directory and
restarted:
Active Sessions 1
Uptime 0d, 9h 11m 7s
Number of pages 16499
And one day later is shows:
Active Sessions 1
Uptime 1d, 10h 15m 43s
Number of pages 46
Then after using for a few minutes it now says:
Active Sessions 1
Uptime 1d, 10h 35m 52s
Number of pages 16500
(And yes one page was really added over the day)
Where Number of pages is the [{$totalpages}]
On the version 2.10.1 below is typical:
Active Sessions 51
Uptime 0d, 18h 30m 39s
Number of pages 16390
The ability to perform a search appears to be related to the
[{$totalpages}] variable. That is when it shows 46 almost nothing can be
found.
I do see in the log:
2022-04-20 10:12:22,050 [main] WARN
org.apache.wiki.providers.CachingProvider - seems
Ldapwiki.jspwiki.pageCache can't hold all pages from your page repository,
so we're delegating on the underlying provider instead. Please consider
increasing your cache sizes on ehcache.xml to avoid this behaviour
Which led to the finding the entry in
https://github.com/apache/jspwiki/blob/master/jspwiki-main/src/main/resources/ini/jspwiki.properties
"
*# By default, JSPWiki caches will hold up to 1.000 elements, except the
RSS cache, which will hold up to 250
elementsjspwiki.cache.custom-config-file = jspwiki-ehcache.xml*"
Both are behind nginx.
--
-jim
Jim Willeke
On Mon, Apr 18, 2022 at 3:40 PM Juan Pablo Santos Rodríguez <
juanpablo.san...@gmail.com> wrote:
> Hi!
>
> Looking at the source code, at jspwiki init, a full reindex is triggered.
> The full reindex is only performed if the Lucene dir is empty. As this is
> not the case, the initial full reindex isn't executed, and that's why you
> are not seeing anything on searches. Pages saves do trigger a partial
> reindex, though, so that explains the other side of the behaviour you're
> seeing.
>
> What files are inside the Lucene dir? If there are Lucene index files, can
> you open then with Luke to see where they came from, or the Lucene index
> version, or any other information? Is there any chance other jspwiki
> instance is using the same workDir?
>
> Last, emptying the lucene dir will enforce a full reindex next time the
> background thread responsible of performing Lucene reindexes runs, but it
> would be better to know why some files are getting created there outside
> your jspwiki instance.
>
>
> HTH,
> juan pablo
>
> El lun., 18 abr. 2022 12:32, Andrew Ducker <
> andrew_duc...@thephoenixgroup.com> escribió:
>
> > Hi,
> >
> > Thanks for the reply.
> >
> > We completely cleared the WorkDir, to be on the safe side, and that
> didn’t
> > help.
> >
> > It has access to the Work and wikipages folders, as it can create them
> > from scratch, and you can edit the Wiki files.
> >
> > No mentions of “unable to index” in the logs.
> >
> > In the jspwiki-custom.properties file there’s the following:
> > jspwiki.applicationName =IS Wiki
> > jspwiki.baseURL =
> > jspwiki.frontPage = Main
> > jspwiki.pageProvider =VersioningFileProvider
> > jspwiki.fileSystemProvider.pageDir =d:/JSPWiki/JSPWikiPages/Pages/wiki/
> > jspwiki.basicAttachmentProvider.storageDir
> > =d:/JSPWiki/JSPWikiPages/Attachments/wiki/
> > jspwiki.interWikiRef.Notes = Notes:%s
> > jspwiki.translatorReader.inlinePattern.1 = *.jpg
> > jspwiki.translatorReader.inlinePattern.2 = *.png
> > jspwiki.translatorReader.inlinePattern.3 = http://images.com/*
> > jspwiki.rss.generate =true
> > jspwiki.rss.channelDescription = IS Wiki
> > mail.from =@mail.from@
> > mail.smtp.host =@mail.smtp.host@
> > jspwiki.workDir =d:/JSPWiki/WorkingDirectory/iswiki/
> > jspwiki.security = jaas
> >
> > Lucene-specific things in the logs:
> > [INFO ] 2022-04-13 13:44:48.094 [main] o.a.w.s.LuceneSearchProvider -
> > Lucene enabled, cache will be in:
> d:\JSPWiki\WorkingDirectory\iswiki\lucene
> > [WARN ] 2022-04-13 13:44:48.725 [JSPWiki Lucene Indexer]
> > o.a.w.WikiBackgroundThread - Starting up background thread: JSPWiki
> Lucene
> > Indexer.
> > [INFO ] 2022-04-13 13:45:48.732 [JSPWiki Lucene Indexer]
> > o.a.w.s.LuceneSearchProvider - Files found in Lucene directory, not
> > reindexing.
> >
> > So could it be starting to index, thinking it’s already indexed (despite
> > the whole WorkingDir being cleared out) and then stopping
Re: java.lang.NoClassDefFoundError: javax/servlet/http/HttpSessionListener
That worked. Thanks -- -jim Jim Willeke On Sun, May 9, 2021 at 9:15 AM Ulf Dittmer wrote: > Tomcat 10 uses Jakarta EE, not Java EE, so it makes sense that it doesn't > know about the javax.servlet package. See > https://tomcat.apache.org/migration-10.html for how to make JavaEE-style > web apps run on Tomcat 10. > > On Sun, May 9, 2021 at 1:29 PM Jim Willeke wrote: > > > Server version name: Apache Tomcat/10.0.5 > > Server built: Mar 30 2021 08:19:50 UTC > > Server version number: 10.0.5.0 > > OS Name: Linux > > OS Version: 5.11.0-16-generic > > Architecture: amd64 > > Java Home: /usr/lib/jvm/java-17-openjdk-amd64 > > JVM Version: 17-ea+19-Ubuntu-1ubuntu1 > > JVM Vendor: Private Build > > CATALINA_BASE: /opt/tomcat/apache-tomcat-10.0.5 > > CATALINA_HOME: /opt/tomcat/apache-tomcat-10.0.5 > > JSPWiki.war 2.11.0.M8 > > > > SEVERE [http-nio-8080-exec-8] > > org.apache.catalina.core.StandardContext.listenerStart Error configuring > > application listener of class [org.apache.wiki.auth.SessionMonitor] > > java.lang.NoClassDefFoundError: javax/servlet/http/HttpSessionListener > > > > Any ideas? > > > > -- > > -jim > > Jim Willeke > > >
java.lang.NoClassDefFoundError: javax/servlet/http/HttpSessionListener
Server version name: Apache Tomcat/10.0.5 Server built: Mar 30 2021 08:19:50 UTC Server version number: 10.0.5.0 OS Name: Linux OS Version: 5.11.0-16-generic Architecture: amd64 Java Home: /usr/lib/jvm/java-17-openjdk-amd64 JVM Version: 17-ea+19-Ubuntu-1ubuntu1 JVM Vendor: Private Build CATALINA_BASE: /opt/tomcat/apache-tomcat-10.0.5 CATALINA_HOME: /opt/tomcat/apache-tomcat-10.0.5 JSPWiki.war 2.11.0.M8 SEVERE [http-nio-8080-exec-8] org.apache.catalina.core.StandardContext.listenerStart Error configuring application listener of class [org.apache.wiki.auth.SessionMonitor] java.lang.NoClassDefFoundError: javax/servlet/http/HttpSessionListener Any ideas? -- -jim Jim Willeke
Re: JSPWiki: Unable to load and setup properties from jspwiki.properties
I still get nothing to work and still the same issue. less /var/log/tomcat9/localhost.2021-03-17.log 17-Mar-2021 11:51:53.595 INFO [Catalina-utility-1] org.apache.catalina.core.ApplicationContext.log JSPWiki: Unable to load and setup properties from jspwiki.properties. Failed to start. Caused by: null; please check log files for better information. 17-Mar-2021 11:51:53.595 INFO [Catalina-utility-1] org.apache.catalina.core.ApplicationContext.log ERROR: Failed to create a Wiki engine: JSPWiki: Unable to load and setup properties from jspwiki.properties. Failed to start. Caused by: null; please check log files for better information. Any ideas? As far as I know, everything is the latest General Release. Uninstalled Tomcat9, Reinstalled, Last attempt I built JSWPWiki on the box it is running on and all tests passed. less /var/log/tomcat9/catalina.2021-03-17.log 17-Mar-2021 10:10:29.616 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Server version name: Apache Tomcat/9.0.31 (Ubuntu) 17-Mar-2021 10:10:29.620 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Server built: Oct 20 2020 12:27:39 UTC 17-Mar-2021 10:10:29.620 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Server version number: 9.0.31.0 17-Mar-2021 10:10:29.620 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log OS Name: Linux 17-Mar-2021 10:10:29.620 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log OS Version: 5.4.0-58-generic 17-Mar-2021 10:10:29.620 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Architecture: amd64 17-Mar-2021 10:10:29.621 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Java Home: /usr/lib/jvm/java-13-openjdk-amd64 17-Mar-2021 10:10:29.621 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log JVM Version: 13.0.4+8-Ubuntu-120.04 17-Mar-2021 10:10:29.621 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log JVM Vendor: Private Build 17-Mar-2021 10:10:29.621 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log CATALINA_BASE: /var/lib/tomcat9 17-Mar-2021 10:10:29.621 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log CATALINA_HOME: /usr/share/tomcat9 17-Mar-2021 10:10:29.659 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: --add-opens=java.base/java.lang=ALL-UNNAMED 17-Mar-2021 10:10:29.660 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: --add-opens=java.base/java.io=ALL-UNNAMED 17-Mar-2021 10:10:29.660 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: --add-opens=java.rmi/sun.rmi.transport=ALL-UNNAMED 17-Mar-2021 10:10:29.660 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djava.util.logging.config.file=/var/lib/tomcat9/conf/logging.properties 17-Mar-2021 10:10:29.661 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager 17-Mar-2021 10:10:29.661 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djava.awt.headless=true 17-Mar-2021 10:10:29.661 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djdk.tls.ephemeralDHKeySize=2048 17-Mar-2021 10:10:29.662 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djava.protocol.handler.pkgs=org.apache.catalina.webresources 17-Mar-2021 10:10:29.662 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Dorg.apache.catalina.security.SecurityListener.UMASK=0027 17-Mar-2021 10:10:29.662 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Dignore.endorsed.dirs= 17-Mar-2021 10:10:29.663 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Dcatalina.base=/var/lib/tomcat9 17-Mar-2021 10:10:29.663 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Dcatalina.home=/usr/share/tomcat9 17-Mar-2021 10:10:29.663 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djava.io.tmpdir=/tmp -- -jim Jim Willeke On Mon, Jan 11, 2021 at 3:28 PM Juan Pablo Santos Rodríguez < juanpablo.san...@gmail.com> wrote: > Hi, > > apologies on not answering before. Couple things to try: > > - would you mind start your tomcat instance passing as env variable > "log4j.rootCategory=DEBUG,ConsoleLog" and attach the contents of > catalina.out? You can see a couple examples on how to do this at [#1] > > - would you mind trying to start your JSPWiki with latest snapshot (you can > obtain it at [#2])? This snapshot should log the stacktrace, which should > at least give a hint of what is happening > > > HTH, > juan pablo > &
Re: JSPWiki: Unable to load and setup properties from jspwiki.properties
I am still stuck. Have repeated this process a few times and still obtain the same results. The file ldapwiki.war was deployed to /var/lib/tomcat9/webapps/ldapwiki.war -rw-r--r-- 1 root root 24143885 Dec 20 12:23 /var/lib/tomcat9/webapps/ldapwiki.war We see that the ldapwiki.war was expanded to: drwxr-x--- 10 tomcat tomcat 4096 Dec 20 12:25 ldapwiki/ When started we see: less /var/log/tomcat9/localhost.2021-01-01.log 01-Jan-2021 12:47:59.264 INFO [main] org.apache.catalina.core.ApplicationContext.log Assigning new engine to 1027332579 01-Jan-2021 12:48:00.149 INFO [main] org.apache.catalina.core.ApplicationContext.log JSPWiki: *Unable to load and setup properties from jspwiki.properties*. Failed to start. Caused by: null; please check log files for better information. Verified that the file exists: -rw-r- 1 tomcat tomcat 1055100 Dec 9 19:16 /var/lib/tomcat9/webapps/ldapwiki/WEB-INF/lib/jspwiki-main-2.11.0.M8.jar Verified that the jspwiki.properties file exists: jar tvf /var/lib/tomcat9/webapps/ldapwiki/WEB-INF/lib/jspwiki-main-2.11.0.M8.jar | grep 'jspwiki.properties' 44746 Wed Dec 09 19:16:24 UTC 2020 ini/jspwiki.properties Any ideas why Tomcat9 did not find the jspwiki.properties file? -- -jim Jim Willeke On Sun, Dec 27, 2020 at 3:34 PM Juan Pablo Santos Rodríguez < juanpablo.san...@gmail.com> wrote: > Hi, > > it's located in > JSPWiki.war!WEB-INF/lib/jspwiki-main-2.11.0.M8.jar!ini/jspwiki.properties > > > br, > juan pablo > > On Sun, Dec 27, 2020 at 12:46 PM Jim Willeke wrote: > > > Where is jspwiki.properties located within the JSPWiki.war file? > > > > I see it nowhere in > > https://apache.osuosl.org/jspwiki/2.11.0.M8/binaries/webapp/JSPWiki.war > > > > -- > > -jim > > Jim Willeke > > > > > > On Mon, Dec 21, 2020 at 3:22 PM Jim Willeke wrote: > > > > > And that is what I have attempted. > > > And even that does not work. > > > -- > > > -jim > > > Jim Willeke > > > > > > > > > On Mon, Dec 21, 2020 at 12:29 PM Juan Pablo Santos Rodríguez < > > > juanpablo.san...@gmail.com> wrote: > > > > > >> Hi, > > >> > > >> given that the OS, Let's Encrypt, Tomcat, etc. are correctly > installed, > > >> I'd > > >> begin with a simple, non-customized jspwiki war to make sure it > deploys > > >> OK. If there are problems, what's the log saying? Are you able to set > it > > >> to > > >> debug level (through JAVA_OPTS, or whatever method)? > > >> > > >> Once you have that, I'd begin with JSPWiki customizations, f.ex., to > set > > >> the page directory you should be using a jspwiki-custom.properties > file. > > >> Where is it located? (the other option is that you've modified the > > >> ini/jspwiki.properties inside the jspwiki-main jar, but that's > > >> discouraged, > > >> since it > > >> would made JSPWiki upgrades more complex). > > >> > > >> > > >> best regards, > > >> juan pablo > > >> > > >> On Sat, Dec 19, 2020 at 10:44 PM Jim Willeke wrote: > > >> > > >> > The issue I have always run into is that upgrading is a huge pain. > > >> > It is never Just JSPwiki but all the dependencies. > > >> > > > >> > These are the facets for upgrades I came up with: > > >> > > > >> >- Operating System > > >> >- let's Encrypt > > >> >- nginx > > >> >- Java > > >> >- Tomcat > > >> >- JSPWiki > > >> > - jspwiki engine > > >> > - jspwiki pages > > >> > > > >> > Frankly speaking, this is a real pain. > > >> > > > >> > Install setup created: > > >> > CATALINA_BASE: /var/lib/tomcat9 > > >> > CATALINA_HOME: /usr/share/tomcat9 > > >> > > > >> > tomcat user home as: > > >> > /opt/tomcat and using /bin/false > > >> > > > >> > And I thought page directory should be: > > >> > /opt/tomcat/jspwikipages/ldapwiki/ > > >> > > > >> > Then I should be able to run: > > >> > > > >> >- sudo apt update > > >> >- sudo apt upgrade > > >> > > > >> > and the Operating system, let's Encrypt, nginx, Tomcat, and Java > would > > >> all > &
Re: JSPWiki: Unable to load and setup properties from jspwiki.properties
Where is jspwiki.properties located within the JSPWiki.war file? I see it nowhere in https://apache.osuosl.org/jspwiki/2.11.0.M8/binaries/webapp/JSPWiki.war -- -jim Jim Willeke On Mon, Dec 21, 2020 at 3:22 PM Jim Willeke wrote: > And that is what I have attempted. > And even that does not work. > -- > -jim > Jim Willeke > > > On Mon, Dec 21, 2020 at 12:29 PM Juan Pablo Santos Rodríguez < > juanpablo.san...@gmail.com> wrote: > >> Hi, >> >> given that the OS, Let's Encrypt, Tomcat, etc. are correctly installed, >> I'd >> begin with a simple, non-customized jspwiki war to make sure it deploys >> OK. If there are problems, what's the log saying? Are you able to set it >> to >> debug level (through JAVA_OPTS, or whatever method)? >> >> Once you have that, I'd begin with JSPWiki customizations, f.ex., to set >> the page directory you should be using a jspwiki-custom.properties file. >> Where is it located? (the other option is that you've modified the >> ini/jspwiki.properties inside the jspwiki-main jar, but that's >> discouraged, >> since it >> would made JSPWiki upgrades more complex). >> >> >> best regards, >> juan pablo >> >> On Sat, Dec 19, 2020 at 10:44 PM Jim Willeke wrote: >> >> > The issue I have always run into is that upgrading is a huge pain. >> > It is never Just JSPwiki but all the dependencies. >> > >> > These are the facets for upgrades I came up with: >> > >> >- Operating System >> >- let's Encrypt >> >- nginx >> >- Java >> >- Tomcat >> >- JSPWiki >> > - jspwiki engine >> > - jspwiki pages >> > >> > Frankly speaking, this is a real pain. >> > >> > Install setup created: >> > CATALINA_BASE: /var/lib/tomcat9 >> > CATALINA_HOME: /usr/share/tomcat9 >> > >> > tomcat user home as: >> > /opt/tomcat and using /bin/false >> > >> > And I thought page directory should be: >> > /opt/tomcat/jspwikipages/ldapwiki/ >> > >> > Then I should be able to run: >> > >> >- sudo apt update >> >- sudo apt upgrade >> > >> > and the Operating system, let's Encrypt, nginx, Tomcat, and Java would >> all >> > be upgraded as needed. >> > >> > any thoughts? >> > >> > -- >> > -jim >> > Jim Willeke >> > >> > >> > On Thu, Dec 17, 2020 at 2:19 PM Juan Pablo Santos Rodríguez < >> > juanpablo.san...@gmail.com> wrote: >> > >> > > Hi Jim, >> > > >> > > I've always have worked with an environment in which CATALINA_BASE == >> > > CATALINA_HOME, said that, yes, your setup seems correct to >> > > me (also 2 min of google https://stackoverflow.com/a/29398713 seem to >> > > confirm that). >> > > >> > > >> > > best regards, >> > > juan pablo >> > > >> > > On Thu, Dec 17, 2020 at 2:19 PM Jim Willeke wrote: >> > > >> > > > My setup is now: >> > > > DISTRIB_DESCRIPTION="Ubuntu 20.04.1 LTS" >> > > > Apache Tomcat/9.0.31 (Ubuntu) >> > > > Java Home: /usr/lib/jvm/java-13-openjdk-amd64 >> > > > JVM Version:13.0.4+8-Ubuntu-120.04 >> > > > CATALINA_BASE: /var/lib/tomcat9 >> > > > CATALINA_HOME: /usr/share/tomcat9 >> > > > >> > > > So I am assuming we would place the jspwiki.war (regardless of name) >> > into >> > > > the >> > > > $CATALINA_BASE/tomcat9/webapps/ >> > > > And that is where we would expect to see the folder "jspwiki" >> created >> > > when >> > > > the war is expanded. >> > > > >> > > > And the jspwiki.war would be owned by tomcat. >> > > > Is that correct? >> > > > >> > > > -- >> > > > -jim >> > > > Jim Willeke >> > > > >> > > > >> > > > On Tue, Dec 15, 2020 at 3:44 PM Juan Pablo Santos Rodríguez < >> > > > juanpablo.san...@gmail.com> wrote: >> > > > >> > > > > Hi Jim, >> > > > > >> > > > > apologies, the e-mail got stuck in drafts and I didn't notice :-/ >> > > > > >> > > > >
Re: JSPWiki: Unable to load and setup properties from jspwiki.properties
And that is what I have attempted. And even that does not work. -- -jim Jim Willeke On Mon, Dec 21, 2020 at 12:29 PM Juan Pablo Santos Rodríguez < juanpablo.san...@gmail.com> wrote: > Hi, > > given that the OS, Let's Encrypt, Tomcat, etc. are correctly installed, I'd > begin with a simple, non-customized jspwiki war to make sure it deploys > OK. If there are problems, what's the log saying? Are you able to set it to > debug level (through JAVA_OPTS, or whatever method)? > > Once you have that, I'd begin with JSPWiki customizations, f.ex., to set > the page directory you should be using a jspwiki-custom.properties file. > Where is it located? (the other option is that you've modified the > ini/jspwiki.properties inside the jspwiki-main jar, but that's discouraged, > since it > would made JSPWiki upgrades more complex). > > > best regards, > juan pablo > > On Sat, Dec 19, 2020 at 10:44 PM Jim Willeke wrote: > > > The issue I have always run into is that upgrading is a huge pain. > > It is never Just JSPwiki but all the dependencies. > > > > These are the facets for upgrades I came up with: > > > >- Operating System > >- let's Encrypt > >- nginx > >- Java > >- Tomcat > >- JSPWiki > > - jspwiki engine > > - jspwiki pages > > > > Frankly speaking, this is a real pain. > > > > Install setup created: > > CATALINA_BASE: /var/lib/tomcat9 > > CATALINA_HOME: /usr/share/tomcat9 > > > > tomcat user home as: > > /opt/tomcat and using /bin/false > > > > And I thought page directory should be: > > /opt/tomcat/jspwikipages/ldapwiki/ > > > > Then I should be able to run: > > > >- sudo apt update > >- sudo apt upgrade > > > > and the Operating system, let's Encrypt, nginx, Tomcat, and Java would > all > > be upgraded as needed. > > > > any thoughts? > > > > -- > > -jim > > Jim Willeke > > > > > > On Thu, Dec 17, 2020 at 2:19 PM Juan Pablo Santos Rodríguez < > > juanpablo.san...@gmail.com> wrote: > > > > > Hi Jim, > > > > > > I've always have worked with an environment in which CATALINA_BASE == > > > CATALINA_HOME, said that, yes, your setup seems correct to > > > me (also 2 min of google https://stackoverflow.com/a/29398713 seem to > > > confirm that). > > > > > > > > > best regards, > > > juan pablo > > > > > > On Thu, Dec 17, 2020 at 2:19 PM Jim Willeke wrote: > > > > > > > My setup is now: > > > > DISTRIB_DESCRIPTION="Ubuntu 20.04.1 LTS" > > > > Apache Tomcat/9.0.31 (Ubuntu) > > > > Java Home: /usr/lib/jvm/java-13-openjdk-amd64 > > > > JVM Version:13.0.4+8-Ubuntu-120.04 > > > > CATALINA_BASE: /var/lib/tomcat9 > > > > CATALINA_HOME: /usr/share/tomcat9 > > > > > > > > So I am assuming we would place the jspwiki.war (regardless of name) > > into > > > > the > > > > $CATALINA_BASE/tomcat9/webapps/ > > > > And that is where we would expect to see the folder "jspwiki" created > > > when > > > > the war is expanded. > > > > > > > > And the jspwiki.war would be owned by tomcat. > > > > Is that correct? > > > > > > > > -- > > > > -jim > > > > Jim Willeke > > > > > > > > > > > > On Tue, Dec 15, 2020 at 3:44 PM Juan Pablo Santos Rodríguez < > > > > juanpablo.san...@gmail.com> wrote: > > > > > > > > > Hi Jim, > > > > > > > > > > apologies, the e-mail got stuck in drafts and I didn't notice :-/ > > > > > > > > > > the contents of the work folder were to see which war was deployed > if > > > > > ldapwiki.war or folder.war.. The unfound jspwiki.properties file > > should > > > > be > > > > > inside the jspwiki-main jar, under the ini folder. > > > > > > > > > > As for starting tomcat passing some system properties and as it > seems > > > > that > > > > > the jspwiki.properties file can't be found when starting JSPWiki, > on > > > your > > > > > $TOMCAT_HOME/bin/catalina.sh file, locate the commented line were > the > > > > > JAVA_OPTS variable is set and uncomment it and set it to something > > > like: &
Re: JSPWiki: Unable to load and setup properties from jspwiki.properties
The issue I have always run into is that upgrading is a huge pain. It is never Just JSPwiki but all the dependencies. These are the facets for upgrades I came up with: - Operating System - let's Encrypt - nginx - Java - Tomcat - JSPWiki - jspwiki engine - jspwiki pages Frankly speaking, this is a real pain. Install setup created: CATALINA_BASE: /var/lib/tomcat9 CATALINA_HOME: /usr/share/tomcat9 tomcat user home as: /opt/tomcat and using /bin/false And I thought page directory should be: /opt/tomcat/jspwikipages/ldapwiki/ Then I should be able to run: - sudo apt update - sudo apt upgrade and the Operating system, let's Encrypt, nginx, Tomcat, and Java would all be upgraded as needed. any thoughts? -- -jim Jim Willeke On Thu, Dec 17, 2020 at 2:19 PM Juan Pablo Santos Rodríguez < juanpablo.san...@gmail.com> wrote: > Hi Jim, > > I've always have worked with an environment in which CATALINA_BASE == > CATALINA_HOME, said that, yes, your setup seems correct to > me (also 2 min of google https://stackoverflow.com/a/29398713 seem to > confirm that). > > > best regards, > juan pablo > > On Thu, Dec 17, 2020 at 2:19 PM Jim Willeke wrote: > > > My setup is now: > > DISTRIB_DESCRIPTION="Ubuntu 20.04.1 LTS" > > Apache Tomcat/9.0.31 (Ubuntu) > > Java Home: /usr/lib/jvm/java-13-openjdk-amd64 > > JVM Version:13.0.4+8-Ubuntu-120.04 > > CATALINA_BASE: /var/lib/tomcat9 > > CATALINA_HOME: /usr/share/tomcat9 > > > > So I am assuming we would place the jspwiki.war (regardless of name) into > > the > > $CATALINA_BASE/tomcat9/webapps/ > > And that is where we would expect to see the folder "jspwiki" created > when > > the war is expanded. > > > > And the jspwiki.war would be owned by tomcat. > > Is that correct? > > > > -- > > -jim > > Jim Willeke > > > > > > On Tue, Dec 15, 2020 at 3:44 PM Juan Pablo Santos Rodríguez < > > juanpablo.san...@gmail.com> wrote: > > > > > Hi Jim, > > > > > > apologies, the e-mail got stuck in drafts and I didn't notice :-/ > > > > > > the contents of the work folder were to see which war was deployed if > > > ldapwiki.war or folder.war.. The unfound jspwiki.properties file should > > be > > > inside the jspwiki-main jar, under the ini folder. > > > > > > As for starting tomcat passing some system properties and as it seems > > that > > > the jspwiki.properties file can't be found when starting JSPWiki, on > your > > > $TOMCAT_HOME/bin/catalina.sh file, locate the commented line were the > > > JAVA_OPTS variable is set and uncomment it and set it to something > like: > > > > > > JAVA_OPTS="$JAVA_OPTS -Dlog4j.rootCategory=DEBUG,ConsoleLog" and that > > > should be fine to start tomcat. > > > > > > Also, do you have any jspwiki-custom.properties file set? is so, how? > > > > > > Last but not least, would you mind trying with new 2.11.0.M8? it > > contains a > > > couple of serious fixes related to search indexing + workflows' > > persistence > > > on disk > > > > > > > > > best regards, > > > juan pablo > > > > > > On Mon, Dec 7, 2020 at 4:13 PM Jim Willeke wrote: > > > > > > > I changed to folder.war, as I was making a feeble attempt to hide > > details > > > > about ldapwiki. > > > > > > > > Not sure what you are looking for here: > > > > ll /var/lib/tomcat9/work/Catalina/localhost/ > > > > total 24 > > > > drwxr-x--- 6 tomcat tomcat 4096 Dec 4 10:43 ./ > > > > drwxr-x--- 3 tomcat tomcat 4096 Dec 4 09:49 ../ > > > > drwxr-x--- 3 tomcat tomcat 4096 Dec 4 11:55 host-manager/ > > > > drwxr-x--- 2 tomcat tomcat 4096 Dec 4 10:43 ldapwiki/ > > > > drwxr-x--- 3 tomcat tomcat 4096 Dec 6 10:48 manager/ > > > > drwxr-x--- 2 tomcat tomcat 4096 Dec 4 09:49 ROOT/ > > > > > > > > /var/lib/tomcat9/work/Catalina/localhost/ldapwiki/ > > > > total 8 > > > > drwxr-x--- 2 tomcat tomcat 4096 Dec 4 10:43 ./ > > > > drwxr-x--- 6 tomcat tomcat 4096 Dec 4 10:43 ../ > > > > > > > > Sorry, No idea how I would start tomcat using > > > > "-Dlog4j.rootCategory=DEBUG,ConsoleLog" > > > > > > > > systemctl status tomcat9 > > > > ● tomcat9.service - Apache Tomcat 9 Web Application Server > > > > Loaded: loaded (/lib/systemd/
Re: JSPWiki: Unable to load and setup properties from jspwiki.properties
My setup is now: DISTRIB_DESCRIPTION="Ubuntu 20.04.1 LTS" Apache Tomcat/9.0.31 (Ubuntu) Java Home: /usr/lib/jvm/java-13-openjdk-amd64 JVM Version:13.0.4+8-Ubuntu-120.04 CATALINA_BASE: /var/lib/tomcat9 CATALINA_HOME: /usr/share/tomcat9 So I am assuming we would place the jspwiki.war (regardless of name) into the $CATALINA_BASE/tomcat9/webapps/ And that is where we would expect to see the folder "jspwiki" created when the war is expanded. And the jspwiki.war would be owned by tomcat. Is that correct? -- -jim Jim Willeke On Tue, Dec 15, 2020 at 3:44 PM Juan Pablo Santos Rodríguez < juanpablo.san...@gmail.com> wrote: > Hi Jim, > > apologies, the e-mail got stuck in drafts and I didn't notice :-/ > > the contents of the work folder were to see which war was deployed if > ldapwiki.war or folder.war.. The unfound jspwiki.properties file should be > inside the jspwiki-main jar, under the ini folder. > > As for starting tomcat passing some system properties and as it seems that > the jspwiki.properties file can't be found when starting JSPWiki, on your > $TOMCAT_HOME/bin/catalina.sh file, locate the commented line were the > JAVA_OPTS variable is set and uncomment it and set it to something like: > > JAVA_OPTS="$JAVA_OPTS -Dlog4j.rootCategory=DEBUG,ConsoleLog" and that > should be fine to start tomcat. > > Also, do you have any jspwiki-custom.properties file set? is so, how? > > Last but not least, would you mind trying with new 2.11.0.M8? it contains a > couple of serious fixes related to search indexing + workflows' persistence > on disk > > > best regards, > juan pablo > > On Mon, Dec 7, 2020 at 4:13 PM Jim Willeke wrote: > > > I changed to folder.war, as I was making a feeble attempt to hide details > > about ldapwiki. > > > > Not sure what you are looking for here: > > ll /var/lib/tomcat9/work/Catalina/localhost/ > > total 24 > > drwxr-x--- 6 tomcat tomcat 4096 Dec 4 10:43 ./ > > drwxr-x--- 3 tomcat tomcat 4096 Dec 4 09:49 ../ > > drwxr-x--- 3 tomcat tomcat 4096 Dec 4 11:55 host-manager/ > > drwxr-x--- 2 tomcat tomcat 4096 Dec 4 10:43 ldapwiki/ > > drwxr-x--- 3 tomcat tomcat 4096 Dec 6 10:48 manager/ > > drwxr-x--- 2 tomcat tomcat 4096 Dec 4 09:49 ROOT/ > > > > /var/lib/tomcat9/work/Catalina/localhost/ldapwiki/ > > total 8 > > drwxr-x--- 2 tomcat tomcat 4096 Dec 4 10:43 ./ > > drwxr-x--- 6 tomcat tomcat 4096 Dec 4 10:43 ../ > > > > Sorry, No idea how I would start tomcat using > > "-Dlog4j.rootCategory=DEBUG,ConsoleLog" > > > > systemctl status tomcat9 > > ● tomcat9.service - Apache Tomcat 9 Web Application Server > > Loaded: loaded (/lib/systemd/system/tomcat9.service; enabled; vendor > > preset: enabled) > > Active: active (running) since Sun 2020-12-06 10:48:37 UTC; 1 day 4h > > ago > >Docs: https://tomcat.apache.org/tomcat-9.0-doc/index.html > > Process: 549 > ExecStartPre=/usr/libexec/tomcat9/tomcat-update-policy.sh > > (code=exited, status=0/SUCCESS) > >Main PID: 574 (java) > > Tasks: 37 (limit: 4620) > > Memory: 255.9M > > CGroup: /system.slice/tomcat9.service > > └─574 /usr/lib/jvm/default-java/bin/java > > -Djava.util.logging.config.file=/var/lib/tomcat9/conf/logging.properties > > -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager > > -Djava.awt.headless=true -Djdk.tls.ephemeralDHKe> > > > > > > -- > > -jim > > Jim Willeke > > > > > > On Mon, Dec 7, 2020 at 9:09 AM Juan Pablo Santos Rodríguez < > > juanpablo.san...@gmail.com> wrote: > > > > > Hi Jim, > > > > > > you mention initially that the war is deployed as folder.war instead of > > > ldapwiki.war, is that correct? What files are placed inside > > > $TOMCAT_HOME/work? Also, would you mind starting tomcat providing it a > > > "-Dlog4j.rootCategory=DEBUG,ConsoleLog" argument? > > > That should provide more information on catalina.out > > > > > > > > > best regards, > > > juan pablo > > > > > > On Sun, Dec 6, 2020 at 11:55 AM Jim Willeke wrote: > > > > > > > Here is what I see: > > > > > > > > less /var/log/tomcat9/catalina.2020-12-06.log > > > > 06-Dec-2020 10:48:43.248 INFO [main] > > > > org.apache.catalina.startup.HostConfig.deployDescriptor Deployment of > > > > deployment descriptor > > [/etc/tomcat9/Catalina/localhost/host-manager.xml] > > > > has fi
Re: JSPWiki: Unable to load and setup properties from jspwiki.properties
I changed to folder.war, as I was making a feeble attempt to hide details about ldapwiki. Not sure what you are looking for here: ll /var/lib/tomcat9/work/Catalina/localhost/ total 24 drwxr-x--- 6 tomcat tomcat 4096 Dec 4 10:43 ./ drwxr-x--- 3 tomcat tomcat 4096 Dec 4 09:49 ../ drwxr-x--- 3 tomcat tomcat 4096 Dec 4 11:55 host-manager/ drwxr-x--- 2 tomcat tomcat 4096 Dec 4 10:43 ldapwiki/ drwxr-x--- 3 tomcat tomcat 4096 Dec 6 10:48 manager/ drwxr-x--- 2 tomcat tomcat 4096 Dec 4 09:49 ROOT/ /var/lib/tomcat9/work/Catalina/localhost/ldapwiki/ total 8 drwxr-x--- 2 tomcat tomcat 4096 Dec 4 10:43 ./ drwxr-x--- 6 tomcat tomcat 4096 Dec 4 10:43 ../ Sorry, No idea how I would start tomcat using "-Dlog4j.rootCategory=DEBUG,ConsoleLog" systemctl status tomcat9 ● tomcat9.service - Apache Tomcat 9 Web Application Server Loaded: loaded (/lib/systemd/system/tomcat9.service; enabled; vendor preset: enabled) Active: active (running) since Sun 2020-12-06 10:48:37 UTC; 1 day 4h ago Docs: https://tomcat.apache.org/tomcat-9.0-doc/index.html Process: 549 ExecStartPre=/usr/libexec/tomcat9/tomcat-update-policy.sh (code=exited, status=0/SUCCESS) Main PID: 574 (java) Tasks: 37 (limit: 4620) Memory: 255.9M CGroup: /system.slice/tomcat9.service └─574 /usr/lib/jvm/default-java/bin/java -Djava.util.logging.config.file=/var/lib/tomcat9/conf/logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djava.awt.headless=true -Djdk.tls.ephemeralDHKe> -- -jim Jim Willeke On Mon, Dec 7, 2020 at 9:09 AM Juan Pablo Santos Rodríguez < juanpablo.san...@gmail.com> wrote: > Hi Jim, > > you mention initially that the war is deployed as folder.war instead of > ldapwiki.war, is that correct? What files are placed inside > $TOMCAT_HOME/work? Also, would you mind starting tomcat providing it a > "-Dlog4j.rootCategory=DEBUG,ConsoleLog" argument? > That should provide more information on catalina.out > > > best regards, > juan pablo > > On Sun, Dec 6, 2020 at 11:55 AM Jim Willeke wrote: > > > Here is what I see: > > > > less /var/log/tomcat9/catalina.2020-12-06.log > > 06-Dec-2020 10:48:43.248 INFO [main] > > org.apache.catalina.startup.HostConfig.deployDescriptor Deployment of > > deployment descriptor [/etc/tomcat9/Catalina/localhost/host-manager.xml] > > has finished in [416] ms > > 06-Dec-2020 10:48:43.252 INFO [main] > > org.apache.catalina.startup.HostConfig.deployWAR Deploying web > application > > archive [/var/lib/tomcat9/webapps/ldapwiki.war] > > 06-Dec-2020 10:48:45.254 INFO [main] > > org.apache.jasper.servlet.TldScanner.scanJars At least one JAR was > scanned > > for TLDs yet contained no TLDs. Enable debug logging for this logger for > a > > complete list of JARs that were scanned but no TLDs were found in them. > > Skipping unneeded JARs during scanning can improve startup time and JSP > > compilation time. > > 06-Dec-2020 10:48:46.202 SEVERE [main] > > org.apache.catalina.core.StandardContext.startInternal One or more > Filters > > failed to start. Full details will be found in the appropriate container > > log file > > 06-Dec-2020 10:48:46.202 SEVERE [main] > > org.apache.catalina.core.StandardContext.startInternal Context > [/ldapwiki] > > startup failed due to previous errors > > 06-Dec-2020 10:48:46.206 WARNING [main] > > org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads > The > > web application [ldapwiki] appears to have started a thread named > > [__DEFAULT__] but has failed to stop it. This is very likely to create a > > memory leak. Stack trace of thread: > > java.base@11.0.9.1/java.lang.Object.wait(Native Method) > > java.base@11.0.9.1/java.lang.Object.wait(Object.java:328) > > java.base@11.0.9.1/java.util.TimerThread.mainLoop(Timer.java:527) > > java.base@11.0.9.1/java.util.TimerThread.run(Timer.java:506) > > 06-Dec-2020 10:48:46.206 WARNING [main] > > org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads > The > > web application [ldapwiki] appears to have started a thread named > > [Statistics Thread-__DEFAULT__-1] but has failed to stop it. This is very > > likely to create a memory leak. Stack trace of thread: > > java.base@11.0.9.1/jdk.internal.misc.Unsafe.park(Native Method) > > > > > > > java.base@11.0.9.1/java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:234) > > > > > > > java.base@11.0.9.1/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2123) > > > > > > > java.base@11.0.9.1/java.util.co
Re: JSPWiki: Unable to load and setup properties from jspwiki.properties
Here is what I see: less /var/log/tomcat9/catalina.2020-12-06.log 06-Dec-2020 10:48:43.248 INFO [main] org.apache.catalina.startup.HostConfig.deployDescriptor Deployment of deployment descriptor [/etc/tomcat9/Catalina/localhost/host-manager.xml] has finished in [416] ms 06-Dec-2020 10:48:43.252 INFO [main] org.apache.catalina.startup.HostConfig.deployWAR Deploying web application archive [/var/lib/tomcat9/webapps/ldapwiki.war] 06-Dec-2020 10:48:45.254 INFO [main] org.apache.jasper.servlet.TldScanner.scanJars At least one JAR was scanned for TLDs yet contained no TLDs. Enable debug logging for this logger for a complete list of JARs that were scanned but no TLDs were found in them. Skipping unneeded JARs during scanning can improve startup time and JSP compilation time. 06-Dec-2020 10:48:46.202 SEVERE [main] org.apache.catalina.core.StandardContext.startInternal One or more Filters failed to start. Full details will be found in the appropriate container log file 06-Dec-2020 10:48:46.202 SEVERE [main] org.apache.catalina.core.StandardContext.startInternal Context [/ldapwiki] startup failed due to previous errors 06-Dec-2020 10:48:46.206 WARNING [main] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The web application [ldapwiki] appears to have started a thread named [__DEFAULT__] but has failed to stop it. This is very likely to create a memory leak. Stack trace of thread: java.base@11.0.9.1/java.lang.Object.wait(Native Method) java.base@11.0.9.1/java.lang.Object.wait(Object.java:328) java.base@11.0.9.1/java.util.TimerThread.mainLoop(Timer.java:527) java.base@11.0.9.1/java.util.TimerThread.run(Timer.java:506) 06-Dec-2020 10:48:46.206 WARNING [main] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The web application [ldapwiki] appears to have started a thread named [Statistics Thread-__DEFAULT__-1] but has failed to stop it. This is very likely to create a memory leak. Stack trace of thread: java.base@11.0.9.1/jdk.internal.misc.Unsafe.park(Native Method) java.base@11.0.9.1/java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:234) java.base@11.0.9.1/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2123) java.base@11.0.9.1/java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1182) java.base@11.0.9.1/java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:899) java.base@11.0.9.1/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1054) java.base@11.0.9.1/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1114) java.base@11.0.9.1/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) java.base@11.0.9.1/java.lang.Thread.run(Thread.java:834) 06-Dec-2020 10:48:46.215 INFO [main] org.apache.catalina.startup.HostConfig.deployWAR Deployment of web application archive [/var/lib/tomcat9/webapps/ldapwiki.war] has finished in [2,963] ms -- -jim Jim Willeke On Sat, Dec 5, 2020 at 10:23 AM Harry Metske wrote: > does catalina.out reveal any more detail? > > regards, > Harry > > On Fri, 4 Dec 2020 at 13:31, Jim Willeke wrote: > > > New install. > > Apache Tomcat/9.0.31 (Ubuntu) > > 11.0.9.1+1-Ubuntu-0ubuntu1.20.04 > > JspWiki: 2.11.0.M7 (Binary download) > > java --version openjdk 11.0.9.1 2020-11-04 > > OpenJDK 64-Bit Server VM (build 11.0.9.1+1-Ubuntu-0ubuntu1.20.04, mixed > > mode, sharing) > > > > No Issue accessing > > http://:8080/manager/ > > > > CATALINA_BASE="/var/lib/tomcat9" > > CATALINA_HOME="/usr/share/tomcat9" > > > > Copied war file to /var/lib/tomcat9/webapps/ > > drwxr-x--- 10 tomcat tomcat 4096 Dec 4 10:43 folder/ > > -rw-r--r-- 1 tomcat tomcat 23277026 Dec 4 10:19 folder.war > > drwxr-xr-x 3 tomcat tomcat 4096 Dec 4 09:49 ROOT/ > > > > Seems like appropriate files are expanded at: > > /var/lib/tomcat9/webapps/folder/ (jsps and WEB-INF/ etc) > > > > INFO [main] org.apache.catalina.core.ApplicationContext.log ERROR: Failed > > to create a Wiki engine: JSPWiki: *Unable to load and setup properties > from > > jspwiki.properties. Failed to start.* Caused by: null; please check log > > files for better information. > > > > find /var/lib/tomcat9/webapps/ldapwiki/ -type f -name "*.properties" > > > > > /var/lib/tomcat9/webapps/ldapwiki/META-INF/maven/org.apache.jspwiki/jspwiki-war/pom.properties > > > > Any Ideas? > > -- > > -jim > > Jim Willeke > > >
JSPWiki: Unable to load and setup properties from jspwiki.properties
New install. Apache Tomcat/9.0.31 (Ubuntu) 11.0.9.1+1-Ubuntu-0ubuntu1.20.04 JspWiki: 2.11.0.M7 (Binary download) java --version openjdk 11.0.9.1 2020-11-04 OpenJDK 64-Bit Server VM (build 11.0.9.1+1-Ubuntu-0ubuntu1.20.04, mixed mode, sharing) No Issue accessing http://:8080/manager/ CATALINA_BASE="/var/lib/tomcat9" CATALINA_HOME="/usr/share/tomcat9" Copied war file to /var/lib/tomcat9/webapps/ drwxr-x--- 10 tomcat tomcat 4096 Dec 4 10:43 folder/ -rw-r--r-- 1 tomcat tomcat 23277026 Dec 4 10:19 folder.war drwxr-xr-x 3 tomcat tomcat 4096 Dec 4 09:49 ROOT/ Seems like appropriate files are expanded at: /var/lib/tomcat9/webapps/folder/ (jsps and WEB-INF/ etc) INFO [main] org.apache.catalina.core.ApplicationContext.log ERROR: Failed to create a Wiki engine: JSPWiki: *Unable to load and setup properties from jspwiki.properties. Failed to start.* Caused by: null; please check log files for better information. find /var/lib/tomcat9/webapps/ldapwiki/ -type f -name "*.properties" /var/lib/tomcat9/webapps/ldapwiki/META-INF/maven/org.apache.jspwiki/jspwiki-war/pom.properties Any Ideas? -- -jim Jim Willeke
Re: Can't find jskwiki.properties
I fail to see why this is jspwiki-custom.properties harder for multiples? What would you propose? -- -jim Jim Willeke On Fri, Jun 1, 2018 at 7:21 AM, Foster Schucker wrote: > So it's a chicken and egg. We can make it harder for the multiples to > work and make it easier for the singles. > > I'm worried about making it impossible for the multiples to work. I'm one > of the multiples, and having the setup the way it is is super simple for me. > > Maybe one of the maintainers will have a clever way to solve both problems. > > Thanks for the feedback! > > Foster > >
Re: Can jspwiki be used for large deployment
http://ldapwiki.com/ has 13,278 pages. -- -jim Jim Willeke On Thu, Mar 22, 2018 at 5:10 AM, lgilardon...@gmail.com < lgilardon...@gmail.com> wrote: > That's a good point Jürgen. > > This however raised two question in my mind. > First one is that *could* be a main point for future work (it would mean > to build a persistent intralinks repo to be buid and maintained > incrementally on pages change - which is surely a major overhaul but does > not look like rocket science). > Second one however - as a consequence - is .. when this would became a > real issue? 1k pages (believe not - we are running an intranet > that order of magnitude size and does not looks a real issue)? 10k? 100k? > Last consequential answer .. letting apart rebuilding wikipedia (which it > is not a real case i guess - and anyway as from > https://en.wikipedia.org/wiki/Wikipedia:Size_comparisons > it is far from that number) I hardly can image a 1B pages wiki. > @dagarwal82 may we know which kind of wiki (i.e. which kind of content) > are you thinking about? > > > On 3/22/2018 8:26 AM, Jürgen Weber wrote: > >> guess not, on startup JSPWiki loads all pages into memory to parse >> intra-page links. >> >> 2018-03-22 5:24 GMT+01:00 dagarwa...@gmail.com : >> >>> JspWiki uses filesystem instead of a conventional database. Would you >>> suggest using jspwiki if it were to cater to 1billion page ? (Provided, a >>> solid backup mechanism ). Would it scale that much with both performance >>> and data-integrity perspective ? >>> >> > >
Re: How to get My Wiki to look like JSPWiki
I think that clearing cookies helped along with deleting the "work" directory. Thanks -- -jim Jim Willeke On Sat, Dec 16, 2017 at 1:40 PM, Dirk Frederickx wrote: > Jim, > > Probably something is wrong with your deployment. Apart from > jspwiki.templateDir=haddock, you should not change anything else. > Check if the "haddock.css" file can be found. > (sometimes clearing cookies could be helpful as well) > > To troubleshoot: > In your browser, select "view developer tools" > Check if you see error messages in the CONSOLE tab. > > > dirk > > > > On Sat, Dec 16, 2017 at 5:48 PM, Jim Willeke wrote: > > > Running JSPWiki v2.10.1 > > > > So I set: > > jspwiki.templateDir = haddock > > > > But my pages do not look at all like > > https://jspwiki-wiki.apache.org/Wiki.jsp?page=Main > > > > Some Ugly green left menu, Title bar and footer. > > > > I see the blurb on > > https://jspwiki-wiki.apache.org/Wiki.jsp?page=Haddock%20Styles > > "The predefined CSS styles are stored in the file jspwiki.css and may > vary > > from site to site. It is up to the site administrator to define them." > > > > Seems like if you publish a site, then folks would expect the download to > > reflect what they see. > > I really do not want to know all about CSS to run a Wiki. > > > > Any ideas? > > > > -- > > -jim > > Jim Willeke > > >
Re: How to get My Wiki to look like JSPWiki
Thanks. Latest versions I see are: *20-Feb-2016*: The current release version is 2.10.2 <https://jspwiki-wiki.apache.org/Wiki.jsp?page=NewIn2.10#section-NewIn2.10-NewInJSPWiki2.10.2ReleasedOn20022016> -- -jim Jim Willeke On Sat, Dec 16, 2017 at 10:45 PM, Greg Burley wrote: > Jim, > > you need the latest version for Haddock to work properly (I think its > 2.10.3) and out of the box. Your version 2.10.1 Haddock was only a work in > progress. > > GB
How to get My Wiki to look like JSPWiki
Running JSPWiki v2.10.1 So I set: jspwiki.templateDir = haddock But my pages do not look at all like https://jspwiki-wiki.apache.org/Wiki.jsp?page=Main Some Ugly green left menu, Title bar and footer. I see the blurb on https://jspwiki-wiki.apache.org/Wiki.jsp?page=Haddock%20Styles "The predefined CSS styles are stored in the file jspwiki.css and may vary from site to site. It is up to the site administrator to define them." Seems like if you publish a site, then folks would expect the download to reflect what they see. I really do not want to know all about CSS to run a Wiki. Any ideas? -- -jim Jim Willeke
Re: [VOTE] Move to github as the primary repo
+1 -- -jim Jim Willeke On Tue, Nov 28, 2017 at 10:39 PM, Rick Brockman wrote: > +1 > > thanks > > -rick > > On 2017-11-28 18:41, Dirk Frederickx wrote: > > > +1 > > > > kr > > dirk > > > > On Wed, Nov 29, 2017 at 12:33 AM, Juan Pablo Santos Rodríguez < > > juanpablo.san...@gmail.com> wrote: > > > > and my +1. > > > > br, > > juan pablo > > > > On Wed, Nov 29, 2017 at 12:33 AM, Juan Pablo Santos Rodríguez < > > juanpablo.san...@gmail.com> wrote: > > > > Hi all, > > > > As noted else-thread, we're currently using ASF's git repo as the > > canonical repo with a read-only copy at github, but infra offers from a > > while back now the opposite possibility: work with github repo, which > sends the commits automatically to the ASF's repo, which gets then > read-only. It woukd treat Github as the canonical source (a copy on ASF's > repo would > > still be made), which allows the PRs and issues to be a bit more > convenient (there are still some things not supported due to the Github's > coarse > > permission structure). It would be required all committers to use > Github's 2FA [https://help.github.com/articles/providing-your-2fa- > > authentication-code/] > > > > This is the formal VOTE required by infra to set github as the primary > > repo for Apache JSPWiki, and as such subject to the usual voting > > guidelines: it will be open for at least 72 hours, everybody is > encouraged to vote, although only PMC ones are binding. > > > > [+1] yes, move to github as the primary repo > > [0] don't mind > > [-1] we are fine as it is now > > > > best regards, > > juan pablo > > -- > > - > > _RICK BROCKMAN_ > > _28 LANCASTER ST._ > > _CHERRY VALLEY, NY 13320_ > > _607 434-4746_
Re: Configuring a public JSPWiki instance for private use
Try not to think of it as infinite complexities but rather infinite Combinations. ;) And if you have a suggestion or a request for an improvement, I am sure folks would listen. I do agree many of the JSPWiki pages could use some refactoring. As with MOST open source projects the docs and code they are out of the beyond the realm of understanding for "common folk". Oh, and on "And how can you even dream of having anonymous users on an internet facing wiki?" Many are, even Wikipedia. And as far as "What is JSPWiki for?", I agree it is somewhat of a middle-road undefined product. - Not for the Enterprise as there is AFIK, no method to keep the sales dept separate from the engineering dept. (Well no reasonable tools to make it happen) - Not for the Casual user as there is too much Flexibility. (or maybe too much Complexity). Perhaps most Casual users would be better off with a "hosted" solution. (https://www.blogger.com/ or something) - Is not designed (or packaged) to be "dropped in" a SaaS like Google App Engine (or whatever AWS and Microsoft Hosting has to offer in that line.) - Perhaps it is best as a toolkit to be embedded within another product offering? So I agree it is somewhat a "For anyone" which is NEVER the right answer for todays crowded market if you want to Succeed. If you would like some help, please provide some details on your configuration. Are you on Tomcat? Do you have Container Authentication turned on? Have you altered the WEB-INF/jspwiki.policy file? Any other details you think might be helpful. -- -jim Jim Willeke On Wed, Oct 4, 2017 at 6:45 PM, Paul Uszak wrote: > I'm sorry Jim, I can't even remotely begin to agree with you. > > There are not *some* complexities. There are almost infinite > complexities. Some of this might be clear to a professional IT guru like > yourself, but (I will wager) that most cannot scratch even the surface. > The document you link to is 7000 words long, and includes enterprise JAAS > configuration that is on (it states) by default. What? And implied > permissions? It reads like a matrix of potential security combinations. > > We don't even know what the relationship is between container users and > wiki users. Are they the same? And what then about the wiki groups & > container roles? Are they the same? I'm in the odd state of not being > able to log out of the wiki. If I log out and the page says logged out > G’day (what is that, Klingon?) I just hit back on the browser and I'm back > in and able to edit! That's a trivial example, but illustrates the point > well. > > And how can you even dream of having anonymous users on an internet facing > wiki? As soon as you try to implement some form of primitive security > against the evil hordes out there, you run afoul of the *flexibility*. I > think that you have to conclude that the whole security thing's a mess. > You might want to review the holistic scope of barriers to adoption. The > reasons run deep and I've written on them previously, but I guess that > nothing is likely to improve. *What is JSPWiki for?* I'd dearly love > JSPWiki to succeed, but honestly I cannot see a way forward even though I > keep desperately searching. Naff powers of persuasion I guess. > > Unfortunately at this moment I'm repurposing my wiki so there's a fierce > debate between heart and mind as to whether I should seek greener grass. > Is this too -ve? > > On 4 October 2017 at 14:01, Jim Willeke wrote: > > > While I somewhat agree that an implementation of using an externalized > > Access Control Model would be better in some respects, I do find that the > > current implementation is well thought out and quite flexible for Wiki > > usage. > > > > Any Java Container implementation must simultaneously deal with file > > permissions, web container permissions, java.policy. > > > > WIKI-Groups and Page ACLs were deliberately meant to be managed outside > of > > the web container or java.policy so that users can create discretionary > > "roles" without getting system admins involved. This is an intentional > > feature, and a very powerful one which along with Page ACLs reduces the > > barrier to adoption. > > We all know the difficulty of getting some administrator in some other > area > > of an organization to grant (or deny) access to a "thing". > > > > Note that the hierarchy for Access Control is: (I do not see this > > documented, it was in a user group a few years back) > > > >- "built-in" roles > >- container-managed roles > >- WIKI-Groups > >- WIKI-Profiles >
Re: Configuring a public JSPWiki instance for private use
While I somewhat agree that an implementation of using an externalized
Access Control Model would be better in some respects, I do find that the
current implementation is well thought out and quite flexible for Wiki
usage.
Any Java Container implementation must simultaneously deal with file
permissions, web container permissions, java.policy.
WIKI-Groups and Page ACLs were deliberately meant to be managed outside of
the web container or java.policy so that users can create discretionary
"roles" without getting system admins involved. This is an intentional
feature, and a very powerful one which along with Page ACLs reduces the
barrier to adoption.
We all know the difficulty of getting some administrator in some other area
of an organization to grant (or deny) access to a "thing".
Note that the hierarchy for Access Control is: (I do not see this
documented, it was in a user group a few years back)
- "built-in" roles
- container-managed roles
- WIKI-Groups
- WIKI-Profiles
AFIK, any "Container" implementation deals with deal with file permissions,
"Container" permissions.
There are some complexities that may documented but not so well for those
not familiar with the concepts.
I think this page probably summarise most of the concepts:
https://jspwiki-wiki.apache.org/Wiki.jsp?page=Wiki.Admin.Security
Questions, Comments and Suggestions for improvements are always welcome.
--
-jim
Jim Willeke
On Tue, Oct 3, 2017 at 10:06 PM, Paul Uszak wrote:
> Well I still have trouble with the permissions /users after a couple of
> years. All sorts of weird things happen.
>
> I've stated previously that I consider the security configuration
> extremely complicated, bordering on unusable. You cannot have a credible
> product that uses (simultaneously) file permissions, web container
> permissions, wiki policies and per page directives. I can't think of
> another application that has such complex security across so many levels.
> It's madness - do you hear me? Sheer madness :-)
>
> Seriously, I would suggest a total overhaul to simplify massively. I'd
> even consider writing some clearer documentation. It might reduce the
> number of set up issues that appear here. Although, with four dimensional
> security I suspect I'm not up to it.
>
> What was the question again..?
>
> It seems to me that if only the front page is publicly visible, it needn't
> be within the wiki's context. Simply have a static front page at one URI,
> and have the private wiki at another. It also means you don't have to
> explain why you're being unfriendly as the wiki will be invisible
> (unlinked). I have something similar myself. Or have I misunderstood?
>
> On 3 October 2017 at 20:09, Jürgen Weber wrote:
>
> > Hi,
> >
> > I followed Dave's blog entry at
> >
> > https://blog.davekoelmeyer.co.nz/2014/07/20/configuring-a-
> > public-jspwiki-instance-for-private-use/
> >
> > Has someone tried to keep the front page public? (i.e. to give a
> > friendly reason for the rest of the pages being private)
> >
> > I tried to give all front facing pages [{ALLOW view ALL}]
> > but still only the login prompt.
> >
> > Greetings,
> > Juergen
> >
>
Some inconsistencies in JSPWiki that lead to confusion
Some inconsistencies in JSPWiki that lead to confusion. A link like [Password Minimum Length] will work to a page named: PasswordMinimumLength (ONLY as long as there is not page named "Password Minimum Length") However, a link of [PasswordMinimumLength] will not work to page named: "Password Minimum Length" And you can create a new page named PasswordMinimumLength So then there are essentially two pages with essentially the same name however, the page named "PasswordMinimumLength" is essentially not reachable. A page named passwordMinimumLength (Created programatically) will still allow a page created named as: PasswordMinimumLength So then there are two pages with essentially the same name however, the page named "passwordMinimumLength" is essentially not reachable. -- -jim Jim Willeke
Re: Open Discussion - How to increasing JSPWiki publicity ...
How many "Global" Corporations are using JSPWiki compared to the competition? And I guess my comments were not given enough context. Internally, where a company may have hundreds of departments, perhaps each with their own WIKI, JSPWiki does not have any method I know of to handle these conditions other than setting discrete instances for each department. Many of these organizations would have 1,000s if not 10,000s roles/groups that are defined, JSPWiki does not have an appropriate administrative interface to deal this this condition. -- -jim Jim Willeke On Sat, Feb 6, 2016 at 1:54 PM, Dave Koelmeyer < dave.koelme...@davekoelmeyer.co.nz> wrote: > On 07/02/16 09:11, Juan Pablo Santos Rodríguez wrote: > > As for companies using JSPWiki, I've seen mostly small/medium companies, > > but if I recall correctly, NetBeans did/does use JSPWiki, f.ex. > > Netbeans certainly did, as did the OpenDS project (now known as OpenDJ) > – both before Oracle took over. If JSPWiki was good enough for a global > like Sun Microsystems to use at the time, I'd say it's still good enough > for corporate use. > > -- > Dave Koelmeyer > http://blog.davekoelmeyer.co.nz > GPG Key ID: 0x238BFF87 > >
Re: Open Discussion - How to increasing JSPWiki publicity ...
I have been using JSPWiki for more than 10 years and I too think it has a lot going for it. I agree with Dave. We need to answer "who is JSPWiki for?" And what does Features does JSPWiki have that is not already present within the market? These need to be one answered in one paragraph. I not see JSPWiki competing in a corporate environment: - Little (if any) support - SHOW STOPPER - No Department Support (cannot be separated into different namespaces) - SHOW STOPPER - NOT mobile friendly - Limited "pre-built" plugins to integrate with other Applications (think source control or issue tracking) - Limited Administration tools - Need more GUI interfaces (like adding a photo or Excel embedded into page) Personal Gripes - No markdown support - No multiple instance support (Well at least poor) It is listed on some comparison sites <http://www.wikimatrix.org/show/JSPWiki>, but not sure how current things are. >From a technical standpoint, of course, almost anything is possible. >From a market penetration standpoint, it is a different story. -jim -- -jim Jim Willeke On Sat, Feb 6, 2016 at 1:13 AM, Dave Koelmeyer < dave.koelme...@davekoelmeyer.co.nz> wrote: > On 30/11/15 11:21, Paul Uszak wrote: > > I think that one of the initial points people should address, prior to > > launching a publicity campaign, is: who is JSPWiki for? It's pretty > > important to identify the market segment that efforts will then be made > > towards. We could all just talk about it a lot, but it's more efficient > if > > someone actually has an idea as to what is to be achieved, for whom. > > Fair point, but some of this is already covered right on > http://jspwiki.apache.org/ and > http://www.ecyrd.com/JSPWiki/wiki/JSPWikiFeatures. Any organisation > looking for the particular features listed there would be in the target > market for JSPWiki, for instance. > > > From a personal perspective as a user, it appears that JSPWiki is only > > suitable for a highly technical computer user. I use it because it meets > > certain nerdy requirements. Most casual users don't know what a server > is. > > I don't follow your logic at all. I don't think any organisation > interested in choosing JSPWiki to host instead of say Confluence or > MediaWiki expects their end users to install and run the product > themselves (comparisons to a desktop app such as Thunderbird are > completely apples to oranges). > > > Dave, you can get an impression of what I'm talking about by comparing > the > > ease of installation of Thunderbird to that of JSPWiki. Therefore, if > you > > think that we should be targeting developers /programmers, I would > suggest > > that perhaps those who want JSPWiki, know or can readily find out about > > JSPWiki. There might be an inherent danger of diminishing returns by > > publicising a highly technical product into the mainstream segment. > > Marketing 101 tells us not to advertise AR15s during the Super Bowl half > > time slot. > > I'm referring to volunteering free time and effort with a fair amount of > existing expertise to a small project which suffers from a lack of > visibility (the JSPWiki page even got yanked from Wikipedia due to a > lack of notability) – not the Super Bowl. > > I use JSPWiki for a variety of product and project documentation tasks, > and it largely excels at both. However, the legacy UI is getting long in > the tooth in terms of ease-of-use, and the problem with HADDOCK as far > as I am concerned is there are just not enough folks using it and > providing feedback. It's a great start but is not there yet for > full-time use (and I feel like a lone voice on JIRA). Hence why I'm in > strong agreement with the original author of this post, and why I'd > really like someone from the project to jump in here with some points of > view. > > Cheers, > Dave > > > > On 29 November 2015 at 10:55, Dave Koelmeyer < > > dave.koelme...@davekoelmeyer.co.nz> wrote: > > > >> Hi All, > >> > >> Sorry to bump an ancient thread (which I bumped previously with no > >> response). There is still only a JSPWiki Facebook group with the same > >> whopping four members. Janne enabled admin access for me a long while > >> back, but what should happen ideally is to create a Facebook Page, and > >> perhaps an associated Twitter channel, and start spreading the word a > bit. > >> > >> I'm super-happy to take the lead on this, but I imagine it would need to > >> be approved by Apache. > >> > >> I currently handle social networks publicity for Moz
Re: http://ldapwiki.com
Thanks for the help. I ran out of time and did a restore. The formatting seems back to normal but now, I remember what started me looking at some issues. When I go to edit a page, appears to be any page, the page appears to be blank. If I view the page or view source, it is fine. If I edit a section, it is fine. If I change the text, the page becomes what I enter. I can create a new page without incident. Catalina shows no entries but INFO. The "wiki.log" file shows only these errors: 2015-03-22 14:17:07,500 [http-bio-8080-exec-1] ERROR org.apache.wiki.providers.AbstractFileProvider Ldapwiki:/ Ldapwiki: http://ldapwiki.com/ - Page Description of Attribute Usage For 2.16.840.1.113719.1.14.4.1.2437.txt.txt was found in directory listing, but could not be located individually. and this warning: 2015-03-22 14:17:22,997 [http-bio-8080-exec-10] WARN org.apache.wiki.providers.CachingProvider Ldapwiki:/wiki/Localization Ldapwiki:http://ldapwiki.willeke.com/wiki/Localization - seems Ldapwiki.jspwiki.pageCache can't hold all pages from your page repository, so we're delegating on the underlying provider instead. Please consider increasing your cache sizes on ehcache.xml to avoid this behaviour Oh, and there is no ehcache.xml file on the server. Any ideas? Thanks again to all for the help. ᐧ -- -jim Jim Willeke On Sun, Mar 22, 2015 at 7:49 AM, David Vittor wrote: > Hi Jim, > > I think ur first statement is right “ Appears, for some reason, > http://ldapwiki.com is not reading the > jspwiki-custom.properties file" > > What's the location of this file? > > Based on the apache logs it was using the shortViewUrlConstructor "/wiki", > but now it's not using that at all, and using the default JSPWiki. > > I'm assuming the error started happening after a tomcat/server restart. > > Cheers, > David V > On 22/03/2015 5:54 PM, "Jim Willeke" wrote: > > > This works: > http://www.ldapwiki.com/ldapwiki/templates/default/jspwiki.css > > This doesn't: > > http://www.ldapwiki.com/*ldapwiki*/templates/default/jspwiki.css > > > > I would expect it to be: > > http://www.ldapwiki.com/templates/default/jspwiki.css > > or > > http://ldapwiki.com/templates/default/jspwiki.css > > > > No httpd (ie no apache server) > > > > webapps: > > drwxr-xr-x 12 tomcat tomcat 4096 Mar 21 09:34 ./ > > drwxr-xr-x 9 tomcat tomcat 4096 Mar 22 06:12 ../ > > drwxr-xr-x 10 tomcat tomcat 4096 Jul 27 2014 classof1968/ > > drwxr-xr-x 14 tomcat tomcat 4096 Jul 19 2014 docs/ > > drwxr-xr-x 7 tomcat tomcat 4096 Jul 19 2014 examples/ > > drwxr-xr-x 10 tomcat tomcat 4096 Jul 27 2014 genealogy/ > > drwxr-xr-x 5 tomcat tomcat 4096 Jul 19 2014 host-manager/ > > drwxr-xr-x 10 tomcat tomcat 4096 Mar 21 09:38 ldapwiki/ > > drwxr-xr-x 5 tomcat tomcat 4096 Jul 19 2014 manager/ > > drwxrwxr-x 7 tomcat tomcat 4096 Aug 10 2014 pwm/ > > -rw-r--r-- 1 tomcat tomcat 31772040 Aug 10 2014 pwm.war > > -rw-r--r-- 1 root root803 Mar 21 09:33 robots.txt > > drwxrwxr-x 10 tomcat tomcat 4096 Jul 27 2014 ROOT/ > > drwxr-xr-x 10 tomcat tomcat 4096 Jul 27 2014 willeke/ > > > > NOTE: ldapwiki/ is a copy of ROOT/ > > Which I did after I started having trouble. > > tomcat/conf/ > > > > default > > / > > > > > > No entries in tomcat/conf/server.xml for any context. > >> unpackWARs="true" autoDeploy="true"> > > .. > > > directory="logs" > >prefix="localhost-access-log." suffix=".log" > >pattern="%h %l %u %t "%r" %s %b" /> > > > > > > > > > > :/usr/share/tomcat# /etc/init.d/tomcat stop > > Using CATALINA_BASE: /usr/share/tomcat7/apache-tomcat-7.0.54/ > > Using CATALINA_HOME: /usr/share/tomcat7/apache-tomcat-7.0.54/ > > Using CATALINA_TMPDIR: /usr/share/tomcat7/apache-tomcat-7.0.54//temp > > Using JRE_HOME:/opt/jdk/jdk1.7.0_65 > > Using CLASSPATH: > > > > > /usr/share/tomcat7/apache-tomcat-7.0.54//bin/bootstrap.jar:/usr/share/tomcat7/apache-tomcat-7.0.54//bin/tomcat-juli.jar > > :/usr/share/tomcat# rm -r work/ > > :/usr/share/tomcat# /etc/init.d/tomcat start > > > > work/ > > total 28 > > drwxrwxr-x 7 tomcat tomcat 4096 Mar 22 06:12 ./ > > drwxr-xr-x 9 tomcat tomcat 4096 Mar 22 06:12 ../ > > drwxrwxr-x 3 tomcat tomcat 4096 Mar 22 06:12 Catalina/ > > drwxrwxr-x 4 tomcat tomcat 4096 Mar 22 06:12 classof1968/ > > drwxrwxr-x 4 t
Re: http://ldapwiki.com
This works: http://www.ldapwiki.com/ldapwiki/templates/default/jspwiki.css This doesn't: http://www.ldapwiki.com/*ldapwiki*/templates/default/jspwiki.css I would expect it to be: http://www.ldapwiki.com/templates/default/jspwiki.css or http://ldapwiki.com/templates/default/jspwiki.css No httpd (ie no apache server) webapps: drwxr-xr-x 12 tomcat tomcat 4096 Mar 21 09:34 ./ drwxr-xr-x 9 tomcat tomcat 4096 Mar 22 06:12 ../ drwxr-xr-x 10 tomcat tomcat 4096 Jul 27 2014 classof1968/ drwxr-xr-x 14 tomcat tomcat 4096 Jul 19 2014 docs/ drwxr-xr-x 7 tomcat tomcat 4096 Jul 19 2014 examples/ drwxr-xr-x 10 tomcat tomcat 4096 Jul 27 2014 genealogy/ drwxr-xr-x 5 tomcat tomcat 4096 Jul 19 2014 host-manager/ drwxr-xr-x 10 tomcat tomcat 4096 Mar 21 09:38 ldapwiki/ drwxr-xr-x 5 tomcat tomcat 4096 Jul 19 2014 manager/ drwxrwxr-x 7 tomcat tomcat 4096 Aug 10 2014 pwm/ -rw-r--r-- 1 tomcat tomcat 31772040 Aug 10 2014 pwm.war -rw-r--r-- 1 root root803 Mar 21 09:33 robots.txt drwxrwxr-x 10 tomcat tomcat 4096 Jul 27 2014 ROOT/ drwxr-xr-x 10 tomcat tomcat 4096 Jul 27 2014 willeke/ NOTE: ldapwiki/ is a copy of ROOT/ Which I did after I started having trouble. tomcat/conf/ default / No entries in tomcat/conf/server.xml for any context. .. :/usr/share/tomcat# /etc/init.d/tomcat stop Using CATALINA_BASE: /usr/share/tomcat7/apache-tomcat-7.0.54/ Using CATALINA_HOME: /usr/share/tomcat7/apache-tomcat-7.0.54/ Using CATALINA_TMPDIR: /usr/share/tomcat7/apache-tomcat-7.0.54//temp Using JRE_HOME:/opt/jdk/jdk1.7.0_65 Using CLASSPATH: /usr/share/tomcat7/apache-tomcat-7.0.54//bin/bootstrap.jar:/usr/share/tomcat7/apache-tomcat-7.0.54//bin/tomcat-juli.jar :/usr/share/tomcat# rm -r work/ :/usr/share/tomcat# /etc/init.d/tomcat start work/ total 28 drwxrwxr-x 7 tomcat tomcat 4096 Mar 22 06:12 ./ drwxr-xr-x 9 tomcat tomcat 4096 Mar 22 06:12 ../ drwxrwxr-x 3 tomcat tomcat 4096 Mar 22 06:12 Catalina/ drwxrwxr-x 4 tomcat tomcat 4096 Mar 22 06:12 classof1968/ drwxrwxr-x 4 tomcat tomcat 4096 Mar 22 06:12 genealogy/ drwxrwxr-x 4 tomcat tomcat 4096 Mar 22 06:12 ldapwiki/ drwxrwxr-x 4 tomcat tomcat 4096 Mar 22 06:12 willeke/ This was working fine and then this is when it changed: 217.198.1.70 - - [20/Mar/2015:12:07:17 +] "GET /wiki/1.2.840.113556.1.4.803 HTTP/1.1" 200 17110 188.165.15.230 - - [20/Mar/2015:12:08:15 +] "GET /wiki/NspmPasswordPolicy HTTP/1.1" 200 25179 66.249.67.5 - - [20/Mar/2015:12:10:03 +] "GET /wiki/SP HTTP/1.1" 200 15842 100.43.85.28 - - [20/Mar/2015:12:10:07 +] "GET /wiki/DirXML-idPolAccessControl HTTP/1.1" 302 - 100.43.85.28 - - [20/Mar/2015:12:10:10 +] "GET /wiki/2.16.840.1.113719.1.14.4.1.2400 HTTP/1.1" 200 18185 180.76.5.75 - - [20/Mar/2015:12:10:34 +] "GET /wiki/DefinitionStartTLSExtendedOperation HTTP/1.1" 200 13084 220.181.108.88 - - [20/Mar/2015:12:11:09 +] "GET /wiki/2.16.840.1.113719.1.4.5.4.1?skin=raw HTTP/1.1" 200 522 66.249.67.13 - - [20/Mar/2015:12:12:01 +] "GET /wiki/CAPK HTTP/1.1" 200 15143 195.154.48.114 - - [20/Mar/2015:12:12:01 +] "GET /wiki/NDSDThreadsAndProcesses/ HTTP/1.0" 200 13520 220.181.108.145 - - [20/Mar/2015:12:12:02 +] "GET /wiki/Krb5.conf HTTP/1.1" 200 18886 71.0.193.131 - - [20/Mar/2015:12:12:02 +] "GET / HTTP/1.1" 200 18468 66.249.67.5 - - [20/Mar/2015:12:12:02 +] "GET /wiki/LRUT HTTP/1.1" 302 - 71.0.193.131 - - [20/Mar/2015:12:12:02 +] "GET /JSPWiki/templates/default/jspwiki.css HTTP/1.1" 404 1025 66.249.67.13 - - [20/Mar/2015:12:12:02 +] "GET /JSPWiki/wiki/LocalReceivedUpTo HTTP/1.1" 404 1011 71.0.193.131 - - [20/Mar/2015:12:12:02 +] "GET /JSPWiki/scripts/mootools.js HTTP/1.1" 404 1005 71.0.193.131 - - [20/Mar/2015:12:12:02 +] "GET /JSPWiki/scripts/jspwiki-common.js HTTP/1.1" 404 1017 71.0.193.131 - - [20/Mar/2015:12:12:02 +] "GET /JSPWiki/attach/TitleBox/ldapwiki-logo.png HTTP/1.1" 404 1033 71.0.193.131 - - [20/Mar/2015:12:12:02 +] "GET /JSPWiki/images/out.png HTTP/1.1" 404 995 71.0.193.131 - - [20/Mar/2015:12:12:02 +] "GET /JSPWiki/attach/LeftMenu/donate_button_nocards.png HTTP/1.1" 404 1049 ᐧ -- -jim Jim Willeke On Sat, Mar 21, 2015 at 6:40 PM, David Vittor wrote: > Hi Jim, > > I'm not sure why you are getting the "*" prefixing and suffixing the > context path (ldapwiki). This is most likely an apache /etc/httpd/conf/ > *httpd.conf* file setting. > i.e. > This works: http://www.ldapwiki.com/ldapwiki/templates/default/jspwiki.css > This doesn't: > http://www.ldapwiki.com/*ldapwiki*/templates/default/jspwiki.css > > As for my settings I'm using: > jspwiki.applicationName=testwiki > jspwiki.baseURL=http://digitalspider.com.au/
Re: http://ldapwiki.com
Yes it is deployed as root. What redirection? It has never been behind anything. Any ideas how to fix? -jim On Mar 21, 2015 7:22 AM, "Juan Pablo Santos Rodríguez" < juanpablo.san...@gmail.com> wrote: > Hi Jim, > > Did you have an Apache server in front of your tomcat? Seems you're serving > your tomcat directly from www.ldapwiki.com. Were you deploying JSPWiki as > a > root app? Somehow the redirection from ldapwiki.com to your wiki seems > broken, be it because you deployed as a root app, and now is a normal war, > be it because you had an apache we server which is not visible anymore, be > it because the redirection from ldapwiki.com to your tomcat has changed, > or > something like that. > > As an aside, I'd recommend you to place an Apache server or similar in > front your tomcat so it only receives jspwiki petitions; f.ex., your tomcat > manager is visible from internet, although it asks for user/password. > > > HTH, > juan pablo > > On Sat, Mar 21, 2015 at 10:49 AM, Jim Willeke wrote: > > > Appears, for some reason, http://ldapwiki.com is not reading the > > jspwiki-custom.properties file > > > > jspwiki.fileSystemProvider.pageDir=/home/tomcat/jspwiki-files/ldapwiki > > > > > jspwiki.basicAttachmentProvider.storageDir=/home/tomcat/jspwiki-files/ldapwiki/attachments > > jspwiki.attachment.forbid=.html .htm .php .asp .exe > > jspwiki.applicationName=ldapwiki > > jspwiki.pageProvider=VersioningFileProvider > > jspwiki.security=jaas > > jspwiki.workDir=/usr/share/tomcat/work/ldapwiki > > jspwiki.baseURL=http//ldapwiki.com/ > > log4j.rootCategory=DEBUG,FileLog > > log4j.appender.Filelog=org.apache.log4j.DailyRollingFileAppender > > log4j.appender.Filelog.DatePattern='.'-MM-dd > > log4j.appender.Filelog$.Append=true > > log4j.appender.FileLog.File=/usr/share/tomcat/logs/ldapwiki.log > > jspwiki.usePageCache=true > > jspwiki.urlConstructor=ShortViewURLConstructor > > jspwiki.shortURLConstructor.prefix=wiki/ > > jspwiki.translatorReader.inlinePattern.1=*.jpg > > jspwiki.translatorReader.inlinePattern.2=*.png > > jspwiki.translatorReader.inlinePattern.3= > > http://willeke.com/ASSETS/IMAGES/* > > jspwiki.translatorReader.inlinePattern.4= > > http://willeke.com/Family/Photos/* > > > > > > When the page(s) load, they look like: > > > > http://ldapwiki.com/*JSPWiki*/images/out.png Failed to load resource: > the > > server responded with a status of 404 (Not Found) > > http://ldapwiki.com/*JSPWiki*/attach/LeftMenu/donate_button_nocards.png > > Failed to load resource: the server responded with a status of 404 (Not > > Found) > > http://ldapwiki.com/JSPWiki/templates/default/jspwiki.css Failed to load > > resource: the server responded with a status of 404 (Not Found) > > http://ldapwiki.com/JSPWiki/templates/default/jspwiki_print.css Failed > to > > load resource: the server responded with a status of 404 (Not Found) > > > > When I would expect them to be more like: > > http://ldapwiki.com/*ldapwiki*/templates/default/jspwiki.css > > > > I am unaware of anything changes recently that would have caused the > change > > as it was working. But of course something has changed. > > > > > > -- > > -jim > > Jim Willeke > > ᐧ > > > ᐧ
was found in directory listing, but could not be located individually.
In my log files I see several entries like: 2015-03-20 11:57:39,336 [http-bio-8080-exec-10] ERROR org.apache.wiki.providers.AbstractFileProvider Ldapwiki:/PageInfo.jsp Ldapwiki:http://ldapwiki.com/PageInfo.jsp - Page Description of Attribute Usage For 2.16.840.1.113719.1.25.4.1.52.txt.txt was found in directory listing, but could not be located individually. What does this imply? -- -jim Jim Willeke ᐧ
http://ldapwiki.com
Appears, for some reason, http://ldapwiki.com is not reading the jspwiki-custom.properties file jspwiki.fileSystemProvider.pageDir=/home/tomcat/jspwiki-files/ldapwiki jspwiki.basicAttachmentProvider.storageDir=/home/tomcat/jspwiki-files/ldapwiki/attachments jspwiki.attachment.forbid=.html .htm .php .asp .exe jspwiki.applicationName=ldapwiki jspwiki.pageProvider=VersioningFileProvider jspwiki.security=jaas jspwiki.workDir=/usr/share/tomcat/work/ldapwiki jspwiki.baseURL=http//ldapwiki.com/ log4j.rootCategory=DEBUG,FileLog log4j.appender.Filelog=org.apache.log4j.DailyRollingFileAppender log4j.appender.Filelog.DatePattern='.'-MM-dd log4j.appender.Filelog$.Append=true log4j.appender.FileLog.File=/usr/share/tomcat/logs/ldapwiki.log jspwiki.usePageCache=true jspwiki.urlConstructor=ShortViewURLConstructor jspwiki.shortURLConstructor.prefix=wiki/ jspwiki.translatorReader.inlinePattern.1=*.jpg jspwiki.translatorReader.inlinePattern.2=*.png jspwiki.translatorReader.inlinePattern.3=http://willeke.com/ASSETS/IMAGES/* jspwiki.translatorReader.inlinePattern.4=http://willeke.com/Family/Photos/* When the page(s) load, they look like: http://ldapwiki.com/*JSPWiki*/images/out.png Failed to load resource: the server responded with a status of 404 (Not Found) http://ldapwiki.com/*JSPWiki*/attach/LeftMenu/donate_button_nocards.png Failed to load resource: the server responded with a status of 404 (Not Found) http://ldapwiki.com/JSPWiki/templates/default/jspwiki.css Failed to load resource: the server responded with a status of 404 (Not Found) http://ldapwiki.com/JSPWiki/templates/default/jspwiki_print.css Failed to load resource: the server responded with a status of 404 (Not Found) When I would expect them to be more like: http://ldapwiki.com/*ldapwiki*/templates/default/jspwiki.css I am unaware of anything changes recently that would have caused the change as it was working. But of course something has changed. -- -jim Jim Willeke ᐧ
"...found in directory listing, but could not be located individually."
In my log files I see several entries like: 2015-03-20 11:57:39,336 [http-bio-8080-exec-10] ERROR org.apache.wiki.providers.AbstractFileProvider Ldapwiki:/PageInfo.jsp Ldapwiki:http://ldapwiki.com/PageInfo.jsp - Page Description of Attribute Usage For 2.16.840.1.113719.1.25.4.1.52.txt.txt was found in directory listing, but could not be located individually. What does this imply? -- -jim Jim Willeke ᐧ
Re: Multiple Wikis..
I would like to know also. ᐧ -- -jim Jim Willeke On Mon, Jan 19, 2015 at 11:46 AM, Eric Ladner wrote: > I noticed the "Multiple Wikis" page hasn't been pulled forward to the > Apache site and I suspect that has mostly to do with the fact that the > properties file handling changed. > > How much of the original Multiple WIkis page is still relevant? I have a > need to run multiple wikis. I got the first one to work but I'm kind of > stuck as to how to proceed. > > Thanks, > > Eric Ladner >
https://jspwiki-wiki.apache.org/ proxy error?
When trying to reach: https://jspwiki-wiki.apache.org/ or http://jspwiki-wiki.apache.org/ The following is returned to a browser: Proxy Error The proxy server received an invalid response from an upstream server. The proxy server could not handle the request *GET / <https://jspwiki-wiki.apache.org/>*. Reason: *Error reading from remote server* -- Apache/2.2.22 (Ubuntu) Server at jspwiki-wiki.apache.org Port 443 -jim -- -jim Jim Willeke ᐧ
Re: JSPWiki will not Start
ldapwiki/ldapwiki.log jspwiki.usePageCache = true jspwiki.breakTitleWithSpaces = true jspwiki.urlConstructor = ShortViewURLConstructor jspwiki.shortURLConstructor.prefix = wiki/ -jim -- -jim Jim Willeke On Sat, Jul 19, 2014 at 7:48 PM, Hassan Schroeder wrote: > On 7/19/14, 4:21 PM, Jim Willeke wrote: > > Installed latest Oracle Java. (Was using openJDK) >> >> Cleared work directory. >> > > >> === >> /usr/share/tomcat/work/jspwiki.log (Why would it be here?) >> > > Good question; my all-defaults installation wrote that logfile into > the Tomcat installation directory rather than ./logs. Which seems > wrong as well, but... > > Is there somewhere in your environment you're setting an explicit > CLASSPATH? > > > I have /usr/share/tomcat/webapps/ldapwiki/jspwiki-custom.properties >> Apparently it does not like that. >> > > So you're not deploying a default JSPWiki.war - it's got this custom > properties file? That muddies the water :-) > > Maybe you could gist that and any other non-standard property files? > > > -- > :about => about.me/hassanschroeder > :email => has...@webtuitive.com > :twitter => @hassan > :voice => +1 408-621-3445 >
Re: JSPWiki will not Start
] INFO org.apache.wiki.ui.admin.DefaultAdminBeanManager - com.sun.jmx.mbeanserver.JmxMBeanServer 2014-07-19 22:36:17,931 [localhost-startStop-1] INFO org.apache.wiki.ui.admin.DefaultAdminBeanManager - DefaultDomain 2014-07-19 22:36:17,936 [localhost-startStop-1] INFO org.apache.wiki.ui.admin.DefaultAdminBeanManager - Registered new admin bean Core bean 2014-07-19 22:36:17,937 [localhost-startStop-1] INFO org.apache.wiki.ui.admin.DefaultAdminBeanManager - Registered new admin bean User administration 2014-07-19 22:36:17,938 [localhost-startStop-1] INFO org.apache.wiki.ui.admin.DefaultAdminBeanManager - Registered new admin bean Search manager 2014-07-19 22:36:17,953 [localhost-startStop-1] INFO org.apache.wiki.ui.admin.DefaultAdminBeanManager - Registered new admin bean Plugins 2014-07-19 22:36:17,954 [localhost-startStop-1] INFO org.apache.wiki.ui.admin.DefaultAdminBeanManager - Registered new admin bean Plain editor 2014-07-19 22:36:17,956 [localhost-startStop-1] INFO org.apache.wiki.filters.DefaultFilterManager - Registering filters 2014-07-19 22:36:17,958 [JSPWiki Lucene Indexer] INFO org.apache.wiki.search.LuceneSearchProvider - Full Lucene index finished in 369 milliseconds. 2014-07-19 22:36:17,967 [localhost-startStop-1] INFO org.apache.wiki.filters.DefaultFilterManager - Cannot find property file for filters (this is okay, expected to find it as: '/WEB-INF/filters.xml') 2014-07-19 22:36:17,968 [localhost-startStop-1] INFO org.apache.wiki.render.RenderingManager - Rendering content with org.apache.wiki.render.XHTMLRenderer. 2014-07-19 22:36:17,977 [localhost-startStop-1] INFO org.apache.wiki.ReferenceManager - Starting cross reference scan of WikiPages 2014-07-19 22:36:17,977 [localhost-startStop-1] INFO org.apache.wiki.ReferenceManager - Unable to unserialize old refmgr information, rebuilding database: /usr/share/tomcat/temp/JSPWiki-553444335/refmgr.ser (No such file or directory) 2014-07-19 22:36:17,984 [localhost-startStop-1] INFO org.apache.wiki.ReferenceManager - Cross reference scan done in 0:00:00.007 2014-07-19 22:36:17,986 [localhost-startStop-1] INFO org.apache.wiki.WikiEngine - WikiEngine configured. 2014-07-19 22:36:17,986 [localhost-startStop-1] INFO org.apache.wiki.WikiEngine - Root path for this Wiki is: '/usr/share/tomcat/webapps/ldapwiki/' 2014-07-19 22:36:17,987 [localhost-startStop-1] INFO org.apache.wiki.util.UtilJ2eeCompat - serverInfo: Apache Tomcat/7.0.54 2014-07-19 22:36:17,987 [localhost-startStop-1] INFO org.apache.wiki.util.UtilJ2eeCompat - Apache Tomcat detected 2014-07-19 22:36:17,993 [localhost-startStop-1] INFO org.apache.wiki.WikiServlet - WikiServlet initialized. 2014-07-19 22:43:22,823 [http-bio-8080-exec-7] INFO org.apache.wiki.util.PropertyReader JSPWiki:/ldapwiki/ JSPWiki: http://wrx.willeke.com:8080/ldapwiki/ - *No jspwiki.custom.config* defined for this context, looking for custom properties file with default name of: /jspwiki-custom.properties 2014-07-19 22:43:22,824 [http-bio-8080-exec-7] INFO org.apache.wiki.util.PropertyReader JSPWiki:/ldapwiki/ JSPWiki: http://wrx.willeke.com:8080/ldapwiki/ - No custom property file found, relying on JSPWiki defaults. 2014-07-19 23:07:23,441 [localhost-startStop-2] INFO org.apache.wiki.WikiServlet - WikiServlet shutdown. 2014-07-19 23:07:23,447 [localhost-startStop-2] WARN org.apache.wiki.WikiBackgroundThread - Detected wiki engine shutdown: killing JSPWiki Lucene Indexer. 2014-07-19 23:07:23,447 [localhost-startStop-2] WARN org.apache.wiki.WikiBackgroundThread - Detected wiki engine shutdown: killing WatchDog for 'JSPWiki'. 2014-07-19 23:07:23,447 [localhost-startStop-2] INFO org.apache.wiki.ui.admin.DefaultAdminBeanManager - Unregistered AdminBean Core bean 2014-07-19 23:07:23,447 [localhost-startStop-2] INFO org.apache.wiki.ui.admin.DefaultAdminBeanManager - Unregistered AdminBean User administration 2014-07-19 23:07:23,447 [localhost-startStop-2] INFO org.apache.wiki.ui.admin.DefaultAdminBeanManager - Unregistered AdminBean Search manager 2014-07-19 23:07:23,447 [localhost-startStop-2] INFO org.apache.wiki.ui.admin.DefaultAdminBeanManager - Unregistered AdminBean Plugins 2014-07-19 23:07:23,447 [localhost-startStop-2] INFO org.apache.wiki.ui.admin.DefaultAdminBeanManager - Unregistered AdminBean Plain editor 2014-07-19 23:07:23,894 [WatchDog for 'JSPWiki'] WARN org.apache.wiki.WikiBackgroundThread - Interrupted background thread: WatchDog for 'JSPWiki'. 2014-07-19 23:07:24,272 [JSPWiki Lucene Indexer] WARN org.apache.wiki.WikiBackgroundThread - Interrupted background thread: JSPWiki Lucene Indexer. And when I (or you) go http://wrx.willeke.com:8080/ldapwiki/ The site is missing the stylesheets (I assume as all lines are shifted left). Clicking on "This page does not exist. Why don’t you go and create it? <http://wrx.willeke.com:8080/JSPWiki/Edit.jsp?page=Main>" The url then becomes: http://wrx.willeke.com:8080/JSPWiki/Edit.jsp?page=Main I have /usr/sha
Re: JSPWiki will not Start
What is "ldapwiki.war"? Is that a standard JSPWiki.war renamed? ->Yes. Latest version 2.10.1. If this is a fresh install of Tomcat and JSPWiki, why are there "persisted sessions" being found? -> Fresh install of both. May have been stopped and started a couple of times. -jim -- -jim Jim Willeke On Sat, Jul 19, 2014 at 5:56 PM, Hassan Schroeder wrote: > On 7/19/14, 12:49 PM, Jim Willeke wrote: > >> Latest version of tomcat7 v7.0.54. >> >> When I have tried to setup using a linux distro of tomcat, there is >> apparently an expectation that jspwiki should be able to write to some >> directories that the linux/Tomcat distro will not permit. >> >> With a download direct from Tomcat and write permissions applied to the >> user tomcat runs under for ALL tomcat directories, I still have POOR >> results. >> > > > INFO: Deploying web application archive > > /usr/share/tomcat7/apache-tomcat-7.0.54/webapps/ldapwiki.war > > What is "ldapwiki.war"? Is that a standard JSPWiki.war renamed? > > > Jul 19, 2014 7:30:03 PM org.apache.catalina.session.StandardManager >> doLoad >> SEVERE: IOException while loading persisted sessions: >> > > If this is a fresh install of Tomcat and JSPWiki, why are there > "persisted sessions" being found? > > I feel like there's something missing here :-) > > > -- > :about => about.me/hassanschroeder > :email => has...@webtuitive.com > :twitter => @hassan > :voice => +1 408-621-3445 >
Re: JSPWiki will not Start
nerBase.java:877) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:632) at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:1083) at org.apache.catalina.startup.HostConfig$DeployWar.run(HostConfig.java:1880) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:744) Caused by: java.io.NotSerializableException: org.apache.wiki.auth.UserManager$JSONUserModule at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1183) at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1547) at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1508) at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1431) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1177) ... log4j:WARN No appenders could be found for logger (org.apache.wiki.util.PropertyReader). log4j:WARN Please initialize the log4j system properly. log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info. Jul 19, 2014 7:30:04 PM org.apache.catalina.startup.HostConfig deployWAR INFO: Deployment of web application archive /usr/share/tomcat7/apache-tomcat-7.0.54/webapps/ldapwiki.war has finished in 4,322 ms Jul 19, 2014 7:30:04 PM org.apache.catalina.startup.HostConfig deployDirectory INFO: Deploying web application directory /usr/share/tomcat7/apache-tomcat-7.0.54/webapps/manager Jul 19, 2014 7:30:04 PM org.apache.catalina.startup.HostConfig deployDirectory INFO: Deployment of web application directory /usr/share/tomcat7/apache-tomcat-7.0.54/webapps/manager has finished in 78 ms Jul 19, 2014 7:30:04 PM org.apache.catalina.startup.HostConfig deployDirectory And although I was told when running Install.jsp that my jspwiki-custom.properties would be: jspwiki.basicAttachmentProvider.storageDir = /home/tomcat/ldapwiki jspwiki.fileSystemProvider.pageDir = /home/tomcat/ldapwiki jspwiki.applicationName = ldapwiki jspwiki.pageProvider = VersioningFileProvider jspwiki.security = jaas jspwiki.workDir = /usr/share/tomcat/ldapwiki jspwiki.baseURL = http://wrx.willeke.com:8080/ldapwiki/ log4j.appender.FileLog.File = /var/log/tomcat/ldapwiki/ldapwiki.log I can not find this file anywhere. (and I would not know where to put it if I was supposed to create it.) Thanks -jim -- -jim Jim Willeke On Sat, Jul 19, 2014 at 2:23 PM, Hassan Schroeder wrote: > On 7/19/14, 10:23 AM, Jim Willeke wrote: > >> I have no idea where to go at this point. >> >> So from a "stock" Apache tomcat7 installation Apache JSPWIKI no longer >> will >> run. >> > > Sorry, I haven't been following this thread particularly closely, but > for grins I just dropped a fresh downloaded JSPWiki.war file into the > webapps directory of a box-stock install of Tomcat 7.0.54 (on a Mac, > OS 10.9.4, java version "1.7.0_45") and started Tomcat. With absolutely > no config changes, JSPWiki starts up fine and based on limited testing > works fine too. > > Why are you using such an old version of Tomcat? There have been a lot > of security-related bug fixes since 7.0.28. > > (http://tomcat.apache.org/security-7.html) > > Perhaps start over with a current Tomcat? > > HTH, > -- > :about => about.me/hassanschroeder > :email => has...@webtuitive.com > :twitter => @hassan > :voice => +1 408-621-3445 >
Re: JSPWiki will not Start
I have no idea where to go at this point. So from a "stock" Apache tomcat7 installation Apache JSPWIKI no longer will run. You mention putting a log4j.properties file in tomcat's webapps/JSPWiki/WEB-INF/classes directory. What should be contained in this file? Thanks for the help. -- -jim Jim Willeke On Sun, May 18, 2014 at 12:58 PM, Harry Metske wrote: > I think neither of these two is the case. > The issue here is that you have a (tomcat) environment where you are not > allowed to write to tomcat's lib directory, or you don't want configuration > in that directory because you don't want these configs to apply to other > (JSPWiki) applications running in the same tomcat. > When you startup a vanilla JSPWiki it will try to log to jspwiki.log in the > current directory, so depending on from where you start it, you will get > the logfile or not. If the logfile cannot be created however, JSPWiki will > still work (though you get an ugly stacktrace to stdout from log4j). > > Maybe there is one option left in this case, and that is putting a > log4j.properties file in tomcat's webapps/JSPWiki/WEB-INF/classes > directory. > > regards, > Harry > > > > On 18 May 2014 17:42, Florian Holeczek wrote: > > > Hi there, > > > > two things come to my mind regarding the "standard" Tomcat coming with a > > Linux distribution: > > > > * Is this Tomcat running with a security manager enabled? JSPWiki isn't > > running under a security manager (i.e. without further configuration). > > * Are advanced security modules like SELinux or AppArmor enabled in these > > environments? If so, it may be that the Tomcat instance needs some > further > > configuration, especially regarding access to additional files like > > jspwiki.log. > > > > Regards > > Florian > > >
Re: JSPWiki will not Start
I have spent way too much time trying to do a "standard" deploy of JSWPWiki on a "Standard" deploy of Tomcat 7 and linux. (Tried Debian and Ubuntu) . A big issue is the attempt to write the jspwiki.log to the location that it should not be trying to write to the CATALINA_HOME for Tomcat instead of the CATALINA_BASE. The desire to incorporate the jspwiki.properties within a jar file so as to make it easier to perform upgrades then causes the customization of the CATALINA_HOME directories which then prevents easy upgrades AND portability of jspwiki across various versions of Tomcat and implementation within many hosted environments. I am trying to move multiple Jspwiki's from a self hosted (not standard install of Tomcat) to a hosted environment and have spent WAY too many hours without ever getting Jspwiki to even start with a clean downloaded tomcat7 and Jspwiki jar. There must be a better method or am I missing something? -jim ᐧ -- -jim Jim Willeke On Sun, May 4, 2014 at 5:30 PM, Juan Pablo Santos Rodríguez < juanpablo.san...@gmail.com> wrote: > Hi Jim, > > from your log, and looking at the code, it seems that the application is > trying to find your policy file (by default, jspwiki.policy, inside the > war's WEB-INF folder), but it's unable to. Have you overriden the > jspwiki.policy.file attribute on your jspwiki-custom.properties file? It's > first searched inside the war's WEB-INF folder, and if not found, then it's > searched on classpath. > > In your case, both searches fail to find the security policy file. I'm > adding some log messages and handling this error-case so it outputs a > meaningful message instead a NPE in a minute > > > br, > juan pablo > > > On Sun, May 4, 2014 at 11:17 AM, Jim Willeke wrote: > > > Thanks for the continued help. > > > > > > In catalina.out we see: > > INFO: Deploying configuration descriptor > > /etc/tomcat7/Catalina/localhost/docs.xml > > May 03, 2014 8:34:32 PM org.apache.catalina.startup.HostConfig > > deployDescriptor > > INFO: Deploying configuration descriptor > > /etc/tomcat7/Catalina/localhost/manager.xml > > May 03, 2014 8:34:32 PM org.apache.catalina.startup.HostConfig deployWAR > > INFO: Deploying web application archive > > /var/lib/tomcat7/webapps/ldapwiki.war > > log4j:WARN No appenders could be found for logger > > (org.apache.wiki.util.PropertyReader). > > log4j:WARN Please initialize the log4j system properly. > > log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for > > more info. > > May 03, 2014 8:34:33 PM org.apache.catalina.core.StandardContext > > startInternal > > SEVERE: Error filterStart > > May 03, 2014 8:34:33 PM org.apache.catalina.core.StandardContext > > startInternal > > SEVERE: Context [/ldapwiki] startup failed due to previous errors > > May 03, 2014 8:34:33 PM org.apache.catalina.loader.WebappClassLoader > > clearReferencesThreads > > SEVERE: The web application [/ldapwiki] appears to have started a thread > > named [net.sf.ehcache.CacheManager@6043a24d] but has failed to stop it. > > This is very likely to create a memory leak. > > May 03, 2014 8:34:33 PM org.apache.catalina.loader.WebappClassLoader > > clearReferencesThreads > > SEVERE: The web application [/ldapwiki] appears to have started a thread > > named [JSPWiki Lucene Indexer] but has failed to stop it. This is very > > likely to create a memory leak. > > May 03, 2014 8:34:33 PM org.apache.catalina.loader.WebappClassLoader > > clearReferencesThreads > > SEVERE: The web application [/ldapwiki] appears to have started a thread > > named [WatchDog for 'Ldapwiki'] but has failed to stop it. This is very > > likely to create a memory leak. > > May 03, 2014 8:34:33 PM org.apache.catalina.loader.WebappClassLoader > > loadClass > > INFO: Illegal access: this web application instance has been stopped > > already. Could not load > > org.apache.lucene.index.DocumentsWriterPerThreadPool$ThreadState. The > > eventual following stack trace is caused by an error thrown for debugging > > purposes as well as to attempt to terminate the thread which caused the > > illegal access, and has no functional impact. > > java.lang.IllegalStateException > > at > > > > > org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1597) > > at > > > > > org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1556) > > at > > > > > org.apache.lucene.index.DocumentsWriterPerThreadPool.(DocumentsWriterPerThreadP
Re: JSPWiki will not Start
entication. 2014-05-03 20:34:33,533 INFO authorize.WebContainerAuthorizer - Authorizer WebContainerAuthorizer initialized successfully. 2014-05-03 20:34:33,543 FATAL wiki.WikiEngine - Failed to start managers. java.lang.NullPointerException at org.apache.wiki.auth.AuthenticationManager.findConfigFile(AuthenticationManager.java:649) at org.apache.wiki.auth.AuthorizationManager.initialize(AuthorizationManager.java:495) at org.apache.wiki.WikiEngine.initialize(WikiEngine.java:586) at org.apache.wiki.WikiEngine.(WikiEngine.java:430) ᐧ -- -jim Jim Willeke On Sun, May 4, 2014 at 2:51 AM, Harry Metske wrote: > Jim, > > I dont know what causes the NPE, but there should be a stacktrace in > tomcat's SystemOut, can you check that? > > Regards, > Harry > Op 4 mei 2014 02:37 schreef "Jim Willeke" : > > > After doing that, I still only get a little further: > > > > 2014-05-03 20:08:24,390 INFO search.LuceneSearchProvider - Lucene > libraries > > do not exist - not using Lucene. > > 2014-05-03 20:34:32,795 INFO wiki.WikiEngine - > > *** > > 2014-05-03 20:34:32,796 INFO wiki.WikiEngine - JSPWiki 2.10.0 starting. > > Whee! > > 2014-05-03 20:34:32,798 INFO wiki.WikiEngine - Servlet container: Apache > > Tomcat/7.0.28 > > 2014-05-03 20:34:32,807 INFO wiki.WikiEngine - JSPWiki working directory > is > > '/tmp/tomcat7-tomcat7-tmp/JSPWiki-108143313' > > 2014-05-03 20:34:33,333 INFO providers.AbstractFileProvider - Wikipages > are > > read from '/home/tomcat/tcdocs/ldapwiki' > > 2014-05-03 20:34:33,333 INFO providers.VersioningFileProvider - Using > > directory /home/tomcat/tcdocs/ldapwiki/OLD for storing old versions of > > pages > > 2014-05-03 20:34:33,344 INFO plugin.DefaultPluginManager - Registering > > plugins > > 2014-05-03 20:34:33,390 INFO diff.DifferenceManager - Using difference > > provider: TraditionalDiffProvider > > 2014-05-03 20:34:33,393 INFO providers.CachingAttachmentProvider - > Initing > > CachingAttachmentProvider > > 2014-05-03 20:34:33,418 INFO search.LuceneSearchProvider - Lucene > enabled, > > cache will be in: /tmp/tomcat7-tomcat7-tmp/JSPWiki-108143313/lucene > > 2014-05-03 20:34:33,420 WARN wiki.WikiBackgroundThread - Starting up > > background thread: JSPWiki Lucene Indexer. > > 2014-05-03 20:34:33,426 WARN wiki.WikiBackgroundThread - Starting up > > background thread: WatchDog for 'Ldapwiki'. > > 2014-05-03 20:34:33,427 INFO search.LuceneSearchProvider - Starting > Lucene > > reindexing, this can take a couple of minutes... > > 2014-05-03 20:34:33,450 INFO ui.EditorManager - Registering editor > modules > > 2014-05-03 20:34:33,465 INFO authorize.WebContainerAuthorizer - Examining > > jndi:/localhost/ldapwiki/WEB-INF/web.xml > > 2014-05-03 20:34:33,533 INFO authorize.WebContainerAuthorizer - JSPWiki > is > > using custom authentication. > > 2014-05-03 20:34:33,533 INFO authorize.WebContainerAuthorizer - > Authorizer > > WebContainerAuthorizer initialized successfully. > > 2014-05-03 20:34:33,543 FATAL wiki.WikiEngine - Failed to start managers. > > java.lang.NullPointerException > > > > > > Any ideas? > > > > Thanks > > -jim > > > > ᐧ > > > > -- > > -jim > > Jim Willeke > > > > > > On Sat, May 3, 2014 at 11:16 AM, Jim Willeke wrote: > > > > > I really appreciate the help, but, this then effects all apps running > on > > > tomcat. > > > > > > There must be a better way. > > > > > > I currently running older versions but have 5 wikis running as Virtual > > > hosts and all their configs are within the context of each host. > > > But, I wanted to do a clean install of one wiki to see how the newer > > > install works and run the ../Install.jsp to see how things should be > > done. > > > > > > > > > ᐧ > > > > > > -- > > > -jim > > > Jim Willeke > > > > > > > > > On Sat, May 3, 2014 at 8:34 AM, Harry Metske > >wrote: > > > > > >> Jim, > > >> > > >> you should put these files in tomcat7/lib, not in > > >> tomcat7/webapps/ldapwiki/WEB-INF/lib. > > >> > > >> regards, > > >> Harry > > >> > > >> > > >> > > >> On 3 May 2014 13:25, Jim Willeke wrote: > > >> > > >> > Creating a creating a log4j.properties in > > >> > tomcat7/webapps/ldapwiki/WEB-INF/lib > > >>
Re: JSPWiki will not Start
After doing that, I still only get a little further: 2014-05-03 20:08:24,390 INFO search.LuceneSearchProvider - Lucene libraries do not exist - not using Lucene. 2014-05-03 20:34:32,795 INFO wiki.WikiEngine - *** 2014-05-03 20:34:32,796 INFO wiki.WikiEngine - JSPWiki 2.10.0 starting. Whee! 2014-05-03 20:34:32,798 INFO wiki.WikiEngine - Servlet container: Apache Tomcat/7.0.28 2014-05-03 20:34:32,807 INFO wiki.WikiEngine - JSPWiki working directory is '/tmp/tomcat7-tomcat7-tmp/JSPWiki-108143313' 2014-05-03 20:34:33,333 INFO providers.AbstractFileProvider - Wikipages are read from '/home/tomcat/tcdocs/ldapwiki' 2014-05-03 20:34:33,333 INFO providers.VersioningFileProvider - Using directory /home/tomcat/tcdocs/ldapwiki/OLD for storing old versions of pages 2014-05-03 20:34:33,344 INFO plugin.DefaultPluginManager - Registering plugins 2014-05-03 20:34:33,390 INFO diff.DifferenceManager - Using difference provider: TraditionalDiffProvider 2014-05-03 20:34:33,393 INFO providers.CachingAttachmentProvider - Initing CachingAttachmentProvider 2014-05-03 20:34:33,418 INFO search.LuceneSearchProvider - Lucene enabled, cache will be in: /tmp/tomcat7-tomcat7-tmp/JSPWiki-108143313/lucene 2014-05-03 20:34:33,420 WARN wiki.WikiBackgroundThread - Starting up background thread: JSPWiki Lucene Indexer. 2014-05-03 20:34:33,426 WARN wiki.WikiBackgroundThread - Starting up background thread: WatchDog for 'Ldapwiki'. 2014-05-03 20:34:33,427 INFO search.LuceneSearchProvider - Starting Lucene reindexing, this can take a couple of minutes... 2014-05-03 20:34:33,450 INFO ui.EditorManager - Registering editor modules 2014-05-03 20:34:33,465 INFO authorize.WebContainerAuthorizer - Examining jndi:/localhost/ldapwiki/WEB-INF/web.xml 2014-05-03 20:34:33,533 INFO authorize.WebContainerAuthorizer - JSPWiki is using custom authentication. 2014-05-03 20:34:33,533 INFO authorize.WebContainerAuthorizer - Authorizer WebContainerAuthorizer initialized successfully. 2014-05-03 20:34:33,543 FATAL wiki.WikiEngine - Failed to start managers. java.lang.NullPointerException Any ideas? Thanks -jim ᐧ -- -jim Jim Willeke On Sat, May 3, 2014 at 11:16 AM, Jim Willeke wrote: > I really appreciate the help, but, this then effects all apps running on > tomcat. > > There must be a better way. > > I currently running older versions but have 5 wikis running as Virtual > hosts and all their configs are within the context of each host. > But, I wanted to do a clean install of one wiki to see how the newer > install works and run the ../Install.jsp to see how things should be done. > > > ᐧ > > -- > -jim > Jim Willeke > > > On Sat, May 3, 2014 at 8:34 AM, Harry Metske wrote: > >> Jim, >> >> you should put these files in tomcat7/lib, not in >> tomcat7/webapps/ldapwiki/WEB-INF/lib. >> >> regards, >> Harry >> >> >> >> On 3 May 2014 13:25, Jim Willeke wrote: >> >> > Creating a creating a log4j.properties in >> > tomcat7/webapps/ldapwiki/WEB-INF/lib >> > does not work. >> > log4j:WARN No appenders could be found for logger >> > (org.apache.wiki.util.PropertyReader). >> > log4j:WARN Please initialize the log4j system properly. >> > log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfigfor >> > more info. >> > log4j:ERROR setFile(null,true) call failed. >> > java.io.FileNotFoundException: jspwiki.log (Permission denied) >> > >> > or creating jspwiki-custom.properties file >> > >> > >> > ᐧ >> > >> > -- >> > -jim >> > Jim Willeke >> > >> > >> > On Sat, May 3, 2014 at 5:22 AM, Harry Metske >> > wrote: >> > >> > > Jim, >> > > >> > > a vanilla JSPWiki will use the log4j settings from >> > ini/jspwiki.properties, >> > > this file is "hidden" inside the WEB-INF/lib/jspwiki.jar file. >> > > The default location for the logfile is jspwiki.log, which means the >> > > current directory. >> > > What the current directory is, depends on how you startup your tomcat. >> > > For example, if you start tomcat from a shell, it will try to log to >> the >> > > current directory (of your shell). >> > > If you start it from the init.d script, it depends on how the init.d >> > script >> > > handles it. >> > > In any case, in your situation, the current directory cannot be >> written >> > to. >> > > You can also solve the logging issue by creating a log4j.properties >> file >> > in >> > > the tomcat lib directory, see #1 for an
Re: JSPWiki will not Start
I really appreciate the help, but, this then effects all apps running on tomcat. There must be a better way. I currently running older versions but have 5 wikis running as Virtual hosts and all their configs are within the context of each host. But, I wanted to do a clean install of one wiki to see how the newer install works and run the ../Install.jsp to see how things should be done. ᐧ -- -jim Jim Willeke On Sat, May 3, 2014 at 8:34 AM, Harry Metske wrote: > Jim, > > you should put these files in tomcat7/lib, not in > tomcat7/webapps/ldapwiki/WEB-INF/lib. > > regards, > Harry > > > > On 3 May 2014 13:25, Jim Willeke wrote: > > > Creating a creating a log4j.properties in > > tomcat7/webapps/ldapwiki/WEB-INF/lib > > does not work. > > log4j:WARN No appenders could be found for logger > > (org.apache.wiki.util.PropertyReader). > > log4j:WARN Please initialize the log4j system properly. > > log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for > > more info. > > log4j:ERROR setFile(null,true) call failed. > > java.io.FileNotFoundException: jspwiki.log (Permission denied) > > > > or creating jspwiki-custom.properties file > > > > > > ᐧ > > > > -- > > -jim > > Jim Willeke > > > > > > On Sat, May 3, 2014 at 5:22 AM, Harry Metske > > wrote: > > > > > Jim, > > > > > > a vanilla JSPWiki will use the log4j settings from > > ini/jspwiki.properties, > > > this file is "hidden" inside the WEB-INF/lib/jspwiki.jar file. > > > The default location for the logfile is jspwiki.log, which means the > > > current directory. > > > What the current directory is, depends on how you startup your tomcat. > > > For example, if you start tomcat from a shell, it will try to log to > the > > > current directory (of your shell). > > > If you start it from the init.d script, it depends on how the init.d > > script > > > handles it. > > > In any case, in your situation, the current directory cannot be written > > to. > > > You can also solve the logging issue by creating a log4j.properties > file > > in > > > the tomcat lib directory, see #1 for an example. > > > > > > regards, > > > Harry > > > #1 - > > > > > > > > > https://jspwiki-wiki.apache.org/Wiki.jsp?page=Documentation#section-Documentation-ConfigurationAndAdministration > > > > > > > > > > > > > > > > > > On 3 May 2014 10:01, Jim Willeke wrote: > > > > > > > New server on "Debian GNU/Linux 7 (wheezy)" > > > > Apache Tomcat/7.0.28 JDK 1.7.0_25-b30 > > > > Deployed JSPWiki.jar from Tomcat Manager. > > > > > > > > > > > > May 02, 2014 2:13:28 PM org.apache.catalina.startup.HostConfig > > deployWAR > > > > INFO: Deploying web application archive > > > /var/lib/tomcat7/webapps/mywiki.war > > > > log4j:WARN No appenders could be found for logger > > > > (org.apache.wiki.util.PropertyReader). > > > > log4j:WARN Please initialize the log4j system properly. > > > > log4j:WARN See > http://logging.apache.org/log4j/1.2/faq.html#noconfigfor > > > > more info. > > > > log4j:ERROR setFile(null,true) call failed. > > > > java.io.FileNotFoundException: jspwiki.log (Permission denied) > > > > > > > > Not sure where it might be trying to write the file to but even did a > > > touch > > > > and set to user running tomcat for > > > > /var/lib/tomcat7/logs > > > > With the same results. > > > > > > > > Which contained all the other log files. > > > > > > > > Any ideas what to look into? > > > > > > > > Thanks > > > > > > > > -- > > > > -jim > > > > Jim Willeke > > > > > > > > > >
Re: JSPWiki will not Start
Creating a creating a log4j.properties in tomcat7/webapps/ldapwiki/WEB-INF/lib does not work. log4j:WARN No appenders could be found for logger (org.apache.wiki.util.PropertyReader). log4j:WARN Please initialize the log4j system properly. log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info. log4j:ERROR setFile(null,true) call failed. java.io.FileNotFoundException: jspwiki.log (Permission denied) or creating jspwiki-custom.properties file ᐧ -- -jim Jim Willeke On Sat, May 3, 2014 at 5:22 AM, Harry Metske wrote: > Jim, > > a vanilla JSPWiki will use the log4j settings from ini/jspwiki.properties, > this file is "hidden" inside the WEB-INF/lib/jspwiki.jar file. > The default location for the logfile is jspwiki.log, which means the > current directory. > What the current directory is, depends on how you startup your tomcat. > For example, if you start tomcat from a shell, it will try to log to the > current directory (of your shell). > If you start it from the init.d script, it depends on how the init.d script > handles it. > In any case, in your situation, the current directory cannot be written to. > You can also solve the logging issue by creating a log4j.properties file in > the tomcat lib directory, see #1 for an example. > > regards, > Harry > #1 - > > https://jspwiki-wiki.apache.org/Wiki.jsp?page=Documentation#section-Documentation-ConfigurationAndAdministration > > > > > > On 3 May 2014 10:01, Jim Willeke wrote: > > > New server on "Debian GNU/Linux 7 (wheezy)" > > Apache Tomcat/7.0.28 JDK 1.7.0_25-b30 > > Deployed JSPWiki.jar from Tomcat Manager. > > > > > > May 02, 2014 2:13:28 PM org.apache.catalina.startup.HostConfig deployWAR > > INFO: Deploying web application archive > /var/lib/tomcat7/webapps/mywiki.war > > log4j:WARN No appenders could be found for logger > > (org.apache.wiki.util.PropertyReader). > > log4j:WARN Please initialize the log4j system properly. > > log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for > > more info. > > log4j:ERROR setFile(null,true) call failed. > > java.io.FileNotFoundException: jspwiki.log (Permission denied) > > > > Not sure where it might be trying to write the file to but even did a > touch > > and set to user running tomcat for > > /var/lib/tomcat7/logs > > With the same results. > > > > Which contained all the other log files. > > > > Any ideas what to look into? > > > > Thanks > > > > -- > > -jim > > Jim Willeke > > >
JSPWiki will not Start
New server on "Debian GNU/Linux 7 (wheezy)" Apache Tomcat/7.0.28 JDK 1.7.0_25-b30 Deployed JSPWiki.jar from Tomcat Manager. May 02, 2014 2:13:28 PM org.apache.catalina.startup.HostConfig deployWAR INFO: Deploying web application archive /var/lib/tomcat7/webapps/mywiki.war log4j:WARN No appenders could be found for logger (org.apache.wiki.util.PropertyReader). log4j:WARN Please initialize the log4j system properly. log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info. log4j:ERROR setFile(null,true) call failed. java.io.FileNotFoundException: jspwiki.log (Permission denied) Not sure where it might be trying to write the file to but even did a touch and set to user running tomcat for /var/lib/tomcat7/logs With the same results. Which contained all the other log files. Any ideas what to look into? Thanks -- -jim Jim Willeke
Re: Contributing Wiki On A Stick - Re: JSPWiki "Support for Multiple Wikis" and Hosting Solutions
+1 -- -jim Jim Willeke On Tue, Oct 15, 2013 at 2:41 PM, Harry Metske wrote: > +1 > > > > > On 15 October 2013 20:39, Juan Pablo Santos Rodríguez < > juanpablo.san...@gmail.com> wrote: > > > Hi Siegfried! > > > > it would be real nice to have WOAS on trunk :-) > > > > > > br, > > juan pablo > > > > > > > > On Mon, Oct 14, 2013 at 8:32 AM, Siegfried Goeschl < > > siegfried.goes...@it20one.at> wrote: > > > > > Hi Dave, > > > > > > let me check with http://svn.apache.org/repos/** > > > asf/jspwiki/tags/jspwiki_2_9_**1_incubating_rc2/< > > > http://svn.apache.org/repos/asf/jspwiki/tags/jspwiki_2_9_1_incubating_rc2/ > > > > > > > > > General question - any objections to contribute it to JSPWiki? Last > time > > > the problem was that my stuff used a different version of jetty - I'm > > still > > > on Jetty 6.1.10 for the distributable > > > > > > Cheers, > > > > > > Siegfried Goeschl > > > > > > On 14.10.13 05:05, Dave Koelmeyer wrote: > > > > > >> On 23/09/13 08:50 AM, Siegfried Goeschl wrote: > > >> > > >>> Hi Jim, > > >>> > > >>> under https://github.com/sgoeschl/**jspwiki-on-a-stick< > > https://github.com/sgoeschl/jspwiki-on-a-stick>I have a portable JSPWiki > > which I use to host up to 11 wiki (spaces) using > > >>> an embedded Jetty > > >>> > > >>> * the JSPWiki libraries are shared across all wikis > > >>> * each wiki is a separate webapp > > >>> > > >> > > >> > > >> Hi Siegfried, > > >> > > >> Does your JSPWiki on a stick work with the current stable release of > > >> JSPWiki? > > >> > > >> Cheers, > > >> Dave > > >> > > >> > > > > > >
JSPWiki "Support for Multiple Wikis" and Hosting Solutions
Currently we host 7 instances of JSPWiki and a couple of other WEB Sites on Linux server we own. We are moving and would like to have this all hosted by "someone else". As our instances are currently defined as HOSTS within Tomcat (not Virtual hosts), it appears we would require a dedicated host? Currently we utilize a firewall that performs port redirection to-from port 80 to the 8080 on Tomcat and then Tomcat performs the URL redirection. We noticed that the http://jspwiki.apache.org/ site shows "Support for Multiple Wikis" but, see nothing that expreses details as to what is supported. What are other people doing for "Multiple Wikis" What are providers are other people using for JSPWiki? Thanks! -- -jim Jim Willeke
Re: ldaps authentication to jspwiki
You might try remove the:
userPattern="uid={0},ou=people,dc=mydomain,dc=com"
and use (what I am using):
userBase="ou=people,dc=mydomain,dc=com"
userSearch="(uid={0})"
userSubtree="true"
We found the LDAP search to be much more flexible using this than the
pattern matching.
You should also be able to get some error from tomcat if it is failing.
You can turn on access logging:
http://tomcat.apache.org/tomcat-7.0-doc/config/host.html#Access_Logs
If you drop the LDAPS, You might also get a trace. (Not sure if SUN can
show the ldap requests) but tcdump (or wireshark) will.
--
-jim
Jim Willeke
On Tue, Aug 27, 2013 at 1:18 PM, John Pimentel wrote:
>
> Hi Jim,
>
> Thanks for the response.
>
> We are using Sun LDAP. Let me give you an example from my user account.
> Under my group container
> cn=UN_CTM_AdminGroup,ou=Control-M,ou=group,dc=mydomain,dc=com
> I have a attribute called uniqueMember.
> The value for my account is as follows:
> uid=JPimen,ou=people,dc=mydomain,dc=com
>
> I of course substituted our actual domain for mydomain in this example, but
> everything else is verbatim.
>
> So our groups are nmed by cn but the users are named by uid.
>
> Unfortunately our LDAP server will not accept anything other than ldaps
> connections, so I am stuck there.
>
> Also if you have any recommendation on how to enable security specific
> debug I would appreciate that.
>
> I found what appears to be a log level entry in my jspwiki.properties file.
> I changed
> log4j.rootCategory=INFO,FileLog
> To read
> log4j.rootCategory=DEBUG,FileLog
>
> Now, I do see debug entries in the /web1/dyscq/tomcat/logs/jspwiki.log
> file, but no entries appear when I try (and fail) to log in.
>
> Thanks again for any ideas.
>
> Regards,
> John Pimentel
>
> (Embedded image moved to file: pic11833.gif)Description: Description:
> ralogo_web
> jpimen...@ra.rockwell.com
> Office (414) 382-3354
> Mobile (262) 501-4785
>
>
>
>
> From: Jim Willeke
> To: user@jspwiki.apache.org
> Date: 08/27/2013 03:40 AM
> Subject:Re: ldaps authentication to jspwiki
>
>
>
> I would guess, as you show no information on your LDAP setup, this line is
> wrong:
> userPattern="uid={0},ou=people,dc=mydomain,dc=com"
>
> Are your users named by uid or cn?
> You show roles as named by cn and since you show dc=,dc= I would guess this
> is AD
>
> Also, try using LDAP vs LDAPS to help troubleshoot.
>
> -jim
>
> --
> -jim
> Jim Willeke
>
>
> On Mon, Aug 26, 2013 at 10:47 AM, John Pimentel
> wrote:
>
> >
> > Greetings,
> >
> > I am having difficulties getting LDAPS authentication to work and I think
> I
> > must be missing some fundamental configuration.
> >
> > My current state is that the Site loads and displays content properly,
> but
> > when I go to edit content or I select the log in page directly, my LDAP
> > credentials do not authenticate, and I am repeatedly presented with a
> login
> > page.
> >
> > I used the follwing information as my "How To" for this effort.
> > http://www.ecyrd.com/JSPWiki/wiki/WebContainerAuthenticationViaLDAP
> >
> > This article is very good but appears to be incomplete.
> >
> > I have done the following configuration to get ldaps to work:
> >
> > 1. I have a previously configured LDAP Server and I stored /trusted the
> > cert for this Sun LDAP server into the central java keystore using this
> > command:
> > /usr/lib64/jvm/jre/bin/keytool -import -alias sunldap
> > -file /web1/sst/dysc/content/CA-RA-v3.crt
> > -keystore /usr/lib64/jvm/jre/lib/security/cacerts
> >
> > 2. I have configured the realm and sorted out all the log errors using
> the
> > following realm in the server.xml file. I believe tomcat is successfully
> > connecting to my LDAP server.
> >
> >> connectionURL="ldaps://mkedsintp.ds.mydomain.com:636"
> > connectionName="uid=[bind User
> > UID],ou=admin,dc=rmydomain,dc=com"
> > connectionPassword="[Password]"
> > userPattern="uid={0},ou=people,dc=mydomain,dc=com"
> > roleBase="ou=Control-M,ou=group,dc=mydomain,dc=com"
> > roleSubtree="true"
> > roleName="cn"
> > roleSearch="(uniqueMember={0})"
> > />
> >
> > 3. I uncommented the "
Re: ldaps authentication to jspwiki
I would guess, as you show no information on your LDAP setup, this line is
wrong:
userPattern="uid={0},ou=people,dc=mydomain,dc=com"
Are your users named by uid or cn?
You show roles as named by cn and since you show dc=,dc= I would guess this
is AD
Also, try using LDAP vs LDAPS to help troubleshoot.
-jim
--
-jim
Jim Willeke
On Mon, Aug 26, 2013 at 10:47 AM, John Pimentel
wrote:
>
> Greetings,
>
> I am having difficulties getting LDAPS authentication to work and I think I
> must be missing some fundamental configuration.
>
> My current state is that the Site loads and displays content properly, but
> when I go to edit content or I select the log in page directly, my LDAP
> credentials do not authenticate, and I am repeatedly presented with a login
> page.
>
> I used the follwing information as my "How To" for this effort.
> http://www.ecyrd.com/JSPWiki/wiki/WebContainerAuthenticationViaLDAP
>
> This article is very good but appears to be incomplete.
>
> I have done the following configuration to get ldaps to work:
>
> 1. I have a previously configured LDAP Server and I stored /trusted the
> cert for this Sun LDAP server into the central java keystore using this
> command:
> /usr/lib64/jvm/jre/bin/keytool -import -alias sunldap
> -file /web1/sst/dysc/content/CA-RA-v3.crt
> -keystore /usr/lib64/jvm/jre/lib/security/cacerts
>
> 2. I have configured the realm and sorted out all the log errors using the
> following realm in the server.xml file. I believe tomcat is successfully
> connecting to my LDAP server.
>
> connectionURL="ldaps://mkedsintp.ds.mydomain.com:636"
> connectionName="uid=[bind User
> UID],ou=admin,dc=rmydomain,dc=com"
> connectionPassword="[Password]"
> userPattern="uid={0},ou=people,dc=mydomain,dc=com"
> roleBase="ou=Control-M,ou=group,dc=mydomain,dc=com"
> roleSubtree="true"
> roleName="cn"
> roleSearch="(uniqueMember={0})"
> />
>
> 3. I uncommented the "CONTAINER-MANAGED AUTH" section
> from /web1/dyscq/webapps/apps/wiki/WEB-INF/web.xml
>
> There is a section at the bottom that says "Update JSPWiki security policy"
> If you would like to set permissions to LDAP groups, you can simply add
> policy entries on authorize.Role. The following is an entry for wiki-admin
> group (from LDAP).
> grant principal com.ecyrd.jspwiki.auth.authorize.Role "wiki-admin" {
> permission com.ecyrd.jspwiki.auth.permissions.AllPermission "*";
> };
>
> I'm thinking it might go into web.xml, but I am not sure of that..
>
> this section of the xml looks like this:
>
>
>
>Authenticated area
>/Edit.jsp
>/Comment.jsp
>/Login.jsp
>/NewGroup.jsp
>/Rename.jsp
>/Upload.jsp
>DELETE
>GET
>HEAD
>POST
>PUT
>
>
>
>Read-only Area
>/attach
>DELETE
>POST
>PUT
>
>
>
>Admin
>Authenticated
>
>
>
>
>
>
>FORM
>
>/LoginForm.jsp
>/LoginForm.jsp
>
>
>
>
>
>This logical role includes all authenticated users
>
>Authenticated
>
>
>
>
>This logical role includes all administrative users
>
>Admin
>
>
>
> Regards,
> John Pimentel
>
> (Embedded image moved to file: pic05844.gif)Description: Description:
> ralogo_web
> jpimen...@ra.rockwell.com
> Office (414) 382-3354
> Mobile (262) 501-4785
>
>
>
>
> From: user-h...@jspwiki.apache.org
> To: jpimen...@ra.rockwell.com
> Date: 08/26/2013 08:16 AM
> Subject:WELCOME to user@jspwiki.apache.org
>
>
>
> Hi! This is the ezmlm program. I'm managing the
> user@jspwiki.apache.org mailing list.
>
> I'm working for my owner, who can be reached
> at user-ow...@jspwiki.apache.org.
>
> Acknowledgment: I have added the address
>
>jpimen...@ra.rockwell.com
>
> to the user mailing list.
>
> Welcome to user@jspwiki.apache.org!
>
> Please save this message so that you know the address you are
> subscribed under, in case you later want to unsubscribe or change your
> subscription address.
>
>
> --- Administrative commands for the user list ---
>
> I
