GlassFish

GlassFish Embedded – a simple way to run Jakarta EE apps

I’ve been asked by the Eclipse GlassFish project to say a few words about how I use GlassFish Embedded. And since they are working on a series of complex issues that I have raised I guess that is fair. The OmniFish team is one of the main contributors to the GlassFish project and I allowed them to post my article on their blog too. 

Running GlassFish Embedded is pretty straightforward – you start GlassFish within a client application and deploy the server application to the running embedded GlassFish. The embedded server is created and destroyed by the tool on each tool session.

I started using GlassFish while GlassFish was in Oracle’s hands as a reference implementation of Java EE. Some time ago, there were suggestions that GlassFish was not being actively maintained. Since Oracle’s donation of GlassFish to the Eclipse Foundation, with support from the Foundation’s GlassFish team, and the OmniFish team (that also provides commercial support), the GlassFish project is very active and the community around it is certainly present and responsive. That’s one more reason for me to continue using GlassFish in the future.

Overview of the APILoader Project

My project is APILoader. APILoader is, I believe (quite possibly wrongly) the seed for the next generation of software performance testing tools. I won’t say a lot about APILoader since it hasn’t been released yet and there is IP to protect. But I can say a bit about how it uses GlassFish Embedded.

For an individual, I intend that APILoader be deployed using GlassFish Embedded. This obviates the server administration, as the server is created and destroyed by the tool on each tool session.

Some software performance engineers work in teams and need to share artefacts. For them, a server-based tool is appropriate. Others work individually. For them, a server-based tool is an overkill, implying, as it does, server administration. So APILoader has a server component and a client component but they are deployed differently depending on the needs of their users. In all deployments, the database remains external.

For teams, I intend that APILoader be deployed as a server installation with multiple clients. The engineers share the server and the database for artefacts, and use the clients for isolation. APILoader supports accounts and projects. Accounts are hermetically sealed sets of projects. Projects are separated sets of artefacts, but with the option to copy selected artefact types between them. So engineers can work completely separately by using different accounts. Or they can work in the same account, sharing account level resources, but with separate sets of project-level artefacts. Or they can work on the same project and share account and project-level resources. A team might use different accounts for testing different products where artefact sharing is unlikely. That team might use a different project for performance testing of each release of one product, initially populating each project selectively from its predecessor.

For an individual, I intend that APILoader be deployed using GlassFish Embedded. This obviates the server administration, as the embedded server is created and destroyed by the tool on each tool session. The individual can still use accounts and projects to separate the artefact sets for different pieces of work.

There is potentially a hybrid approach where each engineer runs an embedded GlassFish instance but they choose to share a single (networked) database. The issue is that the ‘database’ in APILoader is distributed with some data held in a relational database and some held in files associated with the server. So, in this scenario, those artefacts that are held in the database would be shared but those held by the server are not (since each engineer has their own (embedded) server). This scenario doesn’t appear useful as it stands because the relational database is used to access the file-based artefacts held by the server and only a subset of file-based artefacts would be reachable by each engineer. It could be made an installation option that the file-based artefacts be held in one repository, independent of the servers. Then all artefacts would be shared.  This would appear that the installation is shared by the team but with a greater degree of isolation for each engineer since the server isn’t shared.

Simple Setup with GlassFish Embedded

Running GlassFish Embedded is pretty straightforward – you start GlassFish within a client application and deploy the server application to the running embedded GlassFish. There is very little to do in the server application to cater for being runnable both as a remote server or embedded. (Or maybe there was more than I remember but it is a once-only thing.)

However, there is one major consideration. GlassFish Embedded runs in the same JVM as the client. In remote server mode it doesn’t – it runs in a separate JVM process, often on a remote machine. This has significant implications for static resources. In embedded use, a static resource is shared between the client application and the embedded server. This allows some tempting shortcuts in coding that won’t work in non-embedded deployment.

With EJBs, the serialisation is done automatically. With http-based communication, it would have to be done explicitly via SOAP, XML, or Gson/JSON.

Benefits of Remote EJBs as a communication method

The APILoader client is a (very) fat GUI. It started life as a web client but I found myself spending inordinate amounts of time on the minutiae of HTML presentation. So now its a GUI. As such, communication with the server presents new options. I have chosen to use remote EJBs. These work just as well against a remote or embedded GlassFish server. Once you overcome the issue of making the remote class definitions available to the client application, server EJBs are pretty straightforward to use. And, with a GUI client, they are simpler to use than http-based messaging. The APILoader server and client communicate complex objects. With EJBs, the serialisation is done automatically. With http-based communication, it would have to be done explicitly via SOAP, XML, or Gson/JSON.

Note that the APILoader client is not an enterprise client. So it isn’t deployed to the server to run, and the EJBs aren’t injected. Instead, the client gets access to the server’s remotely accessible methods by doing context lookup() calls.

Simplified Distribution and Support

The other benefit of GlassFish Embedded is simplified distribution and support for APILoader to those clients that select it. Packaging and distributing the APILoader only has to cater for one brand of server, and one release of that server. On the other hand, support for the server option is easier in bigger teams because the server environment is usually better understood by infrastructure teams.

Since Oracle’s donation of GlassFish to the Eclipse Foundation, the GlassFish project is very active and the community around it is certainly present and responsive.

Upgrade to Jakarta EE 10 – part 3: Transform incompatible Dependencies

This entry is part 4 of 4 in the series Upgrading to Jakarta EE 10

In this article, we’ll address upgrading individual libraries used by your applications. This solves two problems. First, it improves the build time of your application during development and reduces the build time introduced by transforming the final binary after each build. And second, it solves compilation problems you can face with some libraries after you adjust the source code of your application for Jakarta EE 10.

Upgrade to Jakarta EE 10 – part 2: Transform Application Source Code

This entry is part 3 of 4 in the series Upgrading to Jakarta EE 10

In our previous article, we explored the initial steps of migrating Java EE 8 or Jakarta EE 8 applications to Jakarta EE 10. We transformed the final binary application using the Eclipse Transformer to deploy it on a Jakarta EE 10 runtime. Building upon that foundation, we now dive deeper into the next crucial phase of the upgrade process: transforming the application’s source code to use the Jakarta EE 10 APIs. This will enable you to use new features in Jakarta EE 10 as well as newer versions of external libraries that require Jakarta EE 10.

How to upgrade to Jakarta EE 10 and GlassFish 7 – it’s much easier than you think!

This entry is part 1 of 4 in the series Upgrading to Jakarta EE 10

Upgrading to Jakarta EE 10 from an older version of Jakarta EE or Java EE can be a bit tricky and may require some extra attention to detail. One of the main things you may encounter is making sure your existing code and libraries are compatible. Some libraries may still be using the javax package, which can cause conflicts when trying to run your applications on a Jakarta EE server like Eclipse GlassFish 7. You might also run into problems with some deprecated APIs that were removed in Jakarta EE 10.

But don’t worry, we’ve got you covered! In this post and the future posts in this series, we’ll explain everything you need to know to upgrade to Jakarta EE 10 successfully and almost in no time.

OmniFish supports Jakarta EE 10

OmniFish announces enterprise support for Eclipse GlassFish, Jakarta EE 10, and a new cloud-native Jakarta EE runtime

Estonia, September 22, 2022

OmniFish are proud to announce they’ve established themselves as a new international company in the field of Jakarta EE support, specifically supporting the application server Eclipse GlassFish, a new cloud‑native Jakarta EE runtime Piranha Cloud, and their associated components such as Mojarra, the Jakarta Faces implementation. 

OmniFish, based in Estonia, EU, welcomes the new Jakarta EE 10 version. They are going to support Jakarta EE 10 applications on Eclipse GlassFish 7, which will be released later in October 2022. Moreover, OmniFish have recently joined the Jakarta EE Working Group and they are strongly committed to contributing to the Jakarta EE standards. Some of the OmniFish founders are well-known Jakarta EE experts, which provides strong guarantees that OmniFish will become one of the key players in evolving and modernizing the Jakarta EE platform.

Jakarta EE 10 is coming with GlassFish 7

Jakarta EE 10 and GlassFish 7 soon (300px)

Yes, Jakarta EE 10 is just behind the door, with a rich set of new useful features. GlassFish 7 is also very close to its final release, coming with Jakarta EE 10 support. And it’s now actively maintained and commercially supported by OmniFish. Therefore you can start using Jakarta EE 10 very soon on a reliable and production‑ready server backed by a commercial company. But first, what’s coming to Jakarta EE 10?

Oh, What Did You Do to GlassFish?!

What is Happening?

  • We created our own company for providing consultancy and support: OmniFish
  • Jakarta EE sprints to it’s next release: Jakarta EE 10
  • GlassFish sprints to be a production-ready Jakarta EE 10 compliant application server
  • New fish Piranha is getting born