Asiri's Laboratory

One of the annoying problems I came across recently is that it’s really painful to get tomcat installed on Fedora (or CentOS) without being dependent on OpenJDK. I don’t like using OpenJDK because SunJDK is widely used and well tested (plus, I don’t see a distinct advantage of using OpenJDK). Also in my specific use case, XWiki has some problems when run on OpenJDK (Tomcat).

For me, the main advantage of using platform provided tomcat version (one that depends on OpenJDK) is that it is well integrated into the system (init scripts, updates etc.) but getting it to work with SunJDK is kind of hackish. There are several blog posts on the internet about how to configure the platform provided tomcat version to depend on SunJDK instead of OpenJDK (most solutions make use of the alternatives command) but none of them seems to be without side effects (and in my specific case, it just didn’t work – XWiki failed to start).

I finally made up my mind and decided to install tomcat and SunJDK from their official web sites. Right now I’m executing tomcat from my personal user account and I have set my JAVA_HOME and PATH variables correctly so that tomcat uses SunJDK rather than system provided OpenJDK. It might not be the perfect solution (administrative difficulties, security concerns etc.) but for my particular use case it was acceptable. However, I believe these disadvantages can be overcome with some effort (write an init script, create a separate user account for executing tomcat etc.) and that it’ll still be worthier than being dependent on OpenJDK.

Here’s an xwiki component that integrates recaptcha support into xwiki: xwiki.recaptcha.zip. It can be tested with the following xwiki code snippet:

{{velocity}}
#if("$!{request.recaptcha_challenge_field}" != "")
  #if($recaptcha.isValid($request))
    {{info}}Recaptcha validation succeeded.{{/info}}
  #else
    {{error}}Recaptcha validation failed.{{/error}}
  #end
#end
{{html}}
<form action="$doc.URL" method="post">
  <div id="recaptcha_box"></div>
  <input type="submit" value="Validate"/>
</form>
<script type="text/javascript">
  Recaptcha.
    create("$recaptcha.publicKey", "recaptcha_box", {theme: "red"});
</script>
{{/html}}
{{/velocity}}

However, integrating recaptcha support into xwiki functions (like for comments) is bit tricky and requires some hacking.

UPDATE: From XE 2.3 onwards XWiki has built-in captcha support.

About a week ago I decided to move my web content from myxwiki.org to rathnayake.org. The decision was mainly because I wanted have a personal server which I can use for all sorts of wacky experiments. As an added benefit, now I can host my content under a personal domain. With this move I began working on some of the articles that I always wanted to publish. But there I was bit worried; the default presentational macros of XWiki did not match my taste. For an example, xwiki has three macros for presenting informative messages:

Clearly this wasn’t enough for me, I wanted more aesthetically pleasing, customizable and reusable presentational elements for my work. At this point it came to my mind that coupling XWiki skin extension support with XWiki wiki macros would provide a solution for my problem; I spent several hours with both the technologies and finally came up with the mbox macro:

NOTE: You can download & view source code for mbox macro at MBox macro page.

So how customizable is this new mbox macro? There are two possibilities here. On one hand we can mix-and-match various parameters of the mbox macro to create different presentational elements. For an example, we can quickly put together a warning mbox element like below:

Output of above warning mbox would be:

NOTE: Tango icon library provides a wealth of icons that can be used with mbox macro.

The other approach towards customizing mbox macro is to edit the MBox style sheet extension or the MBox wiki macro Definition itself (both residing inside MBox macro page). Still, this approach might not qualify as a method of customizing, rather it is like a central control box where you can alter the presentation of your content by editing just one wiki page. All your wiki pages will be updated instantly to reflect your new instructions.

Finally what about re-usability? This is where it gets really interesting: xwiki macros can be nested, which means you can derive new macros encapsulating existing ones. I’ll leave the details out for now, just have a look at my mnote macro which is derived from the mbox macro:

NOTE: You can refer MNote macro page for source code and installation instructions.

As we saw above, wiki macros allow authorised users to define new presentational elements which are customizable, reusable and extensible. I should conclude my post stating that this is only one cool feature of XWiki, there are host of other XWiki features which when used wisely makes XWiki a great application / publishing platform. I will be posting more about these cool XWiki features in coming months

We’ve been introducing several enhancements to XWiki OfficeImporter application for past few months. Along with XE 2.0 final release we’ll be launching our latest feature packed OfficeImporter!

Many thanks to laurent lunati for coming up with a cool UI