Comments:JAMWiki 0.3.4
Anonymous editing has been temporarily disabled. Please create an account in order to leave feedback or test wiki functionality.

JAMWiki 0.3.4

Archived from the Feedback page:

Release plans

I'm going to be out of town a lot over the next week, so it may be a while before the next release. The following list is the current schedule of items that might make it into JAMWiki 0.3.4. Let me know if there's anything that seems to be missing:

  • Roadmap#Configurable Signatures. This is now running on jamwiki.org, and will be included in beta3.
  • Allow moving a topic back to its original location (revert a page move). This is working locally, and I'll probably push to jamwiki.org later tonight after a bit more testing.
  • Bug Reports#Character problem
  • "Link to" for redirects does not show final link destination. Update: this functionality isn't hard to add but has performance implications, so will probably slip to another release.
  • Do not parse redirects as ordered lists (see Known Issues#Parser). Implemented for JAMWiki 0.3.4.
  • When deleting, provide an option to also delete comments page.
  • Upgrade functionality should also provide an option for a manual upgrade. If upgrade fails users are now directed to follow the steps outlined in the (new) UPGRADE.txt file.
  • Roadmap#Translation File History. Update: partially implemented. Versions are saved, which might be sufficient, although file uploads do not cause new versions to appear.
  • Allow inter-wiki links such as [[:Wikipedia:Main Page]]. Infrastructure is in place for this, I just need to take an hour to look at it.
  • Look into Colin's issue with a shared JDBC jar file not being found. I think this should be resolved with the next beta, although additional testing with different servers would be appreciated.
  • Remove remaining usage of Utilities.getMessage(). Most are gone, the remaining ones may not be a problem.
  • Add a "User contributions" link from user pages.
  • Address case sensitivity issues for topic names and user names. Update: constraint added to the database to ensure user logins are unique in a case-insensitive way.
  • Add validation to files, database settings, and other values updated through Special:Admin. JAMWiki 0.3.4 beta4 will include updated admin code that will not change configuration settings for the database or files unless the values submitted are valid.
  • Display warning when uploading an image and an image of the same name already exists.
  • Provide a way to delete image files.
  • Do not display the delete tag for users who cannot delete, or for new topics.
  • After editing a section, page should load to that section.
  • Add support for the Mediawiki <gallery> tag.
  • After editing the browser should redirect in a way such that pressing "refresh" will not re-submit the edit content.
  • Topics with names like "Topic/Archive" are currently not allowed, but Mediawiki supports names of this format.
  • Fix Colin's reported issue with relative image path not pre-pending the full path (needs opening /). Update: help text has been added to make it clear what format the path should be entered as.
  • Find a workaround for the Tomcat issue with percent signs in URLS (Bug Reports#Character problem II).

JAMWiki 0.3.4 beta1

Here's the first beta for 0.3.4:

This beta allows moving a page as described in #Move topic below, includes a few cleanups, and includes functionality to add a "n" next to new topics on the recent changes, contributions and history pages. This beta is not recommended for those who use JAMWiki in file persistency mode, although any testing feedback would be appreciated. -- Ryan 11-Sep-2006 23:23 PDT

JAMWiki 0.3.4 beta2

Here's the second beta for 0.3.4:

This beta drops log4j and uses the java.util.logging classes for logging. Sites using a custom /WEB-INF/classes/log4j.properties will need to make appropriate updates to the /WEB-INF/classes/logging.properties file. For sites that are already using the java.util.logging classes, the new code will obey existing logging.property values. -- Ryan 13-Sep-2006 21:39 PDT

JAMWiki 0.3.4 beta3

Here's the third beta for 0.3.4:

This beta (finally) introduces Scott's request for configurable signatures, includes some look & feel changes (recent changes page is sectioned by date, Special:Admin updated, user contributions link on history page), fixes a parser bug with tables, and probably adds one or two other changes that I'm forgetting. As always, feedback is appreciated. The plan for the next beta is to work on making the setup and upgrade process more robust, and once that's done I'll probably get ready to push the final release - hopefully by early next week. -- Ryan 14-Sep-2006 16:54 PDT

JAMWiki 0.3.4 beta4

Here's the fourth beta for 0.3.4:

I'd really appreciate any testing and feedback for this beta - it's not well tested, so don't use it with production data, but it should mostly work. I'm not planning on adding any other significant changes and will just be making bug fixes and cleanups until JAMWiki 0.3.4 is released. Changes in this beta include:

  • Add additional validation during setup to address Michael's issues.
  • Update the search engine initialization to address Michael's issues.
  • Properly retain file history when moving topics in file persistency mode.
  • (Hopefully) address Colin's issues with shared jar files not being found - feedback is appreciated on this one.
  • Fix unhandled exception that could lead to taglib errors being shown to users.
  • Update custom signature options per discussions with Scott.

There are other cleanups and changes in this release - check Subversion if you're interested. I'll be testing for the next couple of days, and will probably get a final release out early next week. -- Ryan 16-Sep-2006 22:24 PDT

Hi Ryan;-) OK, i deployed 0.3.4.

Here is my log-excerpt:

2006-09-17 17:40:16,744 [main] INFO  org.apache.catalina.core.StandardHostDeployer - Installing
web application at context path /jamwiki-0.3.4-beta3 from URL
file:/usr/share/tomcat5/webapps/jamwiki-0.3.4-beta3
Unable to load custom JAMWiki logging configuration, using system default Couldn't get lock
for %t/jamwiki.log.%g
java.io.IOException: Couldn't get lock for %t/jamwiki.log.%g
        at java.util.logging.FileHandler.openFiles(FileHandler.java:372)
        at java.util.logging.FileHandler.<init>(FileHandler.java:346)
        at org.jamwiki.utils.WikiLogger.initializeLogParams(WikiLogger.java:86)
        at org.jamwiki.utils.WikiLogger.<clinit>(WikiLogger.java:46)
        at org.jamwiki.servlets.JAMWikiFilter.<clinit>(JAMWikiFilter.java:39)
Stack trace trimmed
        at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:425)
2006-09-17 17:40:17,780 [main] INFO  org.springframework.web.servlet.DispatcherServlet
 - Initializing servlet 'jamwiki'

This looks pretty much like no accepted path for jamwiki.log. OK, I adjust the path again. -- Michael Habbert 17-Sep-2006 17:41

Ok, the adjustment: org.jamwiki.pattern=/jamwiki-0.3.4-beta3/jamwiki.log did not work either. 
2006-09-17 17:44:43,844 [main] INFO  org.apache.catalina.core.StandardHostDeployer - Installing
web application at context path /jamwiki-0.3.4-beta3 from URL
file:/usr/share/tomcat5/webapps/jamwiki-0.3.4-beta3
Unable to load custom JAMWiki logging configuration, using system default Couldn't get lock
for /jamwiki-0.3.4-beta3/jamwiki.log
java.io.IOException: Couldn't get lock for /jamwiki-0.3.4-beta3/jamwiki.log
        at java.util.logging.FileHandler.openFiles(FileHandler.java:372)
        at java.util.logging.FileHandler.<init>(FileHandler.java:346)
        at org.jamwiki.utils.WikiLogger.initializeLogParams(WikiLogger.java:86)
        at org.jamwiki.utils.WikiLogger.<clinit>(WikiLogger.java:46)
        at org.jamwiki.servlets.JAMWikiFilter.<clinit>(JAMWikiFilter.java:39)
stack trace trimmed
        at java.lang.Class.newInstance(Class.java:303)

-- Michael 17-Sep-2006 17:46

Ryan could you please correct the source-link to the http://jamwiki.org/jamwiki-0.3.4-beta4-src.war ist broken. So I might look at it myself.

-- Michael Habbert 17-Sep-2006 18:08

Hi Michael - the errors you've shown are all permission errors, which I'll try to add checks for. The default logger.properties setting is to write to the user temp directory, which should work but apparently didn't for you - I'll try to figure out how to catch that case. The second error is in trying to write to a /jamwiki-0.3.4-beta3/ directory - does that directory exist, and can Tomcat write to it? If you do a chmod -R 777 on the /jamwiki-0.3.4-beta3 directory, does the install work? Also, I've fixed the source code download links, thanks for pointing that out. -- Ryan 17-Sep-2006 19:04 PDT

JAMWiki 0.3.4 beta5

Here's yet another beta for JAMWiki 0.3.4:

This beta adds additional permission checking to validate that the log file can be written to and that other filesystem permissions are properly set. The setup process should throw an error if it encounters any problems. In addition, the upgrade process will also validate system settings and reports an error message for failed upgrades. This hopefully will be the last time that any translation files are changed prior to the next release - apologies to the translators for changing so many message strings during this release.

Michael, if you're still willing to help test please let me know if this release is more reliable for you. -- Ryan 17-Sep-2006 22:03 PDT

Hi Ryan;-)

I tried again with 0.3.5. With the plain war-file -> see the log-messages:

Unable to load custom JAMWiki logging configuration, using system default Couldn't get lock
for %t/jamwiki.log.%g
java.io.IOException: Couldn't get lock for %t/jamwiki.log.%g
        at java.util.logging.FileHandler.openFiles(FileHandler.java:372)
        at java.util.logging.FileHandler.<init>(FileHandler.java:346)
        at org.jamwiki.utils.WikiLogger.initializeLogParams(WikiLogger.java:83)
        at org.jamwiki.utils.WikiLogger.<clinit>(WikiLogger.java:46)
        at org.jamwiki.servlets.JAMWikiFilter.<clinit>(JAMWikiFilter.java:39)
Stack trace trimmed
        at java.lang.Class.newInstance(Class.java:303)

Adjusting the logging.properties-file: org.jamwiki.pattern=/jamwiki-0.3.4-beta5/log/jamwiki.log produces the following logs:

2006-09-18 12:45:06,004 [main] INFO  org.apache.catalina.core.StandardHostDeployer - Removing
web application at context path /jamwiki-0.3.4-beta5

trimmed

2006-09-18 12:45:21,591 [main] INFO  org.apache.catalina.core.StandardHostDeployer - Installing
web application at context path /jamwiki-0.3.4-beta5 from URL
file:/usr/share/tomcat5/webapps/jamwiki-0.3.4-beta5
Unable to load custom JAMWiki logging configuration, using system default 
Couldn't get lock for /jamwiki-0.3.4-beta5/log/jamwiki.log
java.io.IOException: Couldn't get lock for /jamwiki-0.3.4-beta5/log/jamwiki.log
        at java.util.logging.FileHandler.openFiles(FileHandler.java:372)
        at java.util.logging.FileHandler.<init>(FileHandler.java:346)
        at org.jamwiki.utils.WikiLogger.initializeLogParams(WikiLogger.java:83)
        at org.jamwiki.utils.WikiLogger.<clinit>(WikiLogger.java:46)
        at org.jamwiki.servlets.JAMWikiFilter.<clinit>(JAMWikiFilter.java:39)
Stack trace trimmed
        at java.lang.Class.newInstance(Class.java:303)
        at org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:212)
Sorry about the unfavorable error-loggings, anything I can do more to help? -- Michael Habbert 18-Sep-2006 12:51
Hi Michael - the log information shown above looks OK to me. JAMWiki is saying that it could not create a log file in the /jamwiki-0.3.4-beta5/log/ directory, probably because the directory either does not exist or is not writable. JAMWiki will then default to using whatever log Tomcat uses, and you should be able to continue setup. Did setup still fail for you? Were there any additional messages? What is appearing in your web browser when you try to view a Wiki page? -- Ryan 18-Sep-2006 09:07 PDT

JAMWiki 0.3.4 beta6

Here's yet another beta for JAMWiki 0.3.4:

Scott, this adds some loosened rules for topic names, disallowing only newlines, \, <, and >, [ and ]. It also tightens the rules for user logins, allowing only letters, numbers and the underscore. It also adds some fixes for having percent signs in topic names, but I'm still getting an error from either Apache or Tomcat with those symbols. This needs more testing, but should be fairly stable. -- Ryan 19-Sep-2006 00:40 PDT

Just a warning that the user name validation in this beta contains a bug that will trigger from the Special:Account page - I'll get an updated beta out before 3:00 PM this afternoon. Subversion already has a fix committed. -- Ryan 19-Sep-2006 12:34 PDT

JAMWiki 0.3.4 beta7

Here's hopefully one of the last betas for JAMWiki 0.3.4:

The only major change in this beta is a fix for user login validation. This code is also running on jamwiki.org as of five minutes ago. Testing is appreciated, and barring any surprises this should become the final JAMWiki 0.3.4 version in the next day or two. All of the translation files are currently somewhat out of date, so if any of the translators can update their language files it would be much appreciated. -- Ryan 19-Sep-2006 14:02 PDT

Hi Ryan, I tried beta7. There is still the Warning: 
WARNING: Unable to load custom JAMWiki logging configuration, using system default Couldn't
get lock for %t/jamwiki.log.%g

But I ignored it and started the configuration on: http://localhost:8080/jamwiki-0.3.4-beta7/en/Special:Setup with the know input;-). But:

INFO: Attempting to write file with empty virtual wiki for file topic.id
Sep 20, 2006 4:42:46 PM org.jamwiki.utils.WikiLogger info
INFO: Attempting to write file with empty virtual wiki for file topic_version.id
Sep 20, 2006 4:42:46 PM org.jamwiki.utils.WikiLogger info
INFO: Attempting to write file with empty virtual wiki for file admin.xml
Sep 20, 2006 4:42:46 PM org.jamwiki.utils.WikiLogger severe
SEVERE: Unable to create search instance
/usr/share/tomcat5/webapps/jamwiki-0.3.4-beta7/test/base/search/indexen
java.io.IOException: Cannot create directory: /temp
 at org.apache.lucene.store.FSDirectory.init(FSDirectory.java:171)
 at org.apache.lucene.store.FSDirectory.getDirectory(FSDirectory.java:141)
 at org.apache.lucene.store.FSDirectory.getDirectory(FSDirectory.java:117)
 at org.jamwiki.search.LuceneSearchEngine.getSearchIndexPath(LuceneSearchEngine.java:318)
 at org.jamwiki.search.LuceneSearchEngine.addToIndex(LuceneSearchEngine.java:90)
 at org.jamwiki.persistency.PersistencyHandler.writeTopic(PersistencyHandler.java:997)
 at org.jamwiki.persistency.PersistencyHandler.setupSpecialPage(PersistencyHandler.java:779)
 at org.jamwiki.persistency.PersistencyHandler.setupSpecialPages(PersistencyHandler.java:811)
 at org.jamwiki.persistency.PersistencyHandler.initialize(PersistencyHandler.java:451)
 at org.jamwiki.persistency.file.FileHandler.initialize(FileHandler.java:535)
 at org.jamwiki.WikiBase.reset(WikiBase.java:170)
 at org.jamwiki.servlets.SetupServlet.initialize(SetupServlet.java:115)
Stack trace trimmed
 at java.lang.Thread.run(Thread.java:595)
Sep 20, 2006 4:42:46 PM org.jamwiki.utils.WikiLogger severe
SEVERE: Exception while adding topic StartingPoints
java.io.IOException: Cannot create directory: /temp
 at org.apache.lucene.store.FSDirectory.init(FSDirectory.java:171)
 at org.apache.lucene.store.FSDirectory.getDirectory(FSDirectory.java:141)
 at org.apache.lucene.store.FSDirectory.getDirectory(FSDirectory.java:117)
 at org.jamwiki.search.LuceneSearchEngine.addToIndex(LuceneSearchEngine.java:90)
 at org.jamwiki.persistency.PersistencyHandler.writeTopic(PersistencyHandler.java:997)
 at org.jamwiki.persistency.PersistencyHandler.setupSpecialPage(PersistencyHandler.java:779)
 at org.jamwiki.persistency.PersistencyHandler.setupSpecialPages(PersistencyHandler.java:811)
 at org.jamwiki.persistency.PersistencyHandler.initialize(PersistencyHandler.java:

so its still the temp-dir for Lucene;-). But what will happen to the logging? if jamwiki could not get a lock on %t/jamwiki.log.%g? Where will all the logging go to catalina.out? OK for me but should jamawiki not check for the dir and the file and create it if not existing? I would suggest so. Next try I will start my mysql-db. -- Michael Habbert 20-Sep-2006 16:53

Hi Ryan, back after testing with my mysql so with the database there is the same problem: LuceneSearchEngine.addToIndex can not create directory: /temp. This evening I will look, whats up with this LuceneSearchEngine to become a new hint for the solution;-) so long -- Michael Habbert 20-Sep-2006 17:07
If the log cannot write to the file specified in logging.properties then it will default to the web application server's standard output file, so that warning is safe to ignore. If the file was valid and writable then it would use both that file and the standard out file.
As to the Lucene error, it looks like that is a problem somewhere in the Lucene code, although I suspect that Lucene is trying to use the Java default java.io.tmpdir directory and for some reason that property is not correctly specified on your system. I'm not sure how to work around that problem, but I'll take a look through the Lucene source code to try to figure this one out. Thanks again for all of your help, and sorry again about the trouble. -- Ryan 20-Sep-2006 10:23 PDT
Hi Michael - I've traced through the Lucene code, and it is indeed using java.io.tmpdir to determine where to put its lock files. Apparently that property is set to a directory that either does not exist or is not writable on your system. According to the Lucene code it should be possible to specify a different directory for the lock files using a system property, so I've updated the JAMWiki code to try to do so. I'll release a new beta to include this change. Thanks for your patience and help in tracking this problem down - I think you now hold the record for longest debugging of any JAMWiki issue! -- Ryan 20-Sep-2006 12:15 PDT
As an aside, I've reported this problem to the Lucene folks and the issue reports is at http://issues.apache.org/jira/browse/LUCENE-674. -- Ryan 20-Sep-2006 13:44 PDT

JAMWiki 0.3.4 beta8

Here's hopefully the last beta in what has become an amazingly long release cycle for JAMWiki 0.3.4:

This beta should hopefully, finally, and with any luck fix Michael's issue with Lucene - it explicitly specifies that Lucene should use a JAMWiki directory for storing search file locks, and NOT use the java.io.tmpdir property since that directory is apparently not writable on all systems. The only other change is updated Hungarian translations from User:bdanee and new Polish translations from User:dlpa. I'll wait a day to see if this fixes Michael's problem, and will release JAMWiki 0.3.4 after that, barring any other surprises. -- Ryan 20-Sep-2006 12:25 PDT

Hi Ryan, sorry but for me the problem is not fixed;-/.

Starting my usual configuration-attempt i receive the following:

INFO: Attempting to write file with empty virtual wiki for file topic_version.id
Sep 21, 2006 9:42:34 AM org.jamwiki.utils.WikiLogger info
INFO: Attempting to write file with empty virtual wiki for file admin.xml
Sep 21, 2006 9:42:34 AM org.jamwiki.utils.WikiLogger severe
SEVERE: Unable to create search instance
/usr/share/tomcat5/webapps/jamwiki-0.3.4-beta8/test/base/search/indexen
java.io.IOException: Cannot create directory: /temp
 at org.apache.lucene.store.FSDirectory.init(FSDirectory.java:171)
 at org.apache.lucene.store.FSDirectory.getDirectory(FSDirectory.java:141)
 at org.apache.lucene.store.FSDirectory.getDirectory(FSDirectory.java:117)
 at org.jamwiki.search.LuceneSearchEngine.getSearchIndexPath(LuceneSearchEngine.java:318)
 at org.jamwiki.search.LuceneSearchEngine.addToIndex(LuceneSearchEngine.java:90)
 at org.jamwiki.persistency.PersistencyHandler.writeTopic(PersistencyHandler.java:997)
 at org.jamwiki.persistency.PersistencyHandler.setupSpecialPage(PersistencyHandler.java:779)
 at org.jamwiki.persistency.PersistencyHandler.setupSpecialPages(PersistencyHandler.java:811)
 at org.jamwiki.persistency.PersistencyHandler.initialize(PersistencyHandler.java:451)
 at org.jamwiki.persistency.file.FileHandler.initialize(FileHandler.java:535)
Stack trace trimmed
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
[...]
Sep 21, 2006 9:42:34 AM org.jamwiki.utils.WikiLogger severe
SEVERE: Exception while adding topic StartingPoints
java.io.IOException: Cannot create directory: /temp
 at org.apache.lucene.store.FSDirectory.init(FSDirectory.java:171)
 at org.apache.lucene.store.FSDirectory.getDirectory(FSDirectory.java:141)
 at org.apache.lucene.store.FSDirectory.getDirectory(FSDirectory.java:117)
 at org.jamwiki.search.LuceneSearchEngine.addToIndex(LuceneSearchEngine.java:90)
[...]
INFO: Attempting to write file with empty virtual wiki for file admin.xml
Sep 21, 2006 9:42:34 AM org.jamwiki.utils.WikiLogger severe
SEVERE: Exception while adding topic LeftMenu
java.io.IOException: Cannot create directory: /temp
 at org.apache.lucene.store.FSDirectory.init(FSDirectory.java:171)
 at org.apache.lucene.store.FSDirectory.getDirectory(FSDirectory.java:141)
 at org.apache.lucene.store.FSDirectory.getDirectory(FSDirectory.java:117)
 at org.jamwiki.search.LuceneSearchEngine.addToIndex(LuceneSearchEngine.java:90)
 at org.jamwiki.persistency.PersistencyHandler.writeTopic(PersistencyHandler.java:997)
[...]

The attempt to create the temp-dir occures serveral times. -- Michael Habbert, 21-Sep-2006 09:49

JAMWiki 0.3.4 beta9

This one is for Michael only, provided I haven't scared him off.

If this doesn't work then there are two options:

  1. Fix the invalid java.io.tmpdir system property on your system. It is currently pointing at /temp, which is apparently either a non-existent directory on your system, or one which Tomcat can not write to.
  2. Wait for the Lucene guys to fix their code. They may not make the fix, a discussion is still ongoing.

Thanks again for all of your patience in testing this - my understanding is that it's unusual (but not that unusual) for a system to specify a bad java.io.tmpdir. It can be fixed on your system, but it would also be nice if JAMWiki could handle this case. I'll put out the final JAMWiki 0.3.4 tomorrow morning. -- Ryan 21-Sep-2006 01:01 PDT

Page Redirect

Archived from the Feedback page:

When you view a page with redirect=no (for example: http://jamwiki.org/wiki/en/Baby_Elephants?redirect=no), it parses the # in the redirect command as if it were a numbered list.

Here's an example of how wikipedia handles it: http://en.wikipedia.org/w/index.php?title=Elephants&redirect=no

-- scroco 07-Sep-2006 15:36 PDT

I've got this one listed at Known Issues#Parser - I'll see if I can get it resolved for the next release. -- Ryan 08-Sep-2006 11:04 PDT
I just pushed updated code that fixes this to jamwiki.org, and I've done Mediawiki one better by making it work for previews as well - Mediawiki parses #REDIRECT [[Topic]] as an ordered list when previewing. See Redirect for an example, and let me know if you have any suggestions for improvement. -- Ryan 08-Sep-2006 16:30 PDT

Move topic

Archived from the Feedback page:

If you move a topic, you can't move it back to it's original name (unless you first delete it's original topic, because a redirect has been placed there). Perhaps we could allow a move to an existing topic only if that existing topic is a redirect to the topic we are trying to move. -- scroco 07-Sep-2006 15:49 PDT

This is on the fix list for 0.3.4, and I think I've got an idea of how it could be handled. The existing redirect will need to be a topic with only one version, since otherwise allowing a page to be moved over a redirect would become a backdoor for non-admins to delete pages (you could simply make any page into a redirect and then move something over it). For pages with multiple versions an admin will still need to delete the redirect before a page could be moved into its place. Let me know if you see any shortcomings with that idea. -- Ryan 08-Sep-2006 11:04 PDT

What I propose will not allow a backdoor for deletes because only an original topic would be allowed to be moved over a redirect. For example:

  • Say there is a topic "Tiger"
  • Someone moves it to "Lion"
  • Now "Lion" is a normal topic, and "Tiger" redirects to "Lion"
  • My proposal says, allow a move to an existing topic only if that existing topic is a redirect to the topic we are trying to move.
  • If someone tries to move "Puma" to "Tiger", it won't work, becuase "Tiger" does not redirect to "Puma"
  • But if someone wants to move "Lion" to "Tiger", it will work, because "Tiger" redirects to "Lion"

Does that make sense? -- scroco 08-Sep-2006 13:26 PDT

Provided the history for each topic is kept then this makes sense, and I'm not sure why Mediawiki doesn't do things this way. To maintain topic history I'm envisioning that if "Tiger" redirects to "Lion", moving "Lion" to "Tiger" would be the equivalent of the following:
  1. Change the name of the topic "Lion" to "Tiger".
  2. Change the name of the topic "Tiger" to "Lion".
  3. Change the content of the new "Lion" topic from #REDIRECT [[Lion]] to #REDIRECT [[Tiger]].
Nothing gets deleted, it's easy to revert, and at a quick glance I don't see an easy way for vandals to abuse this scenario. Sourceforge Subversion is having issues again today so it may be a bit before I get to work on implementing this, but provided no one brings up any potential problems I'll try to get it done soon. -- Ryan 08-Sep-2006 17:36 PDT
This ended up being slightly tricky due to the fact that two topics can never have the same name, so the process ended up being:
  1. Delete the destination topic ("Tiger").
  2. Rename the "from" topic ("Lion" → "Tiger").
  3. Rename the destination topic ("Tiger" → "Lion").
  4. Undelete the destination topic.
  5. Update the destination topic content to redirect properly.
I need to test a bit more before pushing this to jamwiki.org, but hopefully later tonight I'll put the new code on the site and make a beta available. Those using file-based persistency will probably want to avoid the new code until at least beta two. -- Ryan 11-Sep-2006 17:46 PDT

log4j vs. java.util.logging

Archived from the Feedback page:

Michael's reported error due to the log file being read-only has gotten me looking more closely at JAMWiki's logging, and I'm wondering whether it would be worthwhile to switch from log4j to the Sun java.util.logging package. I'm more familiar with log4j because projects I've worked on in the past have required JDK 1.3 support, but moving to the java.util.logging package would save 350kb on the JAMWiki download size (no need for log4j.jar) and it looks like it provides the same functionality. In addition, it looks like it may be a bit easier to handle configuration errors with the java.util.logging class, which is the issue that Michael encountered.

Does anyone have any experience with the java.util.logging package? Is there any disadvantage to switching? -- Ryan 13-Sep-2006 11:51 PDT

I've started implementing the java.util.logging package - it's very similar to log4j, and barring problems or objections it will probably be the default logging mechanism for JAMWiki 0.3.4. -- Ryan 13-Sep-2006 15:14 PDT
I just pushed updated code to jamwiki.org that includes the new logging. I'll get a new beta available for download later tonight - users of the new beta will need to update the /WEB-INF/classes/logging.properties file to reflect their preferred log settings. -- Ryan 13-Sep-2006 20:34 PDT

New Recent Changes format

Archived from the Feedback page:

I like the new format of the recent changes page, with the daily date headers. That's a nice improvement. -- scroco 15-Sep-2006 10:14 PDT

It's another feature I've stolen from Wikipedia, so I can't take any credit, but I agree it's a nice improvement. -- Ryan 15-Sep-2006 11:33 PDT

Configuration of jamwiki-0.3.3

Archived from the Feedback page:

Recently I deployed jamwiki on my linux box (tomcat 5 and jdk-1.5.0_xx).

After correcting the log4j.properties to: log4j.appender.R.File=jamwiki-0.3.3/log/jamwiki.log (> java.io.FileNotFoundException: /jamwiki.log (Permission denied)<). The depoyment seems to go fine. But starting with the ../en/Special:Setup produced new trouble;-/

Ein unbekannter Systemfehler ist aufgetreten. Die Fehlermeldung lautet: Cannot create directory: /temp.
 
Verzeichnis für das Dateisystem: 	/path_to_tomcat/jamwiki-0.3.3/test/base
 
Persistenz: 	
[...]
 
Datei Upload Ordner (Webserver muss darauf zugreifen können): 	/path_to_tomcat/jamwiki-0.3.3/test/upload
Relativer Pfad des Upload Ordner bzgl der Webserver Root.: 	jamwiki-0.3.3/test/upload
 
Administrator Benutzer-Login: 	
Neues Passwort: 	
Neues Passwort bestätigen:

Both directories are under control (user:group) of tomcat. btw: I do not need a webserver (like apache)? the wording (webserver versus applicationserver alias tomcat) sometimes suggest it. At this moment I did not figure out where the temp-dir is from and whether or not the three directory-entries are valid?! Any Hints/Help is welcome.

12.09.06 22:03 Michael Habbert
Hi Michael - for 0.3.4 I'm going to try to make the setup & upgrade processes more robust. I've not seen any similar issues with requests for a /temp directory, but if you had a failed install you may want to try deleting the old install and starting from scratch to see if that helps. Also, if there are any messages in the logs let me know. Last of all, a web server is not required - I'll update the documentation unless someone else does so first. Thanks for the feedback, and sorry again for the troubles. -- Ryan 12-Sep-2006 20:21 PDT
Hi Ryan - I followed your Hint: clean deployment (from scatch) with the same result: Error: "Cannot create directory: /temp." So if the relativ path to the upload directory is ok?!, I'll stop searching for the error by now (mybe I try a nother testrun with a database;-). -- Michael Habbert 14-Sep-2006 20:21
Hi again:-) I was only looking for the tomcat logs and not into the jamwiki.log-file, sorry -> here is the Stacktrace (at the end (last line) the next Stacktrace from "Setup error" follows and so on. It look like some relation to the lucene engine. ... Hope this will give you a hint.

-- Michael Habbert 14-Sep-2006 20:28

2006-09-14 20:17:51,968 [http-8080-Processor25] WARN  org.jamwiki.Environment  - Property file
/srv/www/tomcat5/base/webapps/jamwiki-0.3.3/WEB-INF/classes/jamwiki.properties does not exist
2006-09-14 20:17:52,996 [http-8080-Processor25] ERROR org.jamwiki.servlets.SetupServlet  - Setup error
java.io.IOException: Cannot create directory: /temp
 at org.apache.lucene.store.FSDirectory.init(FSDirectory.java:171)
 at org.apache.lucene.store.FSDirectory.getDirectory(FSDirectory.java:141)
 at org.jamwiki.search.LuceneSearchEngine.getIndexDirectory(LuceneSearchEngine.java:338)
 at org.jamwiki.search.LuceneSearchEngine.copyRamIndexToFileIndex(LuceneSearchEngine.java:152)
 at org.jamwiki.search.LuceneSearchEngine.refreshIndex(LuceneSearchEngine.java:427)
 at org.jamwiki.WikiBase.reset(WikiBase.java:173)
 at org.jamwiki.servlets.SetupServlet.initialize(SetupServlet.java:116)
 at org.jamwiki.servlets.SetupServlet.handleRequestInternal(SetupServlet.java:64)
(stack trace trimmed)
 at java.lang.Thread.run(Thread.java:595)
2006-09-14 20:23:19,761 [http-8080-Processor24] ERROR org.jamwiki.servlets.SetupServlet  - Setup error
Yes, that's very helpful. I'll take a look through the Lucene code to try to figure out where the "/temp" directory is coming from and hopefully have this fixed for JAMWiki 0.3.4. Sorry for the trouble, but thanks for the report! -- Ryan 14-Sep-2006 11:45 PDT
One additional question: does the message "Undefined or invalid temp directory, using java.io.tmpdir" appear in your JAMWiki logs? -- Ryan 14-Sep-2006 13:47 PDT
Hi Ryan, im my logs there is no message about java.io.tmpdir you asked for. the only additional item is:
"Property file /srv/www/tomcat5/base/webapps/jamwiki-0.3.3/WEB-INF/classes/jamwiki.properties does not exist"

As long as we will succeed with our effort to configure everything right so I can start with my experinces with jamwiki i won't complain the troubles to get there;-) Michael Habbert 16-Sep-2006 16:24

Thanks for the clarification. The next beta release will include a fix for the problem in the stack trace, and will also include several new validation checks to ensure that configuration values are being set properly. With any luck JAMWiki 0.3.4 should fix your setup problems - thanks for being patient. -- Ryan 16-Sep-2006 16:28 PDT
Hi Ryan, at this moment the reason for my errors (looking for the temp-directory on my linux-system) seems to be located in the java.util.logging.FileHandler.generate()-method. On my system jamwiki will create all the lock-files somewhere in a temp-dir - as the result fo System.getPropery("java.io.tempdir");
My testclass (which is listing all the system-properties) shows: java.io.tempdir=/tmp what is right for my linux-system. Im suprised about the different result inside the tomcat-wiki environment. But I will search for it. -- Michael Habbert, 22-Sep-2006 14:28

Hi Ryan, I found (with the help of newsgroup:de.comp.lang.java) the reason for the wrong temp-dir;-)

catalina.sh:
| CATALINA_TMPDIR="$CATALINA_BASE"/temp
| [...]
| -Djava.io.tmpdir="$CATALINA_TMPDIR"

and CATALINA_BASE was empty;-). -- Michael Habbert 22-Sep-2006 15:07

Glad you found a solution. I was hoping that the JAMWiki 0.3.4 final release would finally solve your problems since I've removed any references in JAMWiki code to java.io.tmpdir, and hopefully also set things up so that Lucene should never use that value either. In any case, hopefully if you've been able to fix your Tomcat configuration then everything should now be working. Thanks for your patience in trying to debug this problem! -- Ryan 22-Sep-2006 11:58 PDT

Ver 0.3.3 and Images

Archived from the Feedback page:

Have just installed ver 0.3.3 after having to recreate new database and copy across all pages as something went wrong during the install - I was too busy doing other things so unfortunately can't comment on what went wrong.

In any case I have my files all up and running but for some reason images I have uploaded are not showing.

Contents of directory specified in admin page was updated (new file was inserted) with filename as in above error message.

Database records were updated (haven't listed all fields) with:

  • jam_file
file_id=3
virtual_wiki_id=1
filename=arctica1280.jpg
fileurl=/2006/9/arctica1280-02104102.jpg
mime_type=image/jpeg
topic_id=30
  • jam_file_version
file_id=3
fileurl=/2006/9/arctica1280-02104102.jpg
mime_type=image/jpeg
  • jam_topic
topic_id=30
virtual_wiki_id=1
topic_name=Image:arctica1280.jpg
topic_type=4

In my page I am referencing file as

[[Image:arctica1280.jpg]] but nothing shows

Clicking on "All Pages" does not show any of my image links but assume this is normal.

Any ideas? CB 02-Sep-2006 08:56 PDT

Found something but am not sure it is right even though it is working.

Under admin there is setting "Relative path from web server root to file upload directory" that I set to wiki/wiki and has worked with all prior versions.

Looking at the output source of web page of ver 0.3.0 and ver 0.3.3 sites I see version 0.3.0 img tag as

<a class="wikiimg" href="/jamwiki-0.3.0/en/Image:dcvFormat.png">
  <img class="wikiimg" src="/wiki/wiki/2006/8/dcvFormat-01081311.png"
       width="756" height="579" alt="" />
</a>

Under version 0.3.3 I see

<a class="wikiimg" href="/wiki/en/Image:dcvFormat.png">
  <img class="wikiimg" src="wiki/wiki/2006/9/dcvFormat-02102211.png"
       width="756" height="579" alt="" />
</a>

Clear difference in img src...

Changing relative path setting to /wiki/wiki under version 0.3.3 (which is now no longer relative) fixed the problem.

I have gone through several versions with relative path of wiki/wiki, but version 0.3.3 required a change - note I never upgraded to 0.3.1 or 0.3.2 so can't comment on these.

Under tomcat5/conf/Catalina/localhost I have wiki.xml file setting up /wiki as context (with linking enabled) and pointing to latest jamwiki version.

Under webapp/jamwiki-xxx I have symbolic link wiki pointing to my external storage directory - see below:

colinbes@colinbes-home:/usr/share/tomcat5/webapps/jamwiki-0.3.3$ ls -l
total 96
-rw-rw-r-- 1 root     colinbes 18915 2006-09-02 09:39 CHANGELOG.txt
-rw-rw-r-- 1 root     colinbes  1854 2006-09-02 09:39 CREDITS.txt
drwxrwxr-x 2 root     colinbes  4096 2006-09-02 09:39 images
-rw-rw-r-- 1 root     colinbes  1623 2006-09-02 09:39 index.jsp
drwxrwxr-x 2 root     colinbes  4096 2006-09-02 09:39 js
-rw-rw-r-- 1 root     colinbes 26980 2006-09-02 09:39 LICENSE.txt
drwxrwxr-x 2 root     colinbes  4096 2006-09-02 09:39 META-INF
-rw-rw-r-- 1 root     colinbes  8350 2006-09-02 09:39 README.txt
drwxrwxr-x 5 root     colinbes  4096 2006-09-02 11:00 WEB-INF
lrwxrwxrwx 1 root     colinbes     9 2006-09-02 09:46 wiki -> /var/wiki

Document says relative path must be relative to root. In my case I assume this is my wiki context (which would be same as jamwiki-0.3.3) - is this correct?

Thought I would provide this feedback, cheers CB

Thanks for the feedback Colin. I'll see what I can do to fix the image path issue for the next JAMWiki version. And I apologize for the problems with the upgrades - the automated upgrade process works for most people, but it's impossible to test with all configurations. In your opinion would it be worthwhile to have a "perform manual upgrade" option that would allow an administrator to simply run the required database upgrade scripts manually? It might solve the problem with an incomplete upgrade always redirecting users to the "Upgrade required" screen.
In any case, the feedback is very much appreciated, and I'll try to come up with some way to make upgrade failure recovery easier. Sorry again for the trouble. -- Ryan 07-Sep-2006 11:15 PDT
> Hey, nothing to be sorry about, you're doing an amazing job. Just wish I was watching a bit closer so that I knew what went wrong.
> With the amount of upgrades you are doing I think it would help if you listed any dependencies on pervious upgrades. This would help when user's install is behind current release. In my case I was at version 0.3.0 and was too lazy to run through each upgrade tp 0.3.3.
> I think it will help supplying a manual upgrade script, even if for only manually tweaking the database tables for conformity. Will also be a help after a failure as it appears present upgrade assume there has been no failed upgrade attempt. For example, in my case, 2nd run at upgrade failed trying to delete fields that no longer existed - they were deleted during failed upgrade. Either script/app should check state or only commit once all steps have been completed (not sure how portable this is though). I did want to look into how you are handling upgrade procedure to see how I could assist/offer advice if you're interested.
> Cheers CB
The latest code adds help text when setting up the file upload directory and relative directory that reads as follows:
File Upload Directory
The directory in which to store uploaded files, and from which files will be downloaded.
File Upload Relative Directory
Root path used in <img> tags; if the file upload directory is /docroot/wiki-files/, then the relative path is /wiki-files/.
That text may not be as clear as it could be, so suggested improvements are welcome. -- Ryan 18-Sep-2006 12:40 PDT