Tag Archives: Java

Forking GlassFish Redux: Payara Server

In the time since I last wrote about the need for a fork of Oracle’s GlassFish Server, Oracle have effectively removed the viability of GlassFish as a production system by killing off professional support in favour of their megabucks closed-source WebLogic product. This was a completely unsurprising move, and simply added to the mountain of orphaned and abandoned techhnology inherited from Oracle’s Sun acquisition (to which we can add some more recent additions).

Fortunately, and largely due to the wisdom of Sun to originally open source the product, a new player in the Java app server scene has appeared with what is to all intents and purposes the GlassFish fork we’ve been waiting for: Payara Server.

You can check out their website at: http://www.payara.co.uk/home. As mentioned on their site: “We take GlassFish upstream. We support it, fix it, enhance it. We release it as open source Payara Server.”

Do I have funds or a current use case to pay for professional support for an app server yet? No. Do I want to use the same product I’ll eventually be using in production while I’m in the startup/setup phase, easily and without restriction? Yes. Will I pay for support if the use case requires it, and if it guarantees a healthy product/project down the line in the best spirit of open source? Happily, and especially if it’s from the same vendor offering the product to begin with. Not rocket science, and when a vendor throws too many obstacles in my path I’ll simply switch to an alternative which does afford me these freedoms.

Looking forward to trying this out.


Configuring a public JSPWiki instance for private use

Been a tad quiet on this blog for a while I realise – time to freshen thing up a bit.

In this blog post we’re going to quickly cover how to configure a JSPWiki instance such that wiki content cannot be viewed without being authenticated with a login account. For example, you may wish to deploy JSPWiki in the cloud for convenient access anywhere, but also use it to host company-sensitive documentation. In this case you probably don’t want the general public even having read-only access to the wiki content.

It turns out this is very straightforward to achieve and merely consists of making the desired changes in the jspwiki.policy file. The function of each policy block within jspwiki.policy is also clearly documented in the same file, so everything is pretty self explanatory.

JSPWiki setup and configuration is outside the scope of this post, so I’m assuming you’ve set up JSPWiki to use container-managed authentication similar to some of my previous articles here. Also note that in recent releases of JSPWiki (certainly v2.10.x) the location of various configurations files has changed – again, outside the scope of this post. All this considered, the following full excerpt of my jspwiki.policy file achieves the following:

  • All public users are prevented from being able to view the wiki.
  • Anonymous users have no permissions.
  • Users authenticated via a browser cookie have no permissions.
  • Users authenticated with a JSPWiki login account (configured in our application server, e.g. GlassFish) have a set of standard permissions for viewing, editing, and modifying content.
  • Admin users have full permissions.

Note that I’ve left the original policy blocks in place commented out so you can see the exact settings I’ve made.

//  Licensed to the Apache Software Foundation (ASF) under one
//  or more contributor license agreements.  See the NOTICE file
//  distributed with this work for additional information
//  regarding copyright ownership.  The ASF licenses this file
//  to you under the Apache License, Version 2.0 (the
//  "License"); you may not use this file except in compliance
//  with the License.  You may obtain a copy of the License at
//    http://www.apache.org/licenses/LICENSE-2.0
//  Unless required by applicable law or agreed to in writing,
//  software distributed under the License is distributed on an
//  KIND, either express or implied.  See the License for the
//  specific language governing permissions and limitations
//  under the License.

// $Id: jspwiki.policy,v 1.23 2007-07-06 10:36:36 jalkanen Exp $
// This file contains the local security policy for JSPWiki.
// It provides the permissions rules for the JSPWiki
// environment, and should be suitable for most purposes.
// JSPWiki will load this policy when the wiki webapp starts.
// As noted, this is the 'local' policy for this instance of JSPWiki.
// You can also use the standard Java 2 security policy mechanisms
// to create a consolidated 'global policy' (JVM-wide) that will be checked first,
// before this local policy. This is ideal for situations in which you are
// running multiple instances of JSPWiki in your web container.
// To set a global security policy for all running instances of JSPWiki,
// you will need to specify the location of the global policy by setting the
// JVM system property 'java.security.policy' in the command line script
// you use to start your web container. See the documentation
// pages at http://doc.jspwiki.org/2.4/wiki/InstallingJSPWiki. If you
// don't know what this means, don't worry about it.
// Also, if you are running JSPWiki with a security policy, you will probably
// want to copy the contents of the file jspwiki-container.policy into your
// container's policy. See that file for more details.

// The first policy block grants privileges that all users need, regardless of
// the roles or groups they belong to. Everyone can register with the wiki and
// log in. Everyone can edit their profile after they authenticate.
// Everyone can also view all wiki pages unless otherwise protected by an ACL.
// If that seems too loose for your needs, you can restrict page-viewing
// privileges by moving the PagePermission 'view' grant to one of the other blocks.

//grant principal org.apache.wiki.auth.authorize.Role "All" {
//    permission org.apache.wiki.auth.permissions.PagePermission "*:*", "view";
//    permission org.apache.wiki.auth.permissions.WikiPermission "*", "editPreferences";
//    permission org.apache.wiki.auth.permissions.WikiPermission "*", "editProfile";
//    permission org.apache.wiki.auth.permissions.WikiPermission "*", "login";

grant principal org.apache.wiki.auth.authorize.Role "All" {
    permission org.apache.wiki.auth.permissions.WikiPermission "*", "editPreferences";
    permission org.apache.wiki.auth.permissions.WikiPermission "*", "editProfile";
    permission org.apache.wiki.auth.permissions.WikiPermission "*", "login";

// The second policy block is extremely loose, and unsuited for public-facing wikis.
// Anonymous users are allowed to create, edit and comment on all pages.
// Note: For Internet-facing wikis, you are strongly advised to remove the
// lines containing the "modify" and "createPages" permissions; this will make
// the wiki read-only for anonymous users.

// Note that "modify" implies *both* "edit" and "upload", so if you wish to
// allow editing only, then replace "modify" with "edit".

//grant principal org.apache.wiki.auth.authorize.Role "Anonymous" {
//    permission org.apache.wiki.auth.permissions.PagePermission "*:*", "modify";
//    permission org.apache.wiki.auth.permissions.WikiPermission "*", "createPages";

grant principal org.apache.wiki.auth.authorize.Role "Anonymous" {

// This next policy block is also pretty loose. It allows users who claim to
// be someone (via their cookie) to create, edit and comment on all pages,
// as well as upload files.
// They can also view the membership list of groups.

//grant principal org.apache.wiki.auth.authorize.Role "Asserted" {
//    permission org.apache.wiki.auth.permissions.PagePermission "*:*", "modify";
//    permission org.apache.wiki.auth.permissions.WikiPermission "*", "createPages";
//    permission org.apache.wiki.auth.permissions.GroupPermission "*:*", "view";

grant principal org.apache.wiki.auth.authorize.Role "Asserted" {

// Authenticated users can do most things: view, create, edit and
// comment on all pages; upload files to existing ones; create and edit
// wiki groups; and rename existing pages. Authenticated users can also
// edit groups they are members of.

grant principal org.apache.wiki.auth.authorize.Role "Authenticated" {
    permission org.apache.wiki.auth.permissions.PagePermission "*:*", "modify,rename";
    permission org.apache.wiki.auth.permissions.GroupPermission "*:*", "view";
    permission org.apache.wiki.auth.permissions.GroupPermission "*:<groupmember>", "edit";
    permission org.apache.wiki.auth.permissions.WikiPermission "*", "createPages,createGroups";

// Administrators (principals or roles possessing AllPermission)
// are allowed to delete any page, and can edit, rename and delete
// groups. You should match the permission target (here, 'JSPWiki')
// with the value of the 'jspwiki.applicationName' property in
// jspwiki.properties. Two administative groups are set up below:
// the wiki group "Admin" (stored by default in wiki page GroupAdmin)
// and the container role "Admin" (managed by the web container).

grant principal org.apache.wiki.auth.GroupPrincipal "Admin" {
    permission org.apache.wiki.auth.permissions.AllPermission "*";
grant principal org.apache.wiki.auth.authorize.Role "Admin" {
    permission org.apache.wiki.auth.permissions.AllPermission "*";

After applying this and restarting the application server domain, one can now see that we need to authenticate even to view any of the wiki content.

JSPWiki now requires authentication to view.

Enjoy, and if you have any problems please leave a comment.

Creating a GlassFish service on Mac OS X

Quick post – when installing GlassFish on Mac OS X (10.8.3 in my case) a GlassFish service won’t be created by the GlassFish installer (whereas Windows and Solaris platforms do get the ability to manage GlassFish as a service).

I came across a handy blog post by a former Sun Microsystems staffer which takes us most of the way there:


The original blog entry was pertaining to Mac OS 10.4 but applies to 10.8 with one exception (in my case). When attempting to load the service the GlassFish process would immediately be killed by launchd. This is alluded to in the blog comments above.

The solution can be found at https://discussions.apple.com/thread/1744853?start=0&tstart=0 and consists of adding the following entry to your GlassFish plist file:



My quick procedure for creating a GlassFish service based on the above information follows. Note that I am not covering the details of how services are created and managed for Mac OS, so this is basically to get up and running quickly.

1) Create a plist file

Simlar to Solaris SMF, the plist file is an XML service descriptor file. These are the contents of my file:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN"
<plist version="1.0">

Replace the UserName and GroupName values with the user and group you wish to launch GlassFish as. Also, GlassFish in my case has been installed to /Users/davek/glassfish3 – alter this path in your plist file accordingly.

Save the file for example as GlassFish.plist and copy it to /Library/LaunchDaemons.


2) Set ownership on the GlassFish domain

We are running the GlassFish service as davek:staff so be sure to change ownership on the relevant GlassFish domain (domain1 in this example) to match.


3) Import the service

Run the following command:

sudo launchctl load /Library/LaunchDaemons/GlassFish.plist

The service starts automatically after importing, so you should be able to browse to the administrative interface for the domain. If you reboot the system, the domain should also start on boot automatically.

Installing the Oracle Java 7 plugin in Firefox on Ubuntu 12.04

We are briefly describing here how to install the Java plugin for Oracle JDK/SE 7 in Firefox. This is a manual procedure, and in this case we are wanting to install the plugin for Java 7 update 10 to enable running of JavaFX apps in Firefox 17.01 on Ubuntu 12.04 x86.

Assuming we are using the full Oracle JDK and have installed it to /opt, then the Firefox/browser plugin is located at at /opt/jdk1.7.0_06/jre/lib/i386, and is the file named libnpjp2.so:

davek@mymachine:/opt/jdk1.7.0_06/jre/lib/i386$ pwd
davek@mymachine:/opt/jdk1.7.0_06/jre/lib/i386$ ls -al libnpjp2.so 
-rwxr-xr-x 1 root root 169420 2012-08-10 15:20 libnpjp2.so

At /usr/lib/firefox/plugins create a symbolic link to this file:

davek@mymachine:/usr/lib/firefox/plugins$ pwd
davek@mymachine:/usr/lib/firefox/plugins$ sudo ln -s /opt/jdk1.7.0_06/jre/lib/i386/libnpjp2.so .
davek@mymachine:/usr/lib/firefox/plugins$ ls -al
total 8
drwxr-xr-x 2 root root 4096 2012-08-15 22:19 .
drwxr-xr-x 6 root root 4096 2012-05-03 00:09 ..
lrwxrwxrwx 1 root root   41 2012-08-15 22:19 libnpjp2.so -> /opt/jdk1.7.0_06/jre/lib/i386/libnpjp2.so

After restarting Firefox, the Java plugin should now be available (and can be enabled and disabled accordingly):

Java plugin in Firefox.

IM+ Pro vs. Xabber as an Android Openfire client

Quick post for those looking for a capable Android client for Openfire. IM+ and IM+ Pro don’t support direct connections to an XMPP server such as Openfire: connections are made first to Shape’s servers then passed on to Openfire (see here for example). Of course, if you are wishing to connect to a private Openfire server, then IM+ Pro is effectively useless. It’s especially disappointing to find this out after shelling out for the “Pro” version, and Shape don’t exactly put a clear warning up or anything.

Xabber on the other hand does permit direct connections to an XMPP server, is free, ad-free, and comes with a nice UI to boot. So, for my purposes there is no competition to speak of 🙂

Xabber connecting to Openfire

Java 7 update 6 arrives, JavaFX now supported in the JRE for Linux

Quick post – the latest update to Oracle Java 7 features Mac OS supported as an equal peer to Windows and Linux – but perhaps more interestingly now includes full JavaFX runtime support in the JRE for Linux. Having cross platform support for Oracle’s next-generation Java UI does finally open up some interesting possibilities for better Java client interfaces than what we’ve generally seen so far.

Screengrab of the JavaFX Ensemble demo app running happily in Firefox on Ubuntu 10.04 x86:

JavaFX in Firefox on Ubuntu

Disable conversation view in the Gmail Android app

Actually, the title is total linkbait because you can’t. Google would rather inflict the wretched conversation view on you whether you like it or not. This might sound peculiar, but perhaps less so if you read “GMail: designer arrogance and the cult of minimalism“, and also this legendary rant from one of Google’s own prominent software engineers (Steve Yegge), of which a relevant excerpt follows:

“But when we [Google] take the stance that we know how to design the perfect product for everyone, and believe you me, I hear that a lot, then we’re being fools. You can attribute it to arrogance, or naivete, or whatever — it doesn’t matter in the end, because it’s foolishness. There IS no perfect product for everyone.

“And so we wind up with a browser that doesn’t let you set the default font size. Talk about an affront to Accessibility. I mean, as I get older I’m actually going blind. For real. I’ve been nearsighted all my life, and once you hit 40 years old you stop being able to see things up close. So font selection becomes this life-or-death thing: it can lock you out of the product completely. But the Chrome team is flat-out arrogant here: they want to build a zero-configuration product, and they’re quite brazen about it, and Fuck You if you’re blind or deaf or whatever. Hit Ctrl-+ on every single page visit for the rest of your life.”


So – if you’re like me and want to check out a great email app for Android which doesn’t use conversation view and includes all the bonus goodies the Gmail app is missing (think Thunderbird for Android), you should check out K-9 Mail:


The really nice thing is that if you want to support the developers of this fine application, you can pay a tiny sum for the deee-luxe version, which goes by the name of Kaiten:


Kaiten Mail running on Android

LDAP secondary group memberships with OpenDJ and Ubuntu 12.04

As a follow-up to this post, let’s now configure OpenDJ and Ubuntu to use LDAP for assigning secondary groups to user accounts.

This is a quick guide intended for testing only, and we are assuming the setup here has been followed. One change is that we are using Ubuntu 12.04 x86 as the client system.


First, let’s create a new test group in OpenDJ. We assign it the structural object class namedObject, and the auxiliary object class posixGroup. The group GID number is 130, and we add a memberUid entry, with the UID of an existing LDAP account:

Adding a new group in OpenDJ

Now, on our test Ubuntu 12.04 x86 client, we modify /etc/ldap.conf, adding the following entry:

nss_schema rfc2307bis

This enables rfc2307bis LDAP schema support for PAM (OpenDJ uses the rfc2307bis schema by default).


Next, again in /etc/ldap.conf we uncomment the nss_base_group setting in the section headed with the comment “RFC2307bis naming contexts”, and give it the value as shown:

nss_base_group ou=Groups,dc=example,dc=co,dc=nz

Obviously you would modify the domain components to suit.


We now restart the nscd service, and verify that the secondary group information can be retrieved for an LDAP user:

itadmin@turrican2:/etc$ sudo /etc/init.d/nscd restart
 * Restarting Name Service Cache Daemon nscd                             [ OK ] 
itadmin@turrican2:/etc$ id davek
uid=1004(davek) gid=50(staff) groups=130(testgroup),50(staff)

We can see that the secondary group testgroup with the GID number of 130 is successfully retrieved from LDAP for this user.

Prevent the “List of attachments” from appearing in documents printed from JSPWiki

In a default installation of JSPWiki files attached to a JSPWiki page are printed in a list along with the rest of the document. If one has a large amount of attached files in a wiki page, this leads to needless extra printed pages:

List of attached files in a document printed from JSPWiki

I enquired about this on the JSPWiki users mailing list, and Dirk Frederickx kindly gave me the solution to this:

“Following changes to the jspwiki_print.css file, in the “templates/default” directory, will hide the attachment list:”

/* add this line to hide the List of Attachments */
#attach {display:none;}

And, it works a charm.

Fun with JSPWiki skins

I really love JSPWiki. It’s super-easy to install, doesn’t require any additional configuration for a back-end database, the native interface is quick and fast to use, and it just runs and runs. Great software.

If there’s one area however where it’s lacking, it’s in a nice selection of bundled good-looking themes. But hey, it’s free and open source software, so one is really in no position to complain – and new skins can be created using entirely standard and familiar HTML and CSS.

It’s worth noting the difference between JSPWiki templates and skins – described at http://www.jspwiki.org/wiki/JSPWikiSkinDesign

After a bit of tinkering with CSS and the bundled “Smart” theme, I came up with this:

JSPWiki - modified "Smart" theme

Not the stuff of professional web design, but a definite improvement on the default theme, in my humble opinion.