Current development on JAMWiki is primarily focused on maintenance rather than new features due to a lack of developer availability. If you are interested in working on JAMWiki please join the jamwiki-devel mailing list.

Comments:JAMWiki 0.1.3

JAMWiki 0.1.3[edit]

Archived from the Feedback page:

Due to a fairly serious database installation error that prevents installing JAMWiki using the "ansi" database option, as well as some problems with the Resin application server, a new version of JAMWiki will probably be released tomorrow. The changes above will then be moved to JAMWiki 0.1.4. -- Ryan 04-Aug-2006 23:39 PDT

Updated code is now running on jamwiki.org. The changes that have been made allow JAMWiki to work (on my laptop) with Resin 2.1.17 and include the following:
  • Fix a bug when using JAMWiki with the "ansi" database option - SQL would not be loaded and JAMWiki fails miserably.
  • Add better exception handling for errors thrown during the setup process. Should (hopefully) make setup more robust.
  • Make the JAMWiki taglibs more standards-compliant. Resin is very strict about not change taglib attribute values, so support that.
  • Remove the code that set the response encoding in the JAMWikiFilter. This broke the stylesheet servlet with Resin, and should not be necessary since JSPs set response encoding. Everything seems OK even when testing with a Chinese language version of IE, so hopefully this change is safe.
  • Fix a bug with the upgrade process where the link returned was being HTML escaped.
I've not been able to reproduce the issue reported with the ApplicationResources properties file failing to load for Resin, but I'll investigate further. In any case, whether that issue is addressed or not JAMWiki 0.1.3 will be getting released later this afternoon. -- Ryan 05-Aug-2006 12:25 PDT

Setup Bug[edit]

When attempting the setup (using ansi DB), a NullPointerException is thrown during setupSpecialPages. The problem is that the handler does not set initialized to true until after setupSpecialPages is complete, but during setupSpecialPages it calls WikiBase.getHandler(), which returns null because the handler is not initialized yet.

2006-08-07 11:55:39,568 [tcpConnection-14609-2] ERROR [SetupServlet] Setup error java.lang.NullPointerException

       at org.jamwiki.persistency.db.DefaultQueryHandler.lookupTopic(DefaultQueryHandler.java:491)<br />
       at org.jamwiki.persistency.db.DatabaseHandler.lookupTopic(DatabaseHandler.java:553)<br />
       at org.jamwiki.persistency.PersistencyHandler.exists(PersistencyHandler.java:321)<br />
       at org.jamwiki.persistency.PersistencyHandler.setupSpecialPage(PersistencyHandler.java:684)<br />
       at org.jamwiki.persistency.PersistencyHandler.setupSpecialPages(PersistencyHandler.java:738)<br />
       at org.jamwiki.persistency.PersistencyHandler.initialize(PersistencyHandler.java:434)<br />
       at org.jamwiki.persistency.db.DatabaseHandler.initialize(DatabaseHandler.java:301)<br />
       at org.jamwiki.WikiBase.reset(WikiBase.java:247)<br />
       at org.jamwiki.servlets.SetupServlet.initialize(SetupServlet.java:116)<br />

stack trace trimmed

       at com.caucho.server.TcpConnection.run(TcpConnection.java:139)<br />
       at java.lang.Thread.run(Thread.java:595)
I'll look into this, although I was able to do a fresh install using Resin 2.1.17, WebSphere 6.0 and Tomcat prior to releasing JAMWiki 0.1.3 so there may be some other weird behavior that is going on here. Thanks for the report. -- Ryan 07-Aug-2006 12:41 PDT
Looking at it further, I'm not really sure how that bug didn't trigger during testing. And either way, it's poorly written. I'll get a JAMWiki 0.1.4 beta out shortly that fixes the problem - it will be available for download from the Feedback page when ready. -- Ryan 07-Aug-2006 12:58 PDT
I've released JAMWiki 0.1.4 beta 1 (see Feedback#JAMWiki 0.1.4) which should resolve this issue. I didn't test very much, so please let me know if you see any problems. Thanks again for all of the bug reports, and sorry for the trouble! -- Ryan 07-Aug-2006 14:17 PDT

I believe there's another issue with setup, not unlike the one you just addressed. In PersistencyHandler in the setupSpecialPage method, there is this:

if ( ! this.isInitialized() ) {
   // do not set up special pages until initial property values set
   logger.warn( "Attempt to setup special pages prior to initializing system" );
   return;
}

When attempting to setup the special pages, isInitialized returns false and the method returns without setting up the page. -- scroco

Thanks - I'll get a new beta out shortly, I just need to make some additional cleanups due to some deprecated methods in the new commons-dbcp package. I'll also make another source release available if you'd like. The initialization code has been re-written several times, so I'm hoping this latest issue is a relic of old code and can be safely removed, but I'll try to do some more serious testing prior to the final release of JAMWiki 0.1.4. I'm still baffled why these issues wouldn't trigger for other people's installs, but if this stuff was easy then everyone would do it...
Anyhow, apologies for all of the bugs you're running into - I'm obviously failing miserably in your case with the goal of making JAMWiki easy to setup, but I very much appreciate the time you're taking to help work out these issues. -- Ryan 07-Aug-2006 15:45 PDT
Beta 2 is out (see Feedback#JAMWiki 0.1.4) and should address your issue above. Also, the 1.2.8 spring.jar file was 1.9MB, so rather than including the whole thing I've only included those sub-components that JAMWiki is using (about 1MB), and that may cause some errors if I've missed anything (I haven't hit any problems yet locally). Also, DBCP 1.2.1 deprecated some classes that JAMWiki was using, so there's a possibility of errors in the database code as well, although removing the deprecated classes seems safe enough to me at first glance and my local database isn't complaining. -- Ryan 07-Aug-2006 16:12 PDT

Okay! Setup performed correctly as expected with 0.1.4 beta2; and the basic wiki funcionality appears to be ship-shape. You can add Resin 2 on Solaris and SQL Server to the list of successful installs (although I had to tweak the ansi sql statements a little).

I'm going to be doing some extensive work to the codebase to meet my special needs, I'm hoping also to be able to incorporate your releases as they come out. My first order of business is to override the authentication and authorization scheme ... I need to integrate into an existing system. I intend to create an architecture like the persistence package that will allow different "UserHandler" implementations. Let me know if you're interested in adding something like that to the project. -- scroco

Great! Sorry it took so long. I'd be very interested in working with you to support whatever specific needs you have, as I can't imagine other businesses would be that different. I wouldn't expect that every customization you make would be generically applicable, but if there are things like moving SQL to properties or making some APIs more generic that help with your integration, then that might also be useful to others. With any luck that sort of collaboration would be a win-win, making upgrades easier for you and also providing useful functionality for others to use.
As an aside, if your authentication system is an LDAP compatible system then I'd really like to work with you on LDAP support if that's a possibility - LDAP support is already on the JAMWiki Roadmap. There is some existing LDAP integration code in the codebase, but it has been disabled since I don't have an LDAP server to test with. And if your system is not LDAP, you'll still probably find the UserGroup code of some use, although it's mostly untouched from the old Very Quick Wiki days and therefore probably in need of cleanup. Similarly, other users have asked for stricter user controls, so a finer-grained ACL system is likely to be implemented in the near future.
In any case, I appreciate all of your feedback and bug reports and will leave it to you to figure out what level of collaboration would work best for you. -- Ryan 07-Aug-2006 17:43 PDT

Nope, it's not LDAP. Sorry. It's database driven.