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.3.0


JAMWiki 0.3.0

Archived from the Feedback page:

Lest anyone think I was taking the day off, the work on JAMWiki 0.3.0 is well underway. The basic work for categories is about 70% done, but in the process I've made some major changes to how the parser works, so things are going slowly. Once I've got categories mostly working I'll push the code to and release JAMWiki 0.3.0-beta1. Other items that may be addressed for 0.3.0 include:

  • Implement Mediawiki categories. Done, feedback and bug reports are welcome.
    • Implement for file persistency mode. Included in beta3, not well tested.
    • Implement sorting using sort keys. Implemented on
    • Implement Special:Categories. Implemented.
    • Display thumbnail gallery for images in a category. Implemented.
  • Roadmap#Special:Manage. Needs testing.
  • Roadmap#Configurable Signatures.
  • Roadmap#Page Move/Redirect (will probably slip to 0.3.1 or later).
  • Fix any issues from the Bug Reports page.
  • Fix the problem with links of the form [[#Section]]. Should be OK now, may require more testing.
  • Resolve diff issues (see Known Issues). javadiff-1.0.5 was released, which seems to fix these issues.
  • Allow inter-wiki links such as [[:Wikipedia:Main Page]]. Infrastructure is in place for this, I just need to take an hour to look at it.
  • Look into Colin's issue with a shared JDBC jar file not being found.
  • Store translation files as Wiki topics.
  • Remove remaining usage of Utilities.getMessage(). Most are gone, the remaining ones may not be a problem.
  • Add a "User contributions" link from user pages.
  • Handle files by MIME type to determine when to use the <img> tag and when to use the <a> tag.
  • Address case sensitivity issues for topic names and user names.
  • Add validation to files, database settings, and other values updated through Special:Admin.
  • Display warning when uploading an image and an image of the same name already exists.
  • Provide a way to delete image files.
  • Uploading a second version of an image should display a record on the Special:RecentChanges page.
  • Delete jam_image table (still under consideration). Done.
  • Add a jamwiki:param tag for use with jamwiki:link.
  • Fix issue with extra "/" in file history URLs.
  • Move WikiMessage and WikiException to the org.jamwiki package.
  • Do not display the delete tag for users who cannot delete, or for new topics.
  • Ajax not parsed as a link. Fixed.
  • After editing a section, page should load to that section.
  • Add support for the Mediawiki <gallery> tag.

As always, any serious bugs will take priority, and depending on the severity could end up forcing a JAMWiki 0.2.2 release prior to 0.3.0. If anyone has any feedback, a question, or a good joke, this is the place to post it. -- Ryan 17-Aug-2006 20:48 PDT

New code has been pushed to, and the first beta for JAMWiki 0.3.0 is available below. The new code will automatically create the jam_category table and drop the jam_image table - if you want to disable automatic upgrading, manually update the wiki-version property in to "0.3.0". In addition, the stylesheet will be automatically upgraded using the contents of the /WEB-INF/classes/pages/StyleSheet file.
This beta implements categories, but the implementation is still very rough. Images are not shown in category pages, editing and displaying new categories is still a work-in-progress, and sorting of categories (especially using the [[Category:Topic|Key]] syntax) is still a work-in-progress. In addition, the parser code has undergone some fairly radical changes, so there will almost certainly be bugs.
Feedback, bug reports and suggestions are welcome. -- Ryan 18-Aug-2006 01:21 PDT

JAMWiki 0.3.0 beta 2 is now available:

The new code is also running on Updates include some primarily cosmetic upgrades to categories (use columns when num elements > 9, do not display "Category:" prefix), updates to WikiPageInfo usage inspired by Scott, a fix for the issue with categories not checking virtual wiki, and a ton of code cleanups. I probably won't be near a computer much tomorrow, but leave a note if you have any issues and I'll get to them on Sunday. -- Ryan 18-Aug-2006 20:04 PDT

JAMWiki 0.3.0 beta 3 is now available:
I also just pushed this code onto The big change is support for categories in file persistency mode, some cosmetic changes in category display, a new version of javadiff that fixes several bugs, support for links of the form [[#Section]], and a few other miscellaneous changes. This beta isn't well tested, so feedback is appreciated. -- Ryan 21-Aug-2006 12:31 PDT

JAMWiki 0.3.0 beta 4 is now available:

This beta implements the Special:Manage functionality (admin only), replacing Special:Delete. There are a lot of new labels introduced with this change - I apologize to the guys who have been contributing translations! This beta also introduces the ability to undelete a deleted topic, fixes some parser bugs when processing links, and adds support for displaying images on a category page.

The latest code isn't on yet but I'll push it shortly once traffic to the site slows down. -- Ryan 22-Aug-2006 13:33 PDT

I've made a couple of small fixes, so prior to a final release here's a beta 5:

There was a bug when adding a new topic with a category, and I've removed the restriction against using an apostrophe in a topic name. Also some Javadoc additions, removal of some unused imports, and other stuff like that. -- Ryan 22-Aug-2006 20:05 PDT

Further testing has turned up a few bugs with image handling when in file persistency mode. It looks like these issues have been present since at least JAMWiki 0.2.1 and possibly longer, so I'm even more anxious to get the new release out. Either tonight, or more likely tomorrow morning. -- Ryan 22-Aug-2006 22:58 PDT
Two more minor bugs found (changing permissions could delete categories and a login redirect issue with Special:Manage). Rather than release a new beta I just uploaded the latest code again as beta5, so anyone downloading beta5 after this point should get all of the latest fixes. -- Ryan 23-Aug-2006 00:00 PDT
New code is running on now. Apologies to the people on the site who just saw a bunch of error messages - site traffic picked up right after I started pushing the changes. -- Ryan 23-Aug-2006 00:14 PDT

Categories and virtual wikis

The sql statment "STATEMENT_SELECT_CATEGORY_TOPICS" doesn't take virtual wikis into account. -- scroco 18-Aug-2006 11:40 PDT

Should be fixed in the latest beta. -- Ryan 18-Aug-2006 20:04 PDT

Release plans

A reasonably embarrassing bug showed up in JAMWiki 0.2.1, and since JAMWiki 0.3.0 beta4 has the minimum number of features I wanted to include in the new release I may try to get the new release out very soon. My plan is to add a few cleanups/bugfixes today, and then do some testing with the plan being getting the final release out early tomorrow. If anyone has feedback, translations, or bug reports please let me know. -- Ryan 22-Aug-2006 14:33 PDT

Hungarian translation updated in Special:Translation page. --bDaneE 22-Aug-2006 15:05 PDT
Thanks! The next release (0.3.1) will probably include functionality to automatically save versions of translations and add an entry on the recent changes page when translations are updated, so hopefully that will make it easier to manage these files. -- Ryan 22-Aug-2006 15:08 PDT


Archived from the Feedback page:

What is the JAM_IMAGE table used for? -- scroco 08-Aug-2006 12:10 PDT

It's unused at the moment, but the idea is that jam_file would be used for generic file information, and jam_image could then be used to store image-specific information like width and height. At the moment a file such as Image:LocationSenegal.png displays with no height or width specified. If no one beats me to it I figured I'd update the image code while implementing image resizing, which is on the Roadmap but unscheduled. -- Ryan 08-Aug-2006 12:34 PDT
I'm having second thoughts about this one - if benchmarking shows that reading the image file from the filesystem to get width & height info is reasonably fast then this table might be able to go away. If you can think of any other advantages to having it, let me know. -- Ryan 15-Aug-2006 00:35 PDT

Personally, I don't think you need it. For that matter, I'm not sure you need to know the width and height of an image at all. Don't all browsers simply show the image at it's natural size if no dimensions are specified in the img tag? And if you only specify one dimension (e.g. width), don't they scale the image appropriately? -- scroco

The problem with not including width and height is that it can slow down the page rendering time (the browser doesn't know how much space to allot for the image) and, more importantly, XHTML compliance requires that the height, width, and alt tag be specified. Those aren't huge issues - things will still work fine, but the programmer who lives in the back of my brain is always yelling about standards compliance.
The Java image processing classes seem to be surprisingly fast, so it may not be a problem to just have them parse an image to get width and height - some image formats store that information as metadata, which should make the process even faster. I'll try and get some performance numbers today, but at this point I'm leaning towards just dropping jam_image entirely. -- Ryan 15-Aug-2006 10:47 PDT


Archived from the Feedback page:

MediaWiki supports categories, I'm interested in that feature. I don't see it on the JAMWiki Roadmap, is it already implemented? -- scroco 08-Aug-2006 10:20 PDT

No, but I'll add it. The eventual goal is feature-parity with Mediawiki, so pretty much anything they do will end up on the roadmap at some point. Generally I try to prioritize things based on how vital they seem to be, how difficult they are to do, and how many people are asking for them. Categories shouldn't be too terribly difficult, so I'll add them under "Unscheduled" for now and expect that they'll make it into one of the next three major releases (0.2, 0.3 or 0.4). If this is a critical feature for you let me know and I can try to bump up the priority. -- Ryan 08-Aug-2006 10:20 PDT

I wouldn't classify it as "critical", but it is important for me. -- scroco 08-Aug-2006 12:55 PDT

Let's put it on the Roadmap tentatively for the JAMWiki 0.2.x release cycle. I don't think categories will be terribly difficult to implement, but if there's some aspect of them that proves troublesome then they'll almost certainly take a bit longer to release. -- Ryan 08-Aug-2006 12:59 PDT


Archived from the Feedback page:

The fact that the following code exists in JAMWikiServlet.loadDefaults() concerns me. If true, the object is being shared by all requests. With heavy traffic, there would surely be problems.

  // reset pageInfo object - seems not to reset with each servlet call
  this.pageInfo = new WikiPageInfo();

In my installation, I removed the pageInfo class variable from JAMWikiServlet and reworked all the servlets so that a new WikiPageInfo is created in every handleRequestInternal method, and then added to the ModelAndView.

  WikiPageInfo pageInfo = new WikiPageInfo();
  next.addObject("pageinfo", pageInfo);

As the ModelAndView is passed around, the pageInfo object is available in subsequent methods.

  WikiPageInfo pageInfo = (WikiPageInfo) next.getModel().get("pageinfo");

FYI -- scroco 18-Aug-2006 10:06 PDT

Good catch, will be cleaned up for the next beta. Thanks. -- Ryan 18-Aug-2006 11:37 PDT
Even though it makes the code a bit messier, I think it makes more sense to just pass methods that need it the WikiPageInfo object, rather than doing:
WikiPageInfo pageInfo = (WikiPageInfo) next.getModel().get("pageinfo");
My reasoning is that explicitly passing an object prevents non-obvious errors - if someone forgot to add the "pageInfo" object to the ModelAndView object, the above will produce a NullPointerException when the pageInfo object is accessed. Similarly, if someone should grab the pageInfo object and try to reset it using pageInfo = new WikiPageInfo(), they also have to remember to add it back to the ModelAndView object. I've got this running in my local code, but let me know if you have any objections. -- Ryan 18-Aug-2006 15:22 PDT

Yeah, that sounds good. -- scroco 18-Aug-2006 17:02 PDT

Lock topic

Archived from the Feedback page:

How would you feel about adding another tab to the top-menu for locking/unlocking topics? If the topic is not read-only, the tab would say "lock". If clicked, the topic would become read-only and the tab would then say "unlock". This would be an admin-only tab. -- scroco 16-Aug-2006 12:12 PDT

I like the idea, but it might be nice if there was some way to offer that functionality without adding another tab - perhaps changing the delete tab to "Manage" or something like that, and then including stuff like topic permissions as checkboxes (read-only, admin-only) and also displaying the current delete functionality. We could then have some other indicator on topic pages to denote to non-admin users that a topic is read-only for them. Would that work? -- Ryan 16-Aug-2006 12:20 PDT
Absolutely, that sounds great. -- scroco 16-Aug-2006 12:37 PDT

Locking of Pages

Archived from the Feedback page:

I assume the correct way to ensure a page can't be edited is to make it read only under the admin tab. When I click on Add button in read-only topics I get "A System Error has occured. The error message is _blank_ Is there an issue with this? Am I using the correct method (not sure how this relates to "Lock List" on left hand side pane. Thanks Colin

Hi Colin. The "read-only" interface is really bad right now, but it's on my to-do list to fix it. To make a page read-only, on the admin page enter the topic name in the box next to the "Add" button under the "Read Only Topics" section and then click "Add". The page will appear in a list there and no users will be able to edit it. I'll make sure the next version of JAMWiki gives a better error message when clicking "Add" with no topic name submitted.
The "LockList" topic in the nav bar was a remnant of the code on which JAMWiki was based and was removed in the latest version. Its purpose was to ensure that two users could never edit a page at the same time, but it had several issues. The new code simply checks for edit conflicts when a page is saved, and requires a manual conflict resolution if a conflict should occur (this is the same as MediaWiki). -- Ryan 19-Jul-2006 10:51 PDT
>>Thanks for speedy response - no sweat that will work. Cheers Colin
The new "Manage" tab at the top of each topic that was added in JAMWiki 0.3.0 should hopefully address this issue. Assuming that it's sufficient I'd like to archive this discussion, but let me know if you have any additional comments. -- Ryan 23-Aug-2006 14:08 PDT
Does the newest version of JAMWiki prevent multiple users from editing the same page at the same time? When one user is editing it, the edit feature is blocked for all other users including admin. -- Van
For a very long time now JAMWiki has provided the same conflict resolution as Mediawiki, so if two people edit a topic simultaneously the second editor gets a message that someone else has already changed the topic, with their version and the current version displayed simultaneously. It is then up to that editor to resolve the conflict. Hopefully that answers your question. -- Ryan 29-Jun-2008 12:38 PDT
That does answer my question, Thank you -- Van

Admin Only Topics

Archived from the Feedback page:

Ran the new upgrade to 0.0.8 and have notice that when logging in as non admin user I can still edit the AdminOnlyTopics page.

I see on your wiki that this is not broken and comes up with appropriate error message. Is there something I broke? Can I make other pages AdminOnly pages?

Thanks for all your great work and look forward to trying this out for my dev team in the near future.
~ CB 20-Jul-2006 18:53 PDT

Hi Colin - one of the bugs resolved for the 0.0.7 version was "BUG: Admin-only topics not marked admin-only during setup." I'm not sure when this bug was introduced, but it was present in several releases. If you installed with one of those releases then anyone will be able to edit admin-only topics on your installation. To resolve the issue (assuming you are using a database) you can execute the following SQL:
update jam_topic set topic_admin_only = 1 where topic_name in ('BottomArea', 'LeftMenu', 'AdminOnlyTopics', 'TopArea', 'StyleSheet');
Apologies for the problems - it's still early in development, so there are more bugs than I'd like. Thanks for the feedback! -- Ryan 20-Jul-2006 19:51 PDT
>>No sweat, great effort in my opinion! Will try that. I like the section edits but when I click this sections edit I was taken to section below it. Cheers CB 21-Jul-2006 11:15 PDT
>>Yup, that did it!
That's weird, the section edit link takes me to the right section. Just to verify, you clicked the "edit" link next to the "Admin Only Topics" heading, right? The logs show that the edit was for "section=8" which is the following section, so either the wrong link was clicked or else for some reason the code counted sections wrong for you. For reference, the section edit links were implemented in the same way that Mediawiki handles them, with the link next to the heading rather than at the bottom of the section. -- Ryan 21-Jul-2006 11:19 PDT
>>Could be my mistake, maybe I clicked on edit on what appeared to be bottom of section.
As an aside, my last edit showed an issue where not adding a newline at the end of a section can splice two sections together. I'll get that fixed. -- Ryan 21-Jul-2006 11:20 PDT
The new "Manage" tab should hopefully address this issue as well - let me know if there is anything else to be added, otherwise I'll go ahead and archive this discussion. -- Ryan 23-Aug-2006 14:10 PDT


Do you think the All Categories page should list each and every category, or only the root categories? If you think it should be all categories, perhaps we should have another special page called Special:RootCategories (or something along those lines) for listing only the root categories. That way a user could navigate the category tree in a more defined manner. When looking at a lot of categories and not knowing which ones are children to which other ones, it can be confusing and overwhelming. -- scroco 24-Aug-2006 12:07 PDT

I thought about trying to be a bit more organized with the all category page layout, but based on the way Mediawiki does their categories it ends up being a really complex task - as an example, consider category1, which contains category2. There is nothing in Mediawiki that stops someone from then saying that category2 contains category1, and as a result there is no longer any sense of "top-level" categories. It gets worse as you add more categories and think of more disaster scenarios. If you can come up with a better way to display the categories page I'd be very interested, but I gave up after about ten minutes of thought and just went with the Mediawiki format. -- Ryan 24-Aug-2006 12:44 PDT

I imagine a root categories page could easily be accomplished by creating Category:Root and manually adding all the root categories. Users would just need to be vigilant in placing the proper categories on that page. -- scroco 25-Aug-2006 11:42 PDT

jamwiki-0.3.0 upgrade

Archived from the Feedback page:

Have downloaded latest code and restarted tomcat to load war file. Have copied across said files from prev version as well as mysql driver jar and restarted app. Whenever I access the site I get the window regarding update. Clicking submit comes up with error regarding failure to remove jam_image file (which was removed with prev submit). I then recreated the table, clicked submit and error message came back as null. Going back to my wiki however still brings up upgrade prompt - any ideas?

Results shown:

Dropped jam_image table
Added jam_category table
Unable to update for version 0.3.0: null

CB 26-Aug-2006 06:38 PDT

Hi Colin - apologies for the problems, this is the first I've heard of any issues - I think I see a potential problem when no user is logged in, which I'll fix for the next release. In any case, as long as the jam_category really does exist then you can manually complete the upgrade by changing the "wiki-version" property in your /WEB-INF/class/ file to "0.3.1". You will also want to manually update the StyleSheet topic with the contents of the /WEB-INF/classes/pages/StyleSheet.txt file. Sorry for the trouble! -- Ryan 26-Aug-2006 10:09 PDT


Archived from the Feedback page:

Hi Ryan could you please explain the parsing steps in JAMWikiParser a bit? For example with a library like ehcache? -- Axel Kramer

Hi Axel - at this point I've done almost no performance optimization, except in a few obvious cases. Something like ehcache looks like it could be a great way to speed things up, and I'll add it to the Roadmap - thanks for the pointer!
Regarding the parser, the steps are the following:
This is the first stage of the parser, and parses most syntax, converting Wiki syntax to HTML, validating HTML, etc.
This is the second stage of the parser, and its purpose is to add paragraph tags and other layout elements.
This method is only called during edits and parses signatures and other elements that shouldn't be saved as markup.
This method is only called prior to edits of sections of an article, and it simply figures out what portions of the topic to return for editing when editing a section.
This method is only called after an edit to a section of a topic is complete, and it simply splices the edited content back into the full topic content.
This method may disappear in the future if I can get rid of it, but its purpose is to call JAMWikiParser.parsePreProcess for fragments of markup such as wiki link captions that for various reasons aren't parsed by parsePreProcess.
Let me know if that helps - I'll try to add some Javadoc to the source code to explain the functions of these methods prior to releasing JAMWiki 0.3.0. -- Ryan 22-Aug-2006 14:13 PDT
Thanks for your description. For a quicker understanding of the parser process I created some JUnits tests. Here are my first results: [1] (in testPreformatedText1 the opening <pre> block was never closed and in the <pre> and <nowiki> tests the & (ampersand) and the '(apostrophe) sign wasn't escaped as I would have expected.) -- Axel Kramer
Thanks for this feedback. I'll take a look at why the pre tag didn't get closed and get a fix out, and also look into the escaping issues within "pre" tags. Automated parser tests have been on the to-do list for a while now, so it's great that you've put together a few tests. -- Ryan 24-Aug-2006 13:28 PDT