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.

Bug Reports/Resolved/1.0.x

This page is an archive of Bug Reports resolved during the JAMWiki 1.0.x release cycle. See Bug Reports/Resolved for an index of all resolved bug reports.



Recent parser changes on trunk appear to have broken Template:Mediawiki. -- Ryan • (comments) • 12-Sep-2010 20:48 PDT

revision 3215 fixes this issue. -- Ryan • (comments) • 16-Sep-2010 20:24 PDT

Capitalization of article names MATTERS the first letter

JAMWiki 0.8, Tomcat 6.0.20, Sun JVM 1.6.0_14

From Wiki Syntax (adapted):

The first letter of articles is automatically capitalized, 
so [[startingPoints]] goes to the same place as [[StartingPoints]]. 
Capitalization matters after the first letter.

This's not true, even in this wiki:

The first letter of articles is automatically capitalized, so startingPoints goes to the same place as StartingPoints. Capitalization matters after the first letter.

Thanks, this was probably overlooked in the initial implementation and no one has called it out. I'll look into getting it fixed as soon as possible. -- Ryan • (comments) • 19-Nov-2009 07:25 PST
Thanks. Interestingly, for links to templates or images it works:
 The link {{todo|something}} or {{Todo|something}} points right to [[Template:Todo]] 
The link TODO something or TODO something point rights to Template:Todo
Looking forward to new version :) 2009-11-30, 17:58 CET
I would like to slightly increase the priority of this bug. It's little bit annoying for me... Thank you.
-- mschayna 02-Mar-2010 02:06 PST
Keep reminding me about this one - it's somewhat difficult to solve, so I haven't attempted it for a minor release (ie 0.8.x) but don't want to overlook it for 0.9.0. -- Ryan • (comments) • 31-Mar-2010 19:12 PDT
I would remind you with this problem, but for 0.9.0 is too late, I think. Thank you.
--mschayna 15-Jun-2010 00:31 PDT
Thanks for the follow-up - at this stage it won't get fixed for 0.9.0, but some of the changes that went into 0.9.0 will make this easier to implement, and it may be possible to implement by making a simple properties change. Please keep reminding me about this issue (bugs that have people interested in them usually get more attention) and I'll see if I can get a fix in early in the 1.0.0 cycle. -- Ryan • (comments) • 15-Jun-2010 07:24 PDT
I think it's safe to expect that this issue will be resolved for JAMWiki 1.0.0. -- Ryan • (comments) • 14-Sep-2010 20:32 PDT
This capability has been implemented in revision 3218 for inclusion in JAMWiki 1.0.0. -- Ryan • (comments) • 18-Sep-2010 12:27 PDT

Employ consistent naming of special pages

Most of the special pages have a camel case naming like RecentChanges or VirtualWiki. But some don't, like Specialpages, Watchlist or Allpages. They should consistently be named in camel case: SpecialPages, WatchList or AllPages. There are more examples. Old names can/should remain for support reasons. -- Michael Osipov 02-Nov-2010 03:39 PDT

The names were originally designed to be the same as Mediawiki; if they've changed things then an update is definitely called for, but otherwise it may make sense to stay consistent with them. -- Ryan • (comments) • 02-Nov-2010 07:17 PDT
Ryan, indeed they did. Check out this page. You'll find all special pages in mediawiki. -- Michael Osipov 03-Nov-2010 13:47 PDT
Any change on this Ryan? -- Michael Osipov 09-Nov-2010 03:34 PST
Thanks for the reminder - I've just added it to Tech:JAMWiki 1.0.0 so that it doesn't get forgotten. I was hoping that some additions to jamwiki-servlet.xml would be sufficient, but it looks like it might also be necessary to set up automatic redirection for the non-camelcase pattern, and that requires further investigation. If you've got suggestions I'd be grateful, otherwise I'll need to dig a bit. -- Ryan • (comments) • 09-Nov-2010 21:13 PST
revision 3260 should take care of this. The Special: topics will now use proper camel case, and redirects are in place for the non-camel case names. -- Ryan • (comments) • 10-Nov-2010 20:39 PST
This code is now live on - Special:Recentchanges will automatically redirect to Special:RecentChanges. -- Ryan • (comments) • 10-Nov-2010 21:12 PST

move 403.jsp to WEB-INF/jsp/

I have noticed that the JSP is directly accessible. A view should actually never be directly accessible but through a controller. I called that page manually in Firefox and Tomcat displayed HTTP 500 with an exception:

org.apache.jasper.JasperException: Unable to compile class for JSP: 
An error occurred at line: 33 in the jsp file: /403.jsp
JAMWikiAuthenticationConstants.JAMWIKI_ACCESS_DENIED_REDIRECT_URI cannot be resolved
30: <c:set var="defaultTopic"><%=  ServletUtil.retrieveVirtualWiki(Environment.getValue(Environment.PROP_VIRTUAL_WIKI_DEFAULT)).getDefaultTopicName()  %></c:set>
31: <c:set var="defaultVirtualWiki"><%= Environment.getValue(Environment.PROP_VIRTUAL_WIKI_DEFAULT) %></c:set>
32: <%
33: String accessDeniedUri = (String)session.getAttribute(JAMWikiAuthenticationConstants.JAMWIKI_ACCESS_DENIED_REDIRECT_URI);
34: if (accessDeniedUri != null) {
35: 	session.removeAttribute(JAMWikiAuthenticationConstants.JAMWIKI_ACCESS_DENIED_REDIRECT_URI);
36: %>
An error occurred at line: 35 in the jsp file: /403.jsp
JAMWikiAuthenticationConstants.JAMWIKI_ACCESS_DENIED_REDIRECT_URI cannot be resolved
32: <%
33: String accessDeniedUri =  (String)session.getAttribute(JAMWikiAuthenticationConstants.JAMWIKI_ACCESS_DENIED_REDIRECT_URI);
34: if (accessDeniedUri != null) {
35: 	session.removeAttribute(JAMWikiAuthenticationConstants.JAMWIKI_ACCESS_DENIED_REDIRECT_URI);
36: %>
37: 	<c:redirect url="<%= accessDeniedUri %>" />
38: <%

Move it to WEB-INF to avoid such things. I malicious attacker could call the page in a while loop with wget and spam the logs. -- Michael Osipov 09-Nov-2010 03:21 PST

Simple enough. This just needs some testing, so if you can confirm that error page functionality still works as expected after moving the file and updating web.xml then I'll make the change, otherwise I'll look at this next chance I get. -- Ryan • (comments) • 09-Nov-2010 21:17 PST
I will add this to my To Do list -- Michael Osipov 16-Nov-2010 10:27 PST
revision 3363 makes this change. I did a bit of testing and as far as I can tell everything still works as expected, but I'm sure that if there are any surprise problems that they will be found prior to the final release of JAMWiki 1.0.0. -- Ryan • (comments) • 29-Dec-2010 12:42 PST

javadiff breaks build process under certain circumstances

I checked out the 1.0-SNAPSHOT and tried to build JAMWiki and it failed due to a missing dependency. Maven was complaining that the parent pom (0.9.2) of javadiff is missing. I was able to tackle down the problem which is rather subtile. You build javadiff along with jamwiki, having the current pom as its parent. This is a very bad way to go since this is a independent package. What happens is that you compile a jamwiki version, run a mvn install and build again. It works fine. Now, someday you remove the jamwiki builds from your local repo. A couple of months later you check a new version of JAMWiki and try to build it again and wonder why maven complains about a missing dep. javadiff is still in your local repo and having the same old parent pom. Now you broke a maven convention, you have to make either the parent version and child version the same or make the parent version publically available. Fixing this inline would be a wrong way to go. If you have not modified the source, remove it completely from the JAMWiki build process and issue a Maven Central upload request with a bundle and declare a dependency to it. If you did modify the source you either have to shade (take) the classes under your namespace (org.jamwiki) or you put a qualifier into the version which makes it unique with your current jamwiki version. I'd be happy to give assistence in this case since I am a maven pro. -- Michael Osipov 09-Nov-2010 05:12 PST

Any advice here would be much appreciated. I did a search through trunk for references to "0.9.2" and only found results in the CHANGELOG and UPGRADE files, so I'm not 100% sure I understand the problem. Looking at trunk/javadiff/pom.xml and I'm seeing the following:
If I understand you correctly, since the javadiff version doesn't change each release but the JAMWiki version does then there is a problem with cached dependencies? If so, any suggestions on how to handle this better would be appreciated as my Maven skills are definitely not at the "pro" level. Ideally, getting javadiff into a central repository would be a great way to go, but as I'm not maintainer of that project I'm not sure how appropriate it would be to push for something like that (I don't know the protocols). -- Ryan • (comments) • 09-Nov-2010 20:58 PST
As a side note, if you know Maven well then any suggestions you have for improving JAMWiki's build files would be much appreciated, and I'd be happy to grant you Subversion access if you have a Sourceforge ID. I haven't yet looked at Maven 3.0, but I would assume upgrading would make sense before too long, so if there are any changes that require the new version then I'd be interested in knowing more. -- Ryan • (comments) • 09-Nov-2010 21:20 PST
Ryan, sorry for answering with a delay, I was kept busy at work and at home. Yes, I'd like to do that. There are some spots in the POMs which do not make sense or could be done way better. I will create appropriate articles to document and discuss changes. What is the best way to ask you why you did things the way you did in the POM? My SourceForge ID is michael-o -- Michael Osipov 16-Nov-2010 10:31 PST
Thanks for the offer to help out! I've added your ID to the project - let me know if you have any issues with Subversion, and please have a look at How to Help#How to contribute which has links to the coding style doc and other useful tidbits. The original discussions about Maven are at Tech:Maven. As to collaboration, as much as I'd prefer to keep discussions on I think the past few years have proven that there is a need for a jamwiki-dev mailing list, so if that sounds OK to you I can get it set up tonight. -- Ryan • (comments) • 16-Nov-2010 11:28 PST
Ryan, please do so. A dev mailinglist would ease the issue tremendously. It's always a pita doing hard work and then see it being reverted by someone. I will discuss stuff in the first place. -- Michael Osipov 17-Nov-2010 00:22 PST
There is a new mailing list through Sourceforge. I'll probably need to tweak the settings, so please let me know if you encounter any issues. -- Ryan • (comments) • 17-Nov-2010 19:48 PST

jamwiki-configuration.dtd is missing namespaces element definition

Eclipse complains: The element 'namespaces' has not been declared. jamwiki-configuration.dtd /jamwiki-war/src/main/resources line 2 DTD Problem —The preceding comment was added by mosipov (commentscontribs) .

Thanks - revision 3362 fixes that. It looks like I removed the element declaration but forgot to update the parent element attribute. -- Ryan • (comments) • 29-Dec-2010 10:35 PST

/WEB-INF/security.tld is never used

File should be deleted. —The preceding comment was added by mosipov (commentscontribs) .

The TLD is used by the Spring Security taglibs, but it is included in the spring-security-taglibs.jar file and (since JAMWiki has upgraded to JSP 2.0) is unneeded. I've removed it in revision 3361 - thanks for pointing that out. -- Ryan • (comments) • 29-Dec-2010 10:32 PST

Move jamwiki.tld to an appropriate place

The jamwiki.tld is not logically part of the war module. The source reside in web and therefore the jamwiki.tld should reside in jamwiki-web/META-INF. Since JSP 2.0 all TLD files are automatically discovered in all JAR files. —The preceding comment was added by mosipov (commentscontribs) .

This is done in revision 3360, thanks for pointing it out. -- Ryan • (comments) • 29-Dec-2010 10:15 PST

building from source

I just downloaded the latest 1.0.0 source and did a build. The build itself completed without error, but I see two problems now when i try to run against the new version.
First, the logging appears to have an issue. I see an error message as tomcat is starting up.

SLF4J: The requested version 1.5.11 by your slf4j binding is not compatible with [1.5.5, 1.5.6, 1.5.7, 1.5.8]
SLF4J: See for further details.

Next, when i set up a new instance of the wiki i get the following error

An unknown system error has occurred. The error message is: java.sql.SQLException:
[SQLCODE: <-30>:<Table or View not found>]
[Location: <Prepare>] [%msg: < Table 'SQLUSER.JAM_CONFIGURATION' not found>].

The lack of logging makes it difficult to tell where the other error happens. I will try to dig into these a bit when i have time, just wanted to make you aware of these if you aren't already.
I am on:

  • Jamwiki 1.0.0 (build 3263 i believe)
  • Tomcat 6.0
  • Caché 2010.2.1

building on :

  • Eclipse 3.5
  • JDK 1.6
  • Maven 2.2
I think I've seen that SLF4J error before, but I can't remember the solution. I'll need to dig a bit, but with the holiday this week time may be limited. The jam_configuration error is due to a table not existing. It looks like the code is there to create that table, so before I try a clean install to verify that it is being properly created, can you confirm that you either did a clean install or upgrade? If you were trying to re-use a 0.9.x database version without upgrading the database then this table wouldn't be there. -- Ryan • (comments) • 22-Nov-2010 08:34 PST
to make it more interesting, the logging was working with 1.0.0 prior to you merging my changes (for the Caché database support) into the trunk. So, somewhere between the version i did my development on and the current version the logging got broken. I do see more versions of slf4j files in my current version than the one that was working, but I have no idea how to track down the real functional differences between the two. For the missing table error, i did a clean install with a fresh database. dkp • (comments)
As I recall, when I originally got the SLF4J error it was because ehcache was pulling in its own SLF4J dependencies - see That was resolved within JAMWiki, but is it possible you have log4j or commons-logging included in your PATH somewhere? If you are seeing multiple SLF4J instances that may explain the issue.
The jam_configuration issue is still puzzling to me - I don't see anything in the code that should cause that to break, so I'll keep digging. -- Ryan • (comments) • 24-Nov-2010 14:52 PST
Sorry for the delay. I finally got around to doing a clean install and can confirm the SFL4J issue (it seems to be harmless, but I'll investigate further) and I'm also getting an error with setup, although a different one from what you've pointed out. What I'm seeing may be a problem related to the Spring upgrade, so I'll dig a bit further and hopefully get a fix out soon. -- Ryan • (comments) • 29-Nov-2010 19:52 PST
revision 3287 fixes the setup errors I was seeing. It looks like there were bugs in Spring Security 3.0.4 when doing redirects that broke some of Spring's context handling; revision 3287 upgrades JAMWiki's dependencies to Spring Security 3.0.5. I'll continue looking into the SFL4J problem, but please let me know if this solves the setup issues you were seeing. -- Ryan • (comments) • 29-Nov-2010 20:35 PST
SLF4J problems fixed in revision 3320. More improments to come. -- Michael Osipov 13-Dec-2010 11:17 PST

Unknown system error for DIFF pages with one edition

For example, Test page with one edition. The page has one variant. If to press Diff selected (in History):

A system error has occurred. The error message is:
An unknown system error has occurred. The error message is: java.lang.Exception: Versions 0 and 0 not found for Test page with one edition. 
Thanks for the report - that should be fairly easy to fix and I'll try to get it done either tonight or tomorrow. -- Ryan • (comments) • 04-Jan-2011 20:01 PST
revision 3404 resolves this issue. The fix will be included in JAMWiki 1.0.0. -- Ryan • (comments) • 04-Jan-2011 23:09 PST

Auto-capitalization not applied for non-existing articles


1: Go to /wiki/en/testX (X being some number so you hit an article that does not exist for both testX and TestX)

2: Create new article for testX (will be changed to TestX)

3: Go to /wiki/en/testX again. You are now told that the article does not exist. However, if you click to create the article you are brought to /wiki/en/TestX

This appears on this very wiki site as well. -- MaX 05-Nov-2010 12:41 CET

Topic capitalization is coming with JAMWiki 1.0. I'll look into the case you've described since is running the latest code. -- Ryan • (comments) • 05-Nov-2010 08:18 PDT
This appears to be a problem with the cache - the original cache entry isn't being cleared when the topic is created. You can test by repeating the steps above and then clicking on the "Clear cache" button from the Special:Maintenance page. I'll try to get this fixed in the next 24 hours on trunk (JAMWiki 1.0.0). -- Ryan • (comments) • 04-Jan-2011 23:19 PST
revision 3405 should resolve this issue. -- Ryan • (comments) • 05-Jan-2011 09:57 PST

Date and time are not in locale formatted in JSPs

Just noticed that the pattern is hardcoded in the JSP file. There is a FIXME also. I fixed the issue and attached the patch. --Michael Osipov 22-Oct-2010 01:48 PDT

Thanks! I'll take a look at this over the weekend and see about getting it into an upcoming release. -- Ryan • (comments) • 23-Oct-2010 06:58 PDT
Apologies for taking so long to get around to this issue - I've been extremely busy. Using DateFormat.SHORT and DateFormat.LONG will actually change the way dates are presented for en_US users, so it might be better to make the date patterns configurable via an admin interface. Would that work for you? The downside is that admins of non-en_US locales would need to change the patterns, but at least they would have the ability to do so. For JAMWiki 0.9.4 admins can set a global date format preference, and in the future this could be pushed down to the user-account level so that users can choose how dates are presented. I may have some time to work on this functionality tomorrow, with a goal of getting something included for JAMWiki 0.9.4. -- Ryan • (comments) • 06-Nov-2010 16:02 PDT
Is this change that bad? It would be a very consistent step. The US locale is faulty, file a bug at Oracle. I checked all patched JSPs with three locales and all looked fine. Using LONG, SHORT, etc are the best and most common way to go in Java. I would not tamper right now with admin-configurable formats. Consider this: you support 50+ locales, an admin defines a pattern for all virtual wikis which would awkward on all locales but his own. I'd like the date to be formatted in the alpha-numerical way my locale defines. Take these three locales: en, de, es. You, as American, would define MMM d, YYYY. Which is a horrible format (imho). It would render as: November 7, 2010; November 7, 2010; noviembe 7, 2010. But it should be for the last two: 7. November 2010, 7 de noviembe de 2010. The other solution would be: ditch all alpha-num formatting and use ISO8601 only. -- Michael Osipov 07-Nov-2010 05:54 PST
I actually agree with you about the horrible default en_US formats, which is my concern - the existing formatting of "7 November 2010" will change to "November 7, 2010" for en_US. I'd like to make sure that if a change is made that there is an ability to keep the existing formatting, but use a locale-specific format if desired. Let me give this a bit more thought - one option might be to default to the short & long formats, but also allow admins (eventually users) to supply a pattern that would override the default. Let me know if you have additional thoughts. -- Ryan • (comments) • 07-Nov-2010 17:11 PST
Your idea is reasonable but should take the time and effort implementing this into your consideration. You have to provide in the administation panel a format field which:
  • allows the type of formatting: pattern or style
  • in the case of style shows for date or time separately: short, medium, long, full
  • in the case of pattern again two fields, date and time
  • in the case when both are displayed in one expression the two above.
And yet, you are not done. Every single date/time aware JSP has to have c:if for the fmts to choose between pattern and style since this cannot mit done with one fmt tag. Additionally, this would be configurable for the admin on a per-wiki basis (towards release 1.0). Later, the user could control this too.
A few thoughts why this flexibility is necessary if you plan to do so:
  1. A single language wiki: folks would always see same date/time style because content and locale are the same OR a pre-defined pattern which would serve well.
  2. A multi-language wiki: folks then should see date/time in a style way because locales are constantly changing.
  3. An international (single lang en but int'l audience) wiki: folks shall only see a numerical pattern to be language-agnostic. This would require to input the ISO8601 date/time pattern.
A complex task after all. -- Michael Osipov 09-Nov-2010 03:42 PST
Agreed. It wouldn't be too terrible to implement - I'd suspect it would be about 1-2 hours to do a global implementation and 2-4 hours for a virtual-wiki-specific implementation - but you're right that additional logic (probably convenience methods) would be needed to sort out what patterns to use and then make the patterns easily accessible to the front end (this would avoid the need for c:if tests). My free time has unfortunately been very limited lately, and this is growing in complexity beyond something that would generally be included in a minor release, but whipping together a patch for the 1.0.x series should be relatively straightforward if I can find a free morning. Note that this is NOT the user-specific implementation - that would require database changes to store the additional patterns, and I'd like to give more thought to handling user preferences before adding schema modifications. -- Ryan • (comments) • 09-Nov-2010 21:07 PST
I've started looking into this. Some notes:
  • There are four different date patterns currently being used in JAMWiki JSPs:
dd-MMM-yyyy HH:mm (1)
dd MMMM yyyy HH:mm (2)
dd-MMM-yyyy HH:mm (1)
dd MMMM yyyy (3)
HH:mm (4)
dd MMMM yyyy HH:mm (2)
dd MMMM yyyy (3)
HH:mm (4)
dd MMMM yyyy HH:mm (2)
dd-MMM-yyyy HH:mm (1)
dd MMMM yyyy (3)
HH:mm (4)
  • Mediawiki appears to have consolidated to just three patterns, those denoted as 2, 3, and 4 above, so JAMWiki should do the same.
  • Virtual wiki-specific date patterns, and user-specific date patterns, look to be out-of-scope for JAMWiki 1.0.0 since they would require schema changes.
I'll look into consolidating to three patterns, and then adding an admin interface to allow specifying those three patterns. Provided the SimpleDateFormat patterns suffice (SHORT, LONG, etc) then new installs can default to those locale-specific variants, although it may make sense to maintain the old patterns for users who are upgrading. -- Ryan • (comments) • 24-Dec-2010 07:43 PST
This functionality should now be in place via revision 3345, revision 3346 and revision 3357. Note that the ability to configure date-patterns is currently wiki-specific, but a possible change for JAMWiki 1.1.0 will be to make this configurable per-user, so that a user logging in from America and a user logging in from Germany can see dates formatted with the appropriate locale-specific pattern. Any feedback is welcome. -- Ryan • (comments) • 26-Dec-2010 17:43 PST