# 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.

# Oracle nukes Sun Ray and VDI

I shouldn’t be surprised, but still: Oracle to halt development of Sun virtualization technologies

What’s really, really rich was one of Oracle’s own folks only a couple of months ago stating the following on the Sun Ray Users mailing list:

“Oracle does not keep acquired products that they do not believe have a future. I’d challenge you to compare release timelines from both Sun and Oracle and see under which flag the product has had more major releases and more features. If Oracle was not committed to Sun Ray and VDI, it would have been gone very soon after the acquisition.

I can tell you Oracle is committed to Sun Ray and VDI. I get that people are unhappy with some of the changes (Firmware requiring a support contract, Public road maps, social media changes), but those things have very little bearing on whether or not Oracle is committed.”

Whoopsies.

At the day job we migrated from Sun Ray onto Onelan for our digital signage needs, and after that my contact with either Sun Ray or Solaris dropped to zero. Still, sad to see what was a fantastic platform kicked to the curb, joining the myriad other Sun products and projects which Oracle has bungled, mismanaged, or ejected – presumably to support the unbelievably crass lifestyle of the guy ostensibly running the joint. Sad times.

# heliod web server: fast then, still fast today

Quick post – as an update to my post here, Jyri Virkki has published a comprehensive set of benchmarks, comparing heliod’s out-of-the-box performance to all the other current popular HTTP servers out there. Considering the last public comparison I could find of what was then Sun Java System Web server vs Apache was in 2007, these new results are highly interesting:

“heliod had the highest throughput at every point tested in these runs. It is slightly faster than nginx at sequential requests (one client) and then pulls away.

“heliod is also quite efficient in CPU consumption. Up to four concurrent clients it is the lightest user of CPU cycles even though it produced higher throughput than all the others. At higher concurrencies, it used slightly more CPU than nginx/lighttpd although it makes up for it with far higher throughput.

“heliod was also the only server able to saturate the gigabit connection (at over 97% utilization). Given that there is 62% idle CPU left at that point, I suspect if I had more bandwidth heliod might be able to score even higher on this machine.

“These results should not be much of a surprise… after all heliod is not new, it is the same code that has been setting benchmark records for over ten years (it just wasn’t open source back then). Fast then, still fast today.

You can read the total run of tests plus information graphs at Jyri’s blog entry: http://173.255.252.27/jyri/articles/.

Incidentally, I came across a blog post from someone who was also apparently on the Sun Java System Web Server group at Sun, who states:

“Since Oracle no longer offers updates to individual users, and refuses to respond to requests for information about how an individual can acquire the updates, I have elected to stop writing about the server. If the moribund Open Web Server gets branched I will happily contribute to the pool of knowledge that exists for it.”

# heliod – Oracle iPlanet Web Server forked as open source

Prior to the Oracle acquisition, I used to be a fan of Sun Microsystems’ web server product, Sun Java System Web Server. It had serious enterprise lineage, a terrific web admin BUI which beat the pants off Apache, and was free, free, freeeee. Needless to say, that all changed once Oracle bungled onto the scene, along with a whole bunch of other stuff.

A little known fact however is that Sun had open-sourced the core of their web server prior to Oracle taking over, releasing it as the Sun Open Web Server. But other than a few headlines at the time of the announcement (such as here) everything went very quiet shortly after – and no doubt I am sure due to Oracle not wanting to advertise the zero-cost availability of the guts of their “re-branded” megabucks flagship web server, now known as Oracle iPlanet Web Server.

So, imagine my surprise to find that one of the original engineers behind Sun Open Web Server (Jyri Virkki) has forked the code open-sourced those three or so years ago and is now actively developing it. Yes, it lives, and is known as heliod web server:

http://173.255.252.27/jyri/articles/index.php/web-server/

Francois Dion has a great write-up here as well:

http://solarisdesktop.blogspot.co.nz/2012/09/netscape-sun-oracle-no-heliod-web-server.html

Attempting to launch heliod on OpenIndiana oi_151a x86, I was met with the following error:

$./bin/startserv ld.so.1: parsexml: fatal: libicui18n.so.3: open failed: No such file or directory ./bin/startserv: line 63: 12686: Killed failure: temporary directory is not writable by user root  This is due to the library/icu package not being present – so install it if it’s missing and it’ll start up fine: $ ./bin/startserv &
[1]	3692
dave@mymachine:/opt/heliod/https-testserver\$ heliod Web Server 0.1 B03/08/2011 21:59
info: CORE3016: daemon is running
info: HTTP3072: http-listener-1: http://mymachine:80 ready to accept requests
info: CORE3274: successful server startup


# 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:

# Sibelius and the risk of proprietary software

Before doing what I do now, I used to do music. It’s not an environment I’m involved in to any great extent any more, although I certainly wouldn’t rule out taking it up again at some point in the future.

So it was interesting after reading about recent customer upset involving much-loved proprietary software vendors being acquired to learn that users of the Sibelius music notation product are similarly getting burned by recent moves by parent company Avid Technology.

In this case, it looks like Avid have shuttered the UK office where Sibelius was originally developed (along with many other products in their portfolio) in what looks like a considerable cost-cutting drive. Reading the general outpouring of concern from Sibelius customers online, I was struck by just how eerily familiar the whole thing sounded to someone who’d gone through the whole rigmarole before – in this case, my experience with Oracle.

For example, the creation of online user concern groups (also on Facebook), the inevitable petitioning of Avid (and publishing of contact information for its senior management team), and representatives from Avid being trotted out to reassure customers of their “commitment” to the product – even though it looks like a large chunk of the core development team have already walked the plank.

Do I think that petitions and corporate assurances are going to make any difference to the likely future of Sibelius whatsoever? Not a chance. This is business, and it’s the risk any customer takes when investing in a product based on non-standard, proprietary technology. You can’t successfully shame nor persuade a corporation (especially a giant like Avid) into rethinking whatever decisions they’ve already made, planned probably months before the announcement. Been there, done that, doesn’t work. Avid management are probably really not too concerned with Sibelius users’ feelings, nor their user community: like many other major technology vendors, they’ll do whatever it takes to satisfy their shareholders, if it means killing or reducing development in a few niche products along the way. Put it this way, this is not the first time a major technology vendor has screwed their professional users, and it sure won’t be the last.

The best scenarios I think Sibelius users can hope for are:

1) Sibelius development continues just fine in whatever office the product moves to
2) The original Sibelius development team sets up privately, launches a competing product
3) Sibelius eventually gets sold to another company that dicks around with it or the pricing, or just lets it languish
4) Competitors start offering extremely attractive crossgrades. Sure enough – check this out.

Scenario 1) would appear to be the least likely scenario, by far. And it would appear Avid have already somewhat indicated their intent on the immediate likelyhood of scenario 3).

It’ll probably take a few months to see where current events lead to with Sibelius the product, but I suspect a lot of customers may start to look at option 4) – until such time that the alternative also hits the rocks, screws its customers, or sells out. And the glorious cycle continues – joy!

The only true peace of mind for me in investing time and resources into any critical application is when it’s based on open source code and open standards. I’d like to think that some of the energy being expended by Sibelius users here would be spent looking at open source notation alternatives, but sadly I don’t see this happening – much the same way in which the vast majority of office apps users can’t handle anything without the Microsoft brand on it.

Still, I do hope I’m being premature, and at least I would hope to see Avid prove any comparisons to Oracle wrong.

# Oracle’s megabucks Sun Servers – the best for enterprise environments…

…just don’t forget your Server Virtualisation for Dummies ebook:

# Container based authentication with JSPWiki, GlassFish and OpenDJ

In this blog entry I am going to describe configuring JSPWiki to use container based authentication to authenticate LDAP users existing in an OpenDJ directory. I am using GlassFish as my web application container, so this can be considered an alternative solution to using Tomcat, for example as described here.

I am running JSPWiki version 2.8.3, deployed in GlassFish Open Source Edition 3.1.1 (build 12) on OpenIndiana oi_151 x86. OpenDJ is version 2.4.4, and I am using Java 6 update 26.

I am assuming prior basic familiarity with installing, configuring, and managing GlassFish and OpenDJ. Our starting point will be a freshly deployed instance of JSPWiki, for which the initial first-run setup procedure has taken place and without any configuration to the JSPWiki configuration files.

This is an insecure setup intended for testing purposes.

Create user and admin groups for JSPWiki in OpenDJ

I have created the Groups OU under my Base DN, and within it created the groups wiki-admin and wiki-users.

Members of the wiki-admin group will be authorized with full permissions in JSPWiki once authenticated. Members of the wiki-users group however will have a lesser set of permissions, suitable for regular day-to-day use of the wiki. You can use LDIF commands if you wish to create the directory entries, however, I just use OpenDJ’s super-easy GUI to do the work. For example:

Create an LDAP security realm in GlassFish

This can be performed in the GlassFish admin BUI. Note that we perform this step under the Configurations -> server-config node in the BUI (not the Configurations -> default-config node):

I have created the LDAP realm JSPWikiUsers with the following settings:

Some observations on the above can be noted here:

• The search-bind-dn and search-bind-password properties may be optional for your OpenDJ installation: they are required in my case because I have disabled anonymous access to my OpenDJ server
• The port used for access to your OpenDJ server may not necessarily be 1389 – change this as necessary.

Change the JACC provider from default to simple

I found that if this step is not performed, LDAP group lookup from GlassFish to OpenDJ will plain just not work.

Navigate to the Configurations -> server-config -> Security node of the GlassFish admin BUI and make the setting as illustrated:

This should be all the configuration needed in GlassFish using the admin BUI, so we can now proceed to making the required modifications to the following JSPWiki deployment descriptor and policy files:

• web.xml
• jspwiki.policy
• glassfish-web.xml

In the following steps, we are assuming that JSPWiki has been deployed to the domain1 domain, and the path to the deployment descriptor and policy configuration files is:

/opt/glassfishv3/glassfish/domains/domain1/applications/JSPWiki/WEB-INF

(Also, in my case no changes needed to be made at all to the jspwiki.properties file.)

Enable container based authentication in the web.xml file

In the web.xml file (in its unmodified state in JSPWiki v2.8.3), look for the section near the end of the file which begins with the following comment:

<!--  REMOVE ME TO ENABLE CONTAINER-MANAGED AUTH

Simply uncomment the section and replace it with the following:

<security-constraint>
<web-resource-collection>
<url-pattern>/Delete.jsp</url-pattern>
</web-resource-collection>
<auth-constraint>
</auth-constraint>
</security-constraint>

<security-constraint>
<web-resource-collection>
<web-resource-name>Authenticated area</web-resource-name>
<url-pattern>/Edit.jsp</url-pattern>
<url-pattern>/Comment.jsp</url-pattern>
<url-pattern>/NewGroup.jsp</url-pattern>
<url-pattern>/Rename.jsp</url-pattern>
<http-method>DELETE</http-method>
<http-method>GET</http-method>
<http-method>POST</http-method>
<http-method>PUT</http-method>
</web-resource-collection>

<web-resource-collection>
<url-pattern>/attach</url-pattern>
<http-method>DELETE</http-method>
<http-method>POST</http-method>
<http-method>PUT</http-method>
</web-resource-collection>

<auth-constraint>
<role-name>wiki-users</role-name>
</auth-constraint>
</security-constraint>

<auth-method>FORM</auth-method>
<realm-name>JSPWikiUsers</realm-name>

<security-role>
<description>
This logical role includes all authenticated users
</description>
<role-name>wiki-users</role-name>
</security-role>

<security-role>
<description>
This logical role includes all administrative users
</description>
</security-role>


Modify the jspwiki.policy file

This will allow users in the wiki-admin LDAP group to be granted full permissions upon authenticating to JSPWiki.

Look for the following section at the end of the jspwiki.policy file (in its unmodified state in a JSPWiki v2.8.3 installation):

// 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).

permission com.ecyrd.jspwiki.auth.permissions.AllPermission "*";
};
permission com.ecyrd.jspwiki.auth.permissions.AllPermission "*";
};


// 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 com.ecyrd.jspwiki.auth.GroupPrincipal "Admin" {
//     permission com.ecyrd.jspwiki.auth.permissions.AllPermission "*";
// };
// grant principal com.ecyrd.jspwiki.auth.authorize.Role "Admin" {
//     permission com.ecyrd.jspwiki.auth.permissions.AllPermission "*";
// };
permission com.ecyrd.jspwiki.auth.permissions.AllPermission "*";
};


Create the glassfish-web.xml file

The primary purpose of this file will be to map the security roles we defined in the web.xml file to the JSPWiki groups we created in OpenDJ. The file should be created at:

/opt/glassfishv3/glassfish/domains/domain1/applications/JSPWiki/WEB-INF

The glassfish-web.xml file should contain the following only:

<!DOCTYPE glassfish-web-app PUBLIC "-//GlassFish.org//DTD GlassFish Application Server 3.1 Servlet 3.0//EN" "http://glassfish.org/dtds/glassfish-web-app_3_0-1.dtd">

<glassfish-web-app>
<security-role-mapping>
</security-role-mapping>
<security-role-mapping>
<role-name>wiki-users</role-name>
<group-name>wiki-users</group-name>
</security-role-mapping>
</glassfish-web-app>


Restart the GlassFish domain, and test LDAP logins to JSPWiki

First, restart the domain either using the asadmin utility or the GlassFish admin BUI. Then test LDAP logins to JSPWiki.

In my case, we can observe that logging in as a user that is a member of the wiki-admin group in OpenDJ, I do indeed have full permissions in JSPWiki:

Whereas logging in as a user that is a member of the wiki-users group in OpenDJ, I am restricted from certain destructive actions:

# Forking GlassFish

(Update: see https://blog.davekoelmeyer.co.nz/2014/11/22/forking-glassfish-redux-payara-server/)

After I made a couple of remarks via Twitter regarding my perceived increase in the amount of Oracle WebLogic marketing material being posted on the GlassFish Twitter, Facebook, and blogs.oracle.com pages – which given recent news I can fully understand a company like Oracle wanting to push at the expense of GlassFish Open Source Edition – I was asked by an Oracle staffer what I would expect from a GlassFish fork.

For me this is less about expectation, and more about what I would hope from a fork, so what follows are some of my feelings in response to this.

Seems like I’m not the first person out there to mull this over, incidentally.

1) Some degree of security that Oracle won’t arbitrarily close the project with no official communication to either the community or customers, because it conflicts with the primary, overriding money-making ethos at the heart of the company.

2) Affordable professional support, with the confidence that support costs won’t unexpectedly and dramatically increase (to use one of many examples), simply to satisfy what any reasonable person would call the disgustingly profligate lifestyle of one man.

3) Knowledge that it’s in the right hands, that is, developed by a company that understands open source, participates in and nurtures a community, doesn’t have its own proprietary products competing for resources, and, doesn’t identify by its own admission open source adoption as one of the key competitive threats to its own business model.

As far as I am concerned, Oracle has also really screwed up with the perception of its own developer talent. Even if I had confidence in Oracle regarding the above points, the increasingly relevant question is, would it be a product anyone would want to use? What other conclusion can a customer reach when the collective ex-Sun/Oracle developer talent responsible for breakthrough OS technologies (for example) are loudly and publicly questioning Oracle’s own competence as a technology provider?

There are other issues to note, but this will do for a start.