Bug Reports/Resolved/Archive
This page is an archive of Bug Reports resolved prior to JAMWiki 0.6.0. See Bug Reports/Resolved for an index of all resolved bug reports. This archive is kept for reference only; please do not make further updates to this page.
[Edit]Setting up pages
Copied from the Feedback page:
Hi Ryan, I got the following in the logs when setting up JamWiki 0.5.0. I have checked the database and can see data populated. Hope you can shed some light on how to solve the following.
The following is my setup:
- Tomcat 5.5.20
- JDK1.4
- Oracle 9i
2007-01-18 09:42:25,812 INFO: org.jamwiki.db.WikiDatabase - Setting
up special page en / StartingPoints
2007-01-18 09:42:25,812 INFO: org.jamwiki.utils.Utilities - File
pages\en_US\StartingPoints.txt does not exist
2007-01-18 09:42:25,812 INFO: org.jamwiki.utils.Utilities - File
pages\en\StartingPoints.txt does not exist
2007-01-18 09:42:26,390 INFO: org.jamwiki.db.WikiDatabase - Setting
up special page en / LeftMenu
2007-01-18 09:42:26,390 INFO: org.jamwiki.utils.Utilities - File
pages\en_US\LeftMenu.txt does not exist
2007-01-18 09:42:26,390 INFO: org.jamwiki.utils.Utilities - File
pages\en\LeftMenu.txt does not exist
2007-01-18 09:42:26,640 INFO: org.jamwiki.db.WikiDatabase - Setting
up special page en / BottomArea
2007-01-18 09:42:26,640 INFO: org.jamwiki.utils.Utilities - File
pages\en_US\BottomArea.txt does not exist
2007-01-18 09:42:26,640 INFO: org.jamwiki.utils.Utilities - File
pages\en\BottomArea.txt does not exist
2007-01-18 09:42:26,875 INFO: org.jamwiki.db.WikiDatabase - Setting
up special page en / StyleSheet
2007-01-18 09:42:26,875 INFO: org.jamwiki.utils.Utilities - File
pages\en_US\StyleSheet.txt does not exist
2007-01-18 09:42:26,890 INFO: org.jamwiki.utils.Utilities - File
pages\en\StyleSheet.txt does not exist
-- Kwee Tin
- The messages above are safe to ignore - what's happening is that during setup the system looks for locale-specific files, but if it can't find them it uses defaults; at the moment I think Hungarian is the only language that has them available.
- Oracle won't work with the classes12.zip drivers (see Supported Configurations#Non-Working Configurations) but otherwise should be OK - are there any other errors in the logs, or is your instance working correctly? -- Ryan 17-Jan-2007 20:37 PST
Hi Ryan, I am currently using ojdbc14.jar to connect to Oracle. When I access Starting Points, the css, left menu, and bottom area did not load. I got warning in ServletUtil which says "error getting cached page en / BottomArea java.lang.NullPointerException at org.jamwiki.servlets.ServletUtil.cachedContent (ServletUtil.java:140). I am unable to edit pages as well. Is this due to the oracle version? Thanks. -- Kwee Tin
- Thanks for being patient. JAMWiki is untested on Oracle 9, so it's possible that's the problem. Are there any other errors showing up in your logs, hopefully with a stack trace? If I can fix the problem I'd like to, but since I don't have access to an Oracle 9 database I'll need some pointers to figure out exactly what the problem is. Also, just to make sure, are you using JAMWiki 0.5.0? -- Ryan 17-Jan-2007 22:23 PST
Hi Ryan, I have sent you the log file in your email. And yes, I am using JamWiki 0.5.0. Thanks. -- Kwee Tin
- Thanks - in addition to the trouble retrieving content from the cache I'm suspicious of this line:
2007-01-18 13:52:30,812 WARNING: org.jamwiki.utils.Utilities - No virtual wiki found in URL: /jamwiki/
- I'll investigate to see if I can figure out what's happening. I don't have a lot of free time at the moment, but hopefully within the next 1-2 days. Sorry for the trouble! -- Ryan 17-Jan-2007 22:53 PST
Sure. Thanks for your help. -- Kwee Tin
- Just a note to say I haven't forgotten about this request, but I didn't have time for any JAMWiki coding tonight. Hopefully tomorrow. -- Ryan 18-Jan-2007 23:49 PST
I couldn't find a free download of Oracle 9 so I won't be able to reproduce this problem. Can you do me a favor and provide the results of the following queries against your database?
select count(*) from jam_topic; select * from jam_topic where topic_name = 'LeftMenu'; select count(*) from jam_topic_version; select * from jam_virtual_wiki;
I'd just like to make absolutely sure that data was properly populated during setup. Thanks! -- Ryan 20-Jan-2007 11:35 PST
SQL> select count(*) from jam_topic;
COUNT(*)
----------
4
SQL> select * from jam_topic where topic_name='LeftMenu';
TOPIC_ID VIRTUAL_WIKI_ID
---------- ---------------
TOPIC_NAME
--------------------------------------------------------------------------------
DELETE_DATE
---------------------------------------------------------------------------
TOPIC_READ_ONLY TOPIC_ADMIN_ONLY CURRENT_VERSION_ID TOPIC_TYPE
--------------- ---------------- ------------------ ----------
REDIRECT_TO
--------------------------------------------------------------------------------
2 1
LeftMenu
TOPIC_ID VIRTUAL_WIKI_ID
---------- ---------------
TOPIC_NAME
--------------------------------------------------------------------------------
DELETE_DATE
---------------------------------------------------------------------------
TOPIC_READ_ONLY TOPIC_ADMIN_ONLY CURRENT_VERSION_ID TOPIC_TYPE
--------------- ---------------- ------------------ ----------
REDIRECT_TO
--------------------------------------------------------------------------------
0 1 2 1
SQL> select count(*) from jam_topic_version;
COUNT(*)
----------
4
SQL> select * from jam_virtual_wiki;
VIRTUAL_WIKI_ID
---------------
VIRTUAL_WIKI_NAME
--------------------------------------------------------------------------------
DEFAULT_TOPIC_NAME
--------------------------------------------------------------------------------
CREATE_DATE
---------------------------------------------------------------------------
1
en
StartingPoints
18-JAN-07 09.38.04.843000 AM
Thanks! -- Kwee Tin 21-Jan-2007 19:20 PST
Hi Ryan, think you can download oracle 9i from http://www.oracle.com/technology/software/products/oracle9i/index.html -- Kwee Tin 21-Jan-2007 21:48 PST
- Thanks, I'm downloading now and will see what I can find out. From the query results you provided above it looks like the data was populated properly, so apparently the problem is elsewhere... -- Ryan 21-Jan-2007 22:48 PST
- I've finally gotten Oracle 9 installed, but I made the mistake of choosing the default installation, and I'm now uninstalling various components trying to figure out what Oracle installed that broke my Tomcat instance. I appreciate you being so patient - one way or another this issue will eventually get solved, but it's proving to be a long, drawn-out process... -- Ryan 22-Jan-2007 23:32 PST
- After a bit of a struggle I think I've gotten Oracle behaving, and I managed to get through a JAMWiki install without incident - everything just worked. So I'm stumped as to what problem you might be running into. The only things that stand out from your posted configuration are:
- You are using the OCI driver. I've always used the THIN driver, and I'm actually not sure what the differences are. You might want to try something like jdbc:oracle:thin:@//hostname:1521/service, although I'm not sure that it should make any difference.
- Your JAMWiki file directory is within your webapp directory. I seriously doubt that should matter, but just in case you may want to try another location on your filesystem.
- If a reinstall with the above changes doesn't work then I'm stumped. I'll add some additional logging to JAMWiki 0.5.1 to hopefully better track down the problem, but this has been a confusing one... -- Ryan 23-Jan-2007 21:25 PST
- After a bit of a struggle I think I've gotten Oracle behaving, and I managed to get through a JAMWiki install without incident - everything just worked. So I'm stumped as to what problem you might be running into. The only things that stand out from your posted configuration are:
- I've finally gotten Oracle 9 installed, but I made the mistake of choosing the default installation, and I'm now uninstalling various components trying to figure out what Oracle installed that broke my Tomcat instance. I appreciate you being so patient - one way or another this issue will eventually get solved, but it's proving to be a long, drawn-out process... -- Ryan 22-Jan-2007 23:32 PST
Hi Ryan, I tried removing jamwiki and reinstall it, this time using the thin driver, however when it comes to inserting into jam_topic_version, I got an exception. When using the OCI driver, I will not get this error. I will send you my log file through email. Thanks. -- Kwee Tin 25-Jan-2007 18:27 PST
- Thanks for the latest logs. As I'm sure you saw, the problem is the following:
Caused by: java.sql.SQLException: Data size bigger than max size for this type: 7409
- ...which is occurring during topic version setup. I'm not sure why Oracle would complain about a column size for you but not for me (or at all, really). I'm still at work but I'll do some Googling when I get home. Thanks again for taking the time to help debug this issue. -- Ryan 25-Jan-2007 18:29 PST
Hi Ryan, I try to deploy JamWiki 0.5.1 in BEA Weblogic, and Oracle 9i and it works! I guess I will be using this configuration instead of Tomcat. Thanks for your help in this puzzling exception. :D -- Kwee Tin 25-Jan-2007 21:23 PST
- I've been doing some searching for this problem and haven't had a lot of luck in finding a solution. One possible issue is mentioned on the IBM WebSphere site - is it possible you have an older Oracle driver file somewhere in your classpath, such as in the Tomcat shared lib directory? JAMWiki definitely doesn't work with the old classes12.zip driver package, and the only references I've found that mention the CLOB error for text values over 4K all recommend upgrading the driver to solve the problem. Otherwise I'm stumped! In any case, glad it's finally working for you! -- Ryan 25-Jan-2007 21:42 PST
Hi Ryan, I just downloaded the latest version of ojdbc14.jar for oracle9i and replaced my previous copy. Now I am able to get JamWiki running on Tomcat and Oracle9i. Thanks for all your help! -- Kwee Tin 25-Jan-2007 22:12 PST
- Great! Thanks for all of your patience in debugging! -- Ryan 25-Jan-2007 22:17 PST
[Edit]Losing configuration on server restart/deploy
Copied from the Feedback page:
Hi Ryan,
i've just set up jamwiki and it is working fine despite of the fact that it loses the complete configuration after i restart the server (JBoss 4). So everytime after a restart it comes up with the installation-screen.
The problem seems to be that the jamwiki.properties file is written in the WEB-INF directory in the tmp folder of the server. So every restart or redeploy deletes this file. Is there a possibility to keep it somewhere else, eg. in the data-directory? I wonder if this occurs only with JBoss...
Regards, Dave
As i figured out meanwhile the solution might be "Exploded Deployment" http://wiki.jboss.org/wiki/Wiki.jsp?page=ExplodedDeployment. Perhaps this helps somebody.
- This does seem to be a JBoss-specific problem, as this is the first report I've heard. The jamwiki.properties file should be in the /WEB-INF/classes/ file, so I'm not sure why JBoss would put it in a different location. I know that BEA drops properties files entirely unless the WAR file is deployed exploded, so this may be a similar situation with JBoss. Thanks for the info, and please feel free to add it to the Installation topic. -- Ryan 18-Jan-2007 08:13 PST
- Exploded deployment does solve the problem, although it's not really optimal. The default in JBoss is not to default to exploded deployment, so you have to do this explicitly unlike in some other app servers. -- DanR 30-Jan-2007 19:11 PST
[Edit]BEA setup
I set up JamWiki on a WebLogic server. When I try to acces the JamWiki for the first time i get a redirection error (I'm using port 7201). Why ?
- It's possible there's a bug in JAMWiki that is only triggered on BEA. Can you provide any relevant messages from the jamwiki.log file, which will by default be located in the WebLogic temporary directory? Also, what version of WebLogic? -- Ryan 12-Dec-2006 08:28 PST
Hi Ryan, I got the following in the log file when trying to install JamWiki in Weblogic 8.1 SP5. It goes into an endless loop of loading the Special:Setup page. Any idea on how to resolve this?
2007-01-09 12:04:49,968 CONFIG: org.jamwiki.utils.WikiLogger - JAMWiki log initialized from E:\work\Wiki\WEB-INF\classes\logging.properties with pattern E:/work/Wiki/logs/jamwiki.log.%g 2007-01-09 12:05:08,093 WARNING: org.jamwiki.Environment - Property file E:\work\Wiki\WEB-INF\classes\jamwiki.properties does not exist 2007-01-09 12:05:08,203 CONFIG: org.jamwiki.WikiConfiguration - Configuration values loaded from E:\work\Wiki\WEB-INF\classes\jamwiki-configuration.xml 2007-01-09 12:05:08,203 INFO: org.jamwiki.servlets.JAMWikiServlet - Loaded page /Wiki/en/Special:Setup (0.016 s.) 2007-01-09 12:05:08,203 INFO: org.jamwiki.servlets.JAMWikiServlet - Loaded page /Wiki/en/Special:Setup (0.016 s.) 2007-01-09 12:05:08,234 INFO: org.jamwiki.servlets.JAMWikiServlet - Loaded page /Wiki/en/Special:Setup (0.0 s.) 2007-01-09 12:05:08,234 INFO: org.jamwiki.servlets.JAMWikiServlet - Loaded page /Wiki/en/Special:Setup (0.0 s.) 2007-01-09 12:05:08,234 INFO: org.jamwiki.servlets.JAMWikiServlet - Loaded page /Wiki/en/Special:Setup (0.0 s.) 2007-01-09 12:05:08,234 INFO: org.jamwiki.servlets.JAMWikiServlet - Loaded page /Wiki/en/Special:Setup (0.0 s.) 2007-01-09 12:05:08,250 INFO: org.jamwiki.servlets.JAMWikiServlet - Loaded page /Wiki/en/Special:Setup (0.0 s.) 2007-01-09 12:05:08,250 INFO: org.jamwiki.servlets.JAMWikiServlet - Loaded page /Wiki/en/Special:Setup (0.0 s.)
- That's the second failure report with a BEA install so there's definitely something screwed up somewhere. I've got access to a BEA server at work, so I'll try to do an install there and figure out why BEA redirects indefinitely - I suspect that the filter that determines whether or not setup is required isn't getting processed correctly, although I have no idea why that would be. Thanks for the report, hopefully this will be resolved soon. -- Ryan 08-Jan-2007 20:12 PST
Hi Ryan, any luck in running JamWiki on BEA Weblogic 8.1 SP5? Thanks.
- Not yet. Work is keeping me insanely busy, so I'll try to get this issue fixed soon, but it's kind of a drag to be in the office for twelve hours and then, once all of the day's tasks are done, to spend another couple of hours debugging software ;) If anyone else wants to investigate you're welcome to do so, and patches are always accepted. Otherwise I'll try to get to this soon, but it may be another week or so. -- Ryan 11-Jan-2007 08:19 PST
- I think I've got the bug fixed in Subversion now, and it will be included in JAMWiki 0.5.1. Apparently BEA triggers servlet filters even when forwarding from another servlet, and that was causing an infinite loop during setup. After updating the filter I was able to install on a test machine at work, so hopefully this will fix the install for everyone. Please note that installation on BEA requires that the WAR file be unpacked, otherwise BEA drops required property files during deployment. -- Ryan 15-Jan-2007 21:46 PST
[Edit]0.5.0 beta 7 - Upload works, display fails
Archived from the Feedback page:
The upload image problem is still gone (thanks), but now I can't seem to see the images that were uploaded. This was happening on the patched 0.4.3 that I womped together a couple days ago, but with beta 7 I can't seem to view the images I've uploaded.
process:
- Upload image from my desktop.
- Next screen:
This has been happening all along for me, though I previously assumed it was because I was referring to an upload directory that was outside of the web server's tree (trying to isolate data from installation) I now have my upload directory under WEB-INF and am specifying a relative path in the admin page like "\WEB-INF\upload". Interestingly the uploaded image seems to know how big the file is (note the image broder).
Seems to work fine on this site, so I'm assuming I've got something wrong. hummm.
nomead 07-Dec-2006 06:21 PST
- According to the J2EE specification the WEB-INF directory is special, and users can't see any files that are behind it - the reasoning is that otherwise someone could just view a URL like http://example.com/context/WEB-INF/web.xml and see your site configuration, or even worse start fishing for files that contain passwords. Using your JAMWiki Special:Admin tool, under "File upload settings" you should be able to change your image file directory and relative directory, and if you use a value other than WEB-INF it should hopefully work - let me know if the problems continue! -- Ryan 07-Dec-2006 08:02 PST
- that definitely fixed it. I had presumed you had replaced the default servlet (duh - the need for a relative path should have been the tipoff). Thanks! nomead 09-Dec-2006 07:32 PST
[Edit]Logo image link broken on nested pages
The logo image is invisible on nested pages like
Stuff/NestedStuff
Version 0.4.3, Reported by Jens 04 Jan 2006
- Thanks! This will be fixed for JAMWiki 0.5.1. For reference, Feedback/Archives also demonstrates this problem. -- Ryan 04-Jan-2007 09:17 PST
- I've fixed this in the Subversion repository and will upload the fix to jamwiki.org soon. A quick fix for those who can't wait for the 0.5.1 release is to change the logo image source in wiki.jsp from
<img border="0" src="../images/<c:out value="${logo}" />" alt="" /> - to
<img border="0" src="<c:url value="/images/${logo}" />" alt="" /> - -- Ryan 06-Jan-2007 17:16 PST
- I've fixed this in the Subversion repository and will upload the fix to jamwiki.org soon. A quick fix for those who can't wait for the 0.5.1 release is to change the logo image source in wiki.jsp from
[Edit]Image upload problem on windows
When uploading an image I get the following error message:
Error A system error has occurred. The error message is: The requested value "Image:C:\bgbody.png" was invalid. It may contain one or more characters which cannot be used in titles.
Uploading works just fine with firefox on Linux.
JAMWiki 0.4.3, Tomcat 5.0.30, Reported by Jens 04 Jan 2006
- This issue should be fixed in JAMWiki 0.5.0. See Comments:JAMWiki 0.5.0#Problem with Upload for details. -- Ryan 04-Jan-2007 09:17 PST
[Edit]SVN #1286 is broken
Installing a new wiki from svn #1286 sources fails:
- The setup screen show's an error (message: null)
- Providing any values to the setup screen won't change anything but show an error message
- Log shows an error in SetupServlet:
22.12.2006 15:38:51 org.jamwiki.utils.WikiLogger severe SCHWERWIEGEND: Setup error java.lang.NumberFormatException: null at java.lang.Integer.parseInt(Integer.java:415) at java.lang.Integer.parseInt(Integer.java:497) at org.jamwiki.servlets.SetupServlet.setProperties(SetupServlet.java:176) at org.jamwiki.servlets.SetupServlet.initialize(SetupServlet.java:111) at org.jamwiki.servlets.SetupServlet.handleJAMWikiRequest(SetupServlet.java:68) at org.jamwiki.servlets.JAMWikiServlet.handleRequestInternal(JAMWikiServlet.java:72)
Version 1283 in svn works ok for me. -- Rainer 22-Dec-2006 06:46 PST
- Thanks! I need to do a round of install & upgrade tests, hopefully tonight, so I'll look into it then if the bug is still around. -- Ryan 22-Dec-2006 08:28 PST
- I'm actually getting a different error from JAMWikiDaoImpl.loadUserByUsername during setup - it's late here now, but I'll try to spend some time this weekend running through setup and upgrade testing to get everything working again. -- Ryan 22-Dec-2006 23:32 PST
- OK, fixed - that was a dumb logic error on my part introduced during one of the PMD cleanups. There is another problem when trying to do a new setup if previously a "remember me" cookie was set, and I'm not sure how to work around it. The problem is that Acegi tries to lookup a user, but since setup is not complete it fails and an error is thrown before the setup screen is shown. This probably won't be a common case, but it will eventually need a solution - any ideas? -- Ryan 26-Dec-2006 13:33 PST
- During user lookup a check could be made whether the database (or JAMWiki at all) is configured already. If not, a UsernameNotFoundException should be thrown which is handled by appropriately by Acegi Security. -- Rainer 27-Dec-2006 06:59 PST
- OK, fixed - that was a dumb logic error on my part introduced during one of the PMD cleanups. There is another problem when trying to do a new setup if previously a "remember me" cookie was set, and I'm not sure how to work around it. The problem is that Acegi tries to lookup a user, but since setup is not complete it fails and an error is thrown before the setup screen is shown. This probably won't be a common case, but it will eventually need a solution - any ideas? -- Ryan 26-Dec-2006 13:33 PST
- I'm actually getting a different error from JAMWikiDaoImpl.loadUserByUsername during setup - it's late here now, but I'll try to spend some time this weekend running through setup and upgrade testing to get everything working again. -- Ryan 22-Dec-2006 23:32 PST
[Edit]MS SQL properties query
In the sql.mssql.properties file, STATEMENT_SELECT_TOPICS_ADMIN has a bug/typo.
Line 18 of the query is: + ' and topic_admin_only = 1 \
It should be: + ' and topic_admin_only = 1 ' \
It's missing the closing tick (and a space in front of it). -- scroco 13-Nov-2006 15:09 PST
- Thanks - I've committed the fix to the source code repository, and it will be included in JAMWiki 0.5.0 beta 1. -- Ryan 13-Nov-2006 16:58 PST
Found another issue with sql.mssql.properties. For any of the queries that manage pagination (offset and limit), an error occurs in situations where the offset is larger than the number of items in the list. For example, jamwiki.org handles this page just fine: http://jamwiki.org/wiki/en/Special:TopicsAdmin?num=50&offset=20, showing no results. But if using the MS SQL properties it returns an ugly error page.
For each query that contains the line:
IF (@COUNT < @OFFSET + @LIMIT) SET @TOP = @COUNT - @OFFSET \
This line needs to be inserted above it:
IF (@OFFSET > @COUNT) SET @OFFSET = @COUNT \
Making the queries look like this:
IF (@OFFSET > @COUNT) SET @OFFSET = @COUNT \ IF (@COUNT < @OFFSET + @LIMIT) SET @TOP = @COUNT - @OFFSET \
By my count, there are 8 queries that need this fix:
- STATEMENT_SELECT_CATEGORIES
- STATEMENT_SELECT_RECENT_CHANGES
- STATEMENT_SELECT_RECENT_CHANGES_TOPIC
- STATEMENT_SELECT_TOPIC_BY_TYPE
- STATEMENT_SELECT_TOPICS_ADMIN
- STATEMENT_SELECT_WATCHLIST_CHANGES
- STATEMENT_SELECT_WIKI_USER_CHANGES_ANONYMOUS
- STATEMENT_SELECT_WIKI_USER_CHANGES_LOGIN
The effect is that any requests with an offset larger than the number of available results will see a page with no results (mirroring jamwiki.org). -- scroco 15-Nov-2006 11:51 PST
- Thanks - I've updated the code in the source repository. I don't have an MS SQL database to test with, but if you or anyone else has any ideas at all for simplifying the MS SQL pagination queries I'd be interested - they're getting out of hand for something that most databases can handle with simple "limit" and "offset" parameters. -- Ryan 15-Nov-2006 13:39 PST
- Welcome to reason #15 why MS SQL is below average. Normally, when I do pagination with MS SQL I do it programatically, using the result set and jumping the cursor to the rows I'm interested in. MS SQL doesn't offer anything in the way of an OFFSET, so a convoluted query or extra code are the only ways to handle it. I haven't looked at whether these particular queries can be improved but wanted to let you know the deal with MS SQL Server. -- scroco 15-Nov-2006 14:17 PST
- Fair enough - the last time I had to use MS SQL was on a project in 2001, so I've pretty much forgotten most of its oddities. It may be possible to handle pagination programmatically (as you've suggested) from the MSSQLQueryHandler class, but in the mean time I very much appreciate the bug reports & fixes - working but ugly code is almost always better than broken code. -- Ryan 15-Nov-2006 15:20 PST
- Welcome to reason #15 why MS SQL is below average. Normally, when I do pagination with MS SQL I do it programatically, using the result set and jumping the cursor to the rows I'm interested in. MS SQL doesn't offer anything in the way of an OFFSET, so a convoluted query or extra code are the only ways to handle it. I haven't looked at whether these particular queries can be improved but wanted to let you know the deal with MS SQL Server. -- scroco 15-Nov-2006 14:17 PST
[Edit]Links back lost after upgrade
After upgrading to 0.3.5 from 0.3.3, links in the 'Links' tab at the top of the screen no longer work. During the upgrade, there was an error message saying that the directory 'uploads' didn't exist. This is the folder I specified in initial setup to store uploaded files. Copying this from my backup allowed the upgrade to go ahead but afterwards there was this lost link problem. Unfortunately due to my mistake I no longer have the original database backup from before the upgrade.
Any ideas how to get them back? My db is postgresql. How are they stored in the the database?
Regards, Oliver 05-Oct-2006 03:39 PDT
- I'll have to look into why it happened, but you can rebuild the link histories by going to Special:Admin and clicking on the "refresh search index" button. Sorry for the trouble! -- Ryan 05-Oct-2006 09:13 PDT
That's it, thanks. Oliver 06-Oct-2006 09:21 PDT
[Edit]Upgrade from 0.3.6 to 0.4.1
I am running jamwiki on Tomcat 5.0.28/JDK 1.4.2. When upgrading from v0.3.6 to 0.4.1 I am challenged for a login and warned about the pending upgrade. I am then presented with:
2006-10-27 11:48:15 StandardWrapperValve[jamwiki]: Servlet.service() for servlet jamwiki threw exception java.lang.UnsupportedClassVersionError: org/hsqldb/jdbcDriver (Unsupported major.minor version 49.0) at java.lang.ClassLoader.defineClass0(Native Method) trimmed at java.lang.Class.forName(Class.java:219) at org.jamwiki.db.DatabaseConnection.setUpConnectionPool(DatabaseConnection.java:59) at org.jamwiki.db.DatabaseConnection.getConnection(DatabaseConnection.java:208) at org.jamwiki.db.DatabaseConnection.executeQuery(DatabaseConnection.java:115) at org.jamwiki.db.DefaultQueryHandler.getVirtualWikis(DefaultQueryHandler.java:321) at org.jamwiki.db.DatabaseHandler.isInitialized(DatabaseHandler.java:995) at org.jamwiki.WikiBase.reset(WikiBase.java:183) at org.jamwiki.servlets.UpgradeServlet.upgrade040(UpgradeServlet.java:184) at org.jamwiki.servlets.UpgradeServlet.upgrade(UpgradeServlet.java:134) at org.jamwiki.servlets.UpgradeServlet.handleRequestInternal(UpgradeServlet.java:67) trimmed at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:683) at java.lang.Thread.run(Thread.java:534)
Replacing the packaged hsql jar with an earlier one solves this issue. Unfortunately, after the upgrade completes none of my topics are successfully converted and the log is full of the following for each topic:
SEVERE: Unable to convert topic: en / Earthwalk java.lang.Exception: Failure while executing insert into jam_topic ( topic_id, virtual_wiki_id, topic_name, topic_type, topic_read_only, topic_content, delete_date, topic_admin_only, redirect_to ) values ( ?, ?, ?, ?, ?, ?, ?, ?, ? ) at org.jamwiki.db.WikiPreparedStatement.executeUpdate(WikiPreparedStatement.java:120) at org.jamwiki.db.DefaultQueryHandler.insertTopic(DefaultQueryHandler.java:453) at org.jamwiki.db.DatabaseHandler.addTopic(DatabaseHandler.java:139) at org.jamwiki.db.DatabaseHandler.convertFromFile(DatabaseHandler.java:280) at org.jamwiki.servlets.UpgradeServlet.upgrade040(UpgradeServlet.java:187) at org.jamwiki.servlets.UpgradeServlet.upgrade(UpgradeServlet.java:134) at org.jamwiki.servlets.UpgradeServlet.handleRequestInternal(UpgradeServlet.java:67) trimmed at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:683) at java.lang.Thread.run(Thread.java:534) Caused by: java.sql.SQLException: Violation of unique index: JAM_PK_TOPIC in statement [insert into jam_topic ( topic_id, virtual_wiki_id, topic_name, topic_type, topic_read_only, topic_content, delete_date, topic_admin_only, redirect_to ) values ( ?, ?, ?, ?, ?, ?, ?, ?, ? )] at org.hsqldb.jdbc.jdbcUtil.throwError(Unknown Source) at org.hsqldb.jdbc.jdbcPreparedStatement.executeUpdate(Unknown Source) at ...dbcp.DelegatingPreparedStatement.executeUpdate(DelegatingPreparedStatement.java:101) at org.jamwiki.db.WikiPreparedStatement.executeUpdate(WikiPreparedStatement.java:112) ... 43 more
I have also attempted this against 0.4.0 with the same results
- I think the first problem is due to the fact that I compiled the HSQL JAR file with a 1.5 JDK. I'll fix that. The second error is stranger, so I'll have to try to reproduce by doing an upgrade from 0.3.6. Sorry for the trouble, but I'll definitely try to get a fix included in JAMWiki 0.4.2. Thanks for the report. -- Ryan 27-Oct-2006 14:31 PDT
- With the fixed HSQL jar file I'm able to upgrade from 0.3.6 to 0.4.2 in file persistency mode, so I'm hoping that your problem may have been due to the bad jar file and having junk left over from the previous failed upgrade. Can you perhaps do the following with either JAMWiki 0.4.2-rc1 or later (available from the Feedback page), and let me know if it still fails?
- Delete the /database directory in your JAMWiki file-system directory. This directory will contain any files created during the failed upgrade.
- Make sure that the "persistenceType" value in your jamwiki.properties file is still set to "FILE".
- Make sure that the "wiki-version" value in your jamwiki.properties file is still set to "0.3.6".
- Restart your web application server.
- View any page to begin the upgrade process.
- Hopefully that will work for you - let me know if there are any issues. -- Ryan 30-Oct-2006 23:16 PST
- This issue was (hopefully) resolved for JAMWiki 0.4.2. -- Ryan 09-Nov-2006 18:26 PST
- With the fixed HSQL jar file I'm able to upgrade from 0.3.6 to 0.4.2 in file persistency mode, so I'm hoping that your problem may have been due to the bad jar file and having junk left over from the previous failed upgrade. Can you perhaps do the following with either JAMWiki 0.4.2-rc1 or later (available from the Feedback page), and let me know if it still fails?
I'm seeing this while upgrading from 0.3.6 to 0.4.3. My initial investigation shows that the 'id' in the topic files isnt unique, hence the "Violation of unique index" error shown above. I dont know why these id's arent unique. Manually changing the offending id's to a unique value before running the update doesnt sort this, as there are cross references from other files.
- Thanks - I'll try to figure out if there's anything I can do to fix the issue, although I'm baffled as to why ID values wouldn't be unique. How many topics do you have? I don't want to leave you without an upgrade path, but I also don't want to spend hours trying to come up with a solution if this is a relatively isolated incident and it's possible to do a fresh install and just manually copy-and-paste your existing content. Sorry for the troubles - this was one of the reasons why I dumped the old file persistency code for JAMWiki 0.4.0... -- Ryan 16-Nov-2006 17:37 PST
[Edit]References
I've used a reference like [1] but it seems not to be resolved by the parser. The References Tag (see bottom of this Page) as well. Can't find a remark that the feature is not yet implemented.
- I'll add this to the Roadmap. Thanks! -- wrh2 08-Sep-2006 10:48 PDT
- References were implemented for JAMWiki 0.4.3. -- Ryan 09-Nov-2006 18:26 PST
[Edit]When upload image, Description isnt support utf-8
When upload image, i use chinese in description, but is will get wrong character. see [1]
![[1]](http://jamwiki.org/wiki/en/Image:computer_guy.jpg){kind=link}
- Thanks, I'm trying to figure out where the problem is and will get it fixed for JAMWiki 0.4.3. -- Ryan 08-Nov-2006 17:15 PST
- I think I've fixed some of the problems - see Image:测试图片.gif, which has Chinese characters in the image description. The actual image isn't appearing, but that is (I think) a server problem rather than a JAMWiki problem. Please let me know if you have any additional comments. Updated code will be included in JAMWiki 0.4.3. -- Ryan 08-Nov-2006 23:59 PST
- A fix for this issue was implemented for JAMWiki 0.4.3. -- Ryan 09-Nov-2006 18:26 PST
[Edit]Upgrade from 0.2.0 to 0.3.1
Upgrade failed when upgrading from 0.2.0 to 0.3.1 using file persistency mode. Special:Upgrade page reports:
Unable to complete upgrade to new JAMWiki version.: null
And jamwiki.log reports:
006-08-29 08:37:35,784 [http-8080-Processor24] ERROR org.jamwiki.persistency.file.FileHandler - Failure while initializing topic for file c:\java\data\wiki\en\topics\StyleSheet.xml java.lang.IllegalArgumentException: Timestamp format must be yyyy-mm-dd hh:mm:ss.fffffffff at java.sql.Timestamp.valueOf(Unknown Source) at org.jamwiki.persistency.file.FileHandler.initTopic(FileHandler.java:621) at org.jamwiki.persistency.file.FileHandler.lookupTopic(FileHandler.java:967) at org.jamwiki.persistency.file.FileHandler.lookupTopic(FileHandler.java:958) at org.jamwiki.persistency.PersistencyHandler.updateSpecialPage(PersistencyHandler.java:813) at org.jamwiki.servlets.UpgradeServlet.upgradeStyleSheet(UpgradeServlet.java:245) at org.jamwiki.servlets.UpgradeServlet.upgrade030(UpgradeServlet.java:205) at org.jamwiki.servlets.UpgradeServlet.upgrade(UpgradeServlet.java:93) at org.jamwiki.servlets.UpgradeServlet.handleRequestInternal(UpgradeServlet.java:68) ...
The StyleSheet.xml had been modified slightly from default.
- Thanks, it's difficult for me to test the upgrade code so I was a bit worried. I'll get a updated version out later this morning. -- Ryan 29-Aug-2006 10:29 PDT
- Here's a beta that contains a fix. I'll release this as the final JAMWiki 0.3.2 later today unless any other major bugs are reported:
The upgrade appears to work but now all of my article links link to the edit page. i.e. prefixed with Special:Edit?topic=
- Sorry! I normally do most of my development using a Postgres database for persistency, but I guess I'll need to focus on file persistency. Here's a version that works for me in file persistency mode:
I managed to install an older version, delete a few files, and then upgrade to JAMWiki 0.3.2 successfully, so I've released a final JAMWiki 0.3.2 on Sourceforge - I didn't like the idea of leaving a version out there that would break for some users. Sorry for the trouble, and thanks for your bug report! -- Ryan 29-Aug-2006 13:46 PDT
[Edit]Apostrophes in IE
In IE, all apostrophes are displayed as ' -- scroco 29-Aug-2006 15:15 PDT
- According to this site it's apparently IE deviating from the standards... I'll switch to ' for the next release - let me know if you need a quick beta that fixes this. Thanks for the report. -- Ryan 29-Aug-2006 15:26 PDT
[Edit]Category links
Links to categories don't parse correctly.
* [[:Category:JAMWiki|JAMWiki Category]]
-- scroco 25-Aug-2006 13:21 PDT
- Mediawiki categories treat a second paramater as a sort key for the page, so that on Category:JAMWiki page the Bug Reports page will now appear as "JAMWiki Category" and be sorted using that name (actually it won't because the later [[Category:JAMWiki]] tag on this page will supersede this one, but that's the idea). To link to a category add a colon in front of the category name - JAMWiki Category / [[:Category:JAMWiki|JAMWiki Category]]. -- Ryan 25-Aug-2006 13:25 PDT
Got it, thanks. I forgot for a second that the syntax for adding a page to a category is the same as link syntax. -- scroco 25-Aug-2006 13:34 PDT
- No problem. The fact that categories and images use the same syntax as links seems like a big shortcoming with the Mediawiki markup, but there are some ongoing discussions about how things could be changed make more sense. -- Ryan 25-Aug-2006 13:45 PDT
[Edit]Internal link with query string
Valid internal links that contain a query string don't parse properly, like this one to the sandbox history page:
Sandbox history
[[Special:History?topic=Sandbox|Sandbox history]]
-- scroco 24-Aug-2006 17:19 PDT
- This should work now, and will be included in JAMWiki 0.3.1 beta2. I may have broken other links in the process, so let me know if you notice anything. -- 10.0.0.5 24-Aug-2006 20:08 PDT
[Edit]no big deal
In the class org.jamwiki.persistency.file.FileHandler line 1473 to 1477 (saveWikiUser) you have:
if (WIKI_USER_ID_HASH == null && userIdHashFile.exists()) {
WIKI_USER_ID_HASH.load(new FileInputStream(userIdHashFile));
} else if (WIKI_USER_ID_HASH == null) {
WIKI_USER_ID_HASH = new Properties();
}
that throws a null pointer exception it should probably be:
if (WIKI_USER_ID_HASH == null) {
WIKI_USER_ID_HASH = new Properties();
if(userIdHashFile.exists()){
WIKI_USER_ID_HASH.load(new FileInputStream(userIdHashFile));
}
}
- Thanks! Will be fixed in the source repository momentarily. -- Ryan 22-Aug-2006 14:19 PDT
- That was fast. -- garem 22-Aug-2006 17:24 EST
- I do my best, thanks for the bug report. The fix will be in JAMWiki 0.3.0, which should be out in the next day or two. -- Ryan 22-Aug-2006 14:29 PDT
[Edit]Named Anchor / Pipe Link within Table
When I try to use a named anchor / pipe link in a table, the link does not render correctly. Example:
| This | is |
|---|---|
| a | Title |
- The problem is that the pipe symbol is used to indicate link text AND to indicate table style information - in this case it's choosing wrong. It's a bit late here now and I'm tired enough that I don't trust myself around the parser code, but I'll work on a fix tomorrow morning. -- Ryan 15-Aug-2006 00:56 PDT
- This should be OK now. Fix will be included with JAMWiki 0.2.1 - provided I didn't break anything else with this change 8-P -- Ryan 15-Aug-2006 12:19 PDT
[Edit]Print - Edit links
Does the printable page need the "edit" links included for each section? -- scroco 14-Aug-2006 11:33 PDT
- Yeah, that's an oversight, but it should about a 30 second fix once the repository is fixed. Thanks for the report. -- Ryan 14-Aug-2006 11:51 PDT
- Fixed in the source repository, I'll push it to jamwiki.org a bit later when traffic to the site slows down. -- Ryan 14-Aug-2006 14:38 PDT
[Edit]Print - No Topic
Not sure if this is a bug or a feature ... When bringing up the printable version of a page, the Topic title is not displayed. -- scroco 11-Aug-2006 14:49 PDT
- It's a bug, but one of the good kind (easy to fix). I just pushed a bunch of new code onto jamwiki.org that includes a fix. -- Ryan 11-Aug-2006 15:03 PDT
[Edit]XSS10
| X |
- Should be fixed now, will be released with JAMWiki 0.2.0. -- Ryan 11-Aug-2006 14:03 PDT
[Edit]XSS11
| X |
- Should be fixed now, will be released with JAMWiki 0.2.0. -- Ryan 11-Aug-2006 14:03 PDT
[Edit]XSS8
| X |
| </u> |
MediaWiki used to have the same problem. -- All the best, NickJ.
- Thanks, I'll see if I can update the parser to be more strict about disabling Javascript, hopefully for the next release. -- Ryan 28-Jul-2006 19:41 PDT
- Javascript is now a configurable option, and without enabling it I think all of the "onFoo" functions should be disabled. This change will be released with JAMWiki 0.1.1, hopefully in the next day or two. Thanks again for the report. -- Ryan 29-Jul-2006 22:54 PDT
- You're welcome. There's a MediaWiki fuzz tester that I wrote that may help you with finding some of these types of things. If you'd like I can paste the URL in here when I update it next, which should be sometime this week; it's in PHP and would need some updating of URLs and suchlike to test JAMwiki, but it could perhaps be useful. -- All the best, NickJ.
- I'd appreciate the link if you'd be willing. At the moment it has been one month since JAMWiki 0.0.1 was released, so developer resources are still a bit scarce (I'm coding as fast as I can!). My hope is that as time goes on and the code settles down a bit there will be more people getting involved and more hours to put into looking out for these sorts of issues. With any luck things will progress to the point where I/we can begin feeding some reports back towards Mediawiki, although given your head start that's probably a long ways off. Anyhow, thanks a million for the help! -- Ryan 31-Jul-2006 00:55 PDT
- You're welcome. There's a MediaWiki fuzz tester that I wrote that may help you with finding some of these types of things. If you'd like I can paste the URL in here when I update it next, which should be sometime this week; it's in PHP and would need some updating of URLs and suchlike to test JAMwiki, but it could perhaps be useful. -- All the best, NickJ.
- Javascript is now a configurable option, and without enabling it I think all of the "onFoo" functions should be disabled. This change will be released with JAMWiki 0.1.1, hopefully in the next day or two. Thanks again for the report. -- Ryan 29-Jul-2006 22:54 PDT
[Edit]Tomcat stack overflow during setup
java.lang.StackOverflowError when launching 0.0.8 for the first time. Windows XP, Tomcat 5.0.28, JDK 1.4, file persistence. Perhaps related to file persistence fix for 0.0.8.
- Is there any additional log information from that error? Perhaps a stack trace? StackOverflow can be due to a lot of different issues, so I'll need need a bit more information to try and figure out what's going on. You can find that additional info in either the c:/jamwiki.log file or in the Tomcat /logs/stdout.log file. Thanks for the report! -- Ryan 24-Jul-2006 12:01 PDT
From jamwiki.log:
2006-07-24 12:42:18,278 [http-8080-Processor25] ERROR org.jamwiki.parser.ParserUtil - Failure while parsing link StartingPoints 2006-07-24 12:42:18,294 [http-8080-Processor25] ERROR org.jamwiki.parser.ParserUtil - Failure while parsing link AdminOnlyTopics
Not much in stdout for some reason. I'll keep looking.
- I think that those two errors are actually OK during setup - they just mean that no topic information exists yet for the links, which is expected prior to setup (I need to clean up the process to not write an error in that case, but the to-do list is looooong). I'm hoping that your Tomcat stdout.log has some additional information as this seems like a case where the application server got angry for some reason.
- One additional thing to be sure of is that you're starting the install process with a clean installation - if you've previously tried to install JAMWiki and it failed, make sure you delete everything from the JAMWiki webapp location and then install a fresh copy of jamwiki 0.0.8. It's possible that if an install previously failed that it may have left a partially installed system. The worst case scenario is that I can install JDK 1.4 and Tomcat 5.0.28 on my system and try to track the issue down, but things are pretty busy right now so it will probably be at least a few days before I get to that. Sorry for the problems, and the feedback is very much appreciated! -- Ryan 24-Jul-2006 14:05 PDT
Looks like the stack overflow is due to some sort of recursive forwarding. Here is a snippet of the stack trace (sorry it's long!):
... at org.apache.jsp.WEB_002dINF.jsp.wiki_jsp._jspService(wiki_jsp.java:173) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:94) ''trimmed'' at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:704) at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:474) at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:409) at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:312) at org.apache.jasper.runtime.PageContextImpl.doForward(PageContextImpl.java:670) at org.apache.jasper.runtime.PageContextImpl.forward(PageContextImpl.java:637) at org.apache.jsp.WEB_002dINF.jsp.wiki_jsp._jspService(wiki_jsp.java:173) ...
- Perfect, thanks! That forward has been problematic, so I'll see if I can figure out some way of making sure it doesn't loop forever. In the mean time (and if you're willing) could you confirm that this problem is occurring with a fresh install - deleting the current JAMWiki WAR installation and re-installing with 0.0.8, and deleting any files that may be in your JAMWiki file directory (specified during setup, if it let you get that far) should do the trick. Again, many thanks for help in tracking this issue down. -- Ryan 24-Jul-2006 14:37 PDT
Yes, it was definitely a clean install.
- OK, thanks for confirming. I'll have to install JDK 1.4 and Tomcat 5.0.28, but once that's done I'll see if I can reproduce this issue and try to get a fix ready - hopefully either tonight or early tomorrow. -- Ryan 24-Jul-2006 15:55 PDT
- I think I've fixed the problem (JAMWiki 0.0.9 now installs with Tomcat 5.0.28 for me) and I've released the fix as JAMWiki 0.0.9 - it seemed like a fairly serious issue that might affect more than just Tomcat (not sure how I didn't catch it during testing). 0.0.9 can be downloaded from Sourceforge (link is on the front page but it may take a short while for the mirrors to update).
- The only change in this release is this bugfix; if JAMWiki 0.0.8 is installed and working there is no need to upgrade. I appreciate the feedback on this issue and I'm sorry for the problems - please let me know if this change fixes the problem for you. -- Ryan 24-Jul-2006 18:34 PDT
0.0.9 is now working in JDK 1.4 with Tomcat 5.0.28. Thanks!
- Great, thanks for your help in reporting this issue and tracking it down, it is much appreciated! -- Ryan 25-Jul-2006 10:31 PDT
[Edit]Article title
I see on top of the page article name twice: JAMWiki - Feedback and Feedback next to it, what is it? Feature or mistake?
- It's a bug in the new image handling code. Thanks for catching it, a fix will be in Subversion shortly. -- Ryan 13-Jul-2006 16:41 PDT
- Fixed in Subversion and on jamwiki.org now. -- Ryan 13-Jul-2006 16:48 PDT
Ok, thanks! :) -- AleXis
[Edit]Locking issue
One more question - did you implement locking for editing? Looks like we both edited this article at same time)
- Ok)) I see changes in Issues)
- May be move discussion into comments? I.e. make it like three, forum?
-- AleXis
- If you'd rather have the comments there then please feel free to move them. I was planning on removing the old locking code and replacing it with something more reliable soon, although there's a lot to be done, so I don't know exactly when I'll get to it. Once the 0.0.6 release is done I'll take a look at how much work is involved (it shouldn't take more than a half day, I hope). My plan was also to implement section edits (for example, an edit link next to "Locking issue" above that shows only the text for that section) so altogether it's probably a full day's work to implement both. -- Ryan 13-Jul-2006 16:19 PDT
Section edit is cool feature! Its very useful! :) -- AleXis
[Edit]Caching issue
I am using Opera, and it shows cached versions of pages too long, so i am offer to keep page size small (by separating CSS) and add "no cache" headers. What do you think about it?
MediaWiki uses this header: Cache-Control: private, s-maxage=0, max-age=0, must-revalidate
If it situable you can use this filter (only for jsp's, it is important):
package ...;
import javax.servlet.*;
import javax.servlet.http.HttpServletResponse;
import java.io.IOException;
public class CachingPreventFilter implements Filter {
public void init(FilterConfig filterConfig) throws ServletException {
}
public void doFilter(ServletRequest servletRequest, ServletResponse servletResponse,
FilterChain filterChain) throws ServletException, IOException {
if (servletResponse instanceof HttpServletResponse) {
HttpServletResponse hr = (HttpServletResponse)servletResponse;
hr.setHeader("Cache-Control", "no-cache, no-store, must-revalidate");
hr.setHeader("Pragma", "no-cache");
}
filterChain.doFilter(servletRequest, servletResponse);
}
public void destroy() {
}
}
-- AleXis
- Having the CSS file not be included inline within the HTML is on my To Do List, but if you're interested in working on it then I'd be glad for the help. If not I was planning on adding it for either the 0.0.7 or 0.0.8 releases (some time in the next week or two). The cache headers is easier to solve though - I've added the response headers you suggested to the JSP files, although instead of using a filter I simply added response.setHeader() methods within the JSP pages. That change is live on jamwiki.org now - do you still see the same problems with Opera? I thought Spring was supposed to be handling cache headers for me, but I'll have to go back and re-read the documentation a bit more I guess. Thanks again for pointing this out. -- Ryan 12-Jul-2006 17:01 PDT
Thank you! It works! Page reloads correctly :) I've created new head for styles issue -- AleXis
[Edit]Problems with compiling in Resin
I am using Resin container and have such messages: com.caucho.java.JavaCompileException: /WEB-INF/jsp/setup.jsp:114: code too large for try statement } catch (Throwable _jsp_exn_1306) {
And 8 errors more
It is possible to fix this problem?
- I'll take a look at it and try to get a fix in the 0.0.6 release. Thanks for the bug report! -- Ryan 12-Jul-2006 12:58 PDT
- For those finding this page from search engines, the issue is that a compiled JSP page cannot be larger than a certain maximum size which varies with compiler. To solve the problem either move some code out of your JSP, or else use jsp:include directives to split the JSP file into smaller units. -- Ryan 01-Aug-2006 22:02 PDT
Thank you! Also one problem with libs: commons-logging.jar is missing by default and Resin does not want run web app. Please add it to libs :) -- AleXis
- Can you elaborate on the problem with commons-logging? As far as I'm aware there isn't any code using it, although some of the Spring framework classes offer commons-logging support and can optionally use commons logging features. -- Ryan 12-Jul-2006 13:57 PDT
It is log from Resin, he stops loading web app after java.lang.NoClassDefFoundError: org/apache/commons/logging/LogFactory exception. Looks like problem in org.springframework.web.servlet.DispatcherServlet.<clinit>(DispatcherServlet.java:215). May be some option to pervent logging exists in configuration? -- AleXis
[01:38:41.609] java.lang.NoClassDefFoundError: org/apache/commons/logging/LogFactory [01:38:41.609] at org.springframework.web.servlet.DispatcherServlet.<clinit>(DispatcherServlet.java:215) [01:38:41.609] at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) ''trimmed by [[User:wrh2|Ryan]] for readability'' [01:38:41.625] ... 20 more
- Thanks, that explains the problem. I'll see what I can do to resolve that issue as well, although hopefully there won't be a need to include another jar file in the distribution - it's already quite large! Thanks again, the bug reports are much appreciated! -- Ryan 12-Jul-2006 14:55 PDT
Nop :) Thank you! Logging lib is only 38Kb - I think it is not a big problem :) Will wait for new release :) -- AleXis
[Edit]Small problem building from source
When building from the latest SVN source with "ant war" I get this error:
BUILD FAILED /home/hamish/ext/jamwiki/latest/jamwiki/build.xml:79: /home/hamish/ext/jamwiki/latest/jamwiki/local-files not found.
(Ant 1.6.5 on Sun Java 1.5.0 on Ubuntu edgy.)
If I mkdir local-files the error goes away. Perhaps the source tree should contain an empty local-files?
Hamish Cunningham 2-Mar-2007
- Thanks for pointing this out - it should be fairly trivial to update the build script, so I'll make sure that gets done prior to the 0.5.2 release. -- Ryan 02-Mar-2007 19:23 PST
[Edit]Endless loop with certain topic names
I discovered a critical problem with certain wiki words with a certain length and having an "?" at the end. E.g. [[Urnordisch oder Nordwestgermanisch?]] causes the engine to use 100% cpu power for a few minutes. It loops at the following point:
at java.util.regex.Pattern$GroupTail.match(Pattern.java:4629) ... ... ... at java.util.regex.Pattern$Curly.match0(Pattern.java:4235) at java.util.regex.Pattern$Curly.match(Pattern.java:4197) at java.util.regex.Pattern$GroupHead.match(Pattern.java:4570) at java.util.regex.Pattern$Dummy.match(Pattern.java:2993) at java.util.regex.Pattern$Branch.match(Pattern.java:4530) at java.util.regex.Pattern$GroupHead.match(Pattern.java:4570) at java.util.regex.Pattern$Branch.match(Pattern.java:4530) at java.util.regex.Pattern$GroupHead.match(Pattern.java:4570) at java.util.regex.Pattern$Loop.matchInit(Pattern.java:4713) at java.util.regex.Pattern$Prolog.match(Pattern.java:4653) at java.util.regex.Matcher.match(Matcher.java:1114) at java.util.regex.Matcher.matches(Matcher.java:495) at org.jamwiki.utils.LinkUtil.parseWikiLink(LinkUtil.java:271) at org.jamwiki.parser.jflex.WikiLinkTag.parseWikiLink(WikiLinkTag.java:185) at org.jamwiki.parser.jflex.WikiLinkTag.processLinkMetadata(WikiLinkTag.java:211) at org.jamwiki.parser.jflex.WikiLinkTag.parse(WikiLinkTag.java:109) at org.jamwiki.parser.jflex.AbstractLexer.parseToken(AbstractLexer.java:106) at org.jamwiki.parser.jflex.JAMWikiPreProcessor.yylex(JAMWikiPreProcessor.java:760) at org.jamwiki.parser.jflex.JFlexParser.lex(JFlexParser.java:114) at org.jamwiki.parser.jflex.JFlexParser.parsePreProcess(JFlexParser.java:204) at org.jamwiki.parser.jflex.JFlexParser.parseHTML(JFlexParser.java:163)
guido
- Thanks, I just noticed that the Sandbox was broken and was investigating what happened - your stack trace is a big help. This will definitely get fixed for 0.5.2. -- Ryan 25-Feb-2007 10:40 PST
- I think I've got a fix available, but it may break some other link parsing so I'd like to test it on jamwiki.org for a while. Code is in Subversion and can also be downloaded from Feedback#JAMWiki 0.5.2 beta 2. -- Ryan 25-Feb-2007 21:19 PST
[Edit]jamwiki-configuration.dtd missing elements
The elements parsers user-handlers? data-handlers are not defined -- Jack 07-Mar-2007
- Thanks, I've checked in a fix for 0.5.3. -- Ryan 18-Mar-2007 14:24 PST
[Edit]java.lang.ClassCastException: java.lang.Integer in several pages
I've found the "java.lang.ClassCastException: java.lang.Integer" error running JAMwiki 0.5.2 with Resin 3.1.0, internal database and Java 1.5.0_07. Error persists on following pages:
- Special:RecentChanges
- Special:History for any existing topic
- Special:Watchlist for any existing topic or when topic is not specified
Here is sample from Special:RecentChanges page:
java.lang.ClassCastException: java.lang.Integer
at org.springframework.web.util.ExpressionEvaluationUtils.evaluateString(ExpressionEvaluationUtils.java:186)
at org.jamwiki.taglib.LinkParamTag.doEndTag(LinkParamTag.java:47)
at _jsp._WEB_22dINF._jsp._recent_22dchanges__jsp._jspService(_recent_22dchanges__jsp.java:400)
at com.caucho.jsp.JavaPage.service(JavaPage.java:61)
at com.caucho.jsp.Page.pageservice(Page.java:577)
at com.caucho.server.dispatch.PageFilterChain.doFilter(PageFilterChain.java:190)
at com.caucho.server.webapp.DispatchFilterChain.doFilter(DispatchFilterChain.java:97)
at com.caucho.server.dispatch.ServletInvocation.service(ServletInvocation.java:226)
at com.caucho.server.webapp.RequestDispatcherImpl.include(RequestDispatcherImpl.java:488)
at com.caucho.server.webapp.RequestDispatcherImpl.include(RequestDispatcherImpl.java:353)
at com.caucho.jsp.PageContextImpl.include(PageContextImpl.java:957)
at _jsp._WEB_22dINF._jsp._wiki__jsp._jspService(_wiki__jsp.java:1237)
at com.caucho.jsp.JavaPage.service(JavaPage.java:61)
at com.caucho.jsp.Page.pageservice(Page.java:577)
at com.caucho.server.dispatch.PageFilterChain.doFilter(PageFilterChain.java:190)
at com.caucho.server.webapp.DispatchFilterChain.doFilter(DispatchFilterChain.java:97)
at com.caucho.server.dispatch.ServletInvocation.service(ServletInvocation.java:226)
at com.caucho.server.webapp.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:279)
at com.caucho.server.webapp.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:108)
at org.springframework.web.servlet.view.InternalResourceView.renderMergedOutputModel(InternalResourceView.java:142)
at org.springframework.web.servlet.view.AbstractView.render(AbstractView.java:247)
at org.springframework.web.servlet.DispatcherServlet.render(DispatcherServlet.java:1105)
at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:841)
at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:755)
at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:396)
at org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:350)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:115)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:92)
at com.caucho.server.dispatch.ServletFilterChain.doFilter(ServletFilterChain.java:103)
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.caucho.server.dispatch.FilterFilterChain.doFilter(FilterFilterChain.java:73)
at org.jamwiki.servlets.JAMWikiFilter.doFilter(JAMWikiFilter.java:56)
at com.caucho.server.dispatch.FilterFilterChain.doFilter(FilterFilterChain.java:73)
at com.caucho.server.webapp.WebAppFilterChain.doFilter(WebAppFilterChain.java:167)
at com.caucho.server.dispatch.ServletInvocation.service(ServletInvocation.java:226)
at com.caucho.server.http.HttpRequest.handleRequest(HttpRequest.java:263)
at com.caucho.server.port.TcpConnection.run(TcpConnection.java:477)
at com.caucho.util.ThreadPool$Item.runTasks(ThreadPool.java:591)
at com.caucho.util.ThreadPool$Item.run(ThreadPool.java:513)
at java.lang.Thread.run(Thread.java:595)
-- aevdokimov
- Thanks, I'll investigate. -- Ryan 08-Mar-2007 13:51 PST
- The problem is either in the Spring ExpressionEvaluationUtils.evaluateString method or in Resin's JSTL interpretor, but either way I've got a workaround that should fix the problem for JAMWiki 0.5.3. I'll include the fix in the first beta. Thanks for the report. -- Ryan 18-Mar-2007 12:35 PST
[Edit]Stacktrace in jamwiki.log.0
Hi Ryan, I recently found a stacktrace in my jamwiki.log-file, when I was looking for the problem to be unable to link to uploaded images ([2]). the image link is blue - asigning that there is a image uploaded (as I verified on the filesystem) - I do not see it on the page, and if I klick on the link I get the reported error.
- My Stacktrace:
2007-03-08 09:13:29,665 INFO: org.jamwiki.servlets.JAMWikiServlet - Loaded page /jamwiki-0.5.0/de/Technik (0.827 s.) 2007-03-08 09:13:30,770 INFO: org.jamwiki.parser.jflex.AbstractLexer - Unable to parse == java.lang.StringIndexOutOfBoundsException: String index out of range: -2 at java.lang.String.substring(String.java:1768) at org.jamwiki.parser.jflex.WikiHeadingTag.parse(WikiHeadingTag.java:76) at org.jamwiki.parser.jflex.AbstractLexer.parseToken(AbstractLexer.java:106) at org.jamwiki.parser.jflex.JAMWikiProcessor.yylex(JAMWikiProcessor.java:1410) at org.jamwiki.parser.jflex.JFlexParser.lex(JFlexParser.java:114) at org.jamwiki.parser.jflex.JFlexParser.parseProcess(JFlexParser.java:220) at org.jamwiki.parser.jflex.JFlexParser.parseHTML(JFlexParser.java:164) at org.jamwiki.utils.Utilities.parse(Utilities.java:763) at org.jamwiki.servlets.ServletUtil.viewTopic(ServletUtil.java:486) at org.jamwiki.servlets.ServletUtil.viewTopic(ServletUtil.java:445) at org.jamwiki.servlets.TopicServlet.view(TopicServlet.java:59) at org.jamwiki.servlets.TopicServlet.handleJAMWikiRequest(TopicServlet.java:45) at org.jamwiki.servlets.JAMWikiServlet.handleRequestInternal(JAMWikiServlet.java:72) at org.springframework.web.servlet.mvc.AbstractController.handleRequest(AbstractController.java:153) at org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter.handle(SimpleControllerHandlerAdapter.java:45) at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:820) at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:755) at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:396) at org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:350) at javax.servlet.http.HttpServlet.service(HttpServlet.java:743) at javax.servlet.http.HttpServlet.service(HttpServlet.java:856) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) 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 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.jamwiki.servlets.JAMWikiFilter.doFilter(JAMWikiFilter.java:56) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:214) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:198) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:152) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:137) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:118) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:929) at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:160) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:799) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:705) at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:577) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684) at java.lang.Thread.run(Thread.java:595) 2007-03-08 09:13:30,842 INFO: org.jamwiki.parser.jflex.JFlexParser - Parse time (parseHTML) for Todos (0.091 s.)where can I search for the origin of the parser-Error? -- Michael Habbert 10-Mar-2007 05:58 PST
- The reported error is a failure to parse a heading - the code in question is in org.jamwiki.parser.jflex.WikiHeadingTag. The cause of the problem, however, is probably that whatever text is in your topic is not being handled properly by the parser's expression matching - those expressions are in the source repository under /src/lex/. Could you copy the source of the page that is causing the parser errors to jamwiki.org? That might make it easier to investigate and debug. Thanks! -- Ryan 10-Mar-2007 09:24 PST
- Hi Ryan, looks like the == is the origin of the parser-problem.
== Service-Call 1und1 == 19.02.07 : Servicecall 1und1. Ich wurde umgeroutet, wenn es in 5 Tagen wieder schlechter wird - dies dem Service-techniker erzählen. Rauschunterdrückung mit: #614*1* aktiviert und die Kompression aktiviert. ==> Telefon geht wieder! -- 1und1 Service-Telefon: telefonnummer 13.03.07 Seit gestern immer wieder Verbindungsabbruch (nicht von der Arbeit aus erreichbar!). : heute nach Neustart des Routers scheinbar wieder ok. 14.03.07 17:17 20 berater: beratername sei zu alt: Momentan installierte Firmware-Version: 23.04.15 und der anschluß der box an der zweiten Telefon-dose ist nicht korrekt! http://www.avm.de/de/Download/index.php3 aktuelle Firmware: FRITZ!Box Fon 5010 (UI), Firmware-Version 23.04.27 heruntergeladen und installiert.
- Hi Ryan, looks like the == is the origin of the parser-problem.
hopefully you can catch it now. For me the substitution of the == with -- avoided the parser-error. Thanks ;-) -- Michael Habbert 14-Mar-2007 12:16 PST
- Thanks! The problem is in the jamwiki-processor.jflex file, and I think the following change should fix it:
- Change:
wikiheading = [\=]+ [^\n\=]* [\=]+
- To:
wikiheading = [\=]+ [^\n\=]+ [\=]+
- I should have some time to do some testing this Sunday, so I'll give it a spin and if it works I'll put it in the source repository. Thanks for the report! -- Ryan 14-Mar-2007 20:42 PST
- Surprisingly, despite a long day at work I felt like working on code, so I ran through a few tests on my local instance with this fix, and the error in the logs is gone. As a result I've pushed the fix to the source repository. Thanks again for the bug report. -- Ryan 14-Mar-2007 22:22 PST
[Edit]Equals in Headers
Equals signs in headers work in MediaWiki, but not in JamWiki. Try "== = in Headers ==".
- I think I've got this fixed now, although it's possible that the fix may affect other patterns in headings so some testing is needed. In any case, the new code is now in Subversion and on jamwiki.org, and if it doesn't cause any problems I'll release it with JAMWiki 0.5.3. -- Ryan 24-Mar-2007 14:20 PST
[Edit]Includeonly in templates
I'm using the includeonly-tag in templates to set the category:
<includeonly>[[Category:MyCategory]]</includeonly>
It works correctly, the category is shown in the footer of the article. But the category-page itself don't show the article. If I'm putting the category in the article directly, the article is shown in the category-page. User:Ralf
- Thanks for the report! I'll look into it and try to get a fix ready for JAMWiki 0.5.0. -- Ryan 24-Dec-2006 17:25 PST
- It turns out that the fix to this issue could affect a lot of code, and since it's late in the 0.5.0 development cycle this fix will need to be put off until 0.5.1. It will get fixed eventually though! -- Ryan 26-Dec-2006 22:37 PST
- I'm working on this bug for JAMWiki 0.5.4. The plan is to update the parser to more properly handle generation of metadata, and hopefully to simplify the parser code in the process. Depending on how crazy work gets this week it could be anywhere between a couple of days and a couple of weeks until everything is committed to Subversion. -- Ryan 08-Apr-2007 23:18 PDT
- I've got a fix for this in Subversion now, and it will be included in JAMWiki 0.5.4. The current code has performance issues, but I'll resolve those prior to the final release. Also, the new code isn't yet (as of today) on jamwiki.org since I'd like to do a bit more testing, but I'll put it on the site soon, and will include it in the first beta for 0.5.4. -- Ryan 12-Apr-2007 23:36 PDT
[Edit]noinclude in other pages
In a similar vein, I noticed that if I just do a standard page include that is not a template using:
{{RegularPage}}
that if RegularPage looks like
<noinclude>Should not be visible when included</noinclude> This text should be visible when included
the resulting page shows all the text including the noinclude tags. If RegularPage is defined in the Template namespace as Template:RegularPage then the noinclude tags are processed correctly. I confirmed on the sandbox page at mediawiki that the noinclude should be honored even if the page is not in the Template namespace. -- Unregistered user-Jere 27-Dec-2006
- This one will probably also get fixed, but it will also need to wait until at least 0.5.1. I was under the impression that <includeonly> and <noinclude> were template-only tags, but if that's not the case then it shouldn't be too difficult to modify. -- Ryan 26-Dec-2006 22:40 PST
- This issue should also be addressed by the parser updates planned for 0.5.4. -- Ryan 08-Apr-2007 23:18 PDT
- I've got a fix for this in Subversion now, and it will be included in JAMWiki 0.5.4. The current code has performance issues, but I'll resolve those prior to the final release. Also, the new code isn't yet (as of today) on jamwiki.org since I'd like to do a bit more testing, but I'll put it on the site soon, and will include it in the first beta for 0.5.4. -- Ryan 12-Apr-2007 23:36 PDT
[Edit]NoSuchMethodException (Lucene)
This is a nested exception (deep in the bowels of Spring building a class TopicSpaces uses, which, itself, creates database objects): nested exception is java.lang.NoSuchMethodError: org.apache.lucene.document.Document.add(Lorg/apache/lucene/document/Field;)V
Google that and you see that others are starting to report it as well. Seems to show up in the Lucene 2.0/2.1 transition and nobody seems to have a clue why it's happening. Here is what is going on. As I complete booting JAMWiki, I follow by booting TopicSpaces, which, at this time, is building a new database of its own. While it is creating its own classes, it sends new Topic events into JAMWiki, which fires up Lucene to perform indexing. The exception is tossed in LuceneSearchEngine.createStandardDocument just as it is doing the first doc.add(new Field...) call.
It is interesting that it is showing a NoSuchMethodException; one must decide is there no Document.add() with that signature, or is there no new Field(...) with that signature. Clearly, the source code suggests those methods exist.
Slightly off topic, but one has to wonder (doesn't one?): LuceneSearchEngine is filled with deprecated FSDirectory.getDirectory calls, where telling FSDirectory whether to "create" or not is now handed to IndexWriter's create flag. -- park 09-Apr-2007 11:19 PST
- Interesting observation. Remove lucene core 2.1.0 and replace with 2.0.0 (but leave highlighter alone) and the error shifts to NoClassDefFoundError for org.apache.lucene.document.Fieldable (which is included in 2.1 but not in 2.0. So who's calling Fieldable? It's not referenced anywhere in the highlighter source code. Highlighter must be calling something that, itself, needs that. Replace highlighter 2.1 with 2.0 and the failure persists. So much for that theory. Doing a global search in JAMWiki search finds no references to it. Running out of options... -- park
- The plot thickens. Found a comment by someone in a longish email thread where they simply started over and the bug went away. I removed the 2.0 Lucene jars, renamed the 2.1 jars back to .jar (I never actually removed them, just changed them from being jar files), and presto!, TopicSpaces booted. I don't think that's the last of that bug... -- park
- It's not! Had occasion to do a fresh boot again. Tried booting 4 times all with the same NoSuchMethodException. Then swapped back to 2.0 Lucene and got the NoClassDefFounderror. Then switched back to 2.1 and it boots fine. -- park
- Thanks for the detailed updates. If I see this in my own environment I'll investigate - as to the use of deprecated files, I just upgraded to 2.1, so if files were newly deprecated we'll eventually need to update the code. Feel free to send fixes :) -- Ryan 10-Apr-2007 08:53 PDT
- I managed to upgrade the LuceneSearchEngine: just delete the true and false elements of the calls to FSDirectory.getDirectory since it now just takes a String. Before I did that, the problem I reported did exist just once while booting JAMWiki alone. But, the larger, repeating problem turned out to be not in JAMWiki but in Jackrabbit. I am not seeing the problem either in JAMWiki or in Jackrabbit since I rebuilt Jackrabbit against 2.1.0. The change from Field to Fieldable in Lucene made precompiled jars grumpy. In fact, I am no suspicious that I had been playing with a JAMWiki jar (yes, I modified build.xml to make a jar) that had been compiled against Lucene 2.0.0, and it may well be that this was the problem all along. -- park
[Edit]UserID Collisions
Archived from the Feedback page:
JamWiki 0.3.6, File mode
I don't know if this has been reported or resolved - There are a number of user collisions on 0.3.6 where a new user will get assigned the same ID as an existing user (discovered after an examination of the user account xml files). The result is the new user will seem to hijack all of the edits the previous user made. Both can still log in and make new entries, however JamWiki will only see the new user when listing edit history, etc.
- Since JAMWiki version 0.4.0 file persistency mode has been completely rewritten to use an embedded version of the HSQL database, so unfortunately a bug report from version 0.3.6 is probably no longer relevant to the current code base. Thanks for the report though! -- Ryan 14-Apr-2007 09:55 PDT
==Incorrect table definition; there can be only one TIMESTAMP column with
CURRENT_TIMESTAMP in DEFAULT or ON UPDATE clause==
Installed JAMWiki into Tomcat, bounced Tomcat, then connected to the JAMWiki application. After filling out the initial configuration information, I am getting the following error message when on the initial Setup dialog:
An unknown system error has occurred. The error message is: Failure while executing CREATE TABLE jam_wiki_user ( wiki_user_id INTEGER NOT NULL, login VARCHAR(100) NOT NULL, display_name VARCHAR(100), create_date TIMESTAMP DEFAULT CURRENT_TIMESTAMP NOT NULL, last_login_date TIMESTAMP DEFAULT CURRENT_TIMESTAMP NOT NULL, create_ip_address VARCHAR(15) NOT NULL, last_login_ip_address VARCHAR(15) NOT NULL, is_admin INTEGER DEFAULT 0 NOT NULL, remember_key VARCHAR(100) NOT NULL, default_locale VARCHAR(8), CONSTRAINT jam_pk_wiki_user PRIMARY KEY (wiki_user_id) ).
Signed into the MySQL database (via phpMyAdmin) and manually fired off the command, and got the following error:
SQL query: CREATE TABLE jam_wiki_user( wiki_user_id INTEGER NOT NULL , login VARCHAR( 100 ) NOT NULL , display_name VARCHAR( 100 ) , create_date TIMESTAMP DEFAULT CURRENT_TIMESTAMP NOT NULL , last_login_date TIMESTAMP DEFAULT CURRENT_TIMESTAMP NOT NULL , create_ip_address VARCHAR( 15 ) NOT NULL , last_login_ip_address VARCHAR( 15 ) NOT NULL , is_admin INTEGER DEFAULT 0 NOT NULL , remember_key VARCHAR( 100 ) NOT NULL , default_locale VARCHAR( 8 ) , CONSTRAINT jam_pk_wiki_user PRIMARY KEY ( wiki_user_id ) ) MySQL said: Documentation #1293 - Incorrect table definition; there can be only one TIMESTAMP column with CURRENT_TIMESTAMP in DEFAULT or ON UPDATE clause
Here are the relevant software versions:
| Software | Version |
|---|---|
| JAMWiki | 0.5.3 |
| Tomcat | 5.5.15 |
| JVM | 1.5.0_11-b03 |
| MySQL | 4.1.21 |
| ConnectorJ | 5.0.5 |
| OS | Linux 2.6.19.3-grsec-r3 |
Would appreciate any assistance you can offer. My guess is the issue is with the SQL against MySql 4.1.27, as the same set of install files worked great for me with MySQL 5.0.x install (though under WinXP, not Linux).
The Supported_Configurations page advises JAMWiki works with MySql 4.1, but am wonder if there is perhaps a gotcha here I have not yet unraveled.
Did not see any JAMWiki errors in the Tomcat log files.
Thanks!
--RobW 02-May-2007 20:26 PDT
- When JAMWiki was set up did you select the MySQL option? The create table statement for jam_wiki_user for MySQL includes only a single "CURRENT_TIMESTAMP" default and should work. If you selected MySQL as the database type and there were still problems I'll need to investigate further. For reference, the SQL statement in the properties file is:
STATEMENT_CREATE_WIKI_USER_TABLE = \ CREATE TABLE jam_wiki_user ( \ wiki_user_id INTEGER NOT NULL, \ login VARCHAR(100) NOT NULL, \ display_name VARCHAR(100), \ /* FIXME - mysql only allows one column to use CURRENT_TIMESTAMP, but this should default also */ \ create_date TIMESTAMP NOT NULL DEFAULT 0, \ last_login_date TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP, \ create_ip_address VARCHAR(15) NOT NULL, \ last_login_ip_address VARCHAR(15) NOT NULL, \ is_admin INTEGER NOT NULL DEFAULT 0, \ remember_key VARCHAR(100) NOT NULL, \ default_locale VARCHAR(8), \ CONSTRAINT jam_pk_wiki_user PRIMARY KEY (wiki_user_id) \ )
Thanks for the report! -- Ryan 02-May-2007 21:40 PDT
Ryan,
Bullseye. This was definitely a between the keyboard and chair problem, not a bug! Somehow I missed this step twice by leaving the database type as Ansi. I switched the type to MySQL and JAMWiki is now working like a charm.
Thank you very much for the quick response!
--RobW 03-May-2007 06:27 PDT
- This sort of "bug" is much easier for me to solve than something that requires digging through the code and modifying some obscure method :) Glad it solved your problem. -- Ryan 03-May-2007 09:56 PDT