Bug Reports/Resolved/0.6.x

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

[Edit]

Images won't show up

Moved from the Feedback page:

I am using version 0.5.4 atm. I uploaded a png to my wiki called dragbuildxml.png and the Image:drapbuildxml.png site does not show the image at all. If I refer directly to the image, it is shown pefectly. Hence, I can't really use images at all. I renamed the file to dbx.png and uploaded again and the pciture showed up perfectly. What can I do about? THX, Mike

Can you provide any additional information? Were there any errors in the logs? There have occasionally been reports of image upload failures when the file upload settings are incorrectly specified, but yours is the first report I've heard where uploading one image failed but another succeeded. -- Ryan 28-Jun-2007 22:59 PDT
Ryan, thx for you quick answer. I did some more investigation and noticed that AdBlockPlus blocked the image due to regexp. Works now!
[Edit]

Tomcat reports HTTP 500 on image tag

Moved from the Feedback page:

my config: HP-UX B11.23 IA64N / Tomcat 5.5.20 / Internal database / HP JVM 1.5.0.6 Tested with JAMWiki 0.5.4 using [ [Image:name|right|thumb|<desc>] ] produces exception: can't connect to xserver I started the xserver and now I get:

org.springframework.web.util.NestedServletException: Handler processing failed; nested exception is java.lang.NoClassDefFoundError
	org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:879)
	org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:774)
	org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:460)
	org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:425)
	javax.servlet.http.HttpServlet.service(Unknown Source)
	javax.servlet.http.HttpServlet.service(Unknown Source)
	org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:264)
	org.acegisecurity.intercept.web.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:107)
	org.acegisecurity.intercept.web.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:72)
	org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
	org.acegisecurity.ui.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:110)
	org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
	org.acegisecurity.providers.anonymous.AnonymousProcessingFilter.doFilter(AnonymousProcessingFilter.java:125)
	org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
	org.acegisecurity.ui.rememberme.RememberMeProcessingFilter.doFilter(RememberMeProcessingFilter.java:142)
	org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
	org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:217)
	org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
	org.acegisecurity.ui.logout.LogoutFilter.doFilter(LogoutFilter.java:106)
	org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
	org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:229)
	org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
	org.acegisecurity.util.FilterChainProxy.doFilter(FilterChainProxy.java:148)
	org.acegisecurity.util.FilterToBeanProxy.doFilter(FilterToBeanProxy.java:98)
	org.jamwiki.servlets.JAMWikiFilter.doFilter(JAMWikiFilter.java:58)

root cause

java.lang.NoClassDefFoundError
	java.lang.Class.forName0(Native Method)
	java.lang.Class.forName(Class.java:168)
	java.awt.Toolkit$2.run(Toolkit.java:822)
	java.security.AccessController.doPrivileged(Native Method)
	java.awt.Toolkit.getDefaultToolkit(Toolkit.java:805)
	java.awt.Image.getScaledInstance(Image.java:158)
	org.jamwiki.utils.ImageUtil.resizeImage(ImageUtil.java:173)
	org.jamwiki.utils.ImageUtil.initializeImage(ImageUtil.java:90)
	org.jamwiki.utils.LinkUtil.buildImageLinkHtml(LinkUtil.java:158)
	org.jamwiki.parser.jflex.WikiLinkTag.parseImageLink(WikiLinkTag.java:167)
	org.jamwiki.parser.jflex.WikiLinkTag.buildInternalLinkUrl(WikiLinkTag.java:73)
	org.jamwiki.parser.jflex.WikiLinkTag.processLinkContent(WikiLinkTag.java:205)
	org.jamwiki.parser.jflex.WikiLinkTag.parse(WikiLinkTag.java:113)
	org.jamwiki.parser.jflex.AbstractLexer.parseToken(AbstractLexer.java:108)
	org.jamwiki.parser.jflex.JAMWikiProcessor.yylex(JAMWikiProcessor.java:1479)
	org.jamwiki.parser.jflex.JFlexParser.lex(JFlexParser.java:114)
	org.jamwiki.parser.jflex.JFlexParser.parseProcess(JFlexParser.java:252)
	org.jamwiki.parser.jflex.JFlexParser.parseHTML(JFlexParser.java:170)
	org.jamwiki.utils.Utilities.parse(Utilities.java:783)
	org.jamwiki.servlets.ServletUtil.viewTopic(ServletUtil.java:528)
	org.jamwiki.servlets.EditServlet.preview(EditServlet.java:226)
	org.jamwiki.servlets.EditServlet.edit(EditServlet.java:80)
	org.jamwiki.servlets.EditServlet.handleJAMWikiRequest(EditServlet.java:61)
	org.jamwiki.servlets.JAMWikiServlet.handleRequestInternal(JAMWikiServlet.java:74)
	org.springframework.web.servlet.mvc.AbstractController.handleRequest(AbstractController.java:153)
	org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter.handle(SimpleControllerHandlerAdapter.java:48)
	org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:839)
	org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:774)
	org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:460)
	org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:425)
	javax.servlet.http.HttpServlet.service(Unknown Source)
	javax.servlet.http.HttpServlet.service(Unknown Source)
	org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:264)
	org.acegisecurity.intercept.web.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:107)
	org.acegisecurity.intercept.web.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:72)
	org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
	org.acegisecurity.ui.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:110)
	org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
	org.acegisecurity.providers.anonymous.AnonymousProcessingFilter.doFilter(AnonymousProcessingFilter.java:125)
	org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
	org.acegisecurity.ui.rememberme.RememberMeProcessingFilter.doFilter(RememberMeProcessingFilter.java:142)
	org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
	org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:217)
	org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
	org.acegisecurity.ui.logout.LogoutFilter.doFilter(LogoutFilter.java:106)
	org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
	org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:229)
	org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
	org.acegisecurity.util.FilterChainProxy.doFilter(FilterChainProxy.java:148)
	org.acegisecurity.util.FilterToBeanProxy.doFilter(FilterToBeanProxy.java:98)
	org.jamwiki.servlets.JAMWikiFilter.doFilter(JAMWikiFilter.java:58)

how can I fix this?

I'm not very familiar with HP-UX, but does the HP-UX JDK have any limitations with the java.awt.image package? JAMWiki is using JDK methods for resizing images, so if the HP-UX JDK doesn't offer those methods then I'll need to implement some sort of workaround. -- Ryan 01-Jul-2007 22:53 PDT
Ryan, I enabled the X-Server manually for java.awt.image but no avail. Can you provide a sample class file to test this on the server? It's actually quite bad to rely on the awt package because it relies on an installed X-Server and most servers don't even have one. None of the image resizers work.
I don't have any java.awt test class available at the moment that would be useful for testing, so unfortunately I can't be of much help. HP-UX is actually the first system I've heard of that has had issues - I use a Windows system for development and jamwiki.org runs on a Linux system installed using the Debian server install, and there have been success reports from Solaris users. Ten minutes of Googling isn't turning up anything that looks relevant to figuring out why HP-UX would be different. As a result, I'm not sure what the best solution for your situation is - if there's a better way to handle image resizing it would definitely be worth investigating, but at the same time I don't want to have to support different solutions for different platforms, which is why the standard JDK packages were used in the first place. Let me know if you come up with anything, and apologies for the trouble you're having! -- Ryan 05-Jul-2007 20:24 PDT
Ryan, if this can't be solved right now, it should be added to known issues. I will write some test classes which resize images and use within HP-UX and will post my results!
Please go ahead and update the known issues page - I very much encourage everyone who is willing to add to the documentation, as that's probably my least favorite aspect of trying to coordinate this project! If you do come up with some code that works with HP let me know, and hopefully we can find some way to get it included in the next release. Thanks! -- Ryan 06-Jul-2007 22:55 PDT
Ryan, I am pleased to help. Can you point me to the classes in the project which resize the images? I wll check them out from SVN and try to rebuilt the failure here! I added it to known issues!
The resizing code is in Subversion as /trunk/src/java/org/jamwiki/utils/ImageUtil.java. The method that performs the resizing is resizeImage(). All that the code does is build a Java BufferedImage object and then calls getScaledInstance(). Hope that helps! -- Ryan 07-Jul-2007 15:38 PDT
Ryan, helps alot. I will take a lot after 18th July after my last exam. So expect an answer by the end of July!

Ryan, I found a solution for the problem which affects all UNIX-like OSes
Solution: If you are running a unix/linux server w/o an X-Server or don't have the priviliges to start it, all BufferedImage operations like thumb (resize) jamwiki crashes with can't connect to x-server because java.awt.Image relies on the graphical subsystem of your OS. If you still want to use those methods you have to tell your VM that you are running headless => no X-Server installed. Add to your JAVA_OPTS/VM args "-Djava.awt.headless=true" and all operations are propably done in soft mode but it works flawlessly here.

Thanks for investigating! If you'd like feel free to add this information to the Installation guide - just create a new section called "Other Configuration Settings" (or something similiar). I'll try to remember to add some error handling around that method in the future to log a note indicating the solution you've pointed out, so hopefully this issue won't bite anyone else. -- Ryan 19-Jul-2007 08:51 PDT
Ryan, it's done. Just added another section! But what bothers me the most is that tomcat displays the regular error page for 404 or 500 which is really extremely confusing for a novice. Should be handled with custom pages.
Thanks! I agree that's bad - my previous comment wasn't clear (first thing in the morning I'm not the sharpest tool in the shed) but unless I forget I'll add some error handling to prevent that problem from propagating to the user in the future, which should get rid of the 500 error. -- Ryan 19-Jul-2007 15:14 PDT
OK, the reason that this issue caused a crash is that the code was catching exceptions, but this one threw an error. In ten years of Java programming that may be the first time that the distinction between the two has bit me. In any case I've modified a few chunks of high-level JAMWiki code to catch Throwable instead of Exception, which should hopefully stop this kind of error from biting anyone else. In addition, I've added logging around the image resizing code to note that the java.awt.headless parameter (or X) should be enabled in the case of resize failures on a UNIX box. In addition, the code should return the non-resized image as a fallback. For anyone keeping score at home it's Subversion revision #1550.
Hopefully these changes will make life easier for other UNIX admins in the future! Thanks again, and let me know if you'd like a credit in the CHANGELOG - I just need to know what name to use to credit you with. -- Ryan 19-Jul-2007 19:54 PDT
Ryan, it would be kind of you to mention me in the CHANGELOG. Just add my name: Michael Osipov. Btw, I am planning to commit source too in the near future. I am quite excited about this wiki so my commitment is yet to come!
[Edit]

Changing LinkUtil#buildImageLinkHtml() method?

Moved from the Feedback page:

IMO the image class determination in the method LinkUtil#buildImageLinkHtml() should be changed to:

		if (frame || thumb || StringUtils.hasText(align)) {
			html += "<div class=\"";
			if (thumb || frame) {
				html += "imgthumb ";
			}
			if (align != null && align.equalsIgnoreCase("left")) {
				html += "imgleft ";
			} else if (align != null && align.equalsIgnoreCase("center")) {
				html += "imgcenter ";
			} else if (align != null && align.equalsIgnoreCase("right")) {
				html += "imgright ";
			} else {
				// default alignment
				html += "image "; 
			}
			html = html.trim() + "\">";
		}

At least, if there's no alignment defined in the Image tag, Wikipedia uses class "image".

It looks like you've investigated this issue, so feel free to commit a patch to trunk. Alternatively, if I get a chance I'll look into this a bit further and try to get something committed. Thanks! -- Ryan 19-Jul-2007 08:47 PDT
[Edit]

JNDI Datasource

Moved from the Feedback page:

Hi, i've found a problem in the handling of a JNDI datasource. The DatabaseConnection.testDatabase function does not undestand the JNDI url. I've produced a patch to this problem that you can found here testDatabase.patch -- mnencia 02-Jun-2007 10:13 PDT

Thanks for the patch! I'll see if I can get it integrated the next time I sit down to write code. The JDK 1.3 compatibility stuff shouldn't be necessary since JAMWiki requires JDK 1.4 or greater, but otherwise this looks good! -- Ryan 03-Jun-2007 11:09 PDT
The jdk 1.3 compatibility code is the same i've found in getConnection(), so I've included it because I think that testDatabase() function should have the same behavior of getConnection() -- mnencia 04-Jun-2007 08:25 PDT
Thanks for pointing that out - I suspect it's legacy code from the old Very Quick Wiki days. I'll integrate your patch as-is next chance I get, and will add a to-do item to remove any 1.3 compatibility stuff at some point in the future. Thanks again for the patch! -- Ryan 04-Jun-2007 08:47 PDT
[Edit]

Viewing the history of a deleted topic gives NPE

  1. Delete a topic.
  2. From Special:RecentChanges click on the history link for that topic.
  3. Try to view any version.
  4. NPE. 
    java.lang.NullPointerException
	at org.jamwiki.servlets.HistoryServlet.viewVersion(HistoryServlet.java:85)
	at org.jamwiki.servlets.HistoryServlet.handleJAMWikiRequest(HistoryServlet.java:47)
	at org.jamwiki.servlets.JAMWikiServlet.handleRequestInternal(JAMWikiServlet.java:74)

-- Ryan 05-Aug-2007 18:54 PDT

An appropriate error message has been added in Subversion for 0.6.0 - revision 1776. -- Ryan 05-Aug-2007 23:11 PDT
[Edit]

Character problem

I installed jamwiki on Tomcat 5.5.17 with a MySQL 5.0-DB. I'm using german characters like ü,ö,ä,ß.

Here's a little export from table jam_topic:

topic_name topic_content
Systemübersicht ä,ö,ü,ß

As you can see, the german characters in topic_content column look fine, but not in topic_name. There is an ü character instead the ü. It must be Systemübersicht and not Systemübersicht!

Any ideas why that happens?

Just to be sure, was your database was set up for UTF8 support using create database NAME character set UTF8, and have you added URIEncoding="UTF-8" to the Tomcat Connector descriptions as described on the Installation document? If both of those are true, what page encoding do you see (in your browser: View → Character Encoding)? -- Ryan 22-Aug-2006 10:32 PDT
Yes, i followed the instructions from the Installation document. To be sure i checked the settings in tomcats server.xml and created a new database. Character encoding in my browser shows UTF8. Than i did the same test case again, but the problem is still there. -- Norman 23-Aug-2006 09:20 GMT
OK, it's after midnight here now, but I'll do a round of testing with MySQL tomorrow morning to see if I can reproduce the problem. I normally use Postgres and am not as familiar with MySQL, but I can't think of any obvious reason why a VARCHAR column would have problems with non-ASCII characters while a TEXT column would not. One last question - do other non-ASCII characters in topic names cause this problem, or is just the ü character? -- Ryan 23-Aug-2006 00:38 PDT
I decided not to go to sleep yet. Using MySQL 4.1.20 and Tomcat 5.5.7 on a test machine I'm able to create a link like Systemübersicht, click on it, add text, and save the topic, and everything works as expected. It's possible that the "ü" you're entering is different from the one I copied and pasted - for example, Microsoft uses characters that aren't UTF-8 compatible, so copying and pasting from Word would cause errors. It could be another issue as well - I'm very willing to work with you to figure this out, but since I can't reproduce it I'd need the exact steps you're taking to get that value into the database - for example, are you creating a link in a page, clicking on it, and then saving the new topic, or is there some other way you create the topic? Any other information that might be relevant would also help in figuring this out. Sorry to not have a quick solution! -- Ryan 23-Aug-2006 01:02 PDT
Sorry for keeping you awake ;o). Here the steps to do:
- create a new database jamwikiTest
- click on StartingPoints
- click on edit page
- add > * \[\[TestüÜöÖäÄß\]\] underneath * \[\[StyleSheet\]\]
- save the page
- click on the new link TestüÜöÖäÄß
- now you should see on top of the page TestüÜöÖäÄß instead of TestüÜöÖäÄß.
- edit the new page and save it.
- now you should see in the database column topic_name of jam_topic-table Testü�ö�ä��
-- Norman 23-Aug-2006 10:24 GMT
Heading to bed now, but one last question - which version of JAMWiki are you using? Is it 0.2.1? -- Ryan 23-Aug-2006 01:32 PDT
Yes, i'm using 0.2.1. gn8 -- Norman 23-Aug-2006 10:51 GMT
(re-indenting) So from this description it looks like the topic name is getting mangled when it is added to a URL - the name should be getting escaped (http://jamwiki.org/wiki/en/Systemübersicht should be http://jamwiki.org/wiki/en/System%C3%BCbersicht) but for some reason it seems like it might not be. Some browsers may allow non-ISO-8859-1 in the URL bar, which could be the culprit, so I'll look into it. -- Ryan 23-Aug-2006 14:27 PDT

I think I've found a fix for this issue, and the new code is now running on jamwiki.org and will be included in JAMWiki 0.3.1 beta3. Once the new beta is available I'd be grateful if you would be willing to test the fix to see if the issue is resolved - please let me know if that's possible. -- Ryan 27-Aug-2006 00:16 PDT

JAMWiki 0.3.1 beta3 is now available at http://jamwiki.org/jamwiki-0.3.1-beta3.war. If you're willing, could you let me know if this release still has the bug? The standard caveats about not installing a beta in a production environment or on top of a working configuration apply. -- Ryan 27-Aug-2006 22:10 PDT
Hi Ryan. I checked the new version 0.3.2 of jamwiki. The problem is still there and even more worse ;o(.
Here's what i did:
- created a page called Systemübersicht
- edit the page Systemübersicht
- save the page
- a new row in the database is created. Under topic_name there ist "Systemübersicht" instead of "Systemübersicht".
- and now the new thing
- edit the page again.
- the old content is gone and the headline is "System�¼bersicht" insted of "Systemübersicht".
- store the page
- another new row in table jam_topic is created.
Every time i edit a page and store the changes, the result is that a new row in the database is created. Norman 30-Aug-2006 18:31 GMT
Shoot. The problem (I believe) is that when it reads the topic name from the URL the code assumes the "ISO-8859-1" character set, which (as I understand the standard) is what the value should be encoded as. However, cutting and pasting directly into Firefox I was able to reproduce your problem, but changing the encoding to "UTF-8" fixed it. It may be that for some reason it's reading the values in some other encoding, so I'll have to see if there's an easy way to figure out what encoding is being used and trying converting to that. Sorry this is taking so long to fix, but without being able to easily reproduce the problem (which I think would require using the same OS version and browser version as you are) it's difficult to do. -- Ryan 31-Aug-2006 22:51 PDT
I added a slight change for JAMWiki 0.3.3, but I don't think it's going to fix the problem for you. I'd like to figure out if the issue is with your browser or your server - could you let me know if you can see the article content after clicking on this link: Systemübersicht (content is "this is a test")? And can you click on this link and then edit & save some content: Systemübersicht Test? If one of those fails then I think the problem is with the browser, and I can research further. If both of those tests work then I suspect the problem is with the server, and in that case if you're willing can you email me your server.xml and web.xml files? My email address is removed. Sorry again for the problems, but since I can't reproduce the problem it's very difficult to track down. -- Ryan 01-Sep-2006 15:29 PDT
I suspect that this issue is the same as Bug Reports#Incorrect link for special characters. The problem seems to have been app-server specific, but a fix has been added to the Subversion repository for JAMWiki 0.6.0. -- Ryan 19-May-2007 17:35 PDT
I'm marking this one resolved. I saw the same problem with Tomcat 5.5 and have added a fix in revision 1477. If anyone encounters a similar problem please open a new bug report. -- Ryan 05-Aug-2007 23:27 PDT
[Edit]

Character problem II

The UTF-8 hex value for the percent sign (%) is 25. When trying to use a percent sign in a topic name, the system errors out. For example, try to go to http://jamwiki.org/wiki/en/Percent_50%25_test and it will have issues (while http://jamwiki.org/wiki/en/Ampersand_%26_test works fine). In my instance, this is the stack trace I get:

2006-09-18 12:39:46,236 [tcpConnection-14609-0] ERROR [JAMWikiServlet] Unable
to load topic value in JAMWikiServlet
java.lang.IllegalArgumentException: URLDecoder: Illegal hex characters in
escape (%) pattern - For input string: "_t"
        at java.net.URLDecoder.decode(URLDecoder.java:173)
        at org.jamwiki.utils.Utilities.decodeURL(Utilities.java:157)
        at org.jamwiki.servlets.JAMWikiServlet.getTopicFromURI(JAMWikiServlet.java:153)
        at org.jamwiki.servlets.JAMWikiServlet.loadDefaults(JAMWikiServlet.java:280)
        at org.jamwiki.servlets.JAMWikiServlet.viewError(JAMWikiServlet.java:385)
        at org.jamwiki.servlets.TopicServlet.handleRequestInternal(TopicServlet.java:58)

Try doing the same thing at wikipedia and it does work (http://en.wikipedia.org/wiki/Percent_50%25_test). -- scroco 18-Sep-2006 12:57 PDT

The request never reaches the application server, and shows up in the web server logs as HTTP 400, which is "400 - Bad Request: The request could not be understood by the server due to malformed syntax. The client SHOULD NOT repeat the request without modifications." It almost looks like a bug with Apache, but I'll dig around a bit. -- Ryan 18-Sep-2006 13:09 PDT
On second look it appears that it may be the redirect to the error page or something similar that fails in Apache. I think that the root problem is that the utility method to encodes and decodes topic names may be called more than once, and after decoding the percent sign it later tries to decode "%_t", which fails. I got the message "The error message is: URLDecoder: Illegal hex characters in escape (%) pattern - For input string: "_t"." while trying to create an edit URL for the topic. I'll look into it and try to get a fix out, thanks for the report. -- Ryan 18-Sep-2006 13:19 PDT
I think it's fixed now (see Topic name with a % sign in it). Since request.getParameter() automatically decodes values, the JAMWiki Utilities.decodeURL() method was inappropriate for values that weren't retrieved using request.getURI(). I've added a new decodeFromRequest() method and it seems to have solved the problem, although I'll have to do more testing to make sure I didn't break anything in the process. The final fix will be in the next release - thanks for the bug report. -- Ryan 18-Sep-2006 16:08 PDT
Never mind, I can now create and edit the topic, but viewing it is apparently busted. Give me a bit longer... -- Ryan 18-Sep-2006 16:09 PDT

While working on this can you also test and verify for %22 (quotation mark)? -- scroco 18-Sep-2006 17:11 PDT

Quotation marks are currently disabled in topic names, but I'll look into re-allowing them. As to the % sign, the remaining problem looks like Apache to me - Wikitravel has the same problem (see http://wikitravel.org/en/Topic_name_with_a_%25_sign_in_it). I'm digging around looking for a solution, but haven't found one thus far. If anyone else has experience with this issue any help would be appreciated. -- Ryan 18-Sep-2006 21:57 PDT
The new beta (0.3.4 beta6) is less restrictive for topic names. As to the % issue, the error I'm currently getting looks like it may be coming from mod_jk. The specific message is the following:
[Mon Sep 18 16:13:29 2006] [info] jk_handler::mod_jk.c (1853): No body with status=400 for worker=worker1
Apache shows the following:
localhost - - [18/Sep/2006:16:13:29 -0700] "GET /wiki/en/link_with_%25_sign HTTP/1.1" 400 440 "http://127.0.0.1:81/wiki/en/Special:RecentChanges" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1) Gecko/20060917 BonEcho/2.0"
There's no indication that I can see that the request ever makes it to Tomcat. If anyone has any suggestions or ideas I'd be interested. -- Ryan 19-Sep-2006 00:45 PDT

Once I get that new functionality into my installation, I'll check it out and see if I have any ideas. What version of apache are you running? -- scroco 19-Sep-2006 10:27 PDT

I get error reports both on my Windows and Linux boxes - Apache 2.0.55 and 1.3.33 respectively. I can view URLs with %25 in them that are NOT Tomcat URLs, so I suspect that it's a mod_jk issue, but need to investigate further. Again, if you have any ideas I'd be grateful. -- Ryan 19-Sep-2006 10:34 PDT
... and Resin seems to work fine, so this is definitely Tomcat-specific. -- Ryan 19-Sep-2006 10:50 PDT
Well, that's good news for me. -- scroco 19-Sep-2006 11:36 PDT
This issue does not occur with later versions of Apache / Tomcat, so it does not appear to be a JAMWiki issue. Marking as resolved. -- Ryan 05-Aug-2007 23:27 PDT
[Edit]

web.xml erros leading to GlassFish Issue as well as RAD/WebSphere Issues

JAMWiki 0.5.4 is having an issue deploying on GlassFish v1. The previous version (JAMWiki 0.5.3) deploys fine. Here's the deployment error on JAMWiki 0.5.4:

Deploying application in domain failed; Error loading deployment descriptors for module [jamwiki-0] Line 1 Column 1 -- Deployment descriptor file WEB-INF/web.xml in archive [jamwiki-0]. Content is not allowed in prolog. Error loading deployment descriptors for module [jamwiki-0] Line 1 Column 1 -- Deployment descriptor file WEB-INF/web.xml in archive [jamwiki-0]. Content is not allowed in prolog.

Strange - the web.xml file changed slightly due to a failure deploying with Debian Etch, and I didn't test it as thoroughly as I probably should have. If you change the beginning of the new web.xml to the following, will it deploy properly?

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN" "http://java.sun.com/dtd/web-app_2_3.dtd">
<web-app>
-- Ryan 12-May-2007 10:33 PDT

It is working now. I changed the "web-app xmlns" to:


<web-app xmlns="http://java.sun.com/xml/ns/j2ee"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"
         version="2.4">

--amerigo5 12-May-2007 13:05 PDT

Thanks! Provided there aren't issues with other app servers I'll push this fix out for the next release. -- Ryan 12-May-2007 13:34 PDT

Unfortunately, if you use the schema declaration, you also need to wrap the taglib elements into a jsp-config element. -- Cay Horstmann, 29-May-2007 09:04 PDT

Now I can deploy, but I run into another issue. When I try to launch for the first time, I get a exception java.lang.NoClassDefFoundError org/apache/tools/ant/BuildListener. This is with the GlassFish package on Ubuntu 7.04. -- Cay Horstmann, 29-May-2007 09:15 PDT

Thanks for the report - I'll try to remember to download GlassFish to investigate, although if you find a solution please let me know! -- Ryan 30-May-2007 22:38 PDT

Same errors in the web.xml as described above (additional space in the schemalocation, missing jsp-config element surrounding the taglib elements) also create problems for IBM Rational Application Developer 7.0 (web.xml does not validate when running XML validation) and IBM WebSphere Application Server 6.1 (deployment fails) -- Carsten Seiffert 02-Jul-2007 07:05 PDT

If you're willing to help test, could you try the latest Subversion web.xml file (available here) and let me know if that works? Thanks! -- Ryan 02-Jul-2007 21:11 PDT
Never mind, having just re-read your comments I see that additional changes need to be made. If you get a version working and are willing to contribute it back to the project it would be much appreciated, otherwise I'll revisit this issue in the future when I have time to test with different app servers. -- Ryan 02-Jul-2007 21:13 PDT
No probs - the following web.xml works for me (the only changes compared to the 0.5.4 download are: removed superfluous space from namespace URL, added missing jsp-config element): -- Carsten Seiffert 03-Jul-2007 01:10 PDT

<?xml version="1.0" encoding="ISO-8859-1"?>

<web-app xmlns="http://java.sun.com/xml/ns/j2ee"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"
         version="2.4">
    <!--
	NOTE: do not use the context-param element to initialize the
	ApplicationResources resource bundle here due to a bug in the JSTL and
	Tomcat4 that causes response encoding to be finalized and thus prevents
	setting page encoding to UTF-8.  Instead, load the resource bundle in
	page-init.jsp.
	-->

	<context-param>
		<param-name>contextConfigLocation</param-name>
		<param-value>/WEB-INF/applicationContext-acegi-security.xml</param-value>
	</context-param>

	<!-- set encoding, cache headers, etc. -->
	<filter>
		<filter-name>JAMWikiFilter</filter-name>
		<filter-class>org.jamwiki.servlets.JAMWikiFilter</filter-class>
		<init-param>
			<param-name>encoding</param-name>
			<param-value>UTF-8</param-value>
		</init-param>
	</filter>
	<filter>
		<filter-name>Acegi Filter Chain Proxy</filter-name>
		<filter-class>org.acegisecurity.util.FilterToBeanProxy</filter-class>
		<init-param>
			<param-name>targetClass</param-name>
			<param-value>org.acegisecurity.util.FilterChainProxy</param-value>
		</init-param>
	</filter>
	<filter-mapping>
		<filter-name>JAMWikiFilter</filter-name>
		<url-pattern>/*</url-pattern>
	</filter-mapping>
	<filter-mapping>
		<filter-name>Acegi Filter Chain Proxy</filter-name>
		<url-pattern>/*</url-pattern>
	</filter-mapping>

	<listener>
		<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
	</listener>

	<servlet>
		<servlet-name>jamwiki</servlet-name>
		<servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
		<load-on-startup>1</load-on-startup>
	</servlet>

	<servlet-mapping>
		<servlet-name>jamwiki</servlet-name>
		<url-pattern>/en/*</url-pattern>
	</servlet-mapping>
	<!-- virtual wiki mapping(s) -->
	<servlet-mapping>
		<servlet-name>jamwiki</servlet-name>
		<url-pattern>/test/*</url-pattern>
	</servlet-mapping>

	<welcome-file-list>
		<welcome-file>index.jsp</welcome-file>
	</welcome-file-list>

	<jsp-config>
		<taglib>
			<taglib-uri>http://java.sun.com/jsp/jstl/core</taglib-uri>
			<taglib-location>/WEB-INF/c-rt.tld</taglib-location>
		</taglib>
		<taglib>
			<taglib-uri>http://java.sun.com/jstl/fmt</taglib-uri>
			<taglib-location>/WEB-INF/fmt-rt.tld</taglib-location>
		</taglib>
		<taglib>
			<taglib-uri>http://jamwiki.org/taglib</taglib-uri>
			<taglib-location>/WEB-INF/jamwiki.tld</taglib-location>
		</taglib>
		<taglib>
			<taglib-uri>http://acegisecurity.org/authz</taglib-uri>
			<taglib-location>/WEB-INF/authz.tld</taglib-location>
		</taglib>
	</jsp-config>

</web-app>
Fix added to Subversion as revision 1512. -- Ryan 05-Aug-2007 23:36 PDT
[Edit]

Incorrect link for special characters

Link mit üöä und Ä can not be edited correctly. -- Ryan 14-May-2007 10:17 PDT

See also ვეპხის. Note that things seem to be broken on my local box as well, meaning I've screwed something up in a recent release since this worked fine earlier... -- Ryan 15-May-2007 23:37 PDT
Just a note to say that I don't have time to investigate this issue tonight, but if anyone would like to help fix this problem it would be helpful to know exactly when the problem started occurring. If you're running any JAMWiki version starting with 0.4.0 up through 0.5.4, please let me know if you are or are not seeing this issue on your local installation. To do so, simply copy either of the topic names in this bug report into a topic in your wiki, and then click on the link to see if it is correctly editable. Thanks! -- Ryan 16-May-2007 21:26 PDT
I think this is fixed now in Subversion, although I'd like to get more testing. It appears that this bug has been around for a while, which is surprising as I would have expected to have received bug reports. If anyone has been able to successfully edit topics containing non-ASCII characters during the 0.5.x release cycle please let me know what version of JAMWiki you were using. -- Ryan 19-May-2007 11:16 PDT
People edited non-ASCII topics on jamwiki.org as recently as mid-April, however when I attempted to do so with version 0.5.0 on my local laptop it failed, which leads me to believe that this is a bug that affects only certain app servers (jamwiki.org was upgraded to Tomcat 5.5 in April). The new code will hopefully be more robust, and should address a few of the lingering bug reports for non-ASCII character issues. -- Ryan 19-May-2007 17:35 PDT
Fix added to Subversion as revision 1477. -- Ryan 05-Aug-2007 23:36 PDT
[Edit]

Oracle Installation Problem - root cause identified

JAMWiki 0.5.4 with corrected web.xml (see above), AppServer: WebSphere 6.1.0.2, DB: Oracle 10g XE, driver: oracle.jdbc.driver.OracleDriver

Just as User:bensayers, I am running into error "Failure while executing insert into jam_topic_version ( topic_version_id, topic_id, edit_comment, version_content, wiki_user_id, edit_type, wiki_user_ip_address, edit_date, previous_topic_version_id ) values ( ?, ?, ?, ?, ?, ?, ?, ?, ? )." when configuring JAMWiki to use Oracle as an external database. When looking into the app server log, I find the following messages below:


[7/4/07 17:33:06:844 CEST] 00000029 DatabaseConne W   Rolling back database transactions
[7/4/07 17:33:06:875 CEST] 00000029 DatabaseConne W   Rolling back database transactions
[7/4/07 17:33:07:047 CEST] 00000029 SetupServlet  E   Setup error
                                 java.lang.Exception: Failure while executing insert into jam_topic_version
 ( topic_version_id, topic_id, edit_comment, version_content, wiki_user_id, edit_type, wiki_user_ip_address, edit_date,
 previous_topic_version_id ) values ( ?, ?, ?, ?, ?, ?, ?, ?, ? )
	at org.jamwiki.db.WikiPreparedStatement.executeUpdate(WikiPreparedStatement.java:119)
	at org.jamwiki.db.AnsiQueryHandler.insertTopicVersion(AnsiQueryHandler.java:534)
	at org.jamwiki.db.AnsiDataHandler.addTopicVersion(AnsiDataHandler.java:106)
	at org.jamwiki.db.AnsiDataHandler.writeTopic(AnsiDataHandler.java:1239)
	at org.jamwiki.db.WikiDatabase.setupSpecialPage(WikiDatabase.java:249)
	at org.jamwiki.db.WikiDatabase.setupSpecialPages(WikiDatabase.java:263)
	at org.jamwiki.db.WikiDatabase.setup(WikiDatabase.java:180)
	at org.jamwiki.db.AnsiDataHandler.setup(AnsiDataHandler.java:1081)
	at org.jamwiki.WikiBase.reset(WikiBase.java:184)
	at org.jamwiki.servlets.SetupServlet.initialize(SetupServlet.java:138)
	at org.jamwiki.servlets.SetupServlet.handleJAMWikiRequest(SetupServlet.java:72)
	at org.jamwiki.servlets.JAMWikiServlet.handleRequestInternal(JAMWikiServlet.java:74)
	at org.springframework.web.servlet.mvc.AbstractController.handleRequest(AbstractController.java:153)
	at org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter.handle(SimpleControllerHandlerAdapter.java:48)
	at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:839)
	at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:774)
	at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:460)
	at org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:425)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:763)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
	at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:972)
	at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:907)
	at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:145)
	at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:264)
	at org.acegisecurity.intercept.web.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:107)
	at org.acegisecurity.intercept.web.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:72)
	at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
	at org.acegisecurity.ui.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:110)
	at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
	at org.acegisecurity.providers.anonymous.AnonymousProcessingFilter.doFilter(AnonymousProcessingFilter.java:125)
	at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
	at org.acegisecurity.ui.rememberme.RememberMeProcessingFilter.doFilter(RememberMeProcessingFilter.java:142)
	at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
	at org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:217)
	at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
	at org.acegisecurity.ui.logout.LogoutFilter.doFilter(LogoutFilter.java:106)
	at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
	at org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:229)
	at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
	at org.acegisecurity.util.FilterChainProxy.doFilter(FilterChainProxy.java:148)
	at org.acegisecurity.util.FilterToBeanProxy.doFilter(FilterToBeanProxy.java:98)
	at com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.doFilter(FilterInstanceWrapper.java:190)
	at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:130)
	at org.jamwiki.servlets.JAMWikiFilter.doFilter(JAMWikiFilter.java:58)
	at com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.doFilter(FilterInstanceWrapper.java:190)
	at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:130)
	at com.ibm.ws.webcontainer.filter.WebAppFilterChain._doFilter(WebAppFilterChain.java:87)
	at com.ibm.ws.webcontainer.filter.WebAppFilterManager.doFilter(WebAppFilterManager.java:701)
	at com.ibm.ws.webcontainer.filter.WebAppFilterManager.doFilter(WebAppFilterManager.java:646)
	at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:475)
	at com.ibm.ws.wswebcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:463)
	at com.ibm.ws.webcontainer.servlet.CacheServletWrapper.handleRequest(CacheServletWrapper.java:92)
	at com.ibm.ws.webcontainer.WebContainer.handleRequest(WebContainer.java:744)
	at com.ibm.ws.wswebcontainer.WebContainer.handleRequest(WebContainer.java:1433)
	at com.ibm.ws.webcontainer.channel.WCChannelLink.ready(WCChannelLink.java:93)
	at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleDiscrimination(HttpInboundLink.java:465)
	at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleNewInformation(HttpInboundLink.java:394)
	at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.ready(HttpInboundLink.java:290)
	at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.sendToDiscriminators(NewConnectionInitialReadCallback.java:214)
	at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.complete(NewConnectionInitialReadCallback.java:113)
	at com.ibm.ws.tcp.channel.impl.AioReadCompletionListener.futureCompleted(AioReadCompletionListener.java:152)
	at com.ibm.io.async.AbstractAsyncFuture.invokeCallback(AbstractAsyncFuture.java:213)
	at com.ibm.io.async.AbstractAsyncFuture.fireCompletionActions(AbstractAsyncFuture.java:195)
	at com.ibm.io.async.AsyncFuture.completed(AsyncFuture.java:136)
	at com.ibm.io.async.ResultHandler.complete(ResultHandler.java:194)
	at com.ibm.io.async.ResultHandler.runEventProcessingLoop(ResultHandler.java:741)
	at com.ibm.io.async.ResultHandler$2.run(ResultHandler.java:863)
	at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1510)
Caused by: java.sql.SQLException: Data size bigger than max size for this type: 7624
	at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:134)
	at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:179)
	at oracle.jdbc.ttc7.TTCItem.setArrayData(TTCItem.java:147)
	at oracle.jdbc.dbaccess.DBDataSetImpl.setBytesBindItem(DBDataSetImpl.java:2492)
	at oracle.jdbc.driver.OraclePreparedStatement.setItem(OraclePreparedStatement.java:1194)
	at oracle.jdbc.driver.OraclePreparedStatement.setString(OraclePreparedStatement.java:1614)
	at org.apache.commons.dbcp.DelegatingPreparedStatement.setString(DelegatingPreparedStatement.java:132)
	at org.jamwiki.db.WikiPreparedStatement.loadStatement(WikiPreparedStatement.java:143)
	at org.jamwiki.db.WikiPreparedStatement.executeUpdate(WikiPreparedStatement.java:110)
	... 67 more

10 tables have been created successfully, but the "Data size bigger than max size for this type" looks like being the root cause. Does this help to identify the problem? -- Carsten Seiffert 04-Jul-2007 08:36 PDT

Weird - I just installed JAMWiki on Oracle at work the other day without incident. Just to verify, when you installed you selected database type "Oracle", right? Oracle needs the version_content column to be a CLOB rather than a TEXT field to avoid issues with content size. If that's not the issue then I'll need to investigate further. Thanks for the report! -- Ryan 04-Jul-2007 10:22 PDT
I found it when debugging - the ojdbc14.jar installed on the Application Server was outdated (I had not been aware of that). Oracle's version 9 driver has a limitation of 4k for CLOB size - using the 10g driver instead did fix it, everything works now. -- Carsten Seiffert 05-Jul-2007 02:00 PDT
Thanks for taking the time to debug & then update the Supported Configurations page. Hopefully in the near future everyone will have upgraded to the latest & greatest Oracle version and this type of issue won't crop up as frequently. -- Ryan 05-Jul-2007 20:04 PDT
[Edit]

Page with no content causes errors

It is possible to create a new page with no content. This page will then throw a NPE when it is diffed or any attempt is made to edit it. I believe the problem is due to the fact that a new version is not created if a page has not changed or has no content, but that rule should be ignored when a page is first being created. -- Ryan 26-Jul-2007 11:13 PDT

This issue may be Oracle specific - I'm unable to reproduce it on an installation running Postgres with the latest 0.6.0 code. -- Ryan 26-Jul-2007 19:11 PDT
Stack trace when doing a diff against the new topic: 
2007-07-27 09:00:34,989 SEVERE: org.jamwiki.db.AnsiDataHandler - No versions found for 543 against 0
2007-07-27 09:00:34,989 SEVERE: org.jamwiki.servlets.ServletUtil - Servlet error
java.lang.Exception: No versions found for 543 against 0
	at org.jamwiki.db.AnsiDataHandler.diff(AnsiDataHandler.java:401)
	at org.jamwiki.servlets.DiffServlet.diff(DiffServlet.java:83)
	at org.jamwiki.servlets.DiffServlet.handleJAMWikiRequest(DiffServlet.java:42)
	at org.jamwiki.servlets.JAMWikiServlet.handleRequestInternal(JAMWikiServlet.java:74)
Stack trace when trying to save an edit of the new topic: 
2007-07-27 09:02:00,333 SEVERE: org.jamwiki.servlets.ServletUtil - Servlet error
java.lang.NullPointerException
	at org.jamwiki.servlets.EditServlet.save(EditServlet.java:281)
	at org.jamwiki.servlets.EditServlet.handleJAMWikiRequest(EditServlet.java:59)
	at org.jamwiki.servlets.JAMWikiServlet.handleRequestInternal(JAMWikiServlet.java:74)
-- Ryan 27-Jul-2007 08:42 PDT
Oracle converts empty strings to null values, which seems to have been the cause of the problem. An ugly hack has been implemented in revision 1782 so that if a topic is retrieved and the topic content is null it will be automatically converted to an empty string. -- Ryan 11-Aug-2007 10:40 PDT
[Edit]

Indentation spacing

Is there supposed to be a clear line above all indentations, the way there is following no indentation? Or is there not supposed to be a blank line following no indentation.

Regular/none indentation

Single indentation, will have blank line above
Double indentation, will NOT have blank line above
Triple indentation, will NOT have blank line above

Regular/none indentation

Double indentation, after regular, will have a blank line

Regular/none indentation

Triple indentation, after regular, will have a blank line
Single indentation, following triple, half-height blank line
Single indentation, no blank line
Double indentation, no blank line
Double indentation, no blank line

Just a note to say I didn't miss this one, but since it doesn't seem critical I was planning on pushing it to the next release. My guess is that the problem is the paragraph parser again, which has been an ongoing battle. -- Ryan 16-Aug-2006 16:09 PDT

Looks like this is CSS - the HTML generated seems to be the same as what Mediawiki is generating. I've updated the default JAMWiki stylesheet to more closely conform to this list tag parsing, let me know if it helps. -- Ryan 22-Aug-2006 16:39 PDT
This issue seems to have been resolved by revision 1778. -- Ryan 11-Aug-2007 12:12 PDT
[Edit]

MessageDigest problem

I'm trying to install jamwiki on a server which runs jrun4. Having navigated to the page, filled it out and clicked "save changes" the page reloads with the following error at the top:

"An unknown system error has occurred. The error message is: SHA-512 MessageDigest not available."

Any ideas??

http://www.adobe.com/products/jrun/ indicates that JRun 4 is JDK 1.3 compatible, and JAMWiki requires JDK 1.4 or greater. The error you received is due to the fact that JAMWiki stores passwords encrypted using the SHA-512 algorithm, which according to http://java.sun.com/j2se/1.4.2/docs/guide/security/CryptoSpec.html#AppA should be a part of JDK 1.4. I suspect that a check should probably be added to JAMWiki to verify that the JDK is 1.4 or greater - sorry it won't work for you, but thanks for the report! -- Ryan 01-Dec-2006 02:25 PST
I'm getting the exact same error with JDK 1.4.1_02-b06. Some quick googling seems to suggest that SHA-512 was introduced with JDK 1.4.2, which , if true, leads me to the conclusion that JAMWiki in fact requires JDK 1.4.2 or above, not just 1.4 or above, as indicated on Installation. Couldn't there be a fallback for JDK 1.4.0/1.4.1? -- 77.57.12.10 12-Jun-2007 07:50 PDT
Thanks for pointing this out. I'll add a fallback to JAMWiki 0.6.0 unless someone else submits a patch first (hint to developers out there!) -- Ryan 12-Jun-2007 09:05 PDT
This does the trick for me. Please review carefully, though, I'm by no means an expert. -- Luzi 77.57.12.10 12-Jun-2007 14:51 PDT
Thanks for the time you've spent investigating, it's very much appreciated! I'll take a closer look at the linked solution and make sure that it or something similar is included in the next release. -- Ryan 12-Jun-2007 22:35 PDT
I've committed this to Subversion with only one addition to the patch you provided. If someone is using a JDK that does not support the SHA-512 algorithm and then later upgrades, their existing user passwords would be unavailable since the code would then try to use the SHA-512 algorithm. To work around that issue the code will now save a property value with the encryption algorithm, so that even if the JDK is upgraded the old algorithm can still be used and the old passwords can still be validated against. Thanks again for the patch, and let me know if you want a credit in the CREDITS.txt file - I'd just need to know what name to credit you with (typically something like "Ryan Holliday (wrh2)"). -- Ryan 20-Jun-2007 22:10 PDT
Nice to see this getting fixed! The contribution is hardly large enough to deserve being credited, but just in case, the name is "Luzius Thöny (luzi)". -- 77.57.12.10 28-Jun-2007 09:04 PDT
Resolved in revision 1498. -- Ryan 11-Aug-2007 12:25 PDT
[Edit]

Another Oracle NPE

Oracle's "can't save an empty string" issue cropped up again...

2007-08-30 16:16:49,507 SEVERE: org.jamwiki.servlets.ServletUtil - Servlet error
java.lang.NullPointerException
            at org.jamwiki.servlets.EditServlet.save(EditServlet.java:285)
            at org.jamwiki.servlets.EditServlet.handleJAMWikiRequest(EditServlet.java:59)
            at org.jamwiki.servlets.JAMWikiServlet.handleRequestInternal(JAMWikiServlet.java:74)
            at org.springframework.web.servlet.mvc.AbstractController.handleRequest(AbstractController.java:153)
            at org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter.handle(SimpleControllerHandlerAdapter.java:48)
            at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:857)
            at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:792)

-- Ryan 31-Aug-2007 11:17 PDT

Resolved by revision 1820. -- Ryan 02-Sep-2007 23:13 PDT
[Edit]

link problem with identical link names

Create a document with some headlines, such that an outline is created. If two headlines carry the same name, the link from the outline always only navigates to the first headline.

This should be resolved by revision 1836. -- Ryan 10-Sep-2007 23:35 PDT
[Edit]

Internal links and toc

Something like ==== [[page header|text]] ==== leads to a page header|text entry in the toc, the body appearance is o.k. I think that's not what one expects to happen... ;) -- fmr 07-May-2007 10:11 PDT

This should be resolved by revision 1846 and will be included in the next release. Note that the code isn't yet on jamwiki.org, but will be copied over in the next day or two. -- Ryan 16-Sep-2007 22:20 PDT
[Edit]

Upload File Spam

Anonymous users can upload files even if anonymous posting is not allowed. It is causing lots of spam in my wiki page. This is a critical issue IMO.

JAMWiki 0.6.0 allows uploading to be restricted to specific users. In the mean time have a look at the upload blacklist / whitelist settings in Special:Admin - eliminating html uploads got rid of the vast majority of spam on jamwiki.org. -- Ryan 31-Aug-2007 10:04 PDT
[Edit]

Upgrade to 0.6.0 not working

Archived from the Feedback page:

After I followed the upgrade procedure (as I have done in previous versions) I get the following error message:

org.apache.jasper.JasperException: This absolute uri (http://java.sun.com/jsp/jstl/core) cannot be resolved in either web.xml or the jar files deployed with this application
	at org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:60)
	at org.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java:385)
	at org.apache.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java:109)
	at org.apache.jasper.compiler.TagLibraryInfoImpl.<init>(TagLibraryInfoImpl.java:116)
	at org.apache.jasper.compiler.Parser.parseTaglibDirective(Parser.java:312)
	at org.apache.jasper.compiler.Parser.parseDirective(Parser.java:339)
	at org.apache.jasper.compiler.Parser.parseElements(Parser.java:749)
	at org.apache.jasper.compiler.Parser.parse(Parser.java:77)
	at org.apache.jasper.compiler.ParserController.parse(ParserController.java:159)
	at org.apache.jasper.compiler.ParserController.parse(ParserController.java:111)
	at org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:185)
	at org.apache.jasper.compiler.Compiler.compile(Compiler.java:355)
	at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:427)
	at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:142)
	at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:240)
	at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:187)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:809)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:198)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:144)
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:209)
	at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:595)
	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:432)
	at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:954)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:138)
	at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:595)
	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:432)
	at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:954)
	at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2459)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:132)
	at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:595)
	at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:118)
	at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:593)
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:116)
	at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:593)
	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:432)
	at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:954)
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:126)
	at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:595)
	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:432)
	at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:954)
	at org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:152)
	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
	at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
	at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
	at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
	at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
	at java.lang.Thread.run(Unknown Source)

normally I should see a textbox tp typ my usernae and password for the database upgrade! I'm working with Tomcat version 4.1.34 and JDK 1.5 together with MSSQL

Can anyone help me with this problem?

I'm not sure if this will solve the problem, but two things to check: first, have you made any modifications to the web.xml file? If so, make sure that the taglib definitions include the URI above for the JSTL core library. Second, is it possible that Tomcat is using cached files? You can get rid of any cached JSPs by deleting the contents of the tomcat/work/ directory. Hopefully one of those will help, if not I'll need to investigate further. Thanks for the report! -- Ryan 26-Sep-2007 07:38 PDT

I didn't made any changes to the web.xml file. Just using the one enclosed in de war-file. Deleted the cached files as you sugested but did't made any difference. I'm upgrading from version 0.5.3 i'm skipping a version, could that be a problem? --Angel 27-Sep-2007 00:14 PDT

I have upgrade my Tomcat installation to version 5.x and jdk 1.5. This seems to work. Only have some trouble updating my tables.

Automatic update of my database doesn't work. Manually it work until the last Query :

              INSERT into jam_role_map (role_name, wiki_user_id)
                   select 'ROLE_ADMIN', wiki_user_id
                   from ictwiki.jam_wiki_user where is_admin = 1;
              INSERT into jam_role_map (role_name, wiki_user_id)
                   select 'ROLE_DELETE', wiki_user_id
                   from ictwiki.jam_wiki_user where is_admin = 1;
              INSERT into jam_role_map (role_name, wiki_user_id)
                   select 'ROLE_SYSADMIN', wiki_user_id
                   from ictwiki.jam_wiki_user where is_admin = 1;
              INSERT into jam_role_map (role_name, wiki_user_id)
                   select 'ROLE_TRANSLATE', wiki_user_id
                   from ictwiki.jam_wiki_user where is_admin = 1;
              ALTER TABLE ictwiki.jam_wiki_user DROP COLUMN is_admin;

This give me the following error :


(1 row(s) affected)

Server: Msg 547, Level 16, State 1, Line 4
INSERT statement conflicted with COLUMN FOREIGN KEY constraint 'jam_fk_role_map_role'. The conflict occurred in database 'wiki', table 'jam_role', column 'role_name'.
The statement has been terminated.

(1 row(s) affected)


(1 row(s) affected)

Server: Msg 5074, Level 16, State 1, Line 13
The object 'DF__jam_wiki___is_ad__7D78A4E7' is dependent on column 'is_admin'.
Server: Msg 4922, Level 16, State 1, Line 13
ALTER TABLE DROP COLUMN is_admin failed because one or more objects access this column.

Got it working again. updated my database manually, but had to alter the given statements slightly. --Angel 28-Sep-2007 05:02 PDT

Glad it's working for you - if there are any errors and you're willing to submit a patch it would be gladly accepted :) Sorry I couldn't provide more help in debugging, but I've been buried in work the past two weeks. -- Ryan 28-Sep-2007 07:22 PDT

Since I fixed most problems manually. I'm unable to give a patch. I can give you a detailed description on what I had to do to get it all working again. Let me know if you want that. --Angel 01-Oct-2007 02:29 PDT

If it's something that would be helpful to others then feel free to provide more info, but it sounds like this was a custom solution that worked just for you. I've been giving some thought to improving the upgrade process, since it seems like that's where the majority of the bug reports come from, so hopefully the next major release will go a bit smoother. -- Ryan 01-Oct-2007 23:26 PDT
[Edit]

Including images

Archived from the Feedback page:

Is there a possibility to include images without being links to their original upload files? I just want to get rid of the dotted line below images... -- Frank 11-Sep-2007 03:09 PDT

Presently no. I've been following Mediawiki's lead on wiki syntax, and I don't think that they offer that functionality. However, there shouldn't be any decoration for images - if there is it's possible the CSS that's implemented in the StyleSheet topic is wrong. What browser are you using, and do you see lines under the images on this page? -- Ryan 11-Sep-2007 22:19 PDT
I'm using Firefox 2.0 in a Linux box. And, there are no dotted lines under the images on the Parser Test page. What do I have to do? -- Frank 12-Sep-2007 05:09 PDT
CSS for a site is controlled using the StyleSheet topic. jamwiki.org runs the default StyleSheet for JAMWiki, and upgrades automatically upgrade the stylesheet using the file that can be found in /WEB-INF/classes/pages/StyleSheet.txt. If you paste the contents into the StyleSheet topic for your site then the CSS should match that of jamwiki.org, and the lines under images should go away. Note that if you've customized the CSS for your site then you'll need to re-update that file with your customizations after copying the default styles. -- Ryan 12-Sep-2007 08:00 PDT
You're right! Upgrading to 0.6.0 made those lines disappear..... and my CSS customizations alike. One more for the upgrade todo list. ;) -- Frank 13-Sep-2007 02:25 PDT
In order to fix the problem with people losing CSS customizations during upgrades I'll probably need to split the stylesheet into a system stylesheet that can't be modified and a customizable stylesheet. A side benefit of that approach is that it would allow people to start developing JAMWiki skins, which I suspect would be a popular feature. In the mean time the hope was that since the stylesheet is a wiki topic it would be easy enough to see what changed during an upgrade and to restore an old version if necessary. Sorry about any trouble! -- Ryan 14-Sep-2007 06:29 PDT
[Edit]

Upgrade problems

Archived from the Feedback page:

Tried to switch to 0.6.0. Running tomcat5 on a opensuse10.2 box I stopped tomcat and moved the jamwiki dir to a save plave (upload and system dirs are underneath). Then I replaced jamwiki.war with the new .war file. Restarting tomcat and browsing the JW URL brings up the JW setup page and creates the JW dir (shouldn't that happen immediately after starting tomcat without browsing the URL?). Now I copied dirs system and upload to their appropriate places and the .properties files specified in the Upgrade section. Restarting tomcat and browsing the URL brings up a virginal JW, though dirs system and upload contain the old files. Any suggestions? -- fmr 05-Sep-2007 07:59 PDT

Upgrades are a bit trickier than installs - see Installation#Upgrades. At present it's necessary to deploy the war file as an exploded war, and additionally you'll want to re-use your existing jamwiki.properties file so that you don't lose database settings, wiki preferences, etc. Hopefully that helps! -- Ryan 05-Sep-2007 08:21 PDT
After RTFM (-> Upgrade.txt) I tried to create the tables like delineated. Executing 
java -jar /usr/share/java/hsqldb.jar --sql "CREATE TABLE jam_role ( role_name VARCHAR(30) NOT NULL, role_description VARCHAR(200),
CONSTRAINT jam_pk_role PRIMARY KEY (role_name), CONSTRAINT jam_unique_role_name UNIQUE (role_name) );" jamwiki
seems to work w/o error (no message), but trying to create jam_role_map referencing the other tables induces an error message telling that jam_role does not exist. That links to the hsql problem depicted above that one can browse data but can not manipulate the database that way. -- fmr 07-Sep-2007 04:04 PDT
I'm the first to admit that the JAMWiki documentation isn't as good as it needs to be,
Did I blame JWs documentation? Wouldn't dare.... ;) ... and didn't.
but just to clarify - did the automatic upgrade process (ie deploy the new WAR,
Deliberately you did not mention removing the old WAR and the associated JW directory, did you? This should work by only deploying the new WAR? Acting that way nothing happens to my JW installation, browsing the wiki delivers everything like it was before, considering the other steps you mentioned.
copy the old properties file, view a wiki page - which redirects to the upgrade page - and then let the upgrade happen automatically) not work? The manual instructions in UPGRADE.txt should only be needed if the automatic upgrade fails.
I thought that was how far we got after your first reply........ ;)
That said, it looks like I need to set up a way to interact with HSQL when installed as the internal JAMWiki database. I'll see what I can come up with. -- Ryan 07-Sep-2007 07:35 PDT
In any case interaction with HSQL is an interesting issue. -- fmr 07-Sep-2007 07:55 PDT
Upgrades should be easy, so my comments about potential improvements to the documentation were more meant as self-criticism than in reference to anything you've said :) I'll have to try a Tomcat deployment using just the WAR file to see if I can reproduce your issue - there are known issues when installing or upgrading from a WAR file that isn't exploded, and I haven't actually tried it on Tomcat yet, so I'll see if I can figure anything out. Apologies for the troubles, and thanks for helping out by providing feedback. -- Ryan 07-Sep-2007 09:15 PDT
I just copied a JW backup to my linux box to try out again... and oops, it worked! Becoming audacious I did it again on our server. The difference between my box and the server was, the latter ignored the new WAR file (the first time I deployed the JW WAR it took only seconds to auto-explode). I had to extract/explode the WAR manually, but after that everything looks fine. -- Frank 12-Sep-2007 04:21 PDT
[Edit]

ROLE_VIEW Problem

JAMWiki Version 0.6.0

I unchecked ROLE_VIEW for GROUP_ANONYMOUS in Role view. After that the login page was not formated (no css) and when I tried to login the browser redirected me to the JAMWiki logo. Anyone else with this problem?

Wow, weird. I can confirm that I'm seeing that issue as well and will try to get a fix ready today. Thanks for the bug report. -- Ryan 21-Oct-2007 09:47 PDT
I think I've found the problem - try modifying your /WEB-INF/applicationContext-acegi-security.xml file to add a pattern for /**/*.css and /images/** as shown in the example below:
	
<bean id="filterInvocationInterceptor" class="org.acegisecurity.intercept.web.FilterSecurityInterceptor">
	<property name="authenticationManager">
		<ref local="authenticationManager" />
	</property>
	<property name="accessDecisionManager">
		<ref local="accessDecisionManager" />
	</property>
	<property name="objectDefinitionSource">
		<value>
			PATTERN_TYPE_APACHE_ANT
			/**/Special:Admin=ROLE_SYSADMIN
			/**/Special:Edit=ROLE_EDIT_EXISTING,ROLE_EDIT_NEW
			/**/Special:Login=ROLE_ANONYMOUS,ROLE_USER
			/**/Special:Maintenance=ROLE_SYSADMIN
			/**/Special:Manage=ROLE_ADMIN
			/**/Special:Move=ROLE_MOVE
			/**/Special:RecentChangesFeed=ROLE_ANONYMOUS,ROLE_USER
			/**/Special:Roles=ROLE_SYSADMIN
			/**/Special:Setup=ROLE_ANONYMOUS,ROLE_USER
			/**/Special:Translation=ROLE_TRANSLATE
			/**/Special:Upload=ROLE_UPLOAD
			/**/Special:Upgrade=ROLE_ANONYMOUS,ROLE_USER
			/**/*.jsp=ROLE_ANONYMOUS,ROLE_USER
			/**/*.css=ROLE_ANONYMOUS,ROLE_USER
			/images/**=ROLE_ANONYMOUS,ROLE_USER
			/**=ROLE_VIEW
		</value>
	</property>
</bean>
That fixes the issue for me - let me know if it works for you as well. -- Ryan 21-Oct-2007 10:03 PDT
That fixes the issue for me. Thanks. I love JAMWiki. Jonas 22-Oct-2007 17:16 CET
Glad it fixed the problem, and the JAMWiki love is much appreciated - most people tend to comment only when there's a problem, so it's great to receive some positive feedback as well :) -- Ryan 22-Oct-2007 21:01 PDT
[Edit]

WebSphere support

Moved from the Feedback page:

To get jamwiki 0.4.1 and 0.5.2 working with WebSphere 5.1.1.12 on SuSE 8.1 (Linux) I found it was necessary to replace the hsqldbmain jar file with hsqldb.jar. Unfortunately, I don't know exactly what version this jar is from.

Additionally, WebSphere Enterprise seems to be quite picky. The web.xml elements must appear in the same order they are listed in the DTD. For reference, here is the web.xml I put together for jamwiki 0.5.2

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN" "http://java.sun.com/dtd/web-app_2_3.dtd">
   <web-app>
	<!--
	NOTE: do not use the context-param element to initialize the
	ApplicationResources resource bundle here due to a bug in the JSTL and
	Tomcat4 that causes response encoding to be finalized and thus prevents
	setting page encoding to UTF-8.  Instead, load the resource bundle in
	page-init.jsp.
	-->
      <display-name>jamwiki</display-name>
      <description>jamwiki</description>
      <context-param>
       	 <param-name>contextConfigLocation</param-name>
       	 <param-value>/WEB-INF/applicationContext-acegi-security.xml</param-value>
      </context-param>
      <!-- set encoding, cache headers, etc. -->
      <filter>
         <filter-name>JAMWikiFilter</filter-name>
         <filter-class>org.jamwiki.servlets.JAMWikiFilter</filter-class>
         <init-param>
            <param-name>encoding</param-name>
            <param-value>UTF-8</param-value>
         </init-param>
      </filter>
      <filter>
         <filter-name>Acegi Filter Chain Proxy</filter-name>
         <filter-class>org.acegisecurity.util.FilterToBeanProxy</filter-class>
         <init-param>
            <param-name>targetClass</param-name>
            <param-value>org.acegisecurity.util.FilterChainProxy</param-value>
         </init-param>
      </filter>
      <filter-mapping>
         <filter-name>JAMWikiFilter</filter-name>
         <url-pattern>/*</url-pattern>
      </filter-mapping>
      <filter-mapping>
         <filter-name>Acegi Filter Chain Proxy</filter-name>
         <url-pattern>/*</url-pattern>
      </filter-mapping>
      <listener>
       	 <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
      </listener>
      <servlet>
         <servlet-name>jamwiki</servlet-name>
         <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
         <load-on-startup>1</load-on-startup>
      </servlet>
      <servlet-mapping>
         <servlet-name>jamwiki</servlet-name>
         <url-pattern>/en/*</url-pattern>
      </servlet-mapping>
      <!-- virtual wiki mapping(s) -->
      <servlet-mapping>
         <servlet-name>jamwiki</servlet-name>
         <url-pattern>/test/*</url-pattern>
      </servlet-mapping>
      <welcome-file-list>
         <welcome-file>index.jsp</welcome-file>
      </welcome-file-list>
      <taglib>
         <taglib-uri>http://java.sun.com/jsp/jstl/core</taglib-uri>
         <taglib-location>/WEB-INF/c.tld</taglib-location>
      </taglib>
      <taglib>
         <taglib-uri>http://java.sun.com/jstl/fmt</taglib-uri>
         <taglib-location>/WEB-INF/fmt.tld</taglib-location>
      </taglib>
      <taglib>
         <taglib-uri>http://jamwiki.org/taglib</taglib-uri>
         <taglib-location>/WEB-INF/jamwiki.tld</taglib-location>
      </taglib>
      <taglib>
         <taglib-uri>http://acegisecurity.org/authz</taglib-uri>
         <taglib-location>/WEB-INF/authz.tld</taglib-location>
      </taglib>
   </web-app>
Thanks - I'll take a look this weekend. -- Ryan 15-Mar-2007 22:30 PST
Sorry for the delay. I used to test with Websphere before my trial license expired, and to get things working I had to update the JAMWiki web.xml to the current version that is shipped with JAMWiki. As far as I can tell the only difference between the current web.xml and your version is the display-name and the description elements - does Websphere 5.1 fail without those? Also, the hsqldbmain.jar issue is an odd one - according to the HSQL docs the only difference should be some support files. If you happen to notice any relevant messages in the logs that might explain the problem I'd be interested. Thanks for the report! -- Ryan 20-Mar-2007 19:57 PST
The current web.xml file is incorrect - it specifies version 2.4 instead of 2.3. The web.xml information specified above looks more correct. -- Ryan 21-Oct-2007 13:39 PDT
The web.xml specification issue has been corrected for the 0.6.2 release in revision 1894. -- Ryan 23-Oct-2007 21:40 PDT
Note that the 2.3 web.xml causes issues with JSP code of the form:

<input type="<c:out value="${foo}" />" />
Needs investigation - if anyone knows whether this is expected behavior and there is a workaround, or if it's a configuration issue, any insights would be appreciated. -- Ryan 28-Oct-2007 21:52 PST
[Edit]

Anonymous access problems in 0.6.0

Since upgrading from JAMWiki 0.5.4 to 0.6.0, anonymous users are unable to view the wiki.

When Tomcat is first started, if anyone tries to access the wiki site they are presented with a login page and told that they don't have access to the "Home" article (our default page). If they click any other pages, they get the same result. The CSS and image files also aren't served up properly.

In "User/Group Roles", GROUP_ANONYMOUS is set to have the ROLE_UPLOAD and ROLE_VIEW roles, as per the default settings.

If I set GROUP_ANONYMOUS to also have the ROLE_ADMIN role, click save, then untick the ROLE_ADMIN role and save again, suddenly everyone can view the wiki (at least until Tomcat is restarted).

Any ideas?

Our environment is as follows:

  • JAMWiki 0.6.0, using embedded hsqldb database
  • Apache Tomcat 6.0.13
  • Java 1.6.0_02-b05
  • Windows Server 2003 R2 Enterprise SP1

Thanks for your help. -- Wayne

Unfortunately I haven't seen anything like that on the installations I manage. My first suggestion would be to make sure that all of the old 0.5.4 files have been purged from Tomcat's cache - clear the tomcat/work directory. If the problem persists let me know and I'll see if I can figure out how to address it. Thanks for the bug report, and sorry for the trouble. -- Ryan 25-Sep-2007 19:23 PDT

Hi wiki gurus,

i have the similar problem after upgrading to 0.6.0 from 0.5.1, the only difference is my environment Our environment is as follows:

  • JAMWiki 0.6.0, using oracle 10g database
  • BEA weblogic 9.2 Mp2
  • BEA jRockit 1.5.0-11 (jrockit-R27.3.0-jdk1.5.0_11)
  • SUSE Linux 9.2 64 bit

Please some one help me, our users are stuck, and my knowledge base is totally stored in this wiki. appreciate your help -- Durga

Just to verify, was this installation done with an exploded WAR file? It is extremely important that the new (0.6.0) version of the /WEB-INF/applicationContext-acegi-security.xml file be used. If possible, could you upload your version of that file to jamwiki.org? Also, did you see any errors in your log file during the upgrade? Sorry for the trouble, and hopefully it will be easy to resolve. -- Ryan 12-Oct-2007 14:15 PDT

-- thanks for the reply, the deployment is done through exploded. the i have uploaded the /WEB-INF/applicationContext-acegi-security.xml file here i saw some errors while upgrading, saying i cant create the table(s), so i followed the manual upgrade as per the UPGRADE.txt file.

Please email me dkothapa@bear.com for faster resolution for the above problem, or else will give you a call. --Durga 15-Oct-2007 08:49 PDT

I'm at work so don't have a lot of time to work through issues right now, but could you also include the output of the following queries? Thanks!
select * from jam_role_map;
select * from jam_role;
select * from jam_group;
select * from jam_wiki_user where wiki_user_id = 1;
Sorry again for the trouble - I performed numerous upgrade tests without issue prior to the release of 0.6.0, including with Oracle, so it's frustrating to see that people are encountering bugs. -- Ryan 15-Oct-2007 10:09 PDT

Thanks ryan, uploaded the SQL Output, Please find that file here --Durga 15-Oct-2007 10:30 PDT

Thanks for the upload - I know this is a critical issue for you, so I'll take a look over my lunch hour, which will probably be sometime between noon and 2:00 PDT. -- Ryan 15-Oct-2007 10:48 PDT
Looking at your database vs. mine the following are different, and it looks like there was a typo for group names in the UPGRADE.txt file that might be causing your problems: 
update jam_group set group_name = 'GROUP_ANONYMOUS' where group_name = 'ANONYMOUS_USERS';
update jam_group set group_name = 'GROUP_REGISTERED_USER' where group_name = 'LOGGED_IN_USERS';
You may also want to do the following, depending on what you're using ROLE_ANONYMOUS for: 
delete from jam_role_map where user_id = 0; // bogus user id
delete from jam_role where role_name = 'ROLE_ANONYMOUS'; // keep only if you need it
delete from jam_role where role_name = 'ROLE_DELETE'; // unused role
delete from jam_role_map where group_id = 1 and role_name = 'ROLE_ADMIN'; // don't give anonymous admin access

After making these changes you will need to restart BEA, and with any luck you will be OK. Let me know if that works! -- Ryan 15-Oct-2007 13:43 PDT

Yahoo.. It is resolved. Thanks a zillion ryan. the main culprit in my Wiki is the group names, as per the typo in UPGRADE.txt the GROUP NAMEs are created. --Durga 15-Oct-2007 14:49 PDT

Glad it worked, and apologies again for the trouble. I'll have to remember to quadruple check the UPGRADE.txt document next time! I've got some ideas for making the automatic upgrade process more robust, so with any luck the need for that file may eventually go away. -- Ryan 15-Oct-2007 15:45 PDT
[Edit]

Default Topic

I have changed Default Topic. But after "Login" or "Logout" do not redirect to my default topic

It looks like there's definitely a problem in the code somewhere. I'll look into it. Thanks for the report! -- Ryan 30-Sep-2007 01:29 PDT
I think I figured it out. The "Default Topic" on Special:Admin is the default topic to use when creating new virtual wikis (which can be done from Special:Maintenance). Changing the default for the virtual wiki in question seems to work. I'll add a help text label to the next release to hopefully make this clearer, as I was confused when I tried this last night, and I wrote it - doh! -- Ryan 30-Sep-2007 09:16 PDT
[Edit]

Missing SQL entry in Upgrade.txt

i found a error in the UPGRADE.txt document.

  • in line 126 it tries to insert a role map entires for a role called "ROLE_DELETE", but that role is not there in section 3 e. Please check. --Durga 15-Oct-2007 08:49 PDT
ROLE_DELETE is not actually used and was included in 0.6.0 by mistake. It has been removed from 0.6.1. -- Ryan 15-Oct-2007 10:05 PDT
[Edit]

Index Content Doesn't Display in IE 6.0 SP2

The indexed content (which has been replaced by DIV tags in 0.6.1) doesn't display at all in IE 6.0 SP2. Firefox 2.0.0.8 (latest) works fine. Symptoms are that the index that displayed on 0.6.0 displayed fine on IE 6.0 SP2, but are blank on 0.6.1. This is true of both my site on my server and also the main JAMWiki Site --Bulldog 23-Oct-2007 06:35 PDT

Additional information. The site (JAMWiki.org) _does_ display correctly in IE 7.0. --Bulldog 23-Oct-2007 06:54 PDT

Thanks for the report. Can you clarify which page (full URL) you are referring to when you say "indexed content"? I've noticed the the "Documentation" section on http://jamwiki.org/wiki/en/StartingPoints isn't showing up with IE6, but I haven't noticed any other issues. I've only done a quick run-through with IE6, so I've likely missed something. -- Ryan 23-Oct-2007 07:45 PDT
Sorry - I was referring to the auto-generated "Documentation" section that you mention (I wasn't sure what it was called). But the bug reports list also doesn't show up - the same issue I suspect. I know most of the world has upgraded (or will shortly) to IE 7.0, but we're stuck on IE 6.0SP2 for now. So the two URLs that I'm specifically talking about are http://jamwiki.org/wiki/en/StartingPoints as well as http://jamwiki.org/wiki/en/Bug_Reports. Let me know if you need more detail. --Bulldog 23-Oct-2007 09:44 PDT
Thanks, that helps narrow it down. If I have some time after work today I'll see if there's an easy update to the StyleSheet that can be made to update the issue. Hopefully this one will be an easy fix. Also, for the record, I'd definitely like to make sure IE6 works properly - the last metric I looked at for directv.com (where I'm working) was something like 30% IE6 usage. -- Ryan 23-Oct-2007 10:33 PDT
Okay - a few more points. When loading in IE 6, the auto-generated list "flashes" on and then appears to be cleared. If I take the HTML, and paste it into new file and then load in a browser that allows everything to show, which essentially removes the stylesheet. I probably should help debug it, since I have the ability :-) --Bulldog 24-Oct-2007 06:31 PDT
If you take a look at the history for StyleSheet, the last two changes (http://jamwiki.org/wiki/en/Special:Diff?type=arbitrary&topic=StyleSheet&diff%3A6581=on&diff%3A6514=on) fix the TOC issue for me. Let me know if you're still seeing any problems! Note that the home page is still a bit messed up, but since that's custom CSS that affects only jamwiki.org I'm a bit less worried about it. -- Ryan 24-Oct-2007 08:00 PDT
That fixes it for me. Thanks! --Bulldog 24-Oct-2007 10:22 PDT
[Edit]

Characters bad presented in TOC

I'm writing contents in Spanish, using characters such as á, é, ñ, etc... The text looks fine, but the TOC does not. It shows the caracters like their HTML representation: &aacute, &eacute...

This is the same issue as the TOC umlaut bug report and this bug report, which was fixed for the next release by revision 1899. Since several people have reported the same problem I may need to get the next release out sooner... thanks for the report! -- Ryan 15-Nov-2007 05:47 PST

Ok, I see. Thanks you for all your effort. Yes, I'am willing to see the next version! Maybe I could help in some way, perhaps with a spanish translation. :-D Angel Pinazo

If you're interested in helping out with translations it would be much appreciated - the Spanish translations are very out-of-date! See How to Help#Translators for some details, and if you're interested I can give you access to the Special:Translation page on jamwiki.org. Thanks! -- Ryan 15-Nov-2007 08:29 PST
[Edit]

/TEST/<rep>/issue - the special character issue

Using a header with greater than/lower than signs (<>) causes escape (> <) in html on TOC. See http://www.jpox.org/servlet/wiki/en/Building_JPOX_using_Ant.

Of course, I could not reproduce the issue here :-) - erik Rendering_TOC_for_a_page_with_umlaut_%28%26auml%3B%2C%26ouml%3B%2C%26uuml%3B%2C_...%29_in_a_title

I think the fix that was applied for the TOC umlaut bug report (revision 1899) probably resolves the problem, but I'll verify that that's why it works on jamwiki.org but not in your local wiki. Thanks for the report! -- Ryan 11-Nov-2007 17:03 PST
[Edit]

Rendering TOC for a page with umlaut (ä,ö,ü, ...) in a title

I discovered a silly "bug" in the rendering of the TOC on top of a new page. If you use an (german) umlaut (ä,ö,ü, ...) in the head-line of an article you will see the html-encoding for the umlaut e.g.: &auml; in the generated TOC -- Michael Habbert 29-Oct-2007 07:40 PST

I have the same problem with french accented characters. Louis Martin 02-Nov-2007 02:37 PST

The problem seems to be in the class org.jamwiki.parser.TableOfContents in the method public String toHTML().

The line

text.append("<a href=\"#").append(Utilities.encodeForURL(entry.name)).append("\">").append(HtmlUtils.htmlEscape(entry.text)).append("</a>");

should be

text.append("<a href=\"#").append(Utilities.encodeForURL(entry.name)).append("\">").append(entry.text).append("</a>");

because the entry text is alraedy encoded when it arrive there. Louis Martin 02-Nov-2007 06:00 PST

Thanks for invesigating! I'll get a fix ready for the next release and will be sure to credit you in the CHANGELOG. -- Ryan 02-Nov-2007 06:18 PST
[Edit]

It's almost default virtual wiki's login page

I have created a virtual wiki (for example /zh_CN/). when i will edit some topic before i login in my virtual wiki, jamwiki will redirect to login page, but it almost default virtual wiki's login page, not my virtaul wiki's login page!

Thanks for the report - it is a long holiday weekend here this weekend, but I will try to look at this issue by Monday. If you don't see any update by then please add a reminder note so that I don't forget! -- Ryan 21-Nov-2007 22:06 PST
I believe that revision 1957 will solve this problem. -- Ryan 16-Dec-2007 09:33 PST
[Edit]

Default Virtual Wiki

Application server: tomcat5.5 OS:FreeBsd 6.2 Context Path: ""

error information: I change DEFAULT_VWIKI from "en" to "mn" on WikiBase.java. And I build source and upgrade my jamwiki 0.5.4 to jamwiki 0.6.0. But I have an error HTTP Status 404 - /en/Special:Login. not /mn/Special:Login I found my error. I some change on applicationContext-acegi-security-cas.xml and applicationContext-acegi-security.xml. Now my wiki looks ugly. Sorry my bad english

I'll investigate - I didn't test the new Acegi code very carefully with virtual wikis, so it's possible that something obvious was broken by those changes. Thanks for the bug report! -- Ryan 23-Sep-2007 20:10 PDT
I think this is the same issue as the one above, which should be solved by