Other Sites
Active development of JAMWiki has ceased, and bug fixes and support will be limited at best. If you are interested in taking over management of JAMWiki please send an email to the jamwiki-devel mailing list.

Comments:JAMWiki 0.4.0


JAMWiki 0.4.0

Archived from the Feedback page:

Release plans

This is the list of issues that may be addressed for JAMWiki 0.4.0.

  • Use HSQL for file persistency as described in Roadmap#File_persistency. Implemented for beta1, needs testing.
  • Add support for Mediawiki templates as described in Roadmap#Templates.
    • Add support for <includeonly> and <noinclude> as described here. Added but not well tested, will be included in beta4.
    • "Link to" does not show topics that include a template. Should be working as of beta 5.
    • When template does not exist ({{non-existent template}}) an edit link should be shown. Should be working as of beta 5.
    • Add support for substitution such as {{subst:template}}.
    • Fix parameter substitution for named / unnamed per the spec.
    • Potentially add support for the msgnw option (does anyone use this?).
    • Support page inclusion such as {{:Include}}. Working on jamwiki.org, will be included in beta 7.
    • Test redirected templates (ie template created, then moved, and call made to old name). Support for template redirection added with beta 6.
    • Support for Mediawiki magic words. Update: as of JAMWiki 0.4.0 beta 8 a large number of the magic words are supported. Most likely full magic word support will come in a later release.
    • Template inclusion breaks section edit links (numbering off). Update: for now I've disabled section editing on pages that use template inclusion. This isn't a long-term solution, but thus far I haven't come up with a good way to handle this issue.
    • Wikitravel:Template:Quickbar doesn't work with JAMWiki 0.4.0, probably due to the use of templates in template parameters. This will go on the to-do list for 0.4.1.
  • Fix MS SQL issue described on Image comments:sql.mssql.properties. Resolved per Image comments:sql.mssql.properties, to be included in beta4.
  • During setup, check to see if database already exists in case user really meant to perform an upgrade. Added, will be included in beta 9. User is warned if a database exists and contains JAMWiki tables.
  • Provide translations for default topics as described in Roadmap#Translations_for_Default_Topics.
  • Provide support for a watchlist as described in Roadmap#Watchlist.
  • Add support for the Mediawiki reference tag as described in Roadmap#References.
  • DB2 database support.
  • MS SQL database support. Update: support updated/tested by Robert Matyja.
  • Alphabetical index for pagination as described in #Allpages pagination.
  • When two headings have the same name the TOC always links to the first one.
  • Pagination will link to a page with no elements when total % offset = 0.
  • Add the ability to assign roles to users such as translator, admin, sysadmin (may slip to 0.5.x).
  • Remove references to Special:AllTopics. Will be included in JAMWiki 0.4.0 beta2.
  • 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.
  • When deleting, provide an option to also delete comments page.
  • Roadmap#Translation File History. Update: partially implemented. Versions are saved, which might be sufficient, although file uploads do not cause new versions to appear.
  • 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.
  • 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. I don't think this is relevant any longer.
  • 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.
  • Add an option to limit the TOC depth to a specified number of headings.
  • Upgrade to the newly release Spring 2.0.
  • Parsing of images is slow, so look into parsing some image information to prevent the need to re-read images each time they are used.
  • MySQL upgrade from versions prior to 0.3.1 fails (see below). This one proved to be evil for a few reasons, but beta 9 will include code that I was able to successfully use to upgrade from 0.2.1.
  • Replace the AdminOnlyTopics default topic with a Special: page that automatically builds a list of admin-only (and possibly read-only) topics.
  • Add validation that template names are unique in a case-insensitive manner. Template and user page names should now be checked for uniqueness in a case-insensitive manner. This is not enforced at the database level. A larger discussion is whether or not topic names should be unique in a case-insensitive manner; Mediawiki doesn't do that, but I'm beginning to think it is a good idea.
Quick update, but the work on Mediawiki template support is continuing. The Subversion repository has the initial template code, but that code has some big scary issues that crop up in some test cases, and the cause of those issues is particularly good at hiding so I'm still tracking it down. I've put off some of the parser re-work (discussed below) for now, but will definitely be including some parser changes before the final release. Hopefully the second beta will be ready sometime tomorrow. -- Ryan 05-Oct-2006 23:25 PDT

JAMWiki 0.4.0 beta 1

Here's the first beta for JAMWiki 0.4.0:

This beta includes code to convert older JAMWiki installations using file persistency to use an embedded version of the HSQL database. Individuals interested in helping to test (and it would be appreciated!) can do so by performing the following steps and reporting success or failure:

  1. If you run JAMWiki in database persistency mode, create a copy of the database data by clicking on the "Convert database content to files" option in Special:Convert. This will create a file-persistency copy of your site but will not affect existing data.
  2. Make a backup copy of your /WEB-INF/classes/jamwiki.properties file.
  3. Install the JAMWiki 0.4.0 beta1 WAR file.
  4. If you run JAMWiki in database persistency mode, change the "persistenceType=DATABASE" line to "persistenceType=FILE" in the /WEB-INF/classes/jamwiki.properties file.
  5. Restart your web application server and view any page on your Wiki. The upgrade screen should display.
  6. Click the button to start the upgrade process, and wait while the file persistency files are converted to HSQL database format.
  7. Test the Wiki to ensure that everything is present and working.
  8. To revert to your old setup, simply replace the /WEB-INF/classes/jamwiki.properties file with the old, backed-up copy and restart. You will be prompted to upgrade after viewing any page on the Wiki, but the upgrade will not actually do anything when running in database persistency mode.

Feedback is appreciated! In addition this beta includes updates for DB2/400, so Henri, please let me know if it works for you. -- Ryan 02-Oct-2006 15:05 PDT

JAMWiki 0.4.0 beta 2

Here's the second beta for JAMWiki 0.4.0:

The changes include a fairly extensive rework of how the database interactions are handled. Feedback (as outlined above) is definitely appreciated. -- Ryan 02-Oct-2006 23:06 PDT

DB2/400 support works great. I wonder now if I should drop olds tables and start with new ones -- Henri 03-Oct-2006 14:20 CET
Great! It would probably be best to start with a fresh install, but it's up to you. Thanks for all of the help with testing! -- Ryan 03-Oct-2006 10:39 PDT

JAMWiki 0.4.0 beta 3

Here's the third beta for JAMWiki 0.4.0:

This beta includes early support for Mediawiki templates, but to enable templates you will need to select the "Use Mediawiki templates" checkbox on Special:Admin. Caveats:

  • The current template support is not completely compatible with Mediawiki. I'm working on it, but templates such as will not work.
  • The code for template support is pretty hideous to look at. I'll clean it up a bit, but try to shield your eyes when looking directly at it.
  • Enabling template support can cause the parser to fail in some cases. For example, {{template|param with a brace { in it}} would cause all Wiki markup on the rest of the page to be ignored. I'm still trying to figure out how to fix that.
  • <noinclude> and <includeonly> are not yet implemented.

Feedback on this beta is appreciated, but I know that things don't work perfectly, so please don't go crazy providing examples of broken template code; let me know about anything interesting, and hopefully the next beta will fix the most egregious bugs. -- Ryan 06-Oct-2006 15:06 PDT

JAMWiki 0.4.0 beta 4

Here's the fourth beta for JAMWiki 0.4.0:

The only new features in this beta are support for the template <noinclude> and <includeonly> tags. The majority of changes are bug fixes from beta3 and updates to the parser to (hopefully) begin simplifying things a bit. The parser has gotten so complex that it's tough to make changes to it without causing side effects, so I'm putting some energy into splitting it up into more manageable pieces. The new code is running on jamwiki.org, and there may be some odd parser behavior while bugs are worked out and the cleanups continue. -- Ryan 09-Oct-2006 23:16 PDT

JAMWiki 0.4.0 beta 5

Here's the fifth beta for JAMWiki 0.4.0:

The parser has been significantly overhauled in this beta and I'm sure that there are numerous issues that will need fixing, so this beta should be considered more experimental than most. Other changes this time around include new a new JUnit test framework, and the "Links" tab should again be working. There is more parser cleanup needed, but the code is easier to follow than it was a few days ago. The focus for the next few days will be on additional cleanups and fixes, with probably a couple more betas followed by a release candidate or two - I'd like 0.4.0 to be as well tested as possible. As always, leave any feedback or comments below. This new code is now running on jamwiki.org, so please also let me know if you encounter any problems here. -- Ryan 12-Oct-2006 01:30 PDT

JAMWiki 0.4.0 beta 6

Here's the sixth beta for JAMWiki 0.4.0:

Nothing particularly exciting in this release - as planned it contains a slew of fixes and cleanups, including fixes for some parser bugs that have been around since the beginning (for one, ampersands are now escaped - & to &amp; - so parser output is now closer to XHTML compliance, woo hoo!). The biggest change since yesterday is that I'm close to claiming that the parser cleanups have reached a point where it is possible to figure out how the parser code works, and many parser bugs present in yesterday's beta have been squashed. The only new feature since yesterday is that templates can now be redirected. Feedback is welcome as always, and the long slog towards 0.4.0 final will continue with a few more betas still to go. -- Ryan 12-Oct-2006 21:51 PDT

Couldn't get jamwiki-0.4.0-beta6.war (HTTP 404) -- Henri 14-Oct-2006 10:09 CET
Sorry about that, not sure why it wasn't on the server. It's there now. -- Ryan 14-Oct-2006 10:32 PDT

JAMWiki 0.4.0 beta 7

Here's another beta for JAMWiki 0.4.0:

Updates since the last release include:

  • Initial support for magic words, although work is ongoing.
  • A new list of inter-wiki links from User:axelclk.
  • Code has been added to read inter-wiki links in a case-insensitive way ([[Wikipedia:Article]] is the same as [[wIkiPeDiA:Article]]).
  • Several updated translations.
  • Support for template inclusion ({{:Help:Magic words}}).

More work is needed before the final release is ready, but if possible I'd really like to get 0.4.0 release out this week so I'll hopefully be putting in a lot of effort early this week to try and wrap things up. -- Ryan 15-Oct-2006 23:23 PDT

JAMWiki 0.4.0 beta 8

It's very late, so here's today's batch of updates:

This beta is mostly fixes, including template fixes to allow Template:If and other templates using embedded parameters to work properly. There is also support for additional magic words, HTML attributes are more strictly checked, and there are a few other bug fixes hidden in there. Bug fixing and cleanups will continue tomorrow, and I may try and take care of a few more of the release plan items before going into test mode for the final release. -- Ryan 17-Oct-2006 01:40 PDT

JAMWiki 0.4.0 beta 9

This should be it for new features in this release cycle:

New additions this time include fixes to the setup & upgrade processes, a few new magic words, and some miscellaneous template fixes. I'd like to do some testing and fix any reported bugs during the next few days, and hopefully get the final release out by Friday. As always, feedback is appreciated. -- Ryan 17-Oct-2006 21:58 PDT

Sandbox#Template tests -- ray 18-Oct-2006

Thanks, should be resolved now - "Template:test" and "Template:Test" should be seen as the same value. Thanks for pointing out the problem. -- Ryan 18-Oct-2006 15:17 PDT

JAMWiki 0.4.0 release candidate 1

Here's the first release candidate for JAMWiki 0.4.0:

Changes since beta9 include a few code cleanups, translation updates, and a fix for the issue reported by ray with template names of the form "Template:Test" and "Template:test". The final release won't happen before Friday, so there will probably be one more release candidate tomorrow. -- Ryan 18-Oct-2006 22:13 PDT

JAMWiki 0.4.0 release candidate 2

Here's another release candidate for JAMWiki 0.4.0:

I've been doing a lot of testing of the JAMWiki upgrade process and found some problems when upgrading from 0.2.1 to 0.4.0 using file persistency mode, so this release candidate fixes that problem. I've also tested upgrading from 0.2.1 to 0.4.0 using MySQL, and from 0.3.0 to 0.4.0 using Postgres, both without incident. An additional change was made to remove some references to "database persistency" since 0.4.0 removes file persistency. As always, feedback and any bug reports for this release are appreciated. -- Ryan 19-Oct-2006 12:15 PDT

JAMWiki 0.4.0 release candidate 3

Here's the (hopefully final) release candidate for JAMWiki 0.4.0:

Robert has updated the MS SQL support and Polish translations, and I've added a bunch of Javadoc and removed a couple of unused methods, otherwise this release is the same as RC2. Barring problems the final release will go out either later today or early tomorrow. -- Ryan 20-Oct-2006 11:36 PDT

File management code

Archived from the Feedback page:

I haven't done any Googling yet, but does anyone know a Java technology that they could recommended that offers the capability for querying attributes of file-based objects? Basically I need an easier way to manage JAMWiki's file persistency mode, allowing the capability to store topics and versions on the file system and then query that data store based on specific attributes. Currently JAMWiki's file persistency mode stores a lot of XML files on the file system, and there are some hoops that must be jumped through to keep indexes of needed values and to keep everything in sync. If there's a technology out there that would allow data to be stored on the file system and also provide a framework for querying and retrieving that data it would be nice... -- Ryan 24-Aug-2006 15:13 PDT

It looks like HSQL DB can be used as a database that could be distributed with JAMWiki. This would replace the current method of storing files as XML on the file system, but would still meet the goal of providing a way for people to run JAMWiki without installing a separate database. Given that managing XML files is becoming unwieldy, I'd like to look into implementing an alternative ASAP. If anyone has any experience with this database, or any reasons why it should or should not be used as a replacement for the current file persistency, please let me know. -- Ryan 26-Sep-2006 16:27 PDT
An Embedded HSQL DB would be great! -- wikimania 29-Sep-2006 11:15 CET

If you want another alternative, you could look into Apache Derby (http://db.apache.org/derby/) which can be embedded. I haven't used it myself, but here's an article (which reccommends measuring Derby's performance metrics before deciding if it will meet your needs): http://www.javaworld.com/javaworld/jw-09-2006/jw-0929-derby.html -- scroco 17-Oct-2006 11:44 PDT

I wasn't aware of Derby, so thanks for pointing it out. The Derby JAR file ends up being 2.2 MB, so unless there are significant advantages over HSQL it's probably a bit too heavyweight of a solution to include in the JAMWiki distribution. However, I think it probably makes sense to eventually add support for it as an external database. -- Ryan 17-Oct-2006 13:06 PDT

Topic Include

Archived from the Feedback page:

Just recalled another MediaWiki feature: Including one topic inside another. I'm not super interested in that feature, but wanted to list it here. -- scroco 08-Aug-2006 17:35 PDT

Can you add this to the Roadmap under "Unscheduled", and provide either a detailed description of the functionality or a link to a Mediawiki help page that describes this feature? I just want to be clear as to whether it's the subst functionality or something different. Thanks! -- Ryan 08-Aug-2006 18:12 PDT

This is my bad memory at work. The topic include feature was from a different software package, not MediaWiki. I should have looked it up first. -- scroco 09-Aug-2006 11:00 PDT

I investigated a bit more, and this template pretty much does what you're asking for. Once template support is added to JAMWiki then this should also be possible. -- Ryan 09-Aug-2006 10:56 PDT

JAMWiki 0.4.0 beta7 will include this feature - the syntax is {{:Topic name}} and is further described on http://meta.wikimedia.org/wiki/Help:Template#Composite_pages. -- Ryan 13-Oct-2006 15:59 PDT


Archived from the Feedback page:

Not sure if I understand the template but to me it seems as a way to include a page within a page. I have some common text I want to display in more then one page. Should {{page name}} include the stated page within wiki page? Thanks CB 12-Aug-2006 09:43 PDT

Once they are implemented (currently scheduled for JAMWiki 0.4.x) then yeah, templates should allow you to include common text in multiple pages. The syntax is a bit more complex than what you have above, but it's not too bad. See http://meta.wikimedia.org/wiki/Help:Template, and more specifically http://meta.wikimedia.org/wiki/Help:Substitution for details, and let me know if you have any questions, concerns, or suggestions. -- Ryan 12-Aug-2006 11:03 PDT

Other SQL Engines

Archived from the Feedback page:

I wonder if there is plan to support others DB engines, like Derby or DB2 (in my case DB2/400) ?

For DB2/400, I used the SQL synthax from sql.ansi.properties and only changed TEXT by CLOB. There is still an error with this line :

CREATE UNIQUE INDEX jam_unique_wiki_user_login on jam_wiki_user (lower(login))
Adding support for new databases is fairly easy, but I probably won't personally be adding support for more and will instead wait for patches from others. I'll start a document shortly about how to do this, but the important thing would be to send a sql.db2.properties that contains ONLY those statements that differ between DB2 and what's in sql.ansi.properties. With that file I could then update the required Java files within a few minutes. Someone would of course need to test things using the new database to make sure that there weren't any additional changes required.
If you would be willing to test then I'll put together an update that changes TEXT to CLOB for DB2 and updates the unique index constraint. Let me know. -- Ryan 19-Sep-2006 10:11 PDT
I'll be more than happy to help on DB2/400 port. I just add to change from TEXT to CLOB, and remove the lower(login) in the create index. Do you need more informations, for example JDBC URL to help other users ? -- Henri 19-Sep-2006 23:18 CET
The biggest thing to help with will be testing using DB2, since I don't have a DB2 database. At the moment I'd like to focus on getting the JAMWiki 0.3.4 release done, but once that's out (either tomorrow or Thursday most likely) I can make DB2 support the first item included in 0.3.5, and I'll then wait for your feedback to see if things are working properly. As to additional information needed, anything you think is important (including sample JDBC urls) will be helpful, and I'll also read up on IBM's guidelines for converting from ANSI to DB2. If that plan sounds reasonable then I'll make a first attempt at DB2 support (based on your comments about TEXT to CLOB and the index) for JAMWiki 0.3.5 beta1, and will work with you during the 0.3.5 release process to resolve any other issues. Thanks for offering to help, and hopefully things will go smoothly! Let me know if you have any questions or concerns. -- Ryan 19-Sep-2006 14:27 PDT
Ok ready to help. I need more informations about JamWiki/SQL links. Did JamWiki create the tables from Java and SQL templates or did it use the tables allready created by hand following the SQL properties files ? Regards -- Henri 21-Sep-2006 14:06 CET
All tables are automatically set up by JAMWiki as part of the JAMWiki setup process, which uses the SQL properties files. Thus the only thing you should have to set up by hand is to create the initial (empty) database. I'm going to get the JAMWiki 0.3.4 final release out in the next two hours, and shortly after that I should have a JAMWiki beta ready that includes DB2 support. What I'll need you to do is:
  • Create a new (empty) DB2 database for use by JAMWiki.
  • Completely remove any previously installed JAMWiki versions.
  • Install the JAMWiki war file beta.
  • Update the /WEB-INF/classes/logging.properties file with an appropriate log file location for your system.
  • Make sure permissions are set correctly and other Installation#Prerequisites are met.
  • Using a web browser, view any Wiki page to begin the setup process.
It's almost certain that there will be at least one or two errors, and they should be recorded in the log file - if you can then send me the stack trace from the logs and it should (hopefully) be easy to fix the problems. Again, give me a couple of hours to get the 0.3.4 release out, after which I'll make the first 0.3.5 beta available. And thanks again for helping out! -- Ryan 21-Sep-2006 09:24 PDT
I tried jamwiki 0.3.5 beta1 but I didn't see any activity to the remove DB2/400 system. I used for JDBC class com.ibm.as400.access.AS400JDBCDriver, JDBC url jdbc:as400://as400.mycorp.com;naming=sql;errors=full;date format=iso;time format=iso;extended dynamic=true;package=ODPJWIKI;package library=QTEMP;package error=exception;package cache=true;lazy close=true;trace=false, provided a valid user/password but no way, I didn't see any access to the remote DB. Could I create the tables by name and check if it works ? If so how ? At little later test give me as result : An unknown system error has occurred. The error message is: Cannot get a connection, pool exhausted. Do you want me to mail you the log ? -- Henri 22-Sep-2006 16:13 CET
Never mind, just checked my email and realized you've already sent the logs. I'll look into the problem, thanks! -- Ryan 22-Sep-2006 10:13 PDT
OK, I think that the validation query used to verify that a connection is good failed. That query is by default "select 1" - can you try running that query on your database to see if it is valid? Does "select 1 from sysibm.sysdummy1" work? If not, is there another query that can be run when no tables have been created? In Oracle the query is "select 1 from dual", but I don't think DB2 has an equivalent of Oracle's "dual" system table. -- Ryan 22-Sep-2006 10:52 PDT
select 1 from sysibm.sysdummy1 works on DB2/400 -- Henri 25-Sep-2006 12:50 CET

A first attempt at adding DB2 support is now available:

This beta is completely untested with DB2, so there will almost certainly be errors - please follow the instructions above and let me know any problems, and hopefully we can get them resolved quickly. -- Ryan 21-Sep-2006 11:00 PDT

Upgrading to 0.3.6 from 0.2.0 problem

Archived from the Feedback page:

As I get a error when accessing the Bug_Reports page (An unknown system error has occurred. The error message is: Infinite parsing loop - over 100 parser iterations.) I will put my report here: Im trying to upgrade JAMWiki from 0.2.0 to 0.3.6 but I get the folowing error:

13:07:04,826 INFO  [DispatcherServlet] FrameworkServlet 'jamwiki': initialization completed in 1184 ms
13:07:04,826 INFO  [DispatcherServlet] Servlet 'jamwiki' configured successfully
08-Oct-2006 13:07:08 org.jamwiki.utils.WikiLogger warning
WARNING: Property file /usr/local/geronimo/repository/default/xdtwiki/1160305622152/
 xdtwiki-1160305622152.war/WEB-INF/classes/jamwiki.properties does not exist
08-Oct-2006 13:09:00 org.jamwiki.utils.WikiLogger severe
SEVERE: Failure while refreshing search index
java.lang.Exception: Failure while executing select * from jam_topic
    where virtual_wiki_id = ? and delete_date is null
Caused by: java.sql.SQLException: Unknown column 'delete_date' in 'where clause'

Resulting in the folowing error message After pressing "Save Changes" in the Setup page:

A system error has occurred. The error message is:

org.apache.taglibs.standard.tag.common.core.NullAttributeException: The
"value" attribute illegally evaluated to "null" or "" in <link>

It seems there are som additional column 'delete_date' in jam_topic and a need of a alter table to insert it. Is there a inbetween upgrade that handles this (or any instructions left behind on column properties i guess it is a date)?

Feel free to remove/or move this after responding to it (Just give me a message in User Comments). Peter → Sun Oct 8 13:45:07 CEST 2006

Hi Peter - thanks for the reports, and sorry for the problems. I'm on my way out of the door, but it looks like the database upgrades failed. Since 0.2.0 there have been a couple of database schema changes, which you can manually implement by running the following SQL against your database:
drop table jam_image;
CREATE TABLE jam_category ( 
  child_topic_id INTEGER NOT NULL, 
  category_name VARCHAR(200) NOT NULL, 
  sort_key VARCHAR(200), 
  CONSTRAINT jam_pk_category PRIMARY KEY (child_topic_id, category_name), 
  CONSTRAINT jam_fk_category_child_id FOREIGN KEY (child_topic_id)
    REFERENCES jam_topic(topic_id) 
alter table jam_topic add column redirect_to VARCHAR(200);
alter table jam_topic add column delete_date TIMESTAMP;
alter table jam_topic drop constraint jam_unique_topic_name_vwiki;
alter table jam_topic add constraint jam_unique_topic_name_vwiki
  UNIQUE (topic_name, virtual_wiki_id, delete_date);
update jam_topic set delete_date = CURRENT_TIMESTAMP where topic_deleted = '1';
alter table jam_topic drop column topic_deleted;
alter table jam_file add column delete_date TIMESTAMP;
update jam_file set delete_date = CURRENT_TIMESTAMP where file_deleted = '1';
alter table jam_file drop column file_deleted;
alter table jam_wiki_user drop constraint jam_unique_wiki_user_login;
CREATE UNIQUE INDEX jam_unique_wiki_user_login on jam_wiki_user (lower(login));
Hopefully I didn't forget anything (I copied that down pretty quickly). Sorry again for the trouble - upgrade is unfortunately proving to be a common source of bugs for people. -- Ryan 08-Oct-2006 08:37 PDT
The reason for the upgrade failure just occurred to me:
WARNING: Property file /usr/local/geronimo/repository/default/xdtwiki/1160305622152/
xdtwiki-1160305622152.war/WEB-INF/classes/jamwiki.properties does not exist
When you upgraded, did you keep your old jamwiki.properties file? If JAMWiki cannot find an old property file it will NOT execute the automatic upgrade process, but will instead run through the setup process without performing any database upgrade. I can probably add code so that the JAMWiki version is stored in the database, which hopefully will prevent this confusion. In any case, have a look at the UPGRADE.txt document (distributed in the WAR file).
Also, if you complete the manual upgrade steps above, you will also want to refresh your search instance by going to Special:Admin and clicking on the "refresh search engine" button. I'm late for a meeting, but if you have any other questions I'll be back tonight. -- Ryan 08-Oct-2006 08:51 PDT

Thanks for the quick response Ryan, I did a test upgrade on my dev. maskin (on a db coppy) so this "upgrade" dident have anny inpackt on users ;). I read the UPGRADES section in the README.txt file in the .war and understand now way things whent a bit wrong.

So basically what I shuld do before I start up the upgraded wiki is to coppy the files mentioned in the README.txt file (especially jamwiki.properties) into the new upgrade location and It will trigger the database upgrade on startup of the web app (wiki). The Upgrade Instructions section on this wiki clearly states this things I just havent found it necessary to implement these stepps in other upgrades (but now it makes sence).
Peter → Sun Oct 8 18:56:28 CEST 2006

Thanks for the feedback. The upgrade process works by comparing the JAMWiki version in the jamwiki.properties file against the version reported by the currently running code, and triggering the upgrade process if the two versions don't match. Obviously if the old jamwiki.properties file doesn't exist then the upgrade process won't trigger. Several users have apparently been confused by that, and it's not very intuitive, so I'll try to come up with some way of testing whether a database exists or not and then warning that an upgrade (rather than a new install) should be used - you're not the first user who has missed the instructions in the README file! Perhaps storing a version string in a database table would do the trick - let me know if you have any suggestions. -- Ryan 08-Oct-2006 18:17 PDT
The issue with the Bug Reports page should now be resolved, although the code changes added to support templates may still cause other issues; despite the stability issues I like to put new code on jamwiki.org to provide additional feedback. -- Ryan 08-Oct-2006 22:26 PDT

The upgrade has failed. Please see below and check the logs for any failure messages, and consult the UPGRADE.txt document for details on how to perform a manual upgrade. Please report this error at jamwiki.org and provide any relevant information in the bug report.

I did go aheed and did the upgrade and got this error. This time i copied the jamwiki.properties properties file (and log4j file) to the new location.

Dropped jam_image table
Added jam_category table
Unable to complete upgrade to new JAMWiki version.: Failure while executing select * from
   jam_topic where virtual_wiki_id = ? and delete_date is null and topic_name = ?
Added redirect_to column to table jam_topic
Added delete_date column to table jam_topic
Unable to complete upgrade to new JAMWiki version.: Failure while executing alter
   table jam_topic drop constraint jam_unique_topic_name_vwiki
Unable to complete upgrade to new JAMWiki version.: null

Anny sugestions on how to fix this ? This is what I get when repeating the process.

The upgrade has failed. Please see below and check the logs for any failure
   messages, and consult the UPGRADE.txt document for details on how to perform a
   manual upgrade. Please report this error at  jamwiki.org and provide any
   relevant information in the bug report.
Unable to complete upgrade to new JAMWiki version.: Failure while executing drop
   table jam_image
Unable to complete upgrade to new JAMWiki version.: Failure while executing alter
   table jam_topic add column redirect_to VARCHAR(200)
Unable to complete upgrade to new JAMWiki version.: null
For whatever reason it looks like your upgrade will need to be completed manually - sorry about this. If you manually execute the SQL statements I indicated above (starting with "drop table jam_image"), and then update your jamwiki.properties file to change the wiki-version=0.2.0 property to wiki-version=0.3.6, it should work for you. Note that since the upgrade is partially complete some of the SQL statements may fail, but you should be able to ignore that. Also, once complete you will probably need to rebuild your search engine index by going to Special:Admin and clicking the "refresh search index" button. Sorry again for all of the trouble, and thanks for being patient. -- Ryan 10-Oct-2006 13:26 PDT

Okey thanks I will do that hang on gona report back (hopfully with good news).
Peter → Tue Oct 10 22:39:43 CEST 2006 Okey now i get this error:

An unknown system error has occurred. The error message is: Failure while
    executing select * from jam_topic where virtual_wiki_id = ? and topic_name = ? .

decribe tells me the structure of the table is:

mysql> describe jam_topic;
| Field            | Type         | Null | Key | Default           | Extra |
| topic_id         | int(11)      | NO   | PRI | NULL              |       |
| virtual_wiki_id  | int(11)      | NO   | MUL | NULL              |       |
| topic_name       | varchar(200) | NO   | MUL | NULL              |       |
| topic_read_only  | int(11)      | NO   |     | 0                 |       |
| topic_admin_only | int(11)      | NO   |     | 0                 |       |
| topic_content    | text         | YES  |     | NULL              |       |
| topic_type       | int(11)      | NO   |     | NULL              |       |
| redirect_to      | varchar(200) | YES  |     | NULL              |       |
| delete_date      | timestamp    | YES  |     | CURRENT_TIMESTAMP |       |
9 rows in set (0.01 sec)

Topic names seems okey and virtual_wiki_id=1 (hmm I probably messed up, dident copy the web.xml file)? Here is one potentiall problem

Caused by: java.sql.SQLException: Value '0000-00-00' can not be represented as java.sql.Timestamp

I changed the delete_date '0000-00-00' to somthing usefull (todays date) and got ridd of that error message but ended up with the next one

WARNING: error getting cached page en / LeftMenu
        at org.jamwiki.servlets.JAMWikiServlet.getCachedContent(JAMWikiServlet.java:127)
        at org.jamwiki.servlets.JAMWikiServlet.buildLayout(JAMWikiServlet.java:83)
        at org.jamwiki.servlets.JAMWikiServlet.loadDefaults(JAMWikiServlet.java:276)
        at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
        at java.lang.Thread.run(Thread.java:595)
Oct 10, 2006 11:20:07 PM org.jamwiki.utils.WikiLogger warning
WARNING: error getting cached page en / BottomArea
        at org.jamwiki.servlets.JAMWikiServlet.getCachedContent(JAMWikiServlet.java:127)
        at org.jamwiki.servlets.JAMWikiServlet.buildLayout(JAMWikiServlet.java:87)
        at org.jamwiki.servlets.JAMWikiServlet.loadDefaults(JAMWikiServlet.java:276)
        at java.lang.Thread.run(Thread.java:595)

Gona check what i can do about that.

Ah, my bad - the SQL I gave you above was for Postgres. In MySQL the delete_date column in jam_topic and jam_file is a DATETIME column, not TIMESTAMP. Hopefully if that change is made then all should be well. That should also explain why the upgrade failed - I'll try to make sure that's fixed for the next release. Let me know if that works for you! -- Ryan 10-Oct-2006 14:21 PDT

Yes I noticed it whas a problem with 'delete_date' but couldent find out what until you posted the reason. The wiki is now up again ;) and seems to be working fine.

alter table jam_topic drop column delete_date;
alter table jam_topic add column delete_date datetime;

did it! (and the same for jam_file) I now have one more wiki to update but I shuld probably wait until the next release, many thanks for guiding me throw this!
Peter → Tue Oct 10 23:53:43 CEST 2006

HSQL failure installing fresh from 0.4.0-beta5

Archived from the Feedback page:

Using cauchy resin servlet container on RH FC3, Java 2 Standard Edition (build 1.4.2-b28) -- using both the internal setting and selecting external but with the given defaults for the hsql I get rejected on the first admin page: _A connection could not be established with the database; please re-check the settings._

Is there somewhere that is collecting the log4j or some other diagnostic where I might find out what's going wrong? One possibility may be that there is a conflict between this version of hsql and the webapps/cocoon/WEB-INF/lib/hsqldb-, but since these are within the WEB-INF, wouldn't they be isolated from cross-interference?

Logs are set from the /WEB-INF/classes/logging.properties file - set the "org.jamwiki.pattern" property to the name of your log file. It's possible that the two jar files conflict - let me know if you figure out what the problem is, and if there is a stack trace in the logs feel free to upload it here. I'm buried with parser work at the moment, but if this issue isn't resolved in the next few days I'll try to reproduce it and get a fix ready. Thanks for testing! -- Ryan 12-Oct-2006 11:31 PDT
that property had the value "%t/jamwiki.log.%g" so I'm not at all sure where %t gets set; I'll change it to a hard path and see where that gets me, then get back to you here if there's anything more to report.
"%t" refers to the Java temp directory, and "%g" is a number to use when rotating logs - see the Javadoc for java.util.logging.FileHandler class for allowed values. I use a hard path (/var/log/jamwiki.log.%g) without any problems. This is one more thing I need to add to the documentation - there are always a million things to be done around here :) -- Ryan 12-Oct-2006 12:18 PDT
not a problem of things not done, only a problem of stuff people like me haven't chipped in to fix ;) ... turns out another app on this server is based on an old cocoon, and that cocoon will fail if I try to use the same newer hsql. I've switched to mysql using the driver from their website, but now I have a new problem ...

MySQL failure in 0.4.0-beta5

Archived from the Feedback page:

I hope this is all useful; sorry I'm not able to get better diagnostics out of this, but I'm just learning. This time, using com.mysql.jdbc.Driver and jdbc:mysql://localhost:3306/jamwiki I get a bunch of failurs on DROP TABLE commands (which is logical since there are no tables yet) but then ... [17:03:47.099] java.lang.Exception: Failure while executing select * from jam_virtual_wiki [17:03:47.099] at org.jamwiki.db.DatabaseConnection.executeQuery(DatabaseConnection.java:141)

I have verified that this login/pw can open the db in mysql, and the permissions allow for DROP, CREATE and the rest: grant all privileges on jamwiki.* to maj@localhost identified by 'pw'; flush privileges; -- it just seems like the new-installation build drops the tables but does not attempt to create them. after getting this error, I checked and there are still no tables defined.

oh, never mind, I think it's just not going to work with the older MySQL products; found this in the (now located!) jamwiki.log:

Caused by: com.mysql.jdbc.exceptions.MySQLSyntaxErrorException: You have an error in your SQL syntax near 'CURRENT_TIMESTAMP NOT NULL, CONSTRAINT jam_pk_vwiki PRIMARY KEY (virtual_wiki_id' at line 1

drat. if you want an experience in sysadmin horrorifics, do a google on what it takes to upgrade RH FC3 MySQL 3.23.58 to anything newer. Not for the faint of heart :(

Feedback is always appreciated, I just wish I had more time to address everyone's issues and concerns. As to MySQL 3.x, it's known to fail with the current code - see Supported Configurations#Non-Working Configurations. The problem is that older versions of MySQL don't support some fairly important features and differ from ANSI SQL significantly, so unless someone else can come up with a way to support that database in a way that doesn't make a mess of the JAMWiki codebase then MySQL 4.x and greater will be minimum requirements. I need to update the setup code to do a better job of displaying errors for those kinds of failures, but the to-do list is still quite long...
In addition, the JAMWiki documentation really needs to be updated to include better installation instructions and reflect the prerequisites; hopefully in the future that will get done by someone, but the quick rate of change in the code makes it a thankless task. I'm somewhat hopeful that the next month will see things settle down a bit, so with any luck I'll get to it if someone else doesn't do it first. Thanks again for the feedback. -- Ryan 12-Oct-2006 16:12 PDT

I finally had some time to try to reproduce your issues, and upgrading turned out to have a bunch of problems when using MySQL and when upgrading across more than one version. I've fixed the issues I encountered while doing a test upgrade from 0.2.1 to 0.4.0, so JAMWiki 0.4.0 beta 9 should hopefully solve your problems, although feedback is always helpful. Sorry for the trouble! -- Ryan 17-Oct-2006 19:29 PDT

Interwiki properties file

Archived from the Feedback page:

I created this Interwiki Properties file from the MediaWiki 1.7.1 distribution (path maintenance/interwiki.sql).
Note:: the wiki prefixes are in lower case as in the distribution. -- Axel Kramer

I've updated the JAMWiki interwiki.properties file in the source repository and also modified the InterWikiHandler code so that inter-wiki links are read in a case-insensitive way. My only concern is that we need to be very careful when using anything from the Mediawiki code base since their code is GPL, and JAMWiki is LGPL. It could probably be argued that the inter-wiki list is a specification rather than code, and in addition it is published at http://meta.wikimedia.org/wiki/Interwiki_map (which is GFDL), so in this case I think we're OK, I just tend to be somewhat over-cautious about license violations.
In addition I've added a "wikipedia" prefix to your list - seems like a useful one to have ;) Thanks for the update. -- Ryan 13-Oct-2006 11:21 PDT
An additional note - I removed the Wikipedia language version inter-wiki prefixes for now since they were causing a conflict with JAMWiki's virtual wiki handling - the JAMWiki default virtual wiki of "en" was being confused with the inter-wiki link to en.wikipedia.org. Let me know if that's a problem. -- Ryan 13-Oct-2006 11:47 PDT

Fixed Textarea edit buttons

Archived from the Feedback page:

There was a little bug in edit.js that wouldn't let the editor buttons work, it is fixed now. You can find the new fix here: http://jamwiki.org/files/2006/10/edit-13100931.js . You still need to uncomment the FIX ME line in edit.jsp for this to work.

I've updated the edit.js file with your change, and also updated the Javascript to format using Mediawiki syntax. I'm going to leave it disabled by default for now (remove the "FIXME" in edit.jsp to enable it) - it has some values that need translations, and there are a few other issues. Please feel free to add an item to the Roadmap if you'd like to see this enabled in a future release, or continue to upload changes/fixes and I'd be glad to apply them. -- Ryan 13-Oct-2006 11:47 PDT