Things that may appear to be bugs in JSPWiki to some, but are in fact intentional or misunderstandings.

Bug A Error For Plugins Be Parsing
Bug Ampersand Encoded Incorrectly In Page Info RSS Feed
Bug Anonymous View Denied
Bug Attach Dir Not Found
Bug Automatic Logout
Bug Bug UNABLE To Delete Attachements
Bug Cant Use As Text
Bug Cookies Required For Preview
Bug Different Wikis On Same Tomcat Incorrectly Use Same Lucene Search
Bug External Special Page Not Working
Bug File Name Too Long
Bug Form Failed On Submission
Bug Generated Wikitable Class Tables Include Border Directive
Bug How To Reset User Password
Bug How To Use JSP Wiki Tag
Bug In Error Instead Of Results In Inability To Edit Left Menu Page
Bug Init Reference Manager Running Long With JDBC Page Provider
Bug JSP Wiki Samplepages.zip Should Include More Files.
Bug Links To Filesystem Doesn T Work
Bug List Indentation
Bug Numbered Lists Level 2 Are Broken
Bug PDF Plugin The Border Width And Height Does Not Seem To Work
Bug Page Date Format Needs To Include Miiliseconds
Bug Page Names With Numeric Prefixes
Bug Pictures With Links Do Not Work
Bug Refered Pages Plugin Does Not Recognize Links In Table Construct
Bug Referring Pages Plugin Fails After Upgrade
Bug Reports
Bug SET Alias Scanning Old Versions
Bug Slash In Wiki Link Makes Jspwiki Think It Is An Attachment
Bug Special Page Feature Shows Errorpage
Bug Style Filtered Table Not Supported
Bug Tracking System
Bug URL In Preformatted Text Displayed As Link
Bug Uploads Not Enabled
Bug Weblog Plugin Shows Entries According To Date In Filesystem
Bug Where Is Login Link
Bug Wiki Tag Base Version Problem
Bug Works In Windows.When Deployed In Sunsolaris And Access Gets Error


NO RECENT CHANGES OR SYSTEM INFO

Date 2003-12-17
JSPWiki version 2.0.52 and 2.1.86 alpha
Java version 1.4.2
Operating system Windows 2000
Web server and servlet container Tomcat 5.0.16
Page provider FileSystemProvider
Browser Mozilla Firebird 0.7

The RecentChanges and System pages appear as regular pages (i.e. they are empty and suggest that I create them) rather than have the special property of displaying the recent changes and system info. I cannot find any JSP files that suggest this behaviour either. I am correct to assume that the Wiki has this functionality aren't I? This website does.

Oops -- just realised that this site's recent changes page use a wiki tag to insert the recent changes. Maybe we should leave this here for others as stupid as me?

Well, the line above didn't help me alot, but I found the answer anyhow. You need to remember to unpack the files from JSPWiki-samplepages.zip into the directory where you store all your pages.


DUPLICATE BREADCRUMBS

Date 2003-12-17
JSPWiki version 2.0.52
Java version 1.4.2
Operating system Windows 2000
Web server and servlet container Tomcat 5.0.16
Page provider FileSystemProvider
Browser Internet Explorer 6.0.28

The trail displayed in the breadcrumbs does not check for duplicate entries. So if I start from the main page and then navigate to a bunch of pages on the wiki and come back to main page, it results in two instances of main. Am not sure if this is the intended behavior. If all pages are unique, then the breadcrumbs code should be able to check for duplicate entries and skip them.

Ideally, I would prefer something like this, but am not sure if this scenario applies on a generic basis. When the user comes back to a page that is already in the breadcrumbs then that page becomes the last one in the trail and all the pages visited after that page are removed from the breadcrumbs trail. So this provides a pseudo concept of hierarchical menus even though they are not supported in WIKI framework.

E.g. if the breadcrumb trail looks like this... Main, Bhira, BugReports, Templates, FAQ and then I navigate to the Bug Reports page again then the breadcrumb trail should update... to Main, Bhira, BugReports

This is not a bug. Perhaps you are not familiar with the breadcrumb metaphor? Imagine a bag full of breadcrumbs (or a bag of rice, if you're from the far east) with a hole in the bottom - there is a trail of breadcrumbs following you everywhere you go. Even if you go back to the same place you were before, there will still be breadcrumbs at the places you visited in between. This is actually implemented as a queue of page links. The behavior you describe is not consistent with that metaphor. You're right, wiki pages don't have a hierarchy, if they did then this feature would probably be called page path or something like that. -- KenLiu

Ken - I'm not the original poster and I accept this isn't a bug but it would be nice to have the option to set a unique constraint. As things stand, if I flip between two pages five times my trail might be (assuming default max trail size):

Page9 | Page10 | Page9 | Page10 | Page9 | Page10 | Page9 | Page10 | Page9 | Page10

I would much prefer the following:

Page1 | Page2 | Page3 | Page4 | Page5 | Page6 | Page7 | Page8 | Page9 | Page10

I'm curious as to when the breadcrumb metaphor would be more useful than just seeing the last n visited pages.

-- RayDrew

Two things. First, I use the breadcrumb trail to follow how I got to a page, since I try to keep many paths to a page. So duplicates in a trail help me keep track of what I've been doing.

Second, I changed the tag code to support your request. There is a new parameter called trailtype that takes values of breadcrumb the default and the way it works now. The parameter visit shows the pages that you visited. Let me know if you have problems / questions. -- Foster Schucker

Foster - With use, I'm getting to like the breadcrumb trail but it's great to have both options . Thanks, -- RayDrew


Changes do not appear to pagehistory or to RecentChanges#

Running 1.8.1 on Tomcat 4.0.4 and j2sdk1.4.0.1, and Debian. Using RCSFileProvider.

The system has been running just fine for almost half'n'year, but I was notified of strange behaviour yesterday - it seems that pagechanges are not recorded anywhere, anymore, even if the changes go through just fine. In other words, when you edit a page, it works just fine, but the information about the change is not stored anywhere (not to RecentChanges, not to the pages own version history, and not even to the last changed at the bottom of the page).

Has anyone been experiencing anything like this before? Updating might help, of course.

I'm puzzled. A millenium-bug, just three years late? ;)

-- JukkaKoskelin

Probable reason: RCS locks. RCS, by default, locks the files under the current user. If you restart the web server under a different username, RCS will refuse to check in new files.

Check the jspwiki.log for any checkin commands that have failed (use DEBUG logging level), and check manually if the RCS files have been locked correctly. For more information, see RCSFileProviderIssues.

-- JanneJalkanen

Right. It was all about the locks - obviously, someone had started Tomcat with different userid than before. Changing the locks in every .txt-file helped. Thanks.

-- JukkaKoskelin


2003-Mar-06: Edit, the URL has the page with initial caps, regardless of what the link says#

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

I noticed this because I wrote an script allowing our team to right-click on any OS file and add a wiki page describing the file. Some of the files, such as provider.jsp, have a lowercase character at the front. Some like ProviderDataTag.java have uppercase at the front. With the two names above, the edit pages show as:

http://yourServer/yourAwesomeWiki/Edit.jsp?page=Provider.jsp
http://yourServer/yourAwesomeWiki/Edit.jsp?page=ProviderDataTag.java

Notice the first link has provider.jsp shown as Provider.jsp

You can see this right away by hovering over the links in the paragraph above. Hover and look at the link on your browser's status bar. It will show the initial cap for provider.jsp.

This probably wouldn't bother most uses of a wiki, but since I'm linking in files, it makes a difference.

The .txt files get created correctly with the lowercase name.

One last thing, this also messes up the refered to plug in. After editing one of the lowercase pages, the refering pages plugin shows entries for provider.jsp and Provider.jsp.

--Thanks, Scott Hurlbert

No, the FileSystemProvider is in error. It should create the page with uppercase name, a proper WikiName.

It should not be possible (without accessing Edit.jsp directly) to create a non-WikiName page... You should fix your script to do the proper transformation into a WikiName. Sorry.

-- JanneJalkanen

Ok, thanks for the quick answer. What I'm doing will work one way or the other so I guess we're good. I'll fix my script. If I wanted to post it for others, where would I put it?

-- Scott

How about something like contributed code?

-- JanneJalkanen


ChangeLog page is one very long line with Opera 7 on WindowsXP.#

Not a JSPWiki bug, but still annoying.

Heh. That's because it uses UNIX linefeed convention. Sorry, can't really help you there... Opera should be smart enough to figure it out itself. --JanneJalkanen


Tags not working#

im sure im a bonehead and have done something wrong. but whenever i use a wiki:tag it is passed unfiltered to the web browser. so <wiki:Calendar/> does nothing at all. jspwiki.translatorReader.allowHTML=true has been specified. are wiki:tags not valid in ordinary text editing?

Date : 4/9/2003
The JSPWiki version : 2.0.36
The Java version : 1.4.1
Your operating system : Windows 2000 & XP
The web server and servlet container used : Tomcat 4.0 & 4.1
The used page provider : ?
Used browsers : IE 6.0

Do you mean that when you write normal WikiText? If so, then no, it is not possible to write JSP tags in the normal editor window - they only go to the JSP pages. If you're having problems getting the JSP pages themselves to work, then check that all of your JSP files have the following line at the top:

<%@ taglib uri="/WEB-INF/jspwiki.tld" prefix="wiki" %>
and that you have the jspwiki.tld installed in the WEB-INF -directory. Check also that it is not corrupted or that the process running Tomcat has read access to it.

Does this help?

-- JanneJalkanen

Many thanks. That clears it up. JSPWiki is a great benefit to me at work. We're new to the wikiway and enjoying it.

-- Greg Smith

­----

Java import never used#

This is not really a bug. I am using Eclipse to develop a new plugin for JSPWiki and I have noticed the JSPWiki source code contains many classes with java import never used. Eclipse automatically prints a warning message + underlines the lines + makes funny sounds (!) for each warning. So if you want your code to be gorgeous, you clean it very quickly to get rid of this messages ...

Date : 4/10/2003
The JSPWiki version : 2.0.36
The Java version : 1.4.1
Your operating system : Windows 2000
The web server and servlet container used : Tomcat 4.1
The used page provider : ?
Used browsers : IE 6.0

JeanMichelGarnier

Many of these have already been fixed in the 2.1 branch. However, test classes are practically all misbehaving in this sense, as I want to catch as many ambiguities as possible in test classes...

--JanneJalkanen (move to NotABug).


31 July 2002 NiiloNeuvo#

by unknown#

This page last changed on Mon Jul 29 13:21:24 EEST 2002 by unknown.

I find that by unknown very annoying. In the case the author is not know could it just be:

This page last changed on Mon Jul 29 13:21:24 EEST 2002.

GamesBook: Well, I think this is a good reminder that not everyone has to register to make changes. Of course, as this is controlled from a JSP, it would be easier enough to change this behaviour in your site.

BorisFolgmann: What about using the IP address of the client instead of by unknown? Some other Wikis do this. Even better: do a name lookup and use the full qualified domain name of the host.

JanneJalkanen: This is actually what we do. The "unknown" appears only when the IP address could not be resolved, for example when the PageRepository was modified outside of JSPWiki.


Images are not displayed#

v2.0.0, JDK 1.3.1, Win-NT, JBoss/Jetty, VersioningFileProvider, Mozilla

Images (e.g. jspwiki_logo.png) are not displayed, although I copied the reference to the image literally from the AttachmentsDemo page.

Where shall I put the images? There is no config property in jspwiki.properties.

I (unsuccessfully) tried

  1. the directory which hosts all the wiki pages
  2. the image directory of the app-server war-file-hierarchy
  3. an image directory one level above the data pages...

--GernotStarke, 11-Dec-2002.

The image-ref in AttachmentsDemo is only working, because jspwiki_logo.png is an attachment of that page and is therefore automatically included.

If you have stored the page in the image directory of your app-server you can inline it using [http://yourServer/JSPWiki/images/jspwiki_logo.png] or if you're only working locally, a file-URL would also be possible, in which case the file can be anywhere in the file-system.

Generally speaking, any link to a URL that ends with .png (or what else is defined to be an image in jspwiki.properties) gets inlined in the page.

-- TorstenH


org.apache.jasper.JasperException: Tag failed, check logs: null#

This occurs now when accessing the Search.jsp file. It works great on the default template but I created my own template. I have narrowed it down to the ViewTemplate.jsp. If I copy in the one from the default template directory, all works fine, however mine does not. Obviously it's an error on my side but I cannot figure out why this is happening. I look for code revelant to the Search.jsp file and also changes from the default ViewTemplate.jsp file and mine that could cause an error like this and I am unable to find any.

I do not want to include full stack traces here or my template. Please visit JeremyCTemplateProblems for the full stack trace and the full ViewTemplate.jsp file.

Thank you,

-- JeremyC

This was resolved through personal email... --JanneJalkanen


2002-11-19
The JSPWiki JSPWiki - 1.9.30, but also on 1.8.2
Browser is Chimera (uses Mozilla Gekko)

This either a cry for help or a bug - I need you to tell me which it is.

When I go to UserPreferences there is a comment to the effect that I should be able to set up all sorts of interesting things, but all that clicking "Set my preferences!" seems to do is to set a cookie that allows JSPWiki to recall my WikiName. I guess I was expecting the ScottEade page to be created by default with a bunch of settings available for me to edit. If I have to create the ScottEade page myself then that is fine, but is there a reference somewhere of the available user preference settings?

Thanks.

--ScottEade

Yeah. Well. No. You can just set up your UserName in UserPreferences right now. We were sort of jumping the gun when we said that there would be "all sorts of interesting things"... :-) I should really fix that.

We don't yet do TWiki-style UserPreferences on pages, but we might.

--JanneJalkanen

ScottEade: Okay. Thanks for the quick response.


Mozilla jumping between standards compliant and quirks mode [#1]#

Sep-17, 2002. 1.9.2x.

When I view this site on Mozilla 1.0 or 1.1, the rendering seems to be jumping between Quirks mode and Standards compliant mode. This is quite annoying, since it causes the layout to change slightly each time. If the page comes from the cache, Mozilla seems to go much more probably in Standards mode.

--JanneJalkanen

Reported to mozilla.org. Can't do much else.

This is not just something to blame Mozilla for. If you look at the HTML that is produced, there is a bunch of empty lines before the DOCTYPE. If you modify the JSPs not to produce these empty lines, there is no change in the rendering-mode any more. Unfortunately this reduces readability of the JSPs, as all linebreaks have to occur inside a JSP tag.
Changing this is also a prerequisite to supporting XHTML, because '<?xml' has to be exactly the beginning of any well-formed XML-file, if I'm not mistaken.

--TorstenH

Direct quote from the HTML 4.01 spec:

An HTML 4 document is composed of three parts:

   1. a line containing HTML version information,
   2. a declarative header section (delimited by the HEAD element),
   3. a body, which contains the document's actual content. The body may be implemented 
      by the BODY element or the FRAMESET element.

White space (spaces, newlines, tabs, and comments) may appear before or after each section. 

Mozilla is actually buggy in this respect :-). I will worry about the XML preamble when I get there (but it's probably trivial to just put it on top of any JSP page). Unfortunately, Tomcat 3.2 seems to be producing the linebreaks also from inside JSP tags sometimes. I don't really know why.

--JanneJalkanen

Interestingly enough, I managed to get rid of the quirks mode while fiddling with our ViewTemplate.jsp. Some change related to the table layout in there just magically fixed my layout. =/ --ebu

What if I find bugs, and I fix them myselves. Where should I send the patches?

-- WilfredSpringer

hehe... I just went through the same thing. Take a peek at: ContributingChanges.

--JeremyC


Can't change page color#

  • August 17th, 2002
  • The JSPWiki version: 1.8.2
  • Used browsers Netscape 6

The body tag in Wiki.jsp has a color attribute, thus you cannot change the color using the stylesheets -- Ross Gardler

Really? Putting "BODY { background-color: #808080; }" into the CSS file certainly changed my Wiki.jsp color... Note that you probably need to restart your browser after the change and make sure your caches are empty, as many browsers cache CSS files very aggressively. --JanneJalkanen

Euro symbol not working#

  • September 4st, 2002
  • AlainRavet
  • 1.9.21, Tomcat 4.1, Windows XP, IE6.0, jdk 1.4.1

On my wiki, accentuated characters work fine, but as soon as I add a euro symbol to the page, all the special characters got corrupted. This is produced by Edit.jsp: if I introduce the € with a text editor, it will appear correctly. But as soon as I try to edit the page, kaboom.

Example:

this wikimy wiki
été à la plageété à la plage
été à la plage €Ã©té à la plage €

Hm. Are you using UTF-8 or ISO-8859-1? As you may know, ISO-8859-1 does not support the € sign - you need ISO-8859-15 to do that. But I didn't know that Java was that picky, since they are otherwise totally the same.

-- JanneJalkanen

I was using the default (ISO-8859-1).
Uncommenting the jspwiki.encoding = UTF-8 line in the jspwiki.properties file, solved the problem. Thanks
Any reason for choosing ISO-8859-1 as default value? This wiki uses UTF-8!

-- AlainRavet

Yes. Many older browsers (Opera 5, NS4, etc) do not understand UTF-8, and break the site when you post stuff that contains anything above the ASCII 7-bit limit. However, since euro is now an official currency over here, we should perhaps move to ISO-8859-15. Unfortunately, somehow I doubt that these older browsers would understand that either, and would still get confused. *sigh* Probably it's best to change the default to UTF-8 for the 1.9.x.

-- JanneJalkanen

Servlet.jar not included in distribution#

I compiled JSPWiki from source and noted that servlet.jar is not included with the distribution. Perhaps a note could be added in the ant build.xml doc that this file should be copied from tomcat to the src lib directory?

Perhaps. We're not including servlet.jar because it comes with every servlet container anyway, and since the user cannot run JSPWiki without the container, there is no point in making him download everything twice. Anyway, I added a short note to doc/Compiling.txt, which you should have read anyway before attempting to compile :-).

User name missing#

Even though I have set my user name in the "user preferences" section of *my* Wiki it does not seem to be recording my name as the user who made edits to a page. I get "unknown" in both the "recent changes" page and at the bottom of each edited page.

Anybody know why this is? Is it because I'm not using version control?

Matt

Yes, this is correct. If you don't use versioning, you lose certain things such as author information.

--JanneJalkanen

Perhaps the FileSystemProvider could be enhanced to store page metadata in a single, separate file. (or even one additional file per page) -- KenLiu


2003/07/18 - Non-JSP files not working with JRun 4#

Date 2003/07/18
JSPWiki version 2.0.45
Java version 1.4.1
Operating system Win2000
Web server and servlet container JRun 4
Browser(s) Mozilla 1.3.1 / IE 6.0

I created a war file with the JSPWiki files and deployed it in JRun 4 on our intranet in a JRun web app context named "/wiki"; i.e. the URL is http://some.server/wiki Although the Wiki jsp files all work fine, i.e. http://some.server/wiki/Wiki.jsp and editing and so forth (which verifies that the WEB-INF/lib jars are found, etc.) most non-JSP files are not working:

  1. The images do not work, i.e. the red arrow image for external links. Directly accessing the image, i.e. http://some.server/wiki/images/out.png (as used in the rendered html) also fails.
  2. the style sheets are not found
  3. the web.xml welcome-file-list does not work, so the URL http://some.server/wiki fails. I also tried creating a index.html in the root that redirects to Wiki.jsp and redeployed and that failed as well. Even though index.html exists in the root of the war file, the URL http://some.server/wiki/index.html fails (404)

Thus, I suspect there is a problem serving non-JSP files from the war file in JRun 4

I have tried both leaving jspwiki.baseURL unset or setting it to http://some.server/wiki/ (with the trailing /!) and neither works.

Has anyone successfully deployed JSPWiki as a war file on JRun? -- DavidBiesack

2003/07/18 I found the problem - JRun was fronted by an IIS isapi filter. When we reset the IIS server, it picked up the new /wiki context and now the non-JSP files are working as expected. Leaving this item here in case others run across a similar configuration. -- DavidBiesack


Date 2004-11-10
JSPWiki version 2.1.103-alpha
Java version 1.4.2.05
Operating system Windows 2000
Web server and servlet container Tomcat 5.0.28
Page provider VersioningFileProvider
Browser any
Reported by drrota@us.ibm.com

JSPWiki has detected an error Error Message An unknown exception java.lang.NullPointerException was caught by Error.jsp. Exception java.lang.NullPointerException Place where detected com.ecyrd.jspwiki.filters.FilterManager.doPreTranslateFiltering(), line 277 If you have changed the templates, please do check them. This error message may show up because of that. If you have not changed them, and you are either installing JSPWiki for the first time or have changed configuration, then you might want to check your configuration files. If you are absolutely sure that JSPWiki was running quite okay or you can't figure out what is going on, then by all means, come over to jspwiki.org and tell us. There is more information in the log file (like the full stack trace, which you should add to any error report).

Solution: I had removed some page attachment files, thinking that's the way you delete them. But apparently, this information is cached somewhere and removing attachment files in the webapp/jspwiki-files/<wiki>-app directories. To fix this, save off all the files, and reconstruct the wiki from a new war file and selectively put the files back, without putting back the file-dir directories of the attachments that you removed.

Add new attachment

Only authorized users are allowed to upload new attachments.
« This page (revision-36) was last changed on 15-Nov-2011 11:51 by xiaochang619