JSPWiki bug reporting system has changed.

Please, use JIRA to submit bug reports from now on. IF YOU REPORT A BUG HERE, IT WILL BE IGNORED UNTIL THE END OF TIME.

And I would really, really appreciate it that if you happen to walk by on this page, you would copy a single bug report from this page to the new bug handling system. And also, remove the bug from this page as well so that we know which already exist.

-- JanneJalkanen

back slashes in http string in a file causes file not to load

Date 2004-01-27
JSPWiki version JSPWiki v2.1.86-alpha
Java version 1.4.1
Operating system NT
Web server and servlet container Tomcat 5.0.18
Page provider FileSystemProvider
Browser Mozilla

2003/9/25 - page in weird state on attachment abort#

Date 2003/9/25
JSPWiki version JSPWiki v2.0.52-cvs
Java version 1.4.1
Operating system w2k
Web server and servlet container resin
Page provider FileSystem
Browser IE 5.0

From a user: I had various tid bids stowed away over there - but it somehow vanished. I was in the middle of attaching a file - I tried aborting that - went back to check my page - ony to find all the contents in the page werel blown away. I was left with a blank page :-(

The funny thing is that when I go to edit the tl1FirstPage it still shows my original text, but when I display my tl1page it has none of my text.

Analysis: The page was indeed in the file system but did not display in view mode, but did in edit mode, even after restarting the system. I renamed the file to a different name and it worked fine.

2003/08/24 - Escaping Brackets #

Date 2003/08/24
JSPWiki version 2.0.56
Java version 1.4.1
Operating system Win98
Web server and servlet container Tomcat 4.1
Page provider FileSystem
Browser IE 5.0

I'm trying to insert a javascript inside the LeftMenu.

<select onchange="document.location=options[selectedIndex].value;">

To have my selectedIndex with brackets around I tried:


But it's always translated as:


Seems a bug to me although it's said to be a FixedBug since 1.9.23 --FrancoisParlant

2003/07/22 - Still no ability to go forward with the patched Calendar Tag.#

Date 2003/07/22
JSPWiki version 2.1.53
Java version 1.4.1
Operating system Win2k
Web server and servlet container Tomcat 4.1
Page provider FileSystem
Browser IE 6.0

I compiled the latest CVS release which is supposed to have the patched Calendar tag. I'm still unable to see future months. There is no useage documentation, so I assume it is automatically there...therefore making this a bug. :-p

Please reach me at: AArbit@go-integral.com
Thank you.

Well, it is a design error, not a bug as such. But I will add the ability to go forward in the next release. --JanneJalkanen

2003/07/07 - RecentChangesPlugin does not get resolved.#

Date 2003/07/07

JSPWiki version 2.0.45 / 2.0.39
Java version 1.4.1
Operating system Win2000
Web server and servlet container Tomcat 4.1.18
Page provider FileSystem
Browser(s) Mozilla 1.4 / IE 6.0

I have installed JSPWiki (unzip war file into webapps sub dir), made minor mods to jspwiki to point to page directory. When I display LeftMenuFooter, the plugin is not found. he prevents me from being able to save pages. I get "An unknown exception java.lang.NullPointerException was caught by Error.jsp". See attached file: wikiError07072003.zip. It contains the log file chunk for the 2.0.39 version and the properties file.

I can be reached at: jpettens@rochester.rr.com - J.Pettenski

An update. It looks like this error causes the other above.

2003-07-07 12:46:25,936 Thread-10 INFO com.ecyrd.jspwiki.WikiEngine - Starting cross reference scan of WikiPages 2003-07-07 12:46:26,061 Thread-10 FATAL com.ecyrd.jspwiki.WikiEngine - PageProvider is unable to list pages: com.ecyrd.jspwiki.providers.ProviderException: Specified attachment directory C:\Data\jspwiki\testWiki\attachments does not exist!

Yes. You need to create the "C:\Data\jspwiki\testWiki\attachments" directory first.

-- JanneJalkanen

2003/05/15 - No author shown - only ip adress#

Date 2003/05/12
JSPWiki version 2.0.39
Java version 1.4.1_2
Operating system W2K
Web server and servlet container Tomcat
Page provider RCSFileProvider
Browser(s) n/a

Hi, I thought that if I set the userpreferences cookie to my client that I could find the author who changed a page. But it is not so! Does somebody know why? I read that I must use versioning but this works only if I have attached a file to the site. --RimElrey

Setting your name in the UserPreferences page doesn't change the information available in other pages. However, after you set your name, then any page you edit (or any attachment you upload) will have your name (as stored in the cookie) as the author, which is a Good Thing. I think it is such a Good Thing, that I made the template I contributed (see the ContributedTemplate page) require you to set a name in UserPreferences before you can change pages. (Of course, you can still enter rubbish for the name, but a Wiki is largely about the honor system.) --MichaelGentry
Yes, I hoped that it is so! But with my installation it is not! I set a username first and changed then a page, but the user is "unknown". Only if upload an attachment that I could see a username. Why? --RimElrey
I use the same configuration as you (Tomcat version 4.1.12/.18), except I DO NOT use the RCSFileProvider. I use the VersioningFileProvider and it works fine for me. Unless you have a specific reason for using the RCSFileProvider, I suggest switching to the VersioningFileProvider. --MichaelGentry
Yes, that's it!
This is such an FAQ, that since version 2.1.21 FileSystemProvider also saves author information. Move to JSPWikiFAQ.

2003/05/12 - Can't link to javascript#

Date 2003/05/12
JSPWiki version 2.0.39
Java version n/a
Operating system n/a
Web server and servlet container n/a
Page provider n/a
Browser(s) n/a

linking to a No InterWiki reference defined in properties for Wiki called "javascript"! doesn't work.

- YishayMor

NotABug. We don't allow javascript on this site for security reasons. --JanneJalkanen

2003/05/08 - Error translating embedded HTML#

Date 5/08/2003
JSPWiki version 2.0.39
Java version 1.4.1_01
Operating system Win2000
Web server and servlet container Tomcat 4.1.18
Page provider FileSystemProvider
Browser(s) IE 6.0

If jspwiki.translatorReader.allowHTML = true, if the following code is embedded in a page:

    <a name="Wikiname">Wikiname</a>

    <a name="WikiName">WikiName</a>

    <a name="Nonwikiname">
    Nonwikiname, split line</a>

    <a name="WikiName">
    WikiName, split line</a>
It will be rendered as . . .
Nonwikiname, split line
WikiName"> WikiName, split line

-- PaulDownes

This isn't at all surprising - if you have CamelCase detection enabled at the same time, one of these is going to break =). It gets very complicated if you try to determine where in HTML you can or you cannot do CamelCase translation. NotABug, but should probably be mentioned in JSPWikiFAQ.


2003/05/08 - A convenience bug : Upload servlet should a JSP#

Date 5/08/2003

JSPWiki version All
Java version 1.4.1
Operating system All
Web server and servlet container Tomcat
Page provider FileSystemProvider
Browser(s) All

This is more of an annoyance than a bug. The current implementation of upload uses a servlet. My ISP runs a kind of shared Tomcat where I cannot (not allowed to) register servlet aliases. I hacked the code base to use the fully qualified name for the upload servlet instead of the alias. Would not it make sense to use a JSP instaed of a servlet to be true to JSPWiki being a JSP implementation? That would make the overall homogeneity of the code better(no more servlets), and solve my problem


01/10/2004 - I am running into the same problem with my hosting company. I cannot register "/attach" but I can register "/servlet/attach". So it looks like I need to hack the sources and rebuild to make attachments work. If the upload was a JSP it would not be a problem. Thanks! Bryce Denney

2003/03/28 - Attachment System does not like any non-JSPWiki files in dir tree #

Date 3/28/2003
JSPWiki version 2.0.36
Java version Sun 1.4.1

Operating system Win98
Web server and servlet container Tomcat 4.1.18
Page provider BasicAttachmentProvider
Browser(s) Not Related

(Sorry if this should not go here, since its not really a bug - PLS move it elsewhere if you think) When there are any subdirectories within the attachment tree (dirs that were NOT created by JSPWiki), it leads to many NullPointerExceptions. This is a pity, because it prevents to store the wiki content in some CVS repository (this will leave CVS subdirectories all over the place).

Ignoring any CVS directories could be one (simple) solution... -- Bob
Ok, I did help myself and added a pluggable alternative AttachmentProvider -Bob

  • Date: 03/09/03
  • JSPWiki version: 2.0.32
  • Hosted by an ISP on Linux/Apache/Tomcat 4.0.6
  • The used page provider: VersioningFileProvider
  • Used browsers: Opera7, IE6.0

Everything is working fine exept the attachements. I set the path to the real path (/home/taxony.net/htdocs/wiki/content/) as I did for the pageDir. When I try to uploade an image I get a message An 'unknown error was caught by Error.jsp' but no further log entry.

I also installed the JPSWiki CVS version since the uploads work here (I tested), but the same result. With a PHP-based forum software is it possible to upload attachements thus I doesn't seem to be a restriction of my ISP.

But what else?

JanneJalkanen: Do you have the jspwiki.attachmentProvider set? If yes, then please do set the log4j.rootCategory to DEBUG, FileLog and see if there are any exceptions in the log defined in log4j.appender.FileLog.File.

MarcAndreDumont: The log says: UploadServlet initialized. Using /usr/local/jakarta/temp for temporary storage. Upload failure: Directory /usr/local/jakarta/temp(info) is readonly.

As I run JSPWiki on a server of my ISP, I do not have access to that directory, so is it possible to do uploads without temporary storage?

2003-Mar-09 MarcAndreDumont: I could fix it by replacing "System.getProperty( "java.io.tmpdir" )" in line 74 of AttachementServlet.java with a fix path. I would suggest to add such parameter (e.g. jspwiki.fileSystemProvider.tempDir) in the jspwiki.properties.

No, this is not a good idea - it is not a good idea to mess with java system properties (can you say concurrency issues?). You can always start Java with the command "-Djava.io.tmpdir=/my/tmp/dir".

Besides, the temporary directory should ALWAYS be writeable. Your provider is obviously doing something very wrong if this is not the case.

-- JanneJalkanen I disagree with this last statement : I have the exact same problem with my ISP. I suggest that JSPWiki not rely on the server provided temp directory, but instead uses its own logic, including a property parameter to point to it, or a subdirectory of the pages storage directory. The implementation of temp config can be so different from one install to the other, that I think it is bad form to assume anything about the target environment. I have made the hack (ie new property to use an arbitrary temp directory for uploads, and now it works, when it did not before).--PhilippeO

matchEnglishPlurals & ReferringPagesPlugin#

  • configuration probably does not matter beyond: matchEnglishPlurals==true

Create a page named ExamplePlural then edit this page to refer to it as ExamplePlurals, then goto ExamplePlural and notice that it says it's not referenced by anyone. My assumption is that the ReferringPagesPlugin need to hook up with the logic of matchEnglishPlurals as appropriate. --JohnVolkar

Known bug. There are even tests for this in the current distribution. Will be fixed.

2003-Mar-09: "FindPage" title hardcoded#

  • JSPWiki v2.0.32-beta

I currently translate the JSPWiki to german (yes, of course I'll publish that here when I'm through). If I'm right, the title of the page that displays the search results is hardcoded in the Search.jsp instead in the "presentation layer" (in a template or as a wiki page).

-- MarcAndreDumont

Oops. You're right. Same with UserPreferences...

-- JanneJalkanen

Fixed in 2.1.56. Move to FixedBugs.

2003-Mar-04: Unconfirmed bugginess with XML-RPC and attachments#

I'm running JSPWiki v2.0.22-cvs on http://wiki.cocoondev.org/ for which I created a Python script that mails wiki diffs to a Cocoon mailing list (http://marc.theaimsgroup.com/?l=xml-cocoon-docs&r=1&b=200303&w=2). I had two error situations coming up on irregular occasions, and have now come to the suspection that XMLRPC and binary attachments aren't coming along very well. My script itself was breaking on trying to diff attachments (quite obvious), so I fixed that to make it scan for '%2F' in the page name and skip such a 'page'. It would be a Good Thing if I can differentiate between normal pages and attachments using some more formal than '%2F' appearing in the page name, so maybe the XMLRPC interface should be expanded adding an extra property.

Yup. The XML-RPC interface should not even be returning attachments in the lists, probably. --JanneJalkanen
Since 2.0.35, we no longer list attachments.

Anyway, working my way around the bugs in my own application, I suddenly started thinking that the other problem might have been caused by the combination of binary attachments and XMLRPC. For some reason or another, JSPWiki had periods of very high CPU load on my server (Linux, Sun JDK 1.4), for unapparent reasons (to me). Now, I start to believe that fetching the content of attachments across XMLRPC triggers some error condition in the XMLRPC stuff, and I'm wondering whether my assumption might be correct. I'll check whether not accessing attachments across XMLRPC does resolve the CPU load situation, and if that is the case, my assumption might be correct. Does anyone else has similar experiences with XMLRPC & attachments? -- Steven Noels

2003-Feb-28: error with Tomcat 4.0 and error loading first page after install#

  • Java Version: Sun JDK 1.3.1_04
  • JSPWiki v2.0.32-beta
  • Windows 2000 Professional
  • jakarta-tomcat-4.1.18
  • The used page provider: FileSystemProvider
  • Used browsers: IE 6.026

Ok, I've now set up the 32beta on two machines. I failed on the first machine which was running Tomcat 4.0 for Win, and all attempts to get past a completely blank page failed. There were errors in the log, but when I changed the settings so that they would avoid an error, it would just create another.

So, I moved to the second machine running Tomcat 4.1.18 and it worked. However, on the first load of the Main page (I call mine HomePage), I got the following message.

(class: org/apache/jsp/ViewTemplate_jsp, method: _jspx_meth_wiki_Breadcrumbs_0 signature: 

(Ljavax/servlet/jsp/PageContext;)Z) Incompatible object argument for function call 
After hitting refresh in the browser, this message when away and all appears to be fine.

I went back to the first machine, with a copy of the wiki from the second machine and it still would not run. I upgraded Tomcat to 4.1.18 and viola, it ran. However, the first time I opened the HomePage got the breadcrumb error shown above.

In anycase, most is now as it should be, thanks. Scott

Here's the error as seen in the browser:#

Um. Strange. I really don't have much idea about what is happening here. --JanneJalkanen

2003-Feb-24: error saving a page #

  • Java Version: Sun JRE 1.4.1_01-b01
  • JSPWiki v2.0.32-cvs
  • Windows 2000 Professional
  • jakarta-tomcat-4.1.18
  • The used page provider: DatabaseProvider
  • Used browsers: IE 6.026

Additional information:
Using plugin for Tomcat and Eclipse from
Sysdeo Eclipse Tomcat Launcher Plugin
(c) Sysdeo SA - 2002 - http://www.sysdeo.com/eclipse/tomcatPlugin.html

Submitted by ThierryLach
Note: this also occurs with FileSystemProvider and VersioningFileProvider,

The Sysdeo patch enhances the Tomcat classloader so that JSP pages and java code running in tomcat can be debugged using Eclipse. This causes failures of JSPWiki compiling pages when the default template page is used, since the java code generated by the templates contains

package org.apache.jsp.templates.default;

instead of

package org.apache.jsp;
This causes the jsp page to fail to compile since default is a reserved word.

Though this is not a JSPWiki bug per se, I still suggest that the directory name for the default templates be changed to some non-reserved word (maybe dflt?) since it is possible that a non-Tomcat jsp engine may encounter the same situation.

#  This sets the default template used by the Wiki engine.  The templates
#  live in templates/<template name>.  JSPWiki will attempt to find two
#  basic templates from that directory: "ViewTemplate" and "EditTemplate".
#  By default this is called "dflt".
jspwiki.templateDir = dflt


No, 'default' is not a reserved word in package names (I checked the Java specification). However, it seems that the Java compiler for Windows is broken in this respect - someone else has complained about this as well. Hm. Perhaps we should rename the default template - but I really hate working around compiler bugs in these kind of situations... :-(.


Btw, I'm also using 1.4.1_01-b01 and tomcat-4.1.18 only on WindowsXP, but never had this problem. -- Torsten

I have this problem as well, running under tomcat-4.1.24 on XP with the Sysdeo patch applied.

My read of the Java Language Spec (v2) is that 'default' is a reserved word in package names (6.5 defines Packagename as a sequence of Identifiers, 3.8 defines Identifier as not a Keyword, and 3.9 defines 'default' to be a Keyword.) Did I misinterpret?

See also: http://www.javaworld.com/javaworld/javaqa/2001-12/02-qa-1221-package.html

If this is deemed not a bug, perhaps the workaround (rename the default template) should be mentioned in the Windows install page? This seems to have happened to several people, and for my part, it took a while for me to figure out what was going wrong.


2003-Feb-24: error saving a page #

  • Java Version: JDK 1.3.1_07
  • JSPWiki v1.8.2
  • Windows XP
  • jakarta-tomcat-4.1.18
  • The used page provider: FileSystemProvider
  • Used browsers: IE 6.026

Submitted by AndrewArnold
Don't know whether the problem I've encountered is a bug or results from the fact I'm an inept non-techie trying to do a techie thing. I tried downloading and installing jspwiki. It loads, but I get an error when I try to save a page after edits.

If you could help me work this out, I'd really appreciate it. - Thx, andrew

The HTTP status 500 error that shows in the browser indicates a null pointer exception because the system thinks the Page directory doesn't exist. However, C:
does in fact exist on my file system. Below, I've pasted in the Browser error, log file message, and changes I made to jspwiki.properties.

Changes to the jspwiki.properties file:

jspwiki.fileSystemProvider.pageDir = C:\\Data\\jspwiki 
log4j.appender.FileLog.File = C:\\jakarta-tomcat-4.1.18\\webapps\\MyWiki\\tmp\\jspwiki.log

Relevant section of the log file:

2003-02-24 09:46:16,951 [Thread-9] INFO com.ecyrd.jspwiki.WikiEngine  - JSPWiki 1.8.2 starting. Whee!
2003-02-24 09:46:16,967 [Thread-9] INFO com.ecyrd.jspwiki.FileSystemProvider  - Wikipages are read from : C:\Data\jspwiki 

Hm. Strange. Please make sure that

  1. You can access the directory
  2. The directory name is correct (not "JsPWiki" or something)
  3. You don't have things like an extra space after the directory name in the property file.

-- JanneJalkanen

Just painting Andrew's text with my cursor let's me guess that number 3 is the problem. Andrew, please edit your jspwiki.properties and kill that extra space at the end of the jspwiki.fileSystemProvider.pageDir line. I'm going to check the log message and make sure it has some quotes around it to make noticing this easier...

Done. I hope we're slowly running out of these. This will make life easier in 2.0.32+, but users of older versions will still need to check their spaces.


PageInfo slow with RCSFileProvider#

This site.

For some strange reason RCSFileProvider insists on checking out every single version when doing a version history listing. This causes pages like Ideas to have very slow history pages. This is probably an oversight or a side effect of something being changed somewhere in WikiEngine, as the original version history listing should be quite sufficient for any information.


OK. Found the problem: It's the PageSize tag, which checks out each version from RCS and then displays the result. No wonder it's so bloody slow.

The obvious solution would be to amend RCSFileProvider to put the file size in file metadata, but how exactly could we then do graceful migration for old systems? Or do we even care?

--JanneJalkanen, pondering out loud

Disabled page size for a while on PageInfo pages for pages, which really does speed things up a LOT. Still wondering what we should do.


Websphere Adv 4.0 Install#

Feb 11, 2003 -- den Java 1.2, Servlet 2.2, Windows 2000 Server, IBM Websphere Adv 4.0

I have installed JSPWiki v2.0.27-cvs on IBM Websphere Adv 4.0 Server. Everything seems to be fine except the Page Contents is displayed on the top of each page before the <HTML> tag not withing the body like it is suppose to be. Does anyone know why this is happening? The include-directives are in the right place in the ViewTemplate.jsp file. This happens on both IE and Netscape browsers so the browser it not the problem. I receive no errors in the Web App logs.

Upload fails "An unknown error was caught by Error.jsp" with Tomcat 5.0.19#

Date 2004-03-23
JSPWiki version 2.0.52
Browser any browser
Java version 1.4.1_02-b06
Operating system Win2K
Web server and servlet container Apache Tomcat 5.0.19
JWSDP1.3 (should be Tomcat 5.x))
Page provider FileSystemProvider
Attachment provider BasicAttachmentProvider

JWSDP 1.3 (Sun download, probably any Tomcat 5.x) was replaced with Tomcat 5.0.19. The wiki installation ist unchanged as all user files are in a directory of their own

When JWSDP 1.3 is active everything works fine. With Tomcat 5.0.19 the upload functionality fails like shown above "unknown error". The rest of the wiki however seems to work. At least haven't seen anything changed.

Not shure if this is a jspwiki problem or a Windows Tomcat beta version issue?


ah! found something in log4j.log

2004-03-23 21:28:58,134 [http8080-Processor23] WARN com.ecyrd.jspwiki.attachment.AttachmentServlet  
  - Upload failure: Directory [..\temp] is invalid. (attachment: (unknown))
java.io.IOException: Directory [..\temp] is invalid.

	at http.utils.multipartrequest.MultipartRequest.initParser(MultipartRequest.java:590)
a temp dir is missing. Which one?


I let this Tomcat print out

<%= System.getProperty ("java.io.tmpdir") %>

and it actually hat changed this property to "..\temp". But I don*t know where this relative path points to... after this I created in catalina.policiy the explicit entry

permission java.util.PropertyPermission "java.io.tmpdir", "read";

but it still changes java.io.tmpdir to "..\temp". grr...


Add new attachment

Only authorized users are allowed to upload new attachments.

List of attachments

Kind Attachment Name Size Version Date Modified Author Change note
AttachmentTags.diff 1.7 kB 1 02-Sep-2004 02:17
B32_Scott_Error.jpg 16.3 kB 2 28-Feb-2003 22:05
BasicAttachmentProvider.diff 4.3 kB 1 21-Jan-2003 17:37
BugReport_001_ExcStackTrace.tx... 5.7 kB 1 16-Oct-2003 20:52 Theosophe74
PossibleSiteEnhancements.txt 1.5 kB 1 26-Jan-2003 23:47 RobertMcGovern
TranslatorReader.diff 1.2 kB 1 08-Feb-2003 16:19 TorstenH
Wiki-error-Problem-2003-06-19.... 4.0 kB 1 19-Jun-2003 21:11 RomeoDisca
attachment_migration_error.txt 2.6 kB 1 21-Jan-2003 12:46 Ebu
filter_patch.diff 1.5 kB 1 27-Aug-2004 01:03 Imario
jspwiki_2052_error.txt 8.5 kB 1 03-Oct-2003 21:51 PaulDownes
out.png 0.2 kB 1 16-Feb-2003 23:52
p1.htm 11.0 kB 1 10-Mar-2004 23:19
p2.htm 11.0 kB 1 10-Mar-2004 23:19
wikiError07072003.zip 8.8 kB 1 07-Jul-2003 21:06
« This page (revision-110) was last changed on 10-Jun-2012 10:43 by Janne Jalkanen