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:Bug Reports


Why not a 'real' bug tracker?

I know a wiki can be use for many things, but Sometimes the specialized tool is simply better. Why not use the bug tracker provided by sourceforge. It works well, gives some structure (which I think is useful for bugs), notifies by email everyone, allow advanced queries, etc.

Note that JSPWiki is moving from wiki bugreports to bugzilla. And I think this moves is less painful when done with a limited unmber of bugs ;-)

I agree that a bug tracker offers a lot of benefits, but there are also advantages to having everything in one place -- Ryan 23-Jul-2007 14:25 PDT
You're right on the advantage of having everything in one place, but usually people understand quite well that bugs are at a different place than user documentation, or technical design discussions. -- Régis Décamps
those reporting bugs are likely to come to first, they won't have to register for AND a bug trackign system,
All developers are already registred within sourceforge, and other users can open tickets anonymously in sourceforge. -- Régis Décamps
and a single check of Special:RecentChanges shows all project updates. -- Ryan 23-Jul-2007 14:25 PDT
We can imagine defining a new Bug namespace that points to sourceforge bug tracker, and Bug:123 being added to the RecentChanges page when sourceforge sends a mail notification -- Régis Décamps
That said, while I'd lean towards keeping bug reports on the wiki I'm not strongly opposed to using a bug tracker, so if others would prefer bug reports moved please say so and we can consider making the change. -- Ryan 23-Jul-2007 14:25 PDT
I don't want to make you change anything if you don't prefer it yourself. But I forgot to point that bugtrackers set unique id to issues; which allows to commit code with comments similar to "fix bug 123 Adding new user account NPE when "mail.from" is not set". In conclusion, I believe there is a need to formalize bugs, this can either be build in the wiki like jspwiki did or with the integration of a bug tracker to the wiki (in particular for Special:RecentChanges and Special:Search. All that being said, il n'y a pas le feu au lac (literally, there is no fire to the Geneva Lake, i.e. there is no panic) -- Régis Décamps 24-Jul-2007 03:07 PDT
+1 for a real bugtracker -- Luzi 25-Jul-2008 02:31 PDT

Split Bug Reports

Should we split up Bug Reports for each version like Bug Reports/Resolved, e.g. Bug Reports/0.8.1 and Bug Reports/0.9.0? It would be easier to report and comment, I think. --hp 17-Jan-2010 04:18 PST

The current Bug Reports page is meant to catch all bugs that affect the currently released version, but you're right that it's messy. I've actually been thinking of two possible alternatives to this page:
  1. Use JIRA. I like the idea of having all JAMWiki-related info on a JAMWiki platform, but there are obviously advantages to using an actual bug tracker.
  2. Create either a template or a form-based entry for bug reports so that version, fix, etc are included. It can then be made clear that any bug report is against the latest version.
Any thoughts? -- Ryan • (comments) • 17-Jan-2010 09:07 PST
JIRA is absolutly great, but everyone needs an additional account. I don't know what the best solution would be, but when bug reports stay on, I would prefer a segmentation into versions or into features (database, configuration, upgrade, display,...). A template for reports would be nice too, but without segmentaion Bug Reports will additionally grow thus it (I think). --hp 21-Jan-2010 03:46 PST

Search is not returning any results

Archived from the Feedback page:

Search on my site does not return any results. I created a new page ("FooBar") and added the text: "This is a new page to test the search abilities." I then rebuilt the search index, and searched on "FooBar". I have uploaded a screen-shot to show my results. As you can see, the link to the page "FooBar" is blue because it already exists.

Do I need to do anything special to initialize and/or configure the search engine? --loopback 25-Feb-2011 14:06 PST

Are there any relevant error messages in your logs? Topics should be automatically added to the search index without the need to rebuild the index. -- Ryan • (comments) • 25-Feb-2011 14:19 PST
Yes. I followed the same steps as above and found three error messages in the log file. I've included the first lines of each (they pretty much say the same thing). If you want/need more, I can email, or upload, or ???
2011-02-25 17:26:58,051 [http-8088-Processor1129] ERROR - Exception while updating topic StartingPoints
java.nio.channels.OverlappingFileLockException: null
2011-02-25 17:27:21,239 [http-8088-Processor1131] ERROR - Exception while updating topic FooBar
java.nio.channels.OverlappingFileLockException: null
2011-02-25 17:27:28,176 [http-8088-Processor1131] ERROR - Exception while searching for FooBar
java.nio.channels.OverlappingFileLockException: null

Thanks for your quick response! --loopback 25-Feb-2011 15:40 PST

I haven't seen that error before, although a similar issue will be addressed for JAMWiki 1.0.1. I'll do a bit of investigation this weekend to see if I can figure anything out. Thanks for the report. -- Ryan • (comments) • 26-Feb-2011 08:45 PST
On my JAMWiki 1.0 installation, the search worked after a "Rebuild Search Index". Before rebuliding, the search results appeared empty. I have a new installation with tomcat 7.0.6 and bulid-in database. -- Daniel Beyer 28-Feb-2011 02:36 PST
Thanks for the input, Daniel. I have already tried to rebuild the index. Maybe I will try moving to the internal DB configuration. -- Greg (the user formerly known as loopback) 28-Feb-2011 08:46 PST
The database shouldn't make a difference - the error you're getting is a Lucene error when attempting to obtain a file system lock. This thread sounds similar - are you using an NFS filesystem? Apparently Lucene has issues with NFS, something I was previously unaware of. -- Ryan • (comments) • 28-Feb-2011 12:45 PST
Nope. Just plain ol'e NTFS. -- Greg (the user formerly known as Loopback) 01-Mar-2011 20:40 PST
If there's any additional info from your logs, or any other info that you think might be helpful in debugging the problem I'd be grateful. So far I can't reproduce the issue on either my Windows machine or on the Linux box, so this may be a tough bug to track down. -- Ryan • (comments) • 01-Mar-2011 22:21 PST

Upgrade from 1.0 to 1.0.0

Archived from the Feedback page:

Hi Ryan, I just upgraded to 1.0.2, I skipped 1.0.1 and everythings seems fine. So, I should not jumped over 1.0.1? I will look into the log-files. Thanks -- mbert 26-Apr-2011 07:48 PDT

Since the initial upgrade may not have updated all data you may want to run the "Rebuild search index" and "Regenerate Topic Metadata Records" tools from the Special:Maintenance page to ensure you data is up-to-date. Both may be slow depending on the size of your wiki (parsing several thousand topics will take several minutes), but once that's done you're pretty well guaranteed to have good data. -- Ryan • (comments) • 26-Apr-2011 10:58 PDT
Yes It worked, I could reproduce the Error:
INFO: Server startup in 4025 ms
2011-04-26 17:00:57,764 [TP-Processor3] ERROR org.jamwiki.servlets.JAMWikiServlet - Unable to load default layout No authentication credential available
       at org.jamwiki.authentication.WikiUserDetailsImpl.initWikiUserDetailsImpl( ~[jamwiki-web-1.0.2.jar:na]
       at org.jamwiki.servlets.ServletUtil.currentUserDetails( ~[jamwiki-web-1.0.2.jar:na]
       at org.jamwiki.servlets.JAMWikiServlet.buildUserMenu( [jamwiki-web-1.0.2.jar:na]
       at org.jamwiki.servlets.JAMWikiServlet.loadLayout( [jamwiki-web-1.0.2.jar:na]
       at org.jamwiki.servlets.JAMWikiServlet.viewError( [jamwiki-web-1.0.2.jar:na]
       at org.jamwiki.servlets.JAMWikiServlet.handleRequestInternal( [jamwiki-web-1.0.2.jar:na]
       at org.springframework.web.servlet.mvc.AbstractController.handleRequest( [spring-webmvc-3.0.5.RELEASE.jar:3.0.5.RELEASE]
       at org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter.handle( [spring-webmvc-3.0.5.RELEASE.jar:3.0.5.RELEASE]
       at org.springframework.web.servlet.DispatcherServlet.doDispatch( [spring-webmvc-3.0.5.RELEASE.jar:3.0.5.RELEASE]
       at org.springframework.web.servlet.DispatcherServlet.doService( [spring-webmvc-3.0.5.RELEASE.jar:3.0.5.RELEASE]
       at org.springframework.web.servlet.FrameworkServlet.processRequest( [spring-webmvc-3.0.5.RELEASE.jar:3.0.5.RELEASE]
       at org.springframework.web.servlet.FrameworkServlet.doGet( [spring-webmvc-3.0.5.RELEASE.jar:3.0.5.RELEASE]
       at javax.servlet.http.HttpServlet.service( [servlet-api-2.5.jar:na]
       at javax.servlet.http.HttpServlet.service( [servlet-api-2.5.jar:na]
       at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter( [catalina-6.0.24.jar:na]
       at org.apache.catalina.core.ApplicationFilterChain.doFilter( [catalina-6.0.24.jar:na]
       at [spring-security-web-3.0.5.RELEASE.jar:3.0.5.RELEASE]
       at org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate( [spring-web-3.0.5.RELEASE.jar:3.0.5.RELEASE]
       at org.springframework.web.filter.DelegatingFilterProxy.doFilter( [spring-web-3.0.5.RELEASE.jar:3.0.5.RELEASE]
       at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter( [catalina-6.0.24.jar:na]
       at org.apache.catalina.core.ApplicationFilterChain.doFilter( [catalina-6.0.24.jar:na]
       at org.jamwiki.servlets.JAMWikiFilter.doFilter( [jamwiki-web-1.0.2.jar:na]
       at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter( [catalina-6.0.24.jar:na]
       at org.apache.catalina.core.ApplicationFilterChain.doFilter( [catalina-6.0.24.jar:na]
       at org.apache.catalina.core.StandardWrapperValve.invoke( [catalina-6.0.24.jar:na]
       at org.apache.catalina.core.StandardContextValve.invoke( [catalina-6.0.24.jar:na]
       at org.apache.catalina.authenticator.AuthenticatorBase.invoke( [catalina-6.0.24.jar:na]
       at org.apache.catalina.core.StandardHostValve.invoke( [catalina-6.0.24.jar:na]
       at org.apache.catalina.valves.ErrorReportValve.invoke( [catalina-6.0.24.jar:na]
       at org.apache.catalina.core.StandardEngineValve.invoke( [catalina-6.0.24.jar:na]
       at org.apache.catalina.connector.CoyoteAdapter.service( [catalina-6.0.24.jar:na]
       at org.apache.jk.server.JkCoyoteHandler.invoke( [tomcat-coyote-6.0.24.jar:na]
       at org.apache.jk.common.HandlerRequest.invoke( [tomcat-coyote-6.0.24.jar:na]
       at org.apache.jk.common.ChannelSocket.invoke( [tomcat-coyote-6.0.24.jar:na]
       at org.apache.jk.common.ChannelSocket.processConnection( [tomcat-coyote-6.0.24.jar:na]
       at org.apache.jk.common.ChannelSocket$SocketConnection.runIt( [tomcat-coyote-6.0.24.jar:na]
       at org.apache.tomcat.util.threads.ThreadPool$ [tomcat-coyote-6.0.24.jar:na]
       at [na:1.6.0_24]
2011-04-26 20:33:03,975 [TP-Processor2] ERROR org.jamwiki.servlets.AdminServlet - Failure while regenerating topic metadata
org.jamwiki.DataAccessException: java.sql.BatchUpdateException: Duplicate entry '128-SSHAllgemein' for key 'PRIMARY'
       at org.jamwiki.db.AnsiDataHandler.addTopicLinks( ~[jamwiki-core-1.0.2.jar:na]
       at org.jamwiki.db.AnsiDataHandler.writeTopic( ~[jamwiki-core-1.0.2.jar:na]
       at org.jamwiki.db.WikiDatabase.rebuildTopicMetadata( ~[jamwiki-core-1.0.2.jar:na]
       at org.jamwiki.servlets.AdminServlet.links( [jamwiki-web-1.0.2.jar:na]
       at org.jamwiki.servlets.AdminServlet.handleJAMWikiRequest( [jamwiki-web-1.0.2.jar:na]
       at org.jamwiki.servlets.JAMWikiServlet.handleRequestInternal( [jamwiki-web-1.0.2.jar:na]


So which table has the defect data inside? This stacktrace was from catalina.out. I do not find jamwiki.logs. -- mbert 26-Apr-2011 14:14 PDT

That should be the jam_topic_links table... I'll need to dig a bit to figure out how that error could happen. Sorry for the trouble - you're the first person to report this problem. -- Ryan • (comments) • 26-Apr-2011 15:36 PDT
What database are you using? The only way I can see that this error would trigger is if the database isn't case-sensitive... -- Ryan • (comments) • 26-Apr-2011 20:17 PDT
Hi Ryan, thanks. Right now I'm using Mysql: "5.1.41-3ubuntu12.10". I did not change any default settings on the database. I'll figure out today how to change the case-sensity of the database or the jamwiki tables.
The jam_topic_links table has one strange entry: "| 16 | Kļæ½digung |". I did update the entry with a update-Sql-Statement on the comandline, but after I pressed the button to "Regenerate Topic Metadata Records" tools from the Special:Maintenance page the entry was restored. -- mbert 27-Apr-2011 00:37 PDT
"Regenerate Topic Metadata" will try to rebuild everything, which explains why the entry re-appears. I need to look at the MySQL docs to see if it's case-sensitive, and if not I'll see if there is a good workaround for JAMWiki 1.0.3. If you happen to find out anything else please let me know, and thanks again for helping to debug. -- Ryan • (comments) • 28-Apr-2011 07:33 PDT
Hi Ryan, I wounder why case-sensitivity has something to do with this error. Im working under linux - which is case sensitiv per default - and use tomcat and mysql 5.1.41. Where do the informations come from - who are inserted into the jam_topic_links table? May be I'm able to search for the origin and remove them by hand (using sql comand line). -- mbert 28-Apr-2011 10:01 PDT
The jam_topic_links table is used with the "Links" tab at the top of each topic to determine what topics "link to" the current topic. It is automatically populated when you save a topic using all of the wikilinks in that topic's content.
If MySQL isn't configured to be case-sensitive then the problem is due to the fact that the Java code assumes that "TOPIC" and "topic" are two different values, but if the database isn't case-sensitive then it will try to create a new record for "topic" and throw a primary key violation because "TOPIC" already exists. I think that's what is happening in your case, because the Java code eliminates duplicate topic names. -- Ryan • (comments) • 28-Apr-2011 10:25 PDT
My MySQL-DB should now be case-sensitiv. I altern each table with: "ALTER TABLE `jamwiki`.`jam_<table-name>` CHARACTER SET utf8 COLLATE utf8_bin;" But still the same Error-Message and I can not find any hint to problematic values in the jam_topic table. So, what next? -- mbert 29-Apr-2011 00:41 PDT
Thanks for the additional investigation. I'll dig into this during the weekend, and if you're willing to do some additional testing I can try to make a debugging version of JAMWiki available to you to hopefully track down the specific issue and get this resolved. -- Ryan • (comments) • 29-Apr-2011 08:47 PDT
Debugging.war seems a good idea to me. When I have some time I try to dig into the initial creation (first installation) of the jamwiki-tables for mysql - I may find some options for the tables and the database to compare with my tables. -- mbert 01-May-2011 01:27 PDT is an exact copy of JAMWiki 1.0.2 except I've modified the AnsiQueryHandler.insertTopicLinks method to not use a batch update, to log the parameters being added, and to be a bit more verbose in logging exceptions. If you can install this, run it, and then either email me the log file or upload it to then I can hopefully figure out exactly what's happening. Sorry again for the trouble, and thanks for your help in debugging. -- Ryan • (comments) • 01-May-2011 07:37 PDT