Current development on JAMWiki is primarily focused on maintenance rather than new features due to a lack of developer availability. If you are interested in working on JAMWiki please join the jamwiki-devel mailing list.



Upgrade across multiple versions[edit]

Archived from the Feedback page:

I have fallen behind on my upgrades. Can I go directly from 0.1.0 to 0.1.3 or must I run each individual upgrade? Thanks, CB 05-Aug-2006 07:-5 CDT

The code is set up so that all of the updates you need should be applied incrementally, so upgrading from 0.1.0 to 0.1.3 should work fine. The obligatory caveat is that I've not tried it personally, so it's possible a bug might be lurking in there somewhere, but I've also not heard any bug reports and the code is simple enough that I'm confident you'll be fine. For what it's worth, there were no database schema changes after 0.1.0, so the upgrade process shouldn't actually need to do anything for you other than update your system to register it as 0.1.3. -- Ryan 05-Aug-2006 20:50 PDT
>Upgrade from 0.1.0 to 0.1.3 went fine. Had a bit of a scare because I didn't copy mysql jar file into lib directory, but otherwise fine. Still need to see why I need mysql jar file in WEB-INF/lib as I already have it in shared directory. CB 06-Aug-2006 18:34 PDT
That may be due to the way the file is getting loaded - I'll take a look for the next release, but let me know if you discover anything. -- Ryan

Problems with installation (DB2/400)[edit]

Archived from the Feedback page:

I tried to install jamwiki version 0.4.3 on Windows XP with Tomcat 5.5.17 and Java 1.5.0_06-b05. Database backend should be a DB2/400. I added the newest JTOpen Driver (jt400.jar) to the webapp libs. I get the following error after the first installation page:

Ein unbekannter Systemfehler ist aufgetreten. Die Fehlermeldung lautet: Failure while executing insert into jam_virtual_wiki ( virtual_wiki_id, virtual_wiki_name, default_topic_name ) values ( ?, ?, ? ).

And i can't find any error logs. There is nothing in the standard error logs of Tomcat. There are tables/files created under the schema/lib in the database. Any idea?

By default errors should print to the Tomcat stdout log - there was nothing in those logs? Alternately you can customize the log location by modifying the /WEB-INF/classes/ file and updating the org.jamwiki.pattern value. I assume there had to be a failure creating tables during your installation, but I don't have a copy of DB2/400 to test with so I'd need a stack trace from the logs. If you do find something please let me know - you can either upload the log here, or email it to me at removed. Sorry for the trouble! -- Ryan 28-Nov-2006 10:35 PST
The problem was that the tables were not journaled. By default if the schema is created with the operating system command CRTLIB then the tables in this library/schema will not be journaled. If the schema is created with the sql command CREATE SCHEMA then the operating system will create everything for you (journals, journal receiver, ...) and every table created in this schema will be journaled. Everything went fine the moment i created the schema with the sql command. -- Mihael
Thanks, I've added this information to Installation#DB2/400.

Where is my[edit]

Moved from FAQ

I've downloaded the latest final version (0.6.3), unzipped it, and there isn't a in folder classes. Since I tried setup my Ldap-Connection, I can't login anymore, so I began searching the configuration ...

See Installation#Upgrades and the FAQ. During upgrades you'll need to backup & restore the file from your previous installation. -- Ryan 29-Feb-2008 06:45 PST

jamwiki update[edit]

Archived from the Feedback page:

Hi Ryan, hi all, I do have a problem with my local jamwiki-installation. After a system-crash I lost my jamwiki-war and all the jamwiki-properties and so on. But I do have a copy of the database-tables. How do I reactivate my jamwiki? Update seems impossible to me. How can I re-use my data? Thanks to all for every tips. Michael Habbert 17-Dec-2007 12:27 PST

I'm not sure if this will work for you, but when I'm testing I do the following:
  1. Backup your database data.
  2. Delete the JAMWiki database table (make sure you have a backup!)
  3. Install a new instance of JAMWiki using the same database settings as your old instance.
  4. Shut down JAMWiki.
  5. Restore you database from the backup.
  6. Restart JAMWiki.
I use that process to make a copy of on my local machine, and it seems to work well. Hope that helps. -- Ryan 17-Dec-2007 12:57 PST
Hi Ryan, I finally did it. Nearly done but:
2007-12-20 21:38:34,824 SEVERE: org.jamwiki.model.WikiUser - Unable to retrieve default roles for GROUP_REGISTERED_USER
java.lang.Exception: Failure while executing select * from jam_role where role_name in ( select jam_role_map.role_name from jam_group, 
jam_role_map where jam_group.group_id = jam_role_map.group_id and jam_group.group_name = ? ) 
       at org.jamwiki.db.WikiPreparedStatement.executeQuery(

So can I fix this by hand? ;-) -- Michael Habbert 20-Dec-2007 12:34 PST

Hi Ryan, I fixed it by hand! After some try and error I did setup a clear new jamwiki-site and transferred the old jam_topic and jam_topic_version tables into the new site. After that I rebuilded the StyleSheets and so ;-) the only thing will be to register again and change the sites with the category-tags so the categories become rebuild. Year!! Puh my last error from system crash is fixed ;-) Thanks. -- Michael Habbert 02-Jan-2008 00:21 PST

Upgrade blurs[edit]

Archived from the Feedback page:

I'm new to jamwiki, first of all thank you for that great tool. I'm sure it will help us a lot! Installation of 0.5.1 was plain sailing, but now I don't understand how to upgrade. Neither I can't find the everywhere mentioned UPGRADE.txt nor I know what to do when I'm told to "Remove the old JAMWiki installation" (running tomcat on a SuSE 9.2 box). Does that mean to delete the jamwiki dir tree? fmr 20-Mar-2007 00:20 PST

Documentation is unfortunately not a strong point of this project thus far, but contributions are always welcome. You're right that there isn't an UPGRADE.txt file, so any references should probably be removed. Step-by-step upgrade instructions can be found in the release notes as JAMWiki 0.5.2#Upgrades. "Removing the old installation" means deleting the JAMWiki files in your web application server, although that step isn't 100% necessary - it just avoids problems if (for example) a JAR file was updated and having two versions could produce problems. If you have suggestions as to how to make the upgrade steps clearer please feel free to edit JAMWiki 0.5.2#Upgrades and I'll be sure to use the updated steps for the next release. -- Ryan 20-Mar-2007 21:27 PST

Upgrade from 0.5.4 to 0.6.1[edit]

Archived from the Feedback page:

Today I did upgrade to 0.6.1 (using tomcat 5 with java 1.5 on a linux machine with mysql -> everything worked fine! Thanks to all of you. -- Michael Habbert 29-Oct-2007 07:46 PST

Glad it went smoothly, and thanks for the positive report! Given some of the recent bug reports I was beginning to fear that I was the only person who was able to upgrade without incident! -- Ryan 29-Oct-2007 22:16 PST

successful upgrade from jamwiki 0.5.0 to 0.6.5[edit]

Archived from the Feedback page:

After resolving some problems with my local tomcat installation (jamwiki is not running with the default configuration on kubuntu using the security manager ;-/). So I turned it of and then my old jamwiki (0.5.0) was working as befor. Upgrade then to 0.6.5 was excellent! Thanks Ryan and all the other Supporter. -- Mbert 01-May-2008 05:35 PDT

Thanks for the continued success stories! I test upgrades using a number of different configurations, but it's great to hear from others that it works as expected for them, too. -- Ryan 01-May-2008 08:03 PDT

Upgrade from 0.5.1 to 0.7.1 with database migration[edit]

Moved to Bug Reports#Upgrade from 0.5.1 to 0.7.1 with database migration

H2 database[edit]

Archived from the Feedback page:

tapaya 28-Jan-2009 11:49 PST

Currently running Windows XP / Tomcat 6.0 / HSQLDB (internal db) / Sun JDK 1.4 / JAMWiki 0.6.7.
I tried to move from the internal HSQLDB to a H2 database, so I did the following:

  1. copied h2-1.1.107.jar to C:\Programme\Apache Software Foundation\Tomcat 6.0\webapps\jamwiki-war-0.6.7\WEB-INF\lib\
  2. configured JAMWiki such that the contained the following:
homeDir=C\:\\Programme\\Apache Software Foundation\\Tomcat 6.0\\webapps\\jamwiki-war-0.6.7\\JAMWiki-Systemdateien
url=jdbc\:h2\:tcp\://localhost/~/../../Programme/Apache Software Foundation/Tomcat 6.0/webapps/jamwiki-war-0.6.7/JAMWiki-Systemdateien/h2/jamwiki
  1. re-started Tomcat
  2. started H2
  3. pointed my browser at http://localhost:8148/jamwiki-war-0.6.7/en/
  4. --> error message javax.servlet.jsp.JspException: java.lang.Exception: Failure while executing select * from jam_virtual_wiki

What was I missing?
Can anyone provide step-by-step instructions on how to use H2 database?

You would either need to do a fresh install with H2 (delete your old file) or else migrate the data from your old setup using the database migration tool on Special:Maintenance; the approach outlined above will assume that all tables already exist in the database, which won't be the case for a new instance. Note that the migration tool is experimental, so while it should work any bug reports would be appreciated. -- Ryan • (comments) • 28-Jan-2009 12:57 PST
I tried what you said (this time on my Mac): I set up a fresh JAMWiki including the .../apache-tomcat-6.0.18/webapps/jamwiki-war-0.6.7/WEB-INF/lib/h2-1.1.107.jar. The first access now yields "... Failure while executing CREATE UNIQUE INDEX jam_u_wuser_login on jam_wiki_user (lower(login)) ..." (cp. screenshot). What now? -- tapaya 28-Jan-2009 14:10 PST
H2 Screenshot.png
Thanks for re-trying. If you're willing to continue help debugging, any error message & stack trace from your log files (the default log file path is shown at the bottom of your screenshot) would be helpful. Others have had success installing with H2, so there is either something unique about your setup or else there is an unresolved H2 bug that simply hasn't affected others. -- Ryan • (comments) • 28-Jan-2009 14:44 PST
Back at work on my Windows machine I noticed that the error message is different than on the Mac; whatever, here's the last entries in the jamwiki.log.0:
2009-01-29 09:08:24,504 SEVERE: org.jamwiki.jsp - Error in JSP page
javax.servlet.jsp.JspException: java.lang.Exception: Failure while executing select * from jam_virtual_wiki
Caused by: org.h2.jdbc.JdbcSQLException: Tabelle JAM_VIRTUAL_WIKI nicht gefunden
Table JAM_VIRTUAL_WIKI not found; SQL statement:
select * from jam_virtual_wiki [42102-107]
        at org.h2.message.Message.getSQLException(
        at org.h2.message.Message.getSQLException(
        at org.h2.message.Message.getSQLException(
        at org.h2.command.Parser.readTableOrView(
        at org.h2.command.Parser.readTableFilter(
        at org.h2.command.Parser.parseSelectSimpleFromPart(
        at org.h2.command.Parser.parseSelectSimple(
        at org.h2.command.Parser.parseSelectSub(
        at org.h2.command.Parser.parseSelectUnion(
        at org.h2.command.Parser.parseSelect(
        at org.h2.command.Parser.parsePrepared(
        at org.h2.command.Parser.parse(
        at org.h2.command.Parser.parse(
        at org.h2.command.Parser.prepareCommand(
        at org.h2.engine.Session.prepareLocal(
        at org.h2.engine.Session.prepareCommand(
        at org.h2.jdbc.JdbcConnection.prepareCommand(
        at org.h2.jdbc.JdbcStatement.executeQuery(
        at org.apache.commons.dbcp.DelegatingStatement.executeQuery(
        at org.jamwiki.db.DatabaseConnection.executeQuery(
        ... 72 more

So it seems like the JAM_VIRTUAL_WIKI table doesn't exist; I was under the impression that any tables be created when first accessed ... -- tapaya 29-Jan-2009 00:31 PST

The JAMWiki setup process is triggered when no file is found - the error above looks like a wiki with an existing setup was used on a new database - let me know if that's incorrect. The screenshot posted yesterday looks like a failure during setup with H2, which may be a bug - there have been numerous reports of successful setups with H2, but it's not a database that I've ever used so I can't personally confirm whether there might be any issues with that database. If there are logs available that report the specific failure (the logs will contain the error from the database) then it might be easier to determine if the problem is a JAMWiki bug, a database configuration error, a security/permission error, etc. -- Ryan • (comments) • 29-Jan-2009 08:13 PST
You're right, when I remove the existing and go through the initial JAMWiki setup with H2 again, I always get the very error message from my screenshot. I hope my jamwiki.log.0 will shed some light on this! --tapaya 30-Jan-2009 00:55 PST
Thanks, the log is hugely helpful. It doesn't show any configuration errors, but for some reason it's unable to execute this line in the /WEB-INF/classes/ file:
CREATE UNIQUE INDEX jam_u_wuser_login on jam_wiki_user (lower(login))
The specific database error message is:
Syntax error in SQL statement CREATE UNIQUE INDEX JAM_U_WUSER_LOGIN ON JAM_WIKI_USER (LOWER([*]LOGIN))  ; expected ); SQL statement:
CREATE UNIQUE INDEX jam_u_wuser_login on jam_wiki_user (lower(login))  [42001-107]
I suspect that your version of H2 may not support using "lower" as a unique key, but I'll need to check the provided error code (42001-107) and investigate further. If you have time you can try changing that line in your /WEB-INF/classes/ file to the following and re-testing:
CREATE UNIQUE INDEX jam_u_wuser_login on jam_wiki_user (login)
One additional question - what version of H2 are you using? I'm surprised that others have not hit this issue, so I'm wondering if you have an older version. I'll look into this further this weekend, thanks for all of your patience. -- Ryan • (comments) • 30-Jan-2009 07:03 PST
I tried what you said, now the error message is different. I'll attach my jamwiki.log.0,1 again. I'm using the latest version of H2 (1.1.107). --tapaya 30-Jan-2009 08:05 PST
Thanks again. The message this time is:
NULL nicht zulssig fr Feld REMEMBER_KEY
NULL not allowed for column REMEMBER_KEY [90006-107]
I'm not sure why that would ever happen, so I'll need to try to replicate this weekend. Thank you very much for your patience. -- Ryan • (comments) • 30-Jan-2009 08:12 PST
I installed H2 today and got the errors you've indicated when I chose the "ANSI" database. Choosing "HSQL" worked, however - I'll update JAMWiki 0.7.0 to add a separate option for H2 that uses the HSQL configuration. Thanks for all of your help in debugging. -- Ryan • (comments) • 31-Jan-2009 22:34 PST
Could you please outline all the steps you've taken to get it working (I'm still getting errors when choosing HSQL)? And please let me know about your software setup! I'm especially wondering whether you start H2 on JAMWiki access or in a separate JVM. Thanks for all you help! --tapaya 02-Feb-2009 00:51 PST
First I installed the JAMWiki 0.6.7 WAR file. I had done some earlier tests with H2 so I shutdown the H2 server, cleared out the old H2 database files from my home directory, and then restarted H2 from the command prompt. Next I copied the "h2-1.1.107.jar" file to my /WEB-INF/lib directory, then started the app server (Tomcat), viewed the http://localhost/wiki/ page to start the setup process, and chose "HSQL" as the database type and used "org.h2.Driver" as the JDBC driver and "jdbc:h2:tcp://localhost/~/jamwiki" as the URL. After that the setup proceeded as normal. I also updated the 0.7.0 code to add a database option specifically for H2, and setup with H2 using that option that worked as well. This was all done on a Windows Vista laptop using Tomcat. Hope that helps! -- Ryan • (comments) • 02-Feb-2009 07:49 PST
Finally, I've got it all running! I wasn't aware that one must provide an administrator password. I've written up the steps I'd taken here. Thanks again for your help, Ryan! --tapaya 03-Feb-2009 03:25 PST
Glad it's working, and thanks for being so patient! Would it be OK if I moved the configuration information to Installation#Database Configuration? You've done a great job with the writeup and I suspect it will be very helpful to others. -- Ryan • (comments) • 03-Feb-2009 07:37 PST
It would be great if you put my writeup some place where everybody can find it quickly! Thanks! --tapaya 03-Feb-2009 15:11 PST

Unclear - images[edit]

Something that's a little unclear here is proper configuration of image locations. It seems that this must be located inside of the app deployment directory; I had configured it to an external location (which gets backed up), but there appears to be no logic to retrieve the file if it's not in the web app deployment path. This isn't really a problem, but it could be more clear in the instructions.

Any improvements you can make to the documentation would be much appreciated. The image location does not have to be within the app server directory as long as the app server is not serving the images - for example, on images are served by Apache, and the upload directory is completely outside of the app server path. In this setup the app server only needs access to read and write files to this directory since it must be able to write uploaded images and resize images as needed. Hopefully that's clear, but let me know if you still have questions. -- Ryan • (comments) • 06-May-2010 22:35 PDT

Changing installation paths[edit]

Hi there, I just thought I could share this short piece of knowledge here as it might happen to others as well and I haven't found it described on the main page but also didn't wanted to add it there as I wasn't sure of the significance. I had my system installed new and then had some problems getting JAMWiki to run again. Turned out it came from moving Tomcat to another partition as well as changing the Tomcat folder name. It was actually easy to fix: I had a backup of the whole Tomcat folder and just copied my jamwiki folder as well as the .war file over into the tomcat webapps folder. And then changed the folder paths in the two files

  1. /WEB-INF/classes/ and
  2. /WEB-INF/classes/

Actually not complicated - once I figured it out. :-|

Recreate JamWiki 0.6.6 from One system to another[edit]

Archived from the Feedback page:

Hi, I have installed Jamwiki in one of my system. But that system is going to be formatted. So I need to move all the content to another system.I'm using External database(MySQL). Please help me how to recreate my portal as it is from my new system. I tried to map the MySQL schema(Existing one) while doing the setup but I'was getting Connection could not established. So I created a new schema in MySQL and given it while installing and JamWiki started working. But I could not get any of my old data. Please help me so that I can recover all pages/documents/images/etc as how it was early. Venkat

You should have two options:
  1. You can do a new install on the new system, and if you point to the existing database you will get a warning about "data already exists, new tables will not be created". If you choose to continue JAMWiki will then be set up to use the existing database. Even though the database should not be changed by this process I'd recommend backing up your data first.
  2. You can simply copy your existing JAMWiki webapp files to the new system, and then manually edit any paths in /WEB-INF/classes/ that refer to the old system.
Hope that helps. -- Ryan • (comments) • 03-Jun-2009 10:13 PDT
I've written these steps out in slightly more detail at Installation#Migrating an Installation. -- Ryan • (comments) • 03-Jun-2009 13:09 PDT

Adding initial content[edit]

Archived from the Feedback page:


I need to add about 1000 topics (with files, images, and categories) to the wiki initially after installation. I installed the latest release (0.8.0) and chose to use external DB (MySQL).

After reviewing the database that was created after install, I tried to add some content directly to DB (filled up jam_category, jam_file, jam_file_version, jam_topic, and jam_topic_version tables), but all of the topics I added are shown as "not existing" on Special:Allpages. I reviewed newly inserted data, but didn't find any problems...

What I could miss there?

Thank you!..

Added later: Could this be an issue in character encoding? DB encoding is UTF8, and JAMWiki seems to get the query string correctly (it tells the correct topic name when it says that it's missing)...

Can you provide a sample (including column name) for one jam_topic record and its current jam_topic_version record? Without access to some sample data this one will be tough to debug remotely :) Thanks. -- Ryan • (comments) • 08-Dec-2009 14:22 PST
...also, since you're updating content outside of the normal flow, can you manually clear your cache from Special:Maintenance to ensure that the wiki didn't previously fail to find a topic and then cache the topic name as unavailable? Thanks. -- Ryan • (comments) • 08-Dec-2009 14:35 PST
Here are the samples:


topic_id virtual_wiki_id topic_name delete_date topic_read_only topic_admin_only current_version topic_type redirect_to
1673 1 'Зубов Федор Евтихиев' null 0 0 1673 1 null


topic_version_id topic_id edit_comment version_content wiki_user_id wiki_user_display edit_date edit_type previous_topic_version_id characters_changed version_params
1673 1673 Зубов Федор Евтихиев (?-1689) — иконописец. etc... 1 2009-12-08 16:42:38 1 null 397 null
And by now, I found that probably the problem is the URL/Request encoding, but I don't know how to fight it (I'm a newbie in Tomcat :(). You can see the wiki I'm trying to start in action here (oops, it doesn't respond right now, I submitted a TT to support). You will see the "?? ??????? ????" page - this is one of the pages that was originally added directly to DB. After that I clicked it, and tried to create this page "again" using JAMWiki interface this time. But after saving the page - it's name became a series of question marks (in fact, it created a new page in DB, and called it "?? ??????? ????")
The data above looks good... I'm unable to access the URL provided, but I don't think you should need any special configuration to get Tomcat working with UTF-8. The database, however, does need to be set up for UTF-8 - on MySQL the command to do so is create database database-name character set utf8. If you create an ASCII topic does everything work as expected? And if you create a non-ASCII topic using the wiki does it end up corrupted? If so then it's likely a database character set issue. If creating a non-ASCII topic works via the wiki then perhaps your loader is corrupting the data? -- Ryan • (comments) • 08-Dec-2009 16:04 PST
The website seems to work again. I specified UTF-8 when I was creating the DB. And I forced all of the tables to have UTF8 encoding (alter table xxx convert character set..., or something like this). The thing that looks strange is that Special:Allpages shows titles correctly, as they are in the DB, but it seems to be unable to find the records in the DB upon retrieval :(. BTW, here are the cases I just tried:
  • Created a page with only ASCII chars in title using my app, and it worked OK (the page title is 'An ASCII sample')
  • Created a page with non-ASCII chars in title using JAMWiki, and it gave me an error: "A system error has occurred. The error message is: The requested value "??????" was invalid. It may contain one or more characters which cannot be used in titles."
  • Created a page with only ASCII chars in title using JAMWiki, and it worked OK (the page title is 'Another ASCII sample')
Can you provide the stack trace from your JAMWiki logs when you get the system error? It's possible there is a bug in the JAMWiki code somewhere, but I thought that we had worked out the last of the character encoding issues... -- Ryan • (comments) • 08-Dec-2009 16:40 PST
The log file is empty :( At first there was no access to the directory it wanted to write logs, but I resolved it and the log file was created, but after reproducing the issue again for several times - the log file is empty.
What I understood by now:
  1. if I try to create a page with non-ASCII chars in title - it creates the page, but the page title contains question marks instead of non-ASCII chars in DB (while the DB is UTF-8, and jam_topic contains other non-ASCII strings)
  2. if I try to access a page that does not exist, and type in non-ASCII chars in URL - it writes me that the page doesn't exist, giving me a correct name of the page (ex: The topic "АБВГД" does not currently exist. To create it please follow the link: АБВГД.)
  3. if I try to access a page that was created in point 1 - it returns an error saying " The requested value "???" was invalid. It may contain one or more characters which cannot be used in titles. "
If a system error is generated it should definitely write to the logs, so there may be another issue... in any case, "?" is invalid for use in topic titles, which is probably where the error message you're seeing is coming from, although you're right that the root cause is an encoding problem. Just to make sure it's not a bug in the JAMWiki code, can you create a topic such as "АБВГД" on Others have been able to do so without issue, but let's just make sure there isn't something unique to your browser setup. If it fails on let me know the exact steps, although after four years I'll be surprised if we still have problems with character set encoding. Also, thanks for your patience! -- Ryan • (comments) • 08-Dec-2009 17:35 PST
I've added it - АБВГД :). BTW, I just recalled, that before running it on server I made all the same on my machine, and everything was working... Probably it's the issue with server configuration? But support guys say that URIEncoding is also utf-8, so I just don't know what alse might have a wrong setting...
My first guess would have been a database encoding problem, the second would have been a JAMWiki bug. Since it seems like neither of those are the culprit I did some googling and found this report of a similar issue with JSPWiki. Perhaps adding the config line to your server.xml file as suggested in the article will help? I'm off to bed for the night, but will check this thread again in the morning. -- Ryan • (comments) • 08-Dec-2009 23:05 PST
Morning! :). I submitted another question to my hosting support, but earlier they stated that Tomcat's default URIEncoding is UTF-8... What can you suggest about database encoding? Have a look at these screenshots: 1 2 3 4. Could this problem persist because of MyISAM instead of INNODB? -- Shavkat.
Added later: The web hosting support confirmed, that both connectors HTTP and AJP have a option for UTF encoding.
Thanks for the screenshots... I was able to access but I was getting memory errors when clicking on a topic that look like they're coming from the database. One question - was the database initially set up as UTF-8, or was it converted after you added initial data? Changing the database character set could be problematic. Otherwise your setup looks good, so I'm a bit confused as to what the problem might actually be... -- Ryan • (comments) • 09-Dec-2009 07:22 PST
Hi. Thanks for trying to help me, Ryan! I've just recreated everything from scratch, and nothing changed... The database is for some reason created with another charset, but before installing JAMWiki I changed encoding and collation, so all of the tables were created with utf8. The result is the same as it was earlier :(
(Re-indenting) I've tried accessing your site a few times but I'm consistently getting timeouts and "502 Bad Gateway" errors, which makes me wonder if maybe there are other issues. I've gotten through once and tried creating a topic with non-ASCII characters, and it looks like it created properly but I've been unable to access the site since then. As a result I'm deeply suspicious if there are system errors. Some things to check:
  • Look at your /WEB-INF/classes/ file and make sure that there are no permission errors for the file that it is writing to (which is specified by the org.jamwiki.pattern property). I think you said you were getting an empty log, so maybe try changing the log location (restart Tomcat) and see if you get some log info. If you do, and if there are errors in the logs, feel free to upload your log file to and I'll take a look.
  • Make sure that the "File-system directory" property (specified on Special:Admin under "Parser Settings) is a directory that you have write permissions for. Make sure that JAMWiki has created a "cache" and "search" folder within that directory.
  • Make sure you are using an up-to-date JDBC driver that is appropriate for your Java version. It should be placed in the /WEB-INF/lib directory.
Based on the information provided those are my best guesses, and I'd also follow-up with your hosting provider on why the gateway and other failures keep getting generated. Sorry I can't be more help - if you find any new info feel free to post here. -- Ryan • (comments) • 09-Dec-2009 20:59 PST
Thanks for your help again, Ryan. I have contacted support about those errors recently, and they responded that "you have a shared JVM, so if other users restart it - you can experience temporary 502-503 errors". I am frustrated with it, but I don't want to pay more for hosting on this stage...
In fact it creates pages with non-ASCII characters in title, but it writes a series of question marks into the database instead of the title itself. I know two reasons why this might happen:
# wrong URI encoding, but a) the tomcat's server.xml has HTTP connector's URIEncoding=utf8; and b) when you enter an URL for missing topic, the wiki suggests to create it with a correct name (not a series of question marks) - this means that the URI comes through tomcat with a correct encoding.
# wrong database encoding, but a) if I add a topic into the database manually - it is added in correct encoding, and b) JAMWiki can read those topics in correct encoding (because it shows correct titles on "Special:Allpages").
One more thing is MySQL connection encoding - but I'm not sure about those details.
Anyway, today I will give it a try on another server.
Ok, it's been more than a day, but I have finally been able to start up the project. I started it on a machine that I have full access to, so I could make any configuration changes I needed. Thank you very much for your help, Ryan, and I'm very sorry for taking so much of your time... :(
Right now, I have one last question - is the underscore supported in file names (ex. images)? I've found here that it's "partially resolved" - so is there a way I can upload correct records into DB so that image names with underscore are handled correctly? Currently they look like missing throughout the wiki pages...
Thank you! -- Shavkat.
Glad it's working! Underscores should be converted to spaces in topic names (including Image: topics) but the actual file itself can have underscores - see for example Image:activation link.jpg (space in topic name) which links to the file (underscore in file name). -- Ryan • (comments) • 11-Dec-2009 14:15 PST
Wow, that was easy, I wonder why I didn't find this out myself! :) Thank you! Overall - from what I found by now - JAMWiki is a great project, perfectly balanced and it's really fast. During the last week I installed it 20+ times using different configurations, and I found it always easy to install and maintain, also - a very clean DB structure helps in my case. Just for statistics, if you are interested, I have loaded 2000+ articles into JAMWiki, and didn't notice ANY performance issues... I think that's really cool :). I wonder if it will handle 50 000, but I believe there won't be any issues except for DB server performance optimizations...
Thank you again, and all the best! :) -- Shavkat.
Glad it's working, and thanks for the feedback! As to performance, see Tech:Performance for additional information - when it's released 0.9.0 will contain several significant performance improvements. I'm in the process of creating a wiki instance with five years of history and ~100,000 topics, so scalability should improve as well. -- Ryan • (comments) • 13-Dec-2009 18:46 PST


Archived from the Feedback page:

Long time since I've been here... (running 0.6.0).

As far as I can see nothing has changed with the upgrade doc. And I'm still not familiar with tomcat. Would be nice if you could help me...

I renamed the jamwiki*.war to wiki.war placing it in the CATALINA_BASE. It unpacks to the wiki directory, ok. Upload dir is in wiki/upload, db in wiki/system/database. That's our jamwiki we've been using during the last years and which helped us a lot to organize documentation, thanks a lot!

Now I want to upgrade.

I saved the .properties-files, the upload dir and another file with changes. And now? What does that mean, to remove the application? Does that mean to remove the wiki dir? I did so, cp the new jamwiki-0.6.5.war to wiki.war. I copied the saved files and dirs (incl. DB) into the new wiki dir. In the browser the setup page opens up, and I have to enter the 'wiki' dir into the top field. Entering the admin name and pw I press enter. And it warns me that a new installation will be done... why that? I want to make an upgrade? Seems I'm missing something. Frank 15-Sep-2010 04:22 PDT

I'll see if I can get the documentation updated with more detail after I finish work today, but two issues stand out from your report: automatic JAMWiki upgrades are only supported across two major versions (they will fail with a warning message otherwise) so you'll probably want to upgrade from 0.6.x to either JAMWiki 0.7.2 or JAMWiki 0.8.4, and from there to JAMWiki 0.9.2. I realize that this is somewhat inconvenient, but technically automatic upgrades are very difficult and require a lot of testing, so rather than increase complexity I've decided to only support automatic upgrades across two or fewer major versions. Second, if you see the "Setup" screen instead of the "Upgrade" screen it means JAMWiki is not reading from your old properties file (which contains database location and other configuration settings). Typically that means that JAMWiki was not installed as an exploded war (see I understand that this probably needs further explanation, so I'll try to get that done tonight after work. -- Ryan • (comments) • 15-Sep-2010 07:46 PDT
I've added some additional information to Installation#Upgrades - let me know if that helps. -- Ryan • (comments) • 15-Sep-2010 18:14 PDT
Wow! Thanks a lot, you're very kind!
Since the db is in wiki/system/database, removing the wiki directory will remove the db too. So why do you say it's optional to save the db? Frank 16-Sep-2010 01:36 PDT
In your case it sounds like it's definitely NOT optional, but I think most installations use a system directory that isn't within their webapp. For example, on the wiki is installed in $TOMCAT_HOME/wiki, but the image uploads and the wiki file directory is under $USER_HOME/wiki, so it wouldn't change during an upgrade. That fact can probably be made clearer, so please feel free to make any updates you think are necessary and I'll look at this again, too. For what it's worth, I've been meaning to revisit the upgrade process for a while now, and you've inspired a change that will be made for the 1.0.x release that will make future upgrades easier, so thank you! -- Ryan • (comments) • 16-Sep-2010 06:43 PDT
It's my turn to thank you for taking the time to help me understand the basics! Frank 16-Sep-2010 09:12 PDT
First try, upgrade from 0.6.0 to 0.8.4, error msg: Violation of unique constraint $$: duplicate value(s) for column(s) $$: JAM_P_USERS in statement [insert into jam_users (username, password) select login, encoded_password from jam_wiki_user_info]
Will try to upgrade to 0.7.2 Frank 17-Sep-2010 01:28 PDT
Forgot to copy second try with 0.8.4... now I get Cannot create PoolableConnectionFactory (The database is already in use by another process: org.hsqldb.persist.NIOLockFile@ed557531[file =/var/lib/tomcat6/webapps/wiki/system/database/jamwiki.lck, exists=true, locked=false, valid=false, fl =null]: java.lang.Exception: checkHeartbeat(): lock file [/var/lib/tomcat6/webapps/wiki/system/database/jamwiki.lck] is presumably locked by another process.). How to prevent this?
First, apologies for the trouble. There was a constraint added in (I believe) 0.7.0 to force logins to be unique regardless of case, and it sounds like that may be causing some problems for you. I haven't had to look at the older code in a while, so let me see if I can figure out what the resolution to that issue was. I have to catch a flight home after work today, but I'll make it a priority to get to this during the weekend. -- Ryan • (comments) • 17-Sep-2010 06:58 PDT
Thanks - but don't worry, no stress! Have a nice we! Frank 17-Sep-2010 08:38 PDT
Another user had what I believe is the same issue - see Bug_Reports/Resolved/0.7.x#Upgrade from 0.5.1 to 0.7.1 with database migration. The main problem in that case was there there were login records that differed only by case - example: "User" and "user" - but the security changes in JAMWiki 0.7.0 force logins to be unique in a case-insensitive way. The solution for the other user was to delete the offending user records, none of which had any edits associated with them, and we accomplished that by having him send me a copy of his HSQL database and I then made the necessary changes, upgraded, and sent him back the data. If you're not comfortable or don't know how to directly modify data in your local HSQL repository then I can help out, but I'd need a copy of your database files that I could install locally, something that may not be an option depending on the data in your wiki. Let me know your thoughts, and hopefully we can get this resolve without too much additional trouble. -- Ryan • (comments) • 18-Sep-2010 14:20 PDT
Right, I found a non-unique login re case. Thanks for your offer, but it touches several topics:
1. How to check if at least one of the logins has no edits?
2. If both have edits, how to assign the edits of one login to another?
3. I'm running the wiki on a linux server. I've tried several times to change data in the hsql db via command line, got no error messages, but realized that the data didn't change.
4. Right now I'm testing the upgrade on a fallback server, sending the database to you would mean to shut down the wiki to prevent changes, doesn't matter for the test system, but should be as short as possible on the productive system.
5. I really would like to switch to MySQL, but up to now I didn't find a simple step-by-step howto. Frank 20-Sep-2010 03:01 PDT
This may not be complete, but I think it will get you going in the right direction:
select wiki_user_id from jam_wiki_user where login = 'login_to_delete';
select wiki_user_id from jam_wiki_user where login = 'login_to_transfer_edits_to';
update jam_recent_change set wiki_user_id = id_from_step_two where wiki_user_id = id_from_step_one;
update jam_topic_version set wiki_user_id = id_from_step_two where wiki_user_id = id_from_step_one;
update jam_file_version set wiki_user_id = id_from_step_two where wiki_user_id = id_from_step_one;
delete from jam_watchlist where wiki_user_id = id_from_step_one;
delete from jam_wiki_user where wiki_user_id = id_from_step_one;
delete from jam_users where login = 'login_to_delete';
As to migrating to MySQL, I think that feature may still have been experimental in 0.6.0, but it should work now. See Configuration#System Maintenance - basically you just go to Special:Maintenance, enter the parameters for the new database, and the migration should be automatic, although backups are always recommended. -- Ryan • (comments) • 20-Sep-2010 21:45 PDT
On executing the last but one statement delete from jam_wiki_user where wiki_user_id = id_from_step_one; I get an error:
Integrity constraint violation JAM_FK_WIKI_UINFO_WIKI_USER table: JAM_WIKI_USER_INFO / ERROR CODE: -8 / State: 23000
While the changes to login and users made in JAMWiki 0.7.0 will be of huge benefit going forward, I'll be glad when all users of previous versions have upgraded and these issues are gone :)
I know how it feels! :-)
I think the following should resolve the error you mentioned:
delete from jam_wiki_user_info where wiki_user_id = id_from_step_one;
This table gets deleted as part of the upgrade process, so I'm not 100% sure that's correct, but looking at the old code I think it should resolve the problem. -- Ryan • (comments) • 23-Sep-2010 11:35 PDT
Ok, works! Now I'll try to go on with an upgrade.

Upgrade to 0.8.4 ok! I'll watch the wiki for a week, then I'll upgrade to the latest version.
Thank you once again!!!

Thanks for all of your patience! For what it's worth, future upgrades should be less painful - as JAMWiki matures the upgrade process is slowly becoming easier and more reliable, although it has proven to be one of the most difficult areas of the code to test completely since it is exercised only once by most installations. As I mentioned earlier, based on your experience I'm actually planning on putting some code in place for 1.0.0 that should begin the process of simplifying and consolidating the upgrade & setup flows, making future upgrades simpler and less error-prone. -- Ryan • (comments) • 24-Sep-2010 07:22 PDT

Upgrade from 0.9.5 to 1.0[edit]

Archived from the Feedback page:

Hi folks, I did grab the time to upgrade. After some small struggling it worked. Thanks to all. I got a success-message:

Spalte "logo_image_url" wurde zur Tabelle "jam_virtual_wiki" hinzugefügt.
Spalte "site_name" wurde zur Tabelle "jam_virtual_wiki" hinzugefügt.
Spalte "meta_description" wurde zur Tabelle "jam_virtual_wiki" hinzugefügt.
Sätze aus Tabelle "jam_topic_links" wurden gelöscht.
Neue Sätze wurden in Tabelle "jam_interwiki" hinzugefügt.
Sätze aus Tabelle "jam_configuration" wurden gelöscht.
Spalte "default_topic_name" in Tabelle "jam_virtual_wiki" wurde geändert.
Geänderte Sätze in Tabelle "jam_topic_links".
Geänderte Sätze in Tabelle "jam_category".
Geänderte Sätze in Tabelle "jam_topic".
Geänderte Sätze in Tabelle "jam_topic_version".
Ein optionaler Schritt ist beim Upgraden des Systems fehlgeschlagen. Das Upgrade wird fortgesetzt und das System sollte normal funktionieren.  
Bitte schauen Sie aber trotzdem in den Log-Dateien nach, welche Schritte fehlgeschlagen sein könnten. 
Bitte beachten Sie das /WEB-INF/UPGRADE.txt Dokument um manuelle Upgrade Schritte durchzuführen und Erstellen Sie einen Bug-Report in den Logs auf 
Die  Fehlermeldung lautet: java.sql.BatchUpdateException: Duplicate entry '128-SSHAllgemein' for key 'PRIMARY'
Die Stylesheets für das virtuelle Wiki "de" wurden geändert.
Die Stylesheets für das virtuelle Wiki "en" wurden geändert. 
Does that: "Duplicate entry '128-SSHAllgemein' for key 'PRIMARY'" still mean everythink is ok? -- mbert 26-Apr-2011 07:18 PDT
If it finished successfully then all major steps completed without error, but it sounds like one of the data update steps may have failed. There was an issue (fixed in 1.0.1) where namespace case-sensitivity could cause this sort of error - are you using 1.0, or 1.0.2? Are there any messages in your logs, hopefully with a stack trace? -- Ryan • (comments) • 26-Apr-2011 07:39 PDT
I received a similar message when I upgraded from 0.9.2 to 1.0.6--except my message is in English. My German isn't so good, but I think the messages are the same. ;-)
Upgrade from JAMWiki 0.9.2 to JAMWiki 1.0.6
Upgrade successful: StartingPoints
Added database column "logo_image_url" to table "jam_virtual_wiki".
Added database column "site_name" to table "jam_virtual_wiki".
Added database column "meta_description" to table "jam_virtual_wiki".
Added database table "jam_topic_links".
Added new record(s) to table "jam_interwiki".
Added database table "jam_configuration".
Modified database column "default_topic_name" in table "jam_virtual_wiki".
Updated record(s) in table "jam_topic_links".
Updated record(s) in table "jam_category".
Updated record(s) in table "jam_topic".
Updated record(s) in table "jam_topic_version".
An optional step has failed while upgrading the system. The upgrade will continue and the system will function normally, but view the logs to determine what steps 
may have failed. Please see the /WEB-INF/UPGRADE.txt document for manual upgrade steps and report any errors in the logs at The error 
message is: java.sql.SQLException: Violation of UNIQUE KEY constraint 'jam_u_topic_name'. Cannot insert duplicate key in object 'dbo.jam_topic'.
Updated stylesheet for virtual wiki "en".
What is the issue with the UNIQUE KEY constraint? It seems to be causing me problems, as after the upgrade, when I tried to "Regenerate Topic Metadata Records" from the Maintenance menu, I received the same error message. Can you please help? -- Brian 06-Sept-2011
jam_u_topic_name simply indicates that topic names must be unique (within a virtual wiki, and for topics that haven't been deleted), and somehow you've got two topics with the same name. That constraint has been there since at least the 0.6.x days (2007), so do you have an old installation that preceded the introduction of this constraint? Otherwise there is probably a bug somewhere in the code that might warrant a 1.0.7 release, but any clarification would be appreciated. -- Ryan • (comments) • 06-Sep-2011 19:16 PDT
I did have two topics with the same topic name--I found them by browsing the Allpages list. I have no idea how that happened. We were previously running 0.7.2, then upgraded to 0.9.2, then to 1.0.6. There was a problem with the upgrade from 0.7.2 --> 0.9.2 and it had to be completed manually. Maybe something happened there and a duplicate topic was created. I don't know. To solve the problem, I just deleted the second topic from the "Manage" tab. However, that doesn't seem to have completely deleted it from the database. How do I permanently purge deleted topics from the database/application? -- Brian 06-Sept-2011 22:35 CDT
It shouldn't be necessary to permanently delete it - the unique key is actually "virtual wiki + topic name + delete date", allowing for a topic to be deleted and a new topic with the same name to be created. Are you still encountering any errors, or are you able to successfully regenerate metadata now? If you do need to delete the old topic you can query the database for it, get its ID, and then attempt a "delete cascade" since there will likely be dependencies on topic versions and other metadata. -- Ryan • (comments) • 06-Sep-2011 20:48 PDT
I am still getting this error when trying to "Regenerate Topic Metadata Records" from the Maintenance tab. "The error message is: java.sql.SQLException: Violation of UNIQUE KEY constraint 'jam_u_topic_name'. Cannot insert duplicate key in object 'dbo.jam_topic'.." Other than that, everything else seems to be working fine. -- Brian 07-Sept-2011 09:33 CDT
I'll take a look at this tonight and see if I can make a workaround available that at least continues on after any failures, and preferably prints out a more helpful error message. -- Ryan • (comments) • 07-Sep-2011 08:08 PDT

(Re-indenting) revision 3723 updates the code so that it will continue on after any failure and print out two messages upon completion indicating number of successful topic updates and number of errors (if any). I'd also like to look into getting JAMWIKI-45 and JAMWIKI-46 resolved, and these three fixes would then make up the 1.0.7 release, which would be the last 1.0.x release. If you would like a beta to test with let me know and I can make one available for download, otherwise the final release will most likely be ready in 5-10 days. -- Ryan • (comments) • 07-Sep-2011 20:22 PDT

I'll wait for the 1.0.7 release and let you know how it goes. Thanks for the offer to beta test though. Once installed, I will also confirm that the vulnerabilities no longer exist in my scans. -- Brian 08-Sept-2011 12:26 CDT
I upgraded my wiki to 1.0.7. After the upgrade completed, I ran the "Regenerate Topic Metadata Records" and confirm that the updates continued on after a failure. The completion message that I received was something like "XXX Topics updated" and "X Topic updates failed". For me, two topic updates failed. Thanks for the fix! -- Brian 21-Sept-2011 09:52 CDT
Thanks for the confirmation - it's hugely helpful to get some validation that these issues are fixed beyond just my own testing! -- Ryan • (comments) • 21-Sep-2011 12:02 PDT