The JSPWiki development team thinks 2.6 is the best release yet. Here's a quick summary of the most important enhancements. For the complete and growing documentation, go to http://doc.jspwiki.org/2.6.

Core#

  • Servlet 2.4 container support. JSPWiki 2.6 requires a JEE servlet 2.4-compatible container, such as Apache Tomcat 5.5 or higher.
  • Internationalization support. JSPWiki's JSPs are now fully internationalized. The languages supported out-of-the-box are English, Finnish, German, and Spanish. In the deployed WAR file, localization files for templates are stored in WEB-INF/i18n/templates. "Core" class localization files are in WEB-INF/i18n.
  • Approval workflow for page edits. JSPWiki 2.6 implements moderated page changes. The name of the user, role or group that approves page changes is contained in jspwiki.properties under the property jspwiki.approver.workflow.saveWikiPage. If not supplied (the default), page changes are performed without requiring approval.
  • Support for container-managed e-mail factories. MailUtil gains the ability to use container-managed JNDI JavaMail session factories, in addition to the standalone factory configured via jspwiki.properties. JNDI is now the preferred method of obtaining mail sessions, and will always be attempted first before falling back to the stand-alone method. For configuration hints see JNDI Mail Configuration
  • Goodbye wikinames. User profile JSPs no longer request a distinct wiki name when a user registers. The wiki name is now computed automatically; it is the user name without any whitespace. This change should make registration even easier.
  • Snappy search. JSPWiki now boasts JSON-assisted searches, for instant gratification.
  • XHTML compliance. All pages are XHTML compliant.
  • Welcome, spaces. JSPWiki now supports whitespace in page names, so you no longer have to WriteYourPagesLikeThis.
  • Improved WYSIWYG editor support. FCKeditor is now a viable editor option. You will need to install FCKeditor separately though; however, it should a quick and simple procedure.

Templates and JSPs#

  • New default template. Dirk Frederickx's excellent Brushed template serves as the basis for JSPWiki 2.6's new default template. It's full of AJAX goodness and looks great.
  • Tag enhancements. <PermissionTag> now allows a list of permissions just like <CheckRequestContextTag>, as well as negative permissions.
  • JavaScript compression. The WAR includes compressed jspwiki-edit.js, jspwiki-common.js and jspwiki-prefs.js files, using the Rhino library. This should bring in considerable savings to bandwidth and give better response.
  • JSP 2.0 Tags. All JSP taglib declarations were changed to use JSP 2.0-compatible tags. We also upgraded jstl.jar and standard.jar to JSTL 1.1 versions. Note: if you are a template developer, you should change your taglib declarations as follows:'s
New:
   <%@ taglib uri="http://java.sun.com/jsp/jstl/fmt" prefix="fmt" %>
   <%@ taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c" %>

Old:
   <%@ taglib uri="http://java.sun.com/jstl/fmt" prefix="fmt" %>
   <%@ taglib uri="http://java.sun.com/jstl/core" prefix="c" %>

Security#

A big priority for JSPWiki 2.6 was the simplification of the security configuration. In particular, users wanted us to make it easier to configure security policies, particularly in multi-wiki configurations. Here are a few of the most important changes:
  • Local security policies for each wiki. In JSPWiki 2.5, we implemented security policies by overriding the JVM-wide security with our own. In cases where a security policy was already installed by the container, this was causing JSPWiki to fail. To make things Just Work, we've eliminated the need to set a JVM-wide security policy. Instead, we install a "local policy" that is always read from WEB-INF/jspwiki.policy. If you have a JVM-wide policy, the local policy will supplement it. The practical upshot of this change is that the most common configuration challenge that most first-time admins face (why won't any pages display?) is gone, and gone forever. No more fiddling with the java.security.policy property! The syntax for the local policy is exactly the same as in previous versions.
  • JAAS LoginModule enhancements. JSPWiki now allows full use of non-JSPWiki supplied JAAS LoginModules in the JSPWiki-custom configuration. Previously, we considered a user to be authenticated only if a LoginModule had added Role.AUTHENTICATED to the Subject's principal set. This is clearly unreasonable for LoginModules that have no knowledge of JSPWiki, such as Sun's supplied modules or third-party modules used for LDAP authentication. Now, we consider a user authenticated if they are not anonymous and not asserted, and we lazily add Role.AUTHENTICATED in these cases, after login.
  • Simpler default security policy. The security policy file has been simplified to remove redundant grants that don't vary across roles. It should be simpler to read and understand.
  • E-mail authentication. Configuration options for e-mail services, used for things like password resets, includes authentication support, so that you can use mail servers that require an account (the OpenRelay issue...). You now also can indicate a different smtp port.
  • Spam controls. There's a new SpamLog which can be used to track all changes; accepts and rejects. SpamFilter adds Captcha recognition, if we suspect you to be a spammer. SpamFilter captcha is user-settable. Possible options are "none" and "asirra".
  • Permissions changes. With PagePermissions, the rename permission no longer implies modify (or upload). This will allow separation of uploading attachments from page edit/rename actions.
  • Approval workflow for user profile creation. New profiles can be routed for approval before they become active. The name of the user, role or group that approves new profiles is contained in jspwiki.properties under the property jspwiki.approver.workflow.createUserProfile. If not supplied (the default), user profiles are created without requiring approval. Profile registrations automatically trigger an e-mail confirmation to the user, if an e-mail address was supplied.
  • Profile login/user name changes. Users can change login names and user names ("full names") after registration.
  • Weblog security enhancements. WeblogPlugin now considers ACLs - if the user does not have view permission on an entry, it's ignored on display.
  • No more JAR signing. We have eliminated the need to sign JSPWiki JARs for 95% of most users' deployments. Now, the only case where you need to sign them is when you wish to create a JVM-wide, consolidated security policy. We have retained an Ant target "signjar" for that purpose. If you are upgrading from an earlier version of JSPWiki and are using a customized policy, however, you must remove any "signedBy jspwiki" and "keystore" references, otherwise JSPWiki might act oddly.
  • Tighter defaults. SecurityConfig.jsp now ships off by default, but can be enabled by setting jspwiki-x.securityconfig.enable=true. The page also has instructions on how to accomplish that, when you try to access it.
  • Remember me. Now, by enabling the CookieAuthenticationLoginModule in your JAAS file, you can keep your users logged in for days without the need to write in your username and password every time you visit the site!

Developer#

Under the hood, JSPWiki adds quite a few classes, packages and features for developers. Here are a few of the highlights:
  • We hate bugs less than before. JSPWiki now has a real bug database, at the Apache JIRA site
  • Workflow package. JSPWiki 2.6 adds a significant new package for modeling workflow operations (com.ecyrd.jspwiki.workflow). This package allows arbitrary combinations of "steps" to be modeled, with support for unlimited branching and support for human intervention. The core class is the Workflow class. Workflows are composed of Steps, which can be Tasks (which run uninterrupted) and Decisions (which require input from named Principals -- users, roles or groups). Page edits and profile creation approvals both use this package.
  • i18n. In the trunk, etc/i18n contains internationalization files.
  • Web unit test scripts. Ant build script for webtests is now much smarter. Web tests now perform a "pre-flight" check to make sure preconditions are satisfied before launching. If you've wanted to run web tests before but "couldn't get them working," the new script should set things right.
  • New web unit test tools. We ripped and replaced the old web unit test tool (JWebUnit) and replaced it with Selenium. Web tests are yet not at parity with old (failing) JWebUnit tests, but they are pretty good for a start. We removed all traces of JMeter, HttpUnit and JWebUnit, and re-based Selenium tests to tests/etc/selenium/tests. If you want to try developing your own web tests, check out Selenium IDE, a FireFox plugin that records user actions and generates tests scripts.
  • Administration UI. This feature is still experimental, but you can do some of the basic maintenance tasks, such as user maintenance, using a web UI by going to admin/Admin.jsp.

Bug fixes#

Of course, every release of JSPWiki fixes a number of issues. Here's the list of the issues which we have fixed in this release:

Compatibility notes#

  • 2.6 has a new PageFilter interface definition, so any 2.4-compliant PageFilter MUST be recompiled for 2.6 (please see the javadoc).
  • Templates, in general, should work. However, some very advanced Javascript templates (read BrushedTemplate) won't work. But don't worry, the new default template is based on brushed, and it's got loads of goodies even BrushedTemplate does not have!
  • Plugins should work without modification

Add new attachment

Only authorized users are allowed to upload new attachments.
« This page (revision-28) was last changed on 16-Jul-2008 18:57 by Mardi Rollow