An Interview With the Killerfish--Payara

Q: C2B2 already provided commercial support for GlassFish, what is the idea behind

Payara is a new initiative for C2B2. Previously we provided operational support and consultancy for customers using GlassFish in production. With Payara we are going a completely different direction. We are using the upstream open source GlassFish code base as our core to build a new application server, Payara.

We are looking to build new capabilities into Payara Server and recently we’ve added in JSR107 and data grid capabilities by incorporating Hazelcast. I did a webinar on this with Hazelcast last month: We are also investigating new deployment scenarios for cloud and micro services environments through Payara Micro; and we aim to connect with the wider DevOps ecosystem through integrations with tools like Chef, Puppet, Ansible, Docker and Kubernetes.

Q: Have you got any feedback from Oracle about your Payara activities?

We have had no official feedback from Oracle. A number of our employees have signed the Contributor Licensing Agreement with Oracle and so can now submit fixes back to the upstream GlassFish team.  A number of these have been incorporated into the current GlassFish nightly builds. Informally, we’ve had support and encouragement from some of the engineers of the upstream GlassFish projects and in the spirit of open source they are keen for us to contribute.

Q: I've been watching Payara since JavaOne 2014 and the github account is very active. What triggers the activity?

People are using Payara and GlassFish and see that we are active, so they are reporting bugs and suggest lots of new ideas for new things they would like to see. This drives the list of things we want to add into each release. Payara is released quarterly and all development is carried out in the open on GitHub, which generates all the activity. We also see people raising questions, suggestions and issues on Twitter, StackOverflow, Facebook etc. The community has been really active and the interest is definitely growing – we’re really happy about it and we encourage all Payara and GlassFish users to get involved in the discussion!

Q: Does the community participate in Payara Development?

Absolutely! A number of people have signed the CLA and submitted pull requests for bug fixes and changes, which have been incorporated in the latest Payara release. New ideas from the community are also forming the basis of the enhancements and Payara Micro is a direct result of ideas from the community of how they would like to run their Java EE applications. We are completely open to community contributions and ideas. To be honest, we can’t think of everything ourselves, so we are very keen to get other people’s cool ideas to implement. GitHub is the central place to participate but people can ask questions on Twitter and other social media platforms, or even come along to one of the Java EE & GlassFishUser Group sessions in London (more info

Q:How many GlassFish users are switching to Payara? Can you give us any rough ideas?

There are a number of people we are aware of who are planning to or have already switched to Payara, including some very well know companies. We have been pleasantly surprised at how quickly the level of interest has grown and the speed at which some organisations are planning to switch. The level of interest and demand is growing and this spurs us on to make Payara better and better.

Q:How hard was the implementation of Payara Micro Edition?

To be honest, it was pretty easy to get the initial release of Payara Micro out. Not a lot of people know, but GlassFish has had an embedded edition for a long time. We’ve built on GlassFish embedded and our new Hazelcast integration to produce our first version of Payara Micro. A lot of the work we did was packaging GlassFish embedded in such a way that we could get more JavaEE capabilities and to get full web session clustering. The new Hazelcast integration gave us Dynamic Clustering which is fundamental to Payara Micro.

For us, Payara Micro marks the beginning of development in new ways of deploying JavaEE applications in radically new topologies. I’ve recently written an overview of Payara Micro which can be found on our blog: We have a lot of cool ideas for taking Payara Micro in an exciting direction so stay tuned.

Q:Do you know any cool projects using Payara?

We are aware of projects using or planning to use Payara in many different cool ways e.g. for SAAS, Point of Sale, Intranet and Microservices. You should hear more about this in the near future as we are already gathering some success stories to publish on our website soon. Also, if you continue to blog about cool projects like the recent dreamIT one, I’m sure we’ll hear more on your blog ;-)

Q:What is your opinion about Java EE? Is it productive? How many of your customers are using it?

Is JavaEE productive? Absolutely! You can create applications in very few lines of code using a standard IDE like NetBeans with zero IDE setup. Producing a standard war file which can then be run on the command line with java –jar payara-micro.jar –deploy your.war. What could be more productive? You don’t need complex dependency management, complex installations or weird XML configuration files any more. I’ve got a talk at NetBeans Day in London on the 29th of May which will build and run a simple JavaEE application in 45 minutes:

Q:What are the features of the current release?

The latest release added Payara Micro; a small footprint version of Payara that requires no pre-installation and can run war files from the command line. Saying that, Payara Micro supports applications that use Java EE web profile apis along with JBatch, Concurrency and JCache. It also auto-clusters to give full web session replication across multiple Payara Micro instances.

From core GlassFish we’ve replaced the Shoal based clustering with Hazelcast as an embedded Data Grid which gives us JCache support and dynamic clustering capabilities. We’ve extended the range of JBatch persistence providers by adding support for MySQL, Oracle and DB2. Along with numerous critical bug fixes and upgrades to a lot of the underlying components like Jersey, Tyrus and Grizzly etc.

Q:What are the next cool features we can expect on Payara?

We are focusing on a number of areas.

Payara Micro is going to morph and grow into a fundamentally different way of installing and managing Java EE applications. Targeted at dynamic cloud environments and large scale installations. Our long-term goal is to make 1000 Payara Micro instances manageable from a single console on the cloud. We are looking at how RTS games present a lot of information to a user on the status of their units as a model for building a new management console for the cloud.

We have a focus on manageability and are starting to build in transaction tracing and fault finding capabilities to identify problems and make the operator aware of them as they happen so you don’t have to dig around to work out what went wrong.

Finally we are also focusing on integrating with the rest of the DevOps ecosystem with tooling around Payara for Chef, Docker, Maven etc.

Q: How expensive is the commercial support? Where is the pricelist?

Our commercial support is simply based on the number of Payara servers you are running rather than cpus, cores or power factors. We have priced commercial support in 3 tiers starting from $1,500 per server per annum for the most basic support, which we hope is set at a level that even small shops can get support. Our Enterprise support which provides full 24/7 screen sharing assistance runs to $5,000 per server per annum. We’ve also added unlimited options for organisations looking to run Payara everywhere without having to keep track of the numbers of servers they run. Of course there is also open source support on GitHub on a best endeavours basis. However we want to encourage people to buy commercial support as all the money that people spend with us on support is being reinvested into cool new Payara features. You can get the full pricelist with a feature breakdown on  

Steve, thank you for the interview!


Just an idea I've have some month ago. (it's related with the post because I've been looking JEE servers source code to do that, an payara was one of them, but i left my idea because i haven't got enough time).

What about rewriting @Remote interpretation of @Stateless EJB, in a way that they comunicate each others using HTTP based protocol (not RMI/IIOP), and it could be transparent for user (maybe I imagine an anotation like @Remote(protocol="http")

¿Does exist something like that? ¿It will be difficult adding this to glassfish?

Posted by martdominguez on May 15, 2015 at 04:51 PM CEST #

Post a Comment:
  • HTML Syntax: NOT allowed
...the last 150 posts
...the last 10 comments