Bug Reports/Resolved/0.9.x
This page is an archive of Bug Reports resolved during the JAMWiki 0.9.x release cycle. See Bug Reports/Resolved for an index of all resolved bug reports.
[Edit]"Remember Me" broken on trunk
Per this post, "remember me" functionality is broken in Spring Security 3.0.1, which is the version currently in use on the JAMWiki trunk and on jamwiki.org (but not in any released versions). Upgrading to the next bugfix version of Spring Security should presumably solve this issue. -- Ryan • (comments) • 07-Feb-2010 16:42 PST
- revision 2875 downgrades to version 3.0.0 of Spring Security - the "remember me" issue was proving extremely annoying so it wasn't worthwhile waiting for a fixed version. -- Ryan • (comments) • 08-Feb-2010 21:16 PST
[Edit]Section links (on same page) broken
Links of the form [[Bug Reports#Wrong Path for Uploads]] (Bug Reports#Wrong Path for Uploads) are currently parsing incorrectly. Leaving out the topic name works - [[#Wrong Path for Uploads]] (#Wrong Path for Uploads). -- Ryan • (comments) • 10-Feb-2010 11:53 PST
- revision 3058 fixes this issue. -- Ryan • (comments) • 11-May-2010 22:27 PDT
[Edit]Upgrade from 0.6.7 to 0.8.2 failed
I followed the upgrade instructions. The automatic upgrade failed with an java out of memory error. I checked the manual instructions. All mysql tables seemed to have been changed. So I only changed the version number from 0.6.7 to 0.8.2. The files all have tomca55 as user. The server now tells me:
HTTP Status 404 - /SMwiki/error.jsp
type Status report
message /SMwiki/error.jsp
description The requested resource (/SMwiki/error.jsp) is not available. Apache Tomcat/5.5
I deleted the Tomcat/work/Catalina/wiki directory which did not help. Any ideas?
- Do you have a large wiki? I haven't heard of anyone getting an OOM error on upgrade before and would be curious if there were any specific errors in the logs. That said, the manual upgrade requires following ALL of the upgrade steps from the UPGRADE.txt version for versions after 0.6.7. If you just change the version to 0.8.2 (which is the step for upgrading from 0.8.1 to 0.8.2) then the database will be out of sync with the code, and random errors will be generated. -- Ryan • (comments) • 16-Feb-2010 21:35 PST
- The database.sql is about 6 MB with Data in Hex, I do not consider that a large database, but who knows. I tried to do the manual backup step by step. but I had to notice that the mysql updates already had happened. So I went up in the list and tried to find the last update that had happened. I am sure all of them are in place. There were only two other changes in the list, as far as I can see: Change the version number and some css thing I did not really understand (and not do).
- The CSS upgrade is merely to update the StyleSheet topic to the latest version, but that's optional. Also, 6MB is tiny, so I'm surprised by the OOM error (jamwiki.org is well over 100MB, and I run a test database locally that is about 2GB). Could you paste any errors from your jamwiki.log file here so I can see what is generating the error page? Hopefully that will reveal the problem. -- Ryan • (comments) • 17-Feb-2010 11:48 PST
- Where is that jamwiki.log file meant to be. I have a feeling that it all goes to syslog (Debian) Should I change the logging.properties file somehow?
- See FAQ#I've_encountered_a_problem_/_bug_/_error_with_JAMWiki.__Help!. The
/WEB-INF/classes/logging.propertiesfile configures where log messages are sent. -- Ryan • (comments) • 23-Feb-2010 14:15 PST
- See FAQ#I've_encountered_a_problem_/_bug_/_error_with_JAMWiki.__Help!. The
- Where is that jamwiki.log file meant to be. I have a feeling that it all goes to syslog (Debian) Should I change the logging.properties file somehow?
- The CSS upgrade is merely to update the StyleSheet topic to the latest version, but that's optional. Also, 6MB is tiny, so I'm surprised by the OOM error (jamwiki.org is well over 100MB, and I run a test database locally that is about 2GB). Could you paste any errors from your jamwiki.log file here so I can see what is generating the error page? Hopefully that will reveal the problem. -- Ryan • (comments) • 17-Feb-2010 11:48 PST
- The database.sql is about 6 MB with Data in Hex, I do not consider that a large database, but who knows. I tried to do the manual backup step by step. but I had to notice that the mysql updates already had happened. So I went up in the list and tried to find the last update that had happened. I am sure all of them are in place. There were only two other changes in the list, as far as I can see: Change the version number and some css thing I did not really understand (and not do).
There is the part that happened on my last attempt. I must admit that I did not use chown -R tomcat55 this time, but I did it before and it had no influence. The old log is gone though.
2010-02-23 18:29:50,987 SEVERE: org.jamwiki.servlets.JAMWikiServlet - Servlet error net.sf.ehcache.CacheException: org.jamwiki.db.AnsiDataHandler.CACHE_VIRTUAL_WIKICache: Could not create disk store. Initial cause was /opt/SMwiki/cache/org.jamwiki.db.AnsiDataHandler.CACHE_VIRTUAL_WIKI.data (Permission denied) at net.sf.ehcache.store.DiskStore.<init>(DiskStore.java:175) at net.sf.ehcache.Cache.createDiskStore(Cache.java:675) at net.sf.ehcache.Cache.initialise(Cache.java:640) at net.sf.ehcache.CacheManager.addCacheNoCheck(CacheManager.java:697) at java.lang.Thread.run(Thread.java:619) Caused by: java.io.FileNotFoundException: /opt/SMwiki/cache/org.jamwiki.db.AnsiDataHandler.CACHE_VIRTUAL_WIKI.data (Permission denied) at java.io.RandomAccessFile.open(Native Method) at java.io.RandomAccessFile.<init>(RandomAccessFile.java:212) at net.sf.ehcache.store.DiskStore.initialiseFiles(DiskStore.java:219) at net.sf.ehcache.store.DiskStore.<init>(DiskStore.java:163) ... 45 more 2010-02-23 18:29:50,987 SEVERE: org.jamwiki.servlets.JAMWikiServlet - Servlet error net.sf.ehcache.CacheException: org.jamwiki.db.AnsiDataHandler.CACHE_VIRTUAL_WIKICache: Could not create disk store. Initial cause was /opt/SMwiki/cache/org.jamwiki.db.AnsiDataHandler.CACHE_VIRTUAL_WIKI.data (Permission denied) at net.sf.ehcache.store.DiskStore.<init>(DiskStore.java:175) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:689) at java.lang.Thread.run(Thread.java:619) Caused by: java.io.FileNotFoundException: /opt/SMwiki/cache/org.jamwiki.db.AnsiDataHandler.CACHE_VIRTUAL_WIKI.data (Permission denied) at java.io.RandomAccessFile.open(Native Method) at java.io.RandomAccessFile.<init>(RandomAccessFile.java:212) at net.sf.ehcache.store.DiskStore.initialiseFiles(DiskStore.java:219) at net.sf.ehcache.store.DiskStore.<init>(DiskStore.java:163) ... 45 more 2010-02-23 18:29:50,989 SEVERE: org.jamwiki.servlets.JAMWikiServlet - Unable to load default layout net.sf.ehcache.CacheException: org.jamwiki.db.AnsiDataHandler.CACHE_VIRTUAL_WIKICache: Could not create disk store. Initial cause was /opt/SMwiki/cache/org.jamwiki.db.AnsiDataHandler.CACHE_VIRTUAL_WIKI.data (Permission denied) at net.sf.ehcache.store.DiskStore.<init>(DiskStore.java:175) at net.sf.ehcache.Cache.createDiskStore(Cache.java:675) at net.sf.ehcache.Cache.initialise(Cache.java:640) Caused by: java.io.FileNotFoundException: /opt/SMwiki/cache/org.jamwiki.db.AnsiDataHandler.CACHE_VIRTUAL_WIKI.data (Permission denied) at java.io.RandomAccessFile.open(Native Method) at java.io.RandomAccessFile.<init>(RandomAccessFile.java:212) at net.sf.ehcache.store.DiskStore.initialiseFiles(DiskStore.java:219) at net.sf.ehcache.store.DiskStore.<init>(DiskStore.java:163) ... 43 more 2010-02-23 18:29:50,989 SEVERE: org.jamwiki.servlets.JAMWikiServlet - Unable to load default layout net.sf.ehcache.CacheException: org.jamwiki.db.AnsiDataHandler.CACHE_VIRTUAL_WIKICache: Could not create disk store. Initial cause was /opt/SMwiki/cache/org.jamwiki.db.AnsiDataHandler.CACHE_VIRTUAL_WIKI.data (Permission denied) at net.sf.ehcache.store.DiskStore.<init>(DiskStore.java:175) Caused by: java.io.FileNotFoundException: /opt/SMwiki/cache/org.jamwiki.db.AnsiDataHandler.CACHE_VIRTUAL_WIKI.data (Permission denied) at java.io.RandomAccessFile.open(Native Method) at java.io.RandomAccessFile.<init>(RandomAccessFile.java:212) at net.sf.ehcache.store.DiskStore.initialiseFiles(DiskStore.java:219) at net.sf.ehcache.store.DiskStore.<init>(DiskStore.java:163) ... 43 more 2010-02-23 18:30:18,020 SEVERE: org.jamwiki.jsp - Error in JSP page java.lang.OutOfMemoryError: Java heap space at java.util.Arrays.copyOf(Arrays.java:2882) at java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java:100) at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:390) at java.lang.StringBuilder.append(StringBuilder.java:119) at org.jamwiki.utils.LinkUtil.appendQueryParam(LinkUtil.java:73) at org.jamwiki.utils.LinkUtil.buildEditLinkUrl(LinkUtil.java:99) at org.jamwiki.utils.LinkUtil.buildTopicUrl(LinkUtil.java:359)
PS: the /cache directory is empty.
- During wiki setup there is a step to configure a "file-system directory" which the JAMWiki process must have access to write to. It looks like you've configured
/opt/SMwiki/, but that the permissions on that directory are such that JAMWiki cannot write data there. Fixing the permissions should resolve the problem, which can be done by updating the "File-system directory" parameter on Special:Admin or by directly editing the . Inability to write to thehomeDirproperty in your jamwiki.properties file. An invalid file-system directory is a fatal error for JAMWiki, although I'll investigate to see if I can determine why it would result in a OOM error rather than a more user-friendly message. -- Ryan • (comments) • 24-Feb-2010 07:27 PST- resolved. I did it all again and it worked. So yes, the error message could be nicer. thanks a lot!
- revision 3064 makes the error message friendlier. -- Ryan • (comments) • 20-May-2010 22:01 PDT
- resolved. I did it all again and it worked. So yes, the error message could be nicer. thanks a lot!
[Edit]Horizontal Line
Clicking the rightmost button above (in the editing controls) has no effect...
I've also noticed that when I do include 4 dashes on some pages, it doesn't create a horizontal line like it's supposed to, but instead includes the literal 4 dashes in the page. Not sure exactly what is causing this...
Actually, none of the editing buttons seem to work at the moment (In Firefox 3.6.2) on this wiki at this time.
Just tried clicking the Editing controls buttons in IE8 as well, The Javascript error is:
Webpage error details User Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; MDDR; InfoPath.2) Timestamp: Fri, 2 Apr 2010 14:00:09 UTC Message: 'document.form.contents' is null or not an object Line: 80 Char: 2 Code: 0 URI: http://jamwiki.org/wiki/js/jamwiki.js
- Thanks, I'll make sure that gets fixed. -- Ryan • (comments) • 02-Apr-2010 07:37 PDT
- revision 3001 should fix this issue. I've pushed the change to jamwiki.org. -- Ryan • (comments) • 03-Apr-2010 19:53 PDT
[Edit]Thumbs and downscaled Images
In Tomcat's upload directory a downscaled thumbnail with extension "-180px" is automatically generated for every image uploaded. When the image is embedded in a Wiki page using [[Image:imagename.png|thumb]] the thumbnail is not used but the original image is scaled down by the HTML tag. Is there any way to use the thumbnail instead in order to speed up page rendering? -- (rmv) 27-Apr-2010 21:05 GMT
- There's been a bug introduced somewhere that is causing the downscaled image to generate but not be utilized - I actually noticed this last night while doing some work for 0.9.0. It should get fixed tonight on trunk (for inclusion in JAMWiki 0.9.0), and if there is a JAMWiki 0.8.5 release I'll make sure it's included in that as well. -- Ryan • (comments) • 27-Apr-2010 14:57 PDT
- revision 3038 should resolve this issue. -- Ryan • (comments) • 27-Apr-2010 21:14 PDT
[Edit]Interwiki Links with no topic
Interwiki links of the form Wikipedia are currently parsing incorrectly. -- Ryan • (comments) • 10-Mar-2010 22:30 PST
- revision 3076 fixes this issue. -- Ryan • (comments) • 04-Jun-2010 22:54 PDT
[Edit]Special:OrphanedPages broken
Special:OrphanedPages currently (0.9.0 beta2) returns an error message due to the "delete_date" column. -- Ryan • (comments) • 10-Jun-2010 18:14 PDT
- This issue was due to an out-of-date sql.ansi.properties file on the jamwiki.org server and not to any issue in the code. -- Ryan • (comments) • 12-Jun-2010 11:01 PDT
[Edit]Bliki error
Hi Ryan!
In jamwiki 0.9.0 update 2 I can't change the parser to Bliki! I got the next error message (or so): Bad parser class: org.jamwiki.parser.bliki.BlikiParser.
- Thanks for the report! I'll look at this tonight and make sure a fix is put in place before the final 0.9.0 release goes out. -- Ryan • (comments) • 09-Jun-2010 12:08 PDT
- revision 3087 will resolve this issue. Thanks again for the report. -- Ryan • (comments) • 09-Jun-2010 20:22 PDT
[Edit]Stylesheet error
Hi Ryan!
- In 0.9.0-b2 I found a sylesheet error on Firefox 3.0.x: At Admin/Roles/Create modify role: the description of role input box is covered by the role name input box.
- It would be nice to sign to the user which tab is active by setting the background of the active tab with other color then white.
—The preceding comment was added by cstenkes (comments • contribs) .
- Thanks! I'll try to reproduce your first issue and get a fix out, although I'll have to find a Firefox 3.0 browser to test with (I generally use Firefox 3.6). I like the second idea, and it should be easy and safe to implement so I'll try to get that in as well. -- Ryan • (comments) • 11-Jun-2010 11:58 PDT
- revision 3091 and revision 3092 should address both of these issues. -- Ryan • (comments) • 12-Jun-2010 09:03 PDT
[Edit]Search text box too long using Safari
Using jamwiki 0.9.0 beta2 with Safari 5.0 running on MacOS 10.6.3 the search text box runs into the search frame. It works fine on the same OS using Firefox but I have the same issue with Chrome.
--Tom Schueller 12-Jun-2010 17:05 PDT
- Thanks for the screenshot. Testing locally, Safari 5.0 on Windows doesn't seem to exhibit the same behavior, but I'll investigate. Just to verify, do you see the same thing on jamwiki.org? -- Ryan • (comments) • 12-Jun-2010 18:55 PDT
- I may have found the problem. If you add the following CSS to your StyleSheet topic, does it fix the issue?
#nav-search input[type="text"] {
width: 150px;
}
Yes it was the same when viewing jamwiki.org and the stylesheet addition you provided fixed it for me. It worked for Chrome running on the Mac too. --Tom Schueller 14-Jun-2010 11:11 PDT
- Thanks for the confirmation and testing, Tom. Time permitting I'll try to get a beta 3 out tonight with this fix and a few other tweaks implemented over the past three weeks, and provided no other issues are found that will become the final JAMWiki 0.9.0 release in another week or two. -- Ryan • (comments) • 14-Jun-2010 11:25 PDT
- revision 3095 fixes this issue. -- Ryan • (comments) • 14-Jun-2010 14:07 PDT
[Edit]Topic delete doesn't update cache
With JAMWiki 0.9.0 a topic delete doesn't remove the topic from the cache. -- Ryan • (comments) • 09-Jul-2010 21:00 PDT
- revision 3124 should resolve this issue. -- Ryan • (comments) • 10-Jul-2010 10:18 PDT
[Edit]Search index refresh throws SQLException: Invalid operation
We've upgraded to jamwiki 0.9.0 on tomcat 5.5 with an Oracle 9.2.0.8 database and oracle 10.2 thin jdbc driver. So far all working fine (apart from having to do some manual DB work) but when trying to refresh the search index through maintenance page i get the following sql error:
010-07-01 11:10:20,767 SEVERE: org.jamwiki.search.LuceneSearchEngine - Failure while refreshing search index
org.jamwiki.DataAccessException: java.sql.SQLException: Invalid operation for forward only resultset : isLast
at org.jamwiki.db.AnsiDataHandler.lookupTopic(AnsiDataHandler.java:743)
at org.jamwiki.search.LuceneSearchEngine.refreshIndex(LuceneSearchEngine.java:301)
at org.jamwiki.servlets.AdminServlet.refreshIndex(AdminServlet.java:360)
at org.jamwiki.servlets.AdminServlet.handleJAMWikiRequest(AdminServlet.java:76)
at org.jamwiki.servlets.JAMWikiServlet.handleRequestInternal(JAMWikiServlet.java:258)
[.. theres more stuff ..]
Caused by: java.sql.SQLException: Invalid operation for forward only resultset : isLast
at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:145)
at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:190)
at oracle.jdbc.driver.OracleResultSetImpl.isLast(OracleResultSetImpl.java:485)
at org.apache.commons.dbcp.DelegatingResultSet.isLast(DelegatingResultSet.java:317)
at org.jamwiki.db.AnsiQueryHandler.initTopic(AnsiQueryHandler.java:1240)
This is a bit of a pain as this happens after only 30 or so topics have been parsed (out of ~7000). Any idea? Thanks/
cmasuch • 01-Jul-2010 11:30 am BST
- It looks like your error is coming from AnsiQueryHandler.initTopic:
while (!rs.isLast()) {
// go to the last result - do not use rs.last() since result set may be FORWARD_ONLY
rs.next();
}
- As far as I know that should be fine with any JDBC 3.0 driver, but I may have missed some nuance. Which specific Oracle driver are you using (see here for a list)? Is it the ojdbc14.jar, or are you using classes12.jar? I'll fire up my Oracle instance and also try to reproduce this problem. Additionally, if you have any further information about the "manual DB work" you performed I'd be grateful - did one of the automatic upgrade steps fail? Thanks for the bug report! -- Ryan • (comments) • 01-Jul-2010 08:48 PDT
- I believe that revision 3120 and revision 3121 will fix this issue, but I haven't been able to reproduce it. If you're willing to test please let me know and I can generate a WAR file from the current 0.9.x branch. -- Ryan • (comments) • 07-Jul-2010 18:39 PDT
- Sorry for delay - for your questions: using the ojdbc14_g.jar, version 10.2.0.4 against a 9.2.0.8 database. More than willing to test of course. Let me know how to get the war file. As for the manual DB work, I had some problems with the unique keys (upper(...) ) so disabled them, and subsequently with some foreign keys. Also, the namespace table didn't get populated at all. I didn't yet have the time to look into more details on the issues.cmasuch • 12-Jul-2010 15:57 BST
- If you build from the current branches/0.9.x head the issue should be fixed for you. I'll try to put out a beta release no later than this weekend - let me know if you need something sooner. I'd like to also try and fix whatever caused your other issues, but I'll need to investigate to see if I can figure out what would cause them. -- Ryan • (comments) • 14-Jul-2010 08:01 PDT
- I've made a beta version of JAMWiki 0.9.1 available for testing, and I believe it may resolve this issue. See Latest News#JAMWiki 0.9.1 Beta 1. Barring issues, the final JAMWiki 0.9.1 release should be ready to go in a week or so. -- Ryan • (comments) • 18-Jul-2010 19:44 PDT
- Thanks a lot. Verison 0.9.1 fixes that problem for me. cmasuch • 04-Aug-2010 16:50 BST
- I've made a beta version of JAMWiki 0.9.1 available for testing, and I believe it may resolve this issue. See Latest News#JAMWiki 0.9.1 Beta 1. Barring issues, the final JAMWiki 0.9.1 release should be ready to go in a week or so. -- Ryan • (comments) • 18-Jul-2010 19:44 PDT
- If you build from the current branches/0.9.x head the issue should be fixed for you. I'll try to put out a beta release no later than this weekend - let me know if you need something sooner. I'd like to also try and fix whatever caused your other issues, but I'll need to investigate to see if I can figure out what would cause them. -- Ryan • (comments) • 14-Jul-2010 08:01 PDT
- Sorry for delay - for your questions: using the ojdbc14_g.jar, version 10.2.0.4 against a 9.2.0.8 database. More than willing to test of course. Let me know how to get the war file. As for the manual DB work, I had some problems with the unique keys (upper(...) ) so disabled them, and subsequently with some foreign keys. Also, the namespace table didn't get populated at all. I didn't yet have the time to look into more details on the issues.cmasuch • 12-Jul-2010 15:57 BST
- I believe that revision 3120 and revision 3121 will fix this issue, but I haven't been able to reproduce it. If you're willing to test please let me know and I can generate a WAR file from the current 0.9.x branch. -- Ryan • (comments) • 07-Jul-2010 18:39 PDT
[Edit]Search index refresh throws LockObtainFailException
Upgraded from 0.8.2 to 0.9.0. Refreshing the index reports success, but log gets a lot of the below. Thoughts?
I'm on Tomcat 6.0.26 against postgresql 8.4.2 with JDBC library postgresql-8.4-701.jdbc4.jar. The migration is otherwise successful (though I'm also going to report an unavailable virtual wiki issue shortly, however don't have as stack trace to provide...)
2010-07-17 23:31:50,289 SEVERE: org.jamwiki.search.LuceneSearchEngine - Failure while refreshing search index org.apache.lucene.store.LockObtainFailedException: Lock obtain timed out: NativeFSLock@/home/tomcat/.sites/conf/search/indexen/write.lock at org.apache.lucene.store.Lock.obtain(Lock.java:84) at org.apache.lucene.index.IndexWriter.init(IndexWriter.java:1045) at org.apache.lucene.index.IndexWriter.<init>(IndexWriter.java:868) at org.jamwiki.search.LuceneSearchEngine.retrieveIndexWriter(LuceneSearchEngine.java:372) at org.jamwiki.search.LuceneSearchEngine.refreshIndex(LuceneSearchEngine.java:296) at org.jamwiki.servlets.AdminServlet.refreshIndex(AdminServlet.java:360) at org.jamwiki.servlets.AdminServlet.handleJAMWikiRequest(AdminServlet.java:76) at org.jamwiki.servlets.JAMWikiServlet.handleRequestInternal(JAMWikiServlet.java:258) at org.springframework.web.servlet.mvc.AbstractController.handleRequest(AbstractController.java:153) ''trimmed'' at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:891) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:690) at java.lang.Thread.run(Thread.java:619) 2010-07-17 23:31:51,292 SEVERE: org.jamwiki.search.LuceneSearchEngine - Failure while refreshing search index org.apache.lucene.store.LockObtainFailedException: Lock obtain timed out: NativeFSLock@/home/tomcat/.sites/conf/search/indexpathfinder/write.lock at org.apache.lucene.store.Lock.obtain(Lock.java:84) at org.apache.lucene.index.IndexWriter.init(IndexWriter.java:1045) at org.apache.lucene.index.IndexWriter.<init>(IndexWriter.java:868) at org.jamwiki.search.LuceneSearchEngine.retrieveIndexWriter(LuceneSearchEngine.java:372) at org.jamwiki.search.LuceneSearchEngine.refreshIndex(LuceneSearchEngine.java:296) at org.jamwiki.servlets.AdminServlet.refreshIndex(AdminServlet.java:360) at org.jamwiki.servlets.AdminServlet.handleJAMWikiRequest(AdminServlet.java:76) at org.jamwiki.servlets.JAMWikiServlet.handleRequestInternal(JAMWikiServlet.java:258) at org.springframework.web.servlet.mvc.AbstractController.handleRequest(AbstractController.java:153) ''trimmed'' at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:690) at java.lang.Thread.run(Thread.java:619)
- Thanks for the detailed report. I just checked my local instance and I'm seeing the same thing, so it likely means I've screwed up the lock ordering when updating the search engine. I'll get this fixed for the upcoming JAMWiki 0.9.1 release. -- Ryan • (comments) • 17-Jul-2010 17:24 PDT
- Thanks! Not sure if it possibly contributes to the VW issue entered below as well. Unlikely on consideration. Tim • 17-Jul-2010 11:09 EST
- While I see a few instances of this issue in my logs I'm having trouble reproducing it. My original hunch was that I wasn't properly releasing the writer lock when the app server was restarted, but the Lucene 3.0.2 CHANGELOG references a handful of bug fixes for file system locking issues, so I'm now thinking that this may be a Lucene issue. For JAMWiki 0.9.1 I'll update Lucene to the new version and will keep an eye on the logs to see if the error shows up again. I'll try to post a beta version for download and testing by end-of-day. -- Ryan • (comments) • 18-Jul-2010 09:12 PDT
- I've made a beta version of JAMWiki 0.9.1 available for testing, and I believe it may resolve this issue. See Latest News#JAMWiki 0.9.1 Beta 1. Barring issues, the final JAMWiki 0.9.1 release should be ready to go in a week or so. -- Ryan • (comments) • 18-Jul-2010 19:44 PDT
- While I see a few instances of this issue in my logs I'm having trouble reproducing it. My original hunch was that I wasn't properly releasing the writer lock when the app server was restarted, but the Lucene 3.0.2 CHANGELOG references a handful of bug fixes for file system locking issues, so I'm now thinking that this may be a Lucene issue. For JAMWiki 0.9.1 I'll update Lucene to the new version and will keep an eye on the logs to see if the error shows up again. I'll try to post a beta version for download and testing by end-of-day. -- Ryan • (comments) • 18-Jul-2010 09:12 PDT
- Thanks! Not sure if it possibly contributes to the VW issue entered below as well. Unlikely on consideration. Tim • 17-Jul-2010 11:09 EST
[Edit]Virtual Wiki is 404 on upgrade (0.8.2 → 0.9.0)
From above Lucene report: "Tomcat 6.0.26 against postgresql 8.4.2 with JDBC library postgresql-8.4-701.jdbc4.jar. The migration is otherwise successful." It seems to be difficult to debug because the logs are silent on the matter, only Apache or Tomcat access logging is available (providing only 404 records). Unfortunately, I was also reviewing my logrotate configuration during the migration and noted my catalina.out had grown to nearly 1.5GB (not a typo). I clobbered that log in the clean up, losing what would have been my migration log. Sorry.
The new Virtual Wiki configuration however does show the "lost" VW in the dropdown (will provide screenshots if helpful). Otherwise, any attempt to view the VW fails with 404. Could it be a change in how VWs are referenced from 0.8.2?
- I will try to use my 0.8.2 DB dump to mimic the migration in a VM and capture any issues with Virtual wikis on the upgrade. Tim • 17-Jul-2010 11:10 EST
- After the upgrade did you restore your virtual wiki configuration in
/WEB-INF/web.xml(see Configuration#Virtual Wikis)? Based on the description of the issue that would be my first guess as to what might be wrong. -- Ryan • (comments) • 18-Jul-2010 08:40 PDT- I did not. I will do so. Thanks for the reminder. Tim • 18-Jul-2010 17:23 EST
- That did it. Thanks for the reminder that virtual wikis needed that little hint. I'll strike through this item, but leave it here in case another encounters this.
Maybe deserving of a hint in the upgrade notes.Tim • 18-Jul-2010 17:30 EST- I've updated both the UPGRADE.txt and Installation#Upgrades with pointers to the virtual wiki configuration data. Thanks for the report! -- Ryan • (comments) • 18-Jul-2010 19:44 PDT
- That did it. Thanks for the reminder that virtual wikis needed that little hint. I'll strike through this item, but leave it here in case another encounters this.
- I did not. I will do so. Thanks for the reminder. Tim • 18-Jul-2010 17:23 EST
- After the upgrade did you restore your virtual wiki configuration in
[Edit]Special:Roles Error
With JAMWiki 1.0.0 (and probably earlier versions) I'm getting an error when trying to update my own account that ROLE_SYSADMIN cannot be removed, even though I'm not removing that role. -- Ryan • (comments) • 07-Aug-2010 11:59 PDT
- revision 3164 should resolve this issue. -- Ryan • (comments) • 15-Aug-2010 08:25 PDT
[Edit]UploadServlet
File.renameTo() doesn't work with non-image files in JAMWiki 0.9.0. I get the upload.error.filerename message.
It seems there some issues with renameTo method :
- http://www.coderanch.com/t/373614/java/java/File-renameTo-error
- http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6213298
ImageUtils.loadImage() method has changed and the FileInputStream isn't closed anymore.
A come back to 0.8.4 version of ImageUtils.loadImage() seems necessary.
- Are there any errors in your logs that might provide a stack trace? I haven't seen the issues above in my local instances, so any pointers that could help track down the problems would be appreciated. Thanks for the report. -- Ryan • (comments) • 12-Aug-2010 07:14 PDT
- No error. Method renameTo returns false if I don't close the FileInputStream in ImageUtils.loadImage() for non-image files. Nico 12-Aug-2010 08:46 PDT
- Thanks for the follow-up. I'll see if I can reproduce this issue and get a fix out for 0.9.2. -- Ryan • (comments) • 12-Aug-2010 08:49 PDT
- Based on your suggestions I believe that revision 3163 should resolve this issue, although I haven't been able to reproduce the problem locally so the fix is untested. I've credited you as "an anonymous user", but please let me know your name if you'd like a more specific credit. In addition, if you're willing to test the fix please let me know and I'll make a beta available for testing. -- Ryan • (comments) • 14-Aug-2010 19:41 PDT
- Thanks for the follow-up. I'll see if I can reproduce this issue and get a fix out for 0.9.2. -- Ryan • (comments) • 12-Aug-2010 08:49 PDT
- No error. Method renameTo returns false if I don't close the FileInputStream in ImageUtils.loadImage() for non-image files. Nico 12-Aug-2010 08:46 PDT
[Edit]Null Pointer Exception on retrieveDefaultRelativeUploadDirectory()
Problem is with:
Utilities.getWebappRoot().getName()
(line cca 368). getWebappRoot() may return null (example: websphere). Add null-check (and use tmpdir if null). —The preceding comment was added by igor (comments • contribs) .
- Thanks, I'll get that fixed for JAMWiki 0.9.3. Let me know what name you would like used to credit you in the CHANGELOG, otherwise I'll just use "igor". -- Ryan • (comments) • 18-Sep-2010 18:57 PDT
- When do you expect JAMWiki 0.9.3 is going to be released? Please, let me explain why this simple bug is important. Environment is created in a static block. Problem is that an exception thrown from a static init block is... strange. On Suns VM I have to catch it as Throwable. On IBMs VM I am not able to catch at all:) So, besides fixing this NPE, would you be so kind to reconsider static initialization of Environment? Or add try/catch around [instance = new Environment();] to ensure that static block do not throw any exception. This is important because of potential future issues, when Environment init might fails because of some other thing. p.s. just use igor, i am not much for credits;)
- Bugfix releases are done about once a month unless an issue is serious enough to warrant a sooner release, such as an issue that breaks a common path or adversely affects a majority of users. Since this is a runtime exception from a code block that works on most systems I'll need to take a closer look at it, but will definitely make sure the fix is included in the next release. For what it's worth I was unaware that the code in question would fail, which is why it's in a static initialization block. As you've indicated, if this is something that can fail regularly on some systems then some refactoring is probably necessary. Suggestions are welcome, and thanks for your help in debugging. -- Ryan • (comments) • 22-Sep-2010 01:05 PDT
- in my humble opinion, this is a simple, but important issue. because of it, all major app servers suffer: websphere, jboss, weblogic, resin... hopefully, it is open source project, so i can create a patched version without having to wait a month;)
- I'd prefer not to do a special release unless this really is a high impact issue, so perhaps I don't understand fully - my local JBoss instance (Linux) has never thrown an error from this code, nor has my Resin instance (Windows). I've done some testing in the past on Websphere and Weblogic and didn't encounter a failure from this code, although that was on older versions of JAMWiki. Is this really something that will cause most installations on these servers to fail, or is there something specific to your environment that would cause this to fail? For example, what OS are you using? Do you have any special permission settings that might prevent JAMWiki from writing its properties to the webapp directory? -- Ryan • (comments) • 22-Sep-2010 07:45 PDT
- no problem, that's why open source is cool, we can build our own patch;) anyway, my OS is windows7, and no permission is involved. The project I am talking about is [1] and recently jamwiki is being included. However, we have received various reports from various sources and OSs (users, clients...) about this exception - and we need to fixit asap, of course. our patch for now is to put try/catch (and a warn log) inside of static initialization of Environment class (as explained before). This will at least prevent from stopping the liferay portal.
- I think I got a Google alert on the discussion board posts about your transition and was curious how it was going :) I've been looking into using the Spring methods for working with the webapp root and will give that more attention, assuming Spring has probably worked out any kinks in this area; one way or another a fix will be available for JAMWiki 0.9.3, but if you have code that works for you please feel free to post it here and I'll look into integrating it. In the meantime if you can run a local patch that would be great - JAMWiki 0.9.2 just went out ten days ago, so I'm a bit hesitant to push another update on people so soon. -- Ryan • (comments) • 22-Sep-2010 14:37 PDT
- we just catch and log the exception, to ensure nothing is thrown from static block. not a magic solution, but makes liferay portal starts again;)
- I think I got a Google alert on the discussion board posts about your transition and was curious how it was going :) I've been looking into using the Spring methods for working with the webapp root and will give that more attention, assuming Spring has probably worked out any kinks in this area; one way or another a fix will be available for JAMWiki 0.9.3, but if you have code that works for you please feel free to post it here and I'll look into integrating it. In the meantime if you can run a local patch that would be great - JAMWiki 0.9.2 just went out ten days ago, so I'm a bit hesitant to push another update on people so soon. -- Ryan • (comments) • 22-Sep-2010 14:37 PDT
- no problem, that's why open source is cool, we can build our own patch;) anyway, my OS is windows7, and no permission is involved. The project I am talking about is [1] and recently jamwiki is being included. However, we have received various reports from various sources and OSs (users, clients...) about this exception - and we need to fixit asap, of course. our patch for now is to put try/catch (and a warn log) inside of static initialization of Environment class (as explained before). This will at least prevent from stopping the liferay portal.
- I'd prefer not to do a special release unless this really is a high impact issue, so perhaps I don't understand fully - my local JBoss instance (Linux) has never thrown an error from this code, nor has my Resin instance (Windows). I've done some testing in the past on Websphere and Weblogic and didn't encounter a failure from this code, although that was on older versions of JAMWiki. Is this really something that will cause most installations on these servers to fail, or is there something specific to your environment that would cause this to fail? For example, what OS are you using? Do you have any special permission settings that might prevent JAMWiki from writing its properties to the webapp directory? -- Ryan • (comments) • 22-Sep-2010 07:45 PDT
- in my humble opinion, this is a simple, but important issue. because of it, all major app servers suffer: websphere, jboss, weblogic, resin... hopefully, it is open source project, so i can create a patched version without having to wait a month;)
- Bugfix releases are done about once a month unless an issue is serious enough to warrant a sooner release, such as an issue that breaks a common path or adversely affects a majority of users. Since this is a runtime exception from a code block that works on most systems I'll need to take a closer look at it, but will definitely make sure the fix is included in the next release. For what it's worth I was unaware that the code in question would fail, which is why it's in a static initialization block. As you've indicated, if this is something that can fail regularly on some systems then some refactoring is probably necessary. Suggestions are welcome, and thanks for your help in debugging. -- Ryan • (comments) • 22-Sep-2010 01:05 PDT
- When do you expect JAMWiki 0.9.3 is going to be released? Please, let me explain why this simple bug is important. Environment is created in a static block. Problem is that an exception thrown from a static init block is... strange. On Suns VM I have to catch it as Throwable. On IBMs VM I am not able to catch at all:) So, besides fixing this NPE, would you be so kind to reconsider static initialization of Environment? Or add try/catch around [instance = new Environment();] to ensure that static block do not throw any exception. This is important because of potential future issues, when Environment init might fails because of some other thing. p.s. just use igor, i am not much for credits;)
- (re-indenting) This comment looks like it may explain the problem - my guess is that for systems without the
java.io.tmpdirvariable set to a valid directory it appears that a failure could occur. I'll dig into the Spring classes for reading files from the class loader root and see if they have a workaround. Sorry for the trouble! -- Ryan • (comments) • 23-Sep-2010 18:06 PDT- I think revision 3238 will address the initialization errors, although it doesn't address why determination of the default file upload directory would fail. I'll need to dig further into that issue. -- Ryan • (comments) • 25-Sep-2010 13:54 PDT
- Igor here (from Liferay.com) - here is the fix I've made against v0.9.2.
1) Environment.java. try/catch Throwable in static block should stay, but this doesn't fix the issue.
2) Utilities.java. Here lies the root of the issue. I will go in logical order
2.1) getClassLoaderRoot() searches for ApplicationResources.properties to determine the root. First, if jamwiki-core.jar is deployed *alone* (without jamwiki-war.core) then this file doesn't exists. Moreover, it probably exist in some other jar (since the name is common). So what I did is to lookup for jamwiki-core.properties, a dummy file I've added to the resources, so it will be bundled with the jamwiki-core.jar and the name is unique.
2.2) getClassLoaderFile() unfortunately uses commons FileUtils.copyURLToFile() that doesnt copy file from ZIP(JAR) to the destination. Therefore the whole try block looks like:
String tempFilename = RandomStringUtils.randomAlphanumeric(20); file = File.createTempFile(tempFilename, null); InputStream is = loader.getResourceAsStream(filename); OutputStream os = new FileOutputStream(file); IOUtils.copy(is, os); IOUtils.closeQuietly(is); IOUtils.closeQuietly(os);
that will do the job. Also, please note the randomAlphanumeric()! since you are currently use random() and that gives hell of characters and might give some non allowed names!
2.3) getWebappRoot() is the next stop: you are assuming that we are in the WEB-INF/classes so there are 2 parents, but getClassLoaderRoot() may return a file from TEMP folder, and TEMP folder might be just in root - so there are no TWO parents! I fixed this quickly with:
File webAppRoot = Utilities.getClassLoaderRoot();
if (webAppRoot.getParentFile() != null) {
webAppRoot = webAppRoot.getParentFile();
if (webAppRoot.getParentFile() != null) {
webAppRoot = webAppRoot.getParentFile();
}
}
return webAppRoot;
So that solves things. Moreover, on appservers like Weblogic, old commons-lang (from app server) may be classloaded before v2.5 needed for jamwiki, and therefore users have to configure app server to load correct version of commons-lang.
- Thanks for the additional follow-up. I didn't realize you were using this outside of the standard WAR, which explains the class loader root error (as you've pointed out). I'll make sure this is cleaned up for the 0.9.3 release. -- Ryan • (comments) • 01-Oct-2010 15:21 PDT
- Also note that point (2.3) maybe should be solved by checking exact names of folder, so to go to parent only if first folder is called 'classes' and the 'WEB-INF'.
- revision 3247 incorporates the changes you've suggested, including testing the directory names. I haven't been able to reproduce the problem locally, so I'd be interested in getting some feedback on this before pushing out JAMWiki 0.9.3 - I'm happy to build a beta or do whatever would be easiest to allow you to confirm the fix. Thanks again for all of the follow-up. -- Ryan • (comments) • 09-Oct-2010 18:43 PDT
- Also note that point (2.3) maybe should be solved by checking exact names of folder, so to go to parent only if first folder is called 'classes' and the 'WEB-INF'.
[Edit]No History at all
versions tested: jamwiki-0.9.3 jamwiki-0.8.4
os: debian lenny with tomcat
The click on History button cause this error
A system error has occurred. The error message is:
org.apache.jasper.JasperException: /WEB-INF/jsp/history.jsp(44,61) "${change.import}" contains invalid expression(s): javax.el.ELException: [import] is not a valid Java identifier
with this call stack
org.apache.jasper.JasperException: /WEB-INF/jsp/history.jsp(44,61) "${change.import}" contains invalid expression(s): javax.el.ELException: [import] is not a
valid Java identifier
at org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:40)
at org.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java:407)
at org.apache.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java:198)
at org.apache.jasper.compiler.Validator$ValidateVisitor.checkXmlAttributes(Validator.java:1217)
at org.apache.jasper.compiler.Validator$ValidateVisitor.visit(Validator.java:870)
at org.apache.jasper.compiler.Node$CustomTag.accept(Node.java:1539)
at org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2376)
at org.apache.jasper.compiler.Node$Visitor.visitBody(Node.java:2428)
at org.apache.jasper.compiler.Validator$ValidateVisitor.visit(Validator.java:889)
at org.apache.jasper.compiler.Node$CustomTag.accept(Node.java:1539)
at org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2376)
at org.apache.jasper.compiler.Node$Visitor.visitBody(Node.java:2428)
at org.apache.jasper.compiler.Node$Visitor.visit(Node.java:2434)
at org.apache.jasper.compiler.Node$Root.accept(Node.java:475)
at org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2376)
at org.apache.jasper.compiler.Validator.validateExDirectives(Validator.java:1789)
at org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:216)
at org.apache.jasper.compiler.Compiler.compile(Compiler.java:365)
at org.apache.jasper.compiler.Compiler.compile(Compiler.java:345)
at org.apache.jasper.compiler.Compiler.compile(Compiler.java:332)
at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:594)
at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:327)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:363)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:306)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:304)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:671)
at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:580)
at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:517)
at org.apache.jasper.runtime.JspRuntimeLibrary.include(JspRuntimeLibrary.java:930)
at org.apache.jsp.WEB_002dINF.jsp.wiki_jsp._jspService(wiki_jsp.java:272)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:68)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:387)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:363)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:306)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:304)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:671)
at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:463)
at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:402)
at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:330)
at org.springframework.web.servlet.view.InternalResourceView.renderMergedOutputModel(InternalResourceView.java:238)
at org.springframework.web.servlet.view.AbstractView.render(AbstractView.java:250)
at org.springframework.web.servlet.DispatcherServlet.render(DispatcherServlet.java:1060)
at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:798)
at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:716)
at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:647)
at org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:552)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:621)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:304)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:343)
at org.springframework.security.web.access.intercept.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:109)
at org.springframework.security.web.access.intercept.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:83)
at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:355)
at org.springframework.security.web.access.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:97)
at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:355)
at org.jamwiki.authentication.JAMWikiPostAuthenticationFilter.doFilter(JAMWikiPostAuthenticationFilter.java:78)
at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:355)
at org.springframework.security.web.session.SessionManagementFilter.doFilter(SessionManagementFilter.java:100)
at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:355)
at org.springframework.security.web.authentication.AnonymousAuthenticationFilter.doFilter(AnonymousAuthenticationFilter.java:78)
at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:355)
at org.springframework.security.web.authentication.rememberme.RememberMeAuthenticationFilter.doFilter(RememberMeAuthenticationFilter.java:119)
at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:355)
at org.springframework.security.web.servletapi.SecurityContextHolderAwareRequestFilter.doFilter(SecurityContextHolderAwareRequestFilter.java:54)
at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:355)
at org.springframework.security.web.savedrequest.RequestCacheAwareFilter.doFilter(RequestCacheAwareFilter.java:35)
at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:355)
at org.springframework.security.web.authentication.AbstractAuthenticationProcessingFilter.doFilter(AbstractAuthenticationProcessingFilter.java:188)
at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:355)
at org.springframework.security.web.authentication.logout.LogoutFilter.doFilter(LogoutFilter.java:105)
at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:355)
at org.springframework.security.web.context.SecurityContextPersistenceFilter.doFilter(SecurityContextPersistenceFilter.java:79)
at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:355)
at org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:149)
at org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:237)
at org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:167)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:242)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
at org.jamwiki.servlets.JAMWikiFilter.doFilter(JAMWikiFilter.java:62)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:242)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:240)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:203)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:164)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:108)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:558)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:379)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:242)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:259)
at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:281)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:636)
I am having the same issue on JAMWiki Version 0.9.3. I am running Apache Tomcat/7.0.4 with Java 1.6.0_22 on Win XP SP3.
- Did you perform an upgrade prior to receiving this message? I'd guess you're encountering the issue outlined in step #3 of Installation#Troubleshooting. Try deleting the "work" folder within your TOMCAT_HOME/Catalina folder, restart Tomcat, and see if the problem is fixed. If that doesn't work let me know and I'll try to reproduce the issue with your specific Tomcat version. -- Ryan • (comments) • 13-Nov-2010 09:03 PST
I did a clean install. I tried deleting the work folder and still no history. I was able to get the history page working by setting the following system property
SET JAVA_OPTS="-Dorg.apache.el.parser.SKIP_IDENTIFIER_CHECK=true"
I confirm, deleting work folder don't resolve the problem. The env var work for me too! History work with this at tomcat start: JAVA_OPTS="-Dorg.apache.el.parser.SKIP_IDENTIFIER_CHECK=true" This is my Tomcat and SO informations: Apache Tomcat/7.0.4 1.6.0_0-b11 Sun Microsystems Inc. Linux 2.6.35-22-generic amd64
- Thanks. The SKIP_IDENTIFIER_CHECK option appears to be a Tomcat 7 addition, so I'll need to look into what it's doing and get a fix in place for JAMWiki 0.9.4. http://tomcat.apache.org/tomcat-7.0-doc/config/systemprops.html has some details that will probably be necessary. -- Ryan • (comments) • 14-Nov-2010 19:32 PST
- I believe that revision 3279 will fix this issue, and the fix will be included in JAMWiki 0.9.4. It looks like Apache 7.0.x is validating that field names aren't using Java reserved keywords in the name, and obviously "import" is a Java reserved keyword. I've changed the field name to "importChange" to avoid the conflict. -- Ryan • (comments) • 27-Nov-2010 08:53 PST
[Edit]There is an error on SERVERNAME use
like in this page:
http://jamwiki.org/wiki/en/Help:Links#Internal_links
the result of
[http://{{SERVERNAME}}/pagename]
is
http://http://jamwiki.org/pagename
with a wrong link address:
http://%3cnowiki%3ehttp//jamwiki.org%3C/nowiki%3E/pagename
- Thanks - it looks like this was implemented incorrectly in JAMWiki. {{SERVER}} should add an http: but {{SERVERNAME}} should not. I'll look into getting this fixed for 0.9.4, although with the Thanksgiving holiday I don't think it will be done before next week. -- Ryan • (comments) • 22-Nov-2010 22:53 PST
- revision 3267 will resolve this issue and will be included in JAMWiki 0.9.4. Thanks for the report. -- Ryan • (comments) • 24-Nov-2010 11:05 PST
[Edit]Table of Contents with more than 6 levels not working
Jamwiki 0.9.3
Running under Jetty-6.1.22/Windows XP Pro/Internal Database (HSQL)
Steps to reproduce:
- create a new page
- enter in the following as the contents
=Level 1= ==Level 2== ===Level 3=== ====Level 4==== =====Level 5===== ======Level 6====== =======Level 7=======
- select preview or save
The page will be rendered incorrectly with some extra markup. If you remove level 7 it works as expected.
- Thanks, this should be relatively easy to fix and should be included in the next bugfix release. -- Ryan • (comments) • 09-Dec-2010 17:02 PST
- revision 3307 should resolve this issue. -- Ryan • (comments) • 10-Dec-2010 17:15 PST
[Edit]XSS Security issue
<span style='"><script>alert("XSS")</script>'>d</span> Does the standard evil XSS stuff. Cheers. (I hope its ok to post security issues to this public page). bawolff 02-Jan-2011 01:28 PST
- Thanks, I'll take a look at this today and try to get a fix included in the upcoming JAMWiki 0.9.5 release. And posting XSS vulnerabilities here is probably fine since there really isn't another appropriate forum for them - if there is concern in the future then we'll figure something else out. -- Ryan • (comments) • 02-Jan-2011 07:17 PST
- revision 3395 resolves the issue in my testing environment. I'll push this to jamwiki.org shortly. Thanks for the report - I've credited you as "bawolff", but if you prefer your real name or something different please let me know as soon as possible so I can change it before 0.9.5 is released. -- Ryan • (comments) • 03-Jan-2011 09:47 PST
- Bawolff is fine (real name is Brian Wolff, I'm not really particular about which you use. Bawolff is my username on most of the internet). The reason I found it was that I was curious about how complete JAMwiki's support for "mediawiki" syntax, so I was testing some edge cases to see if it did the same thing. bawolff 12-Jan-2011 15:57 PST
[Edit]Error at deploying on JBoss
If i try to deploy the file on JBoss, running at an Ubuntu-server, i get the following Error:
ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/jamwiki-0.9.1]] (HDScanner) Exception sending context initialized event to listener instance of class org.jamwiki.servlets.JAMWikiListener java.lang.ExceptionInInitializerError at org.jamwiki.utils.WikiUtil.<clinit>(WikiUtil.java:66) at org.jamwiki.servlets.JAMWikiListener.contextInitialized(JAMWikiListener.java:37) ... Caused by: java.lang.NullPointerException at org.jamwiki.Environment.retrieveDefaultRelativeUploadDirectory(Environment.java:368) at org.jamwiki.Environment.initDefaultProperties(Environment.java:213) at org.jamwiki.Environment.<init>(Environment.java:123) at org.jamwiki.Environment.<clinit>(Environment.java:116)
This Error didn't appear on Windows.
- It looks like JAMWiki is hitting a Linux permission error for your "file upload directory", so make sure that JBoss has permission to read & write to that folder. I didn't see any errors when testing with JBoss on CentOS prior to the JAMWiki 0.9.0 release. -- Ryan • (comments) • 06-Aug-2010 09:14 PDT
- I also tested it with chmod 777 for my upload dir.
- Thanks for the follow-up. Looking closer at the code, it looks like the the code that determines the webapp root is returning null. I'm not sure how that could happen so I'll need to investigate further. -- Ryan • (comments) • 09-Aug-2010 07:33 PDT
- Based on the stack trace, this issue appears to be the same one that was resolved for JAMWiki 0.9.3 ("Setting the default file upload properties could cause initialization failures in cases where JAMWiki was deployed without the JAMWiki WAR, such as on the Liferay server."). -- Ryan • (comments) • 22-Jan-2011 10:57 PST
- Thanks for the follow-up. Looking closer at the code, it looks like the the code that determines the webapp root is returning null. I'm not sure how that could happen so I'll need to investigate further. -- Ryan • (comments) • 09-Aug-2010 07:33 PDT
[Edit]Unable to Get WebAppRoot
JAMWiki 0.7, Jboss 5, CentOS 5.2
Complete newbie in Jboss and JAMWiki. I installed all following basic installation guides. Deployed JAMWiki in JBoss in the default server configuration. Opened up the Jamwiki setup page easily. Noticed that the Data Type drop down list is empty. Upon further inspection, I found that the sql.*.properties files in the classes directory are not being found. Any attempt to set the database properties fail becuase there are no sql properties to use (I assume). Is there something I must do to specify the web app root? Either in Jboss or JAMWiki? Some relevant errors follow:
2009-03-23 18:24:42,521 SEVERE: org.jamwiki.Environment - Failure while trying t o retrieve default file upload directory java.io.FileNotFoundException: Found invalid root class loader for file Applicat ionResources.properties
at org.jamwiki.utils.Utilities.getClassLoaderFile(Utilities.java:357)
at org.jamwiki.utils.Utilities.getClassLoaderRoot(Utilities.java:372)
at org.jamwiki.utils.Utilities.getWebappRoot(Utilities.java:397)
at org.jamwiki.Environment.retrieveDefaultUploadDirectory(Environment.java:350)
at org.jamwiki.Environment.initDefaultProperties(Environment.java:186
2009-03-23 18:24:42,544 WARNING: org.jamwiki.Environment - Property file jamwiki.properties does not exist 2009-03-23 18:24:42,595 SEVERE: org.jamwiki.Environment - Error while searching for resource sql.ansi.properties java.io.FileNotFoundException: Found invalid root class loader for file ApplicationResources.properties at org.jamwiki.utils.Utilities.getClassLoaderFile(Utilities.java:357) at org.jamwiki.utils.Utilities.getClassLoaderRoot(Utilities.java:372) at org.jamwiki.Environment.retrievePropertyFile(Environment.java:376) at org.jamwiki.Environment.findProperties(Environment.java:143)
Update: downgraded Jboss to 4.2.3 and the problem went away.
- Thanks for the detailed bug report. I don't personally use JBoss, but time permitting I'll try to install and investigate this weekend and see if I can find a workaround. If you find out anything more in the mean time please let me know! -- Ryan • (comments) • 23-Mar-2009 20:06 PDT
- I still haven't had a chance to look at this issue - if anyone finds out any further info and can help resolve the problem it would be much appreciated. -- Ryan • (comments) • 12-Apr-2009 15:41 PDT
- Based on the stack trace, this issue appears to be the same one that was resolved for JAMWiki 0.9.3 ("Setting the default file upload properties could cause initialization failures in cases where JAMWiki was deployed without the JAMWiki WAR, such as on the Liferay server."). -- Ryan • (comments) • 23-Jan-2011 09:37 PST
- I still haven't had a chance to look at this issue - if anyone finds out any further info and can help resolve the problem it would be much appreciated. -- Ryan • (comments) • 12-Apr-2009 15:41 PDT