Other Sites
Active development of JAMWiki has ceased, and bug fixes and support will be limited at best. If you are interested in taking over management of JAMWiki please send an email to the jamwiki-devel mailing list.

Comments:Supported Configurations


Ingres 2006

Does JAMWiki work with Ingres 2006 Database? Any experiences?

JAMWiki 0.6 works on Resin

Archived from Feedback:

Great!!! It works :) Thank you very much!!
Also it works with H2 database, native java engine

That's awesome - I've never even heard of H2, but it's good to know that the ANSI database support mode actually works. If you don't encounter any problems and are willing, could you list your configuration on Supported Configurations#Known Working Configurations? I'd like to keep a list of what configurations JAMWiki works on (and doesn't work on). -- Ryan 13-Jul-2006 22:09 PDT

Done :) -- AleXis


Database connection failed with RH FC3 using Mysql 3.x and the jdbc2 org.gjt.mm.mysql.Driver: An unknown system error has occurred. The error message is: Cannot disable AUTO_COMMIT.

If MySQL 3.x doesn't support disabling auto-commit then it will probably need to be listed under the non-supported configurations. Hopefully there won't be too many people still using it given that the current MySQL version is 5.x. -- Ryan 26-Sep-2006 18:14 PDT


Apache Derby

Apache Derby (db.apache.org/derby) is a pure-java embeddable webservice database once upon a time owned by IBM, now released as free software under the Apache license. Seems to work with JamWiki, not thoroughly tested, but I get the first screens and that's enough for me to call it a promising success.

  • symlink $DERBY_HOME/lib to the servlet container lib directory (ie ln -s $DERBY_HOME/lib $RESIN_HOME/lib/derby)
  • Install derby.war as a webapp (cp to the webapp dir) and restart the servlet container; visit localhost:8080/derby/derbynet to confirm it is running.
  • at a command line, start up $DERBY_HOME/bin/ij and
  • Derby follows the DB2-style sql. Edit the "db2(experimental)" jamwiki db script webapps/jamwiki/WEB-INF/classes/sql.db2.properties:
    • remove the FIXME comment (the comment syntax is illegal for db2)
    • remove DELETE_DATE as a key column in the CONSTRAINT; null values are not allowed to be keys
  • finally, in the jamwiki startup screen, set
    • set the driver as external and use org.apache.derby.jdbc.ClientDriver
    • set dbtype to db2
    • db URL as given up in the ij step

your mileage may vary, but it worked for me. garym 22-Oct-2006 18:43 PDT

alas, no, didn't get very far. clicking on Recent Changes aborts with the screen display: _An unknown system error has occurred. The error message is: __Failure while executing select * from ( select *, rownumber() over (order by edit_date desc) as rownum from jam_recent_change where virtual_wiki_name = ? ) as jam_recent_change where rownum > ? and rownum <= ? order by rownum__ and in the logs I see: __[22:15:54.843] java.lang.Exception: Failure while executing select ... Caused by: java.sql.SQLException: Syntax error: Encountered "," at line 1, column 25.__
I'll try and take a look at this during the 0.4.1 series unless someone beats me to it. The DB2/400 file is similar to DB/2 and may be a bit more successful, although I suspect there will be some Derby-specific quirks that will need to be worked around. -- Ryan 22-Oct-2006 20:26 PDT

Sybase ASA (SQL Anywhere)

Note that when adding ASA support I had to remove some UNIQUE constraints, notably on the table jam_topic (topic_name, virtual_wiki_id, delete_date). This constraint is not possible because Sybase ASA enforces all fields in a UNIQUE constraint to be non-null, whereas delete_date has to allow nulls - otherwise any non-admin topic cannot be found as it is automatically marked as deleted (it took me a while to figure this one out!). As far as I can tell not adding these constraints has no side effect, but you may be advised post-install to add unique table indices to replace them, e.g.

create unique index jam_topic_name_idx on jam_topic (topic_name, virtual_wiki_id, delete_date);
create unique index jam_u_rmap_idx on jam_role_map (role_name, wiki_user_id, group_id);

When creating a Sybase ASA database for JAMWiki, in addition to specifying the UTF8 collation, make sure to enforce case-sensitive text comparisons (e.g. dbinit -b option).

-- Dallas 17-Mar-2008 13:59 PDT

There are a few databases that have the "no null values in a constraint" limitation, so it probably makes sense to update the database to make sure that constraint columns always have a value. Yet another item for the infinitely long to-do list... -- Ryan 17-Mar-2008 18:35 PDT

How much testing do you want before I say it works on my platform

Archived from the Feedback page:

Your wiki engine is working just fine for me on my platform - Solaris express on an AMD sempron machine, JDK1.5.0_06, Tomcat5.5, mysql5.0.33, but wait, how much confirmation do you want before anyone reports that it works on a platform? I haven't tested any features that might reveal platform issues. Maybe like LDAP. In my day job, this is surely inadequate testing before claiming support for a platform.

If there are test suites that you want testers to go through, I'll see if I can do that. BTW Japanese encoding support through UTF-8 just works fine out of the box.

Obviously I'd like bug reports (and fixes when possible!) for any problems that people find, but since this is an open source project my expectation is that when someone lists their configuration under Supported Configurations that they are at least able to install and perform basic tasks without any errors. It would be great to have additional testing done, and I'd be thrilled if we had more automated tests (currently we've got some JUnit tests and that's about it), but I don't think a lack of such thorough testing should be a reason not to share with others that the software should work on their platform. Using your specific example of LDAP, that functionality is still marked as experimental since it should work, and worked fine in a test setup, but has not been confirmed to work in a variety of setups and could definitely use additional testing.
For anyone with the desire or ability to perform more thorough testing, such testing would be greatly appreciated and would go a long way towards discovering any problems in the current code and helping to make the software more reliable. Hopefully that answers your question! -- Ryan 26-Feb-2007 20:56 PST

JAMWiki has good browser interoperability

Archived from the Feedback page:

One good thing I've noticed about JAMWiki. It doesn't have any problems with all the browsers I use; Firefox2.0.0.2, Opera9.10, IE6.0.2. This is a good thing. The other wiki engines that I know have issues with browsers. I thought you should have a "Supported browsers" corner in the supported platforms area.

The wiki engine I use primary is ZWiki on Plone, but when you use https, it has a minor issue with IE. I also tested XWiki, but the javascript intensive WYSIWYG editor doesn't run on Opera.

When you start playing with javascript too much, you run the risk of browser incompatibilities. I really like the current editing UI (which means I like the UI of mediawiki), without much fancy javascript.

Thanks! Feel free to add a section to Supported Configurations if you'd like, or if you think there's a better then go ahead and add the info wherever you think is best. I've made some effort to make sure that pages validate, so it's good to hear that it's paying off. -- Ryan 28-Feb-2007 08:36 PST

Reverse Proxy

Archived from the Feedback page:

Hi, may I know if JamWiki will work behind a reverse proxy? Are all the links relative? Or is there a setting for a custom absolute path? -- Kwee Tin

At the moment all URLs are relative, although it probably wouldn't be too difficult to add an option to make them absolute if that's a useful feature. I don't know enough about reverse proxies to understand why an absolute URL would be needed - is there any chance you could provide either a quick explanation or a pointer to a site that has some details? I looked briefly at the , but didn't see anything that would indicate why an absolute URL would be needed. I'd just like to be sure that before I make any changes I understand what exactly the benefit is :) -- Ryan 10-Jan-2007 22:40 PST

Hi Ryan, In my case, JamWiki is to be hosted on a webserver in the backend (e.g. http://xxx.xxx.xxx.xx:7001/jamwiki). However, the end users will be hitting the pages through a reverse proxy by the URL (https://mydomain.com/jamwiki). If any of the links/files are not relative paths, then users will not be able to access the pages/files. Thanks. -- Kwee Tin

Thanks for the clarification - if I understand you correctly, since you need all URLs to be relative, JAMWiki should work fine on your setup. -- Ryan 10-Jan-2007 23:32 PST