New Arquillian Container for Payara Server

Uncategorized

One of the core steps in every continuous integration process is running integration tests for your application. Unlike vanilla unit tests, integration tests allow you to assess the state of your applications or systems by testing all of its components together (modules, databases, messaging, etc.) and verifying that they work correctly as a whole unit. Needless to say, integration tests are more complex that simple unit tests, have a larger footprint, take more time and are usually saved to test full releases or major changes to implementations.

 

Usually, when testing Java EE applications, there is a need to configure and start an instance of your preferred application server, run the tests against this running instance and when finished, clear everything up. In some cases it may be needed to prepare a separate running instance for each test, making the whole process CPU intensive, expensive and cumbersome to automate. That was usually the case until Arquillian came along.

 

Simpler Integration Tests with Arquillian

Arquillian came along to simplify the process of running full integration tests suites for Java EE applications, by managing the lifecycle of your application servers or containers, bundling the test case along necessary resources into a test archive, providing dependency injection providers to the test cases to simplify the test writing and more. In addition, Arquillian supports both JUnit and TestNG so writing tests with it shouldn’t be a problem. This is done thanks to the concept of container adapters, which Arquillian uses to connect and manage a profile of an specific application server’s container (like GlassFish or WildFly). If you are developing application that you want to test for an specific container, simply use the corresponding container adapter on your integration tests. There are 3 types of container adapters for application servers:

  • Embedded
    Manages the lifecycle of an embedded container (runs in the same JVM as the test runner). Embedded containers are usually composed of APIs and its implementations without any added features present in the application server like monitoring or administration. Embedded containers are usually opted for faster test suites due to their simplicity of management.
  • Managed
    Manages the lifecycle of a local installation of the container/server. This means that the full application server is used to run the tests, so this might impact on the footprint of the suite, including the time to start/stop the container.
  • Remote
    The adapter itself doesn’t manage the lifecycle of a container but binds to an already running container, either locally or on a remote location. This can simplify tests in many scenarios when the continuous integration workflow depends on an already configured application server’s instance since the tests only need to know where the server’s is located and Arquillian manages the communication to it.

Payara Server & Arquillian

Payara Server has, until now, not been officially supported in the list of available container adapters that Arquillian provides to developers. As a workaround, when writing integration tests for Payara Server in mind, it was officially recommended to use the official Glassfish 3.1 Arquillian Container adapter to let integration tests communicate with Payara Server (since Payara Server is derived from GlassFish, there’s a degree of compatibility between them). If you are using Maven to handle your application testing, you only need to add the following dependency to use the embedded mode adapter for GlassFish 3.1:

 

<dependency>
    <groupId>org.jboss.arquillian.container</groupId>
    <artifactId>arquillian-glassfish-embedded-3.1</artifactId>
    <version>1.0.1</version>
    <scope>test</scope>
</dependency>

 

 There are some problems with depending on this container adapter, mainly that is for communicating with either commercial or open source GlassFish server 3.1, which is compatible with Java EE 6. Considering that Payara Server is derived from GlassFish 4.1 which is compatible with Java EE 7, this means that you won’t be able to test features or APIs introduced in Java EE 7. For this reason alone, starting with release 4.1.2.173, we have developed a special container adapter with the following Maven coordinates:

 

<dependency>
    <groupId>fish.payara.arquillian</groupId>
    <artifactId>arquillian-payara-server-4-embedded</artifactId>
    <version>1.0.Beta2</version>
    <scope>test</scope>
</dependency>

 

And that’s it! To use the managed and remote adapters, change the artifactId to either arquillian-payara-server-4-managed or arquillian-payara-server-4-remote instead.

 

When running an integration test suite using this adapter, you should see no difference when running them using the adapter for GlassFish 3.1, with the exception of updated output values for the libraries and changes made for Payara Server 4.x

 

Also, remember to add the payara-embedded-all or payara-embedded-web dependencies to your project as well. Specify the exact version of the intended Payara Server this way:

 

<dependency>
    <groupId>fish.payara.extras</groupId>
    <artifactId>payara-embedded-all</artifactId>
    <version>4.1.2.173</version>
    <scope>test</scope>
</dependency>

 

Summary

With this official container adapter, Payara Server now has full integration with the Arquillian environment, bringing the following benefits:

  • Allow Payara Server integration tests to be run in a continuous integration setup with 100% reliability
  • Prepare the groundwork for a Payara 5 container adapter, which should allow users the ability to test Java EE 8 APIs
  • Provide means to test specific Payara features (Hazelcast persistence, JCache, etc.)

With this in mind, we recommend you to start using the new Arquillian adapter to run your integration tests – and once you do, please make sure you give us your feedback!

 

 

Comments (5)

Post a comment

Your email address will not be published. Required fields are marked *

Payara needs the contact information you provide to us to contact you about our products and services. You may unsubscribe from these communications at any time. For information on how to unsubscribe, as well as our privacy practices and commitment to protecting your privacy, please review our Legal & Privacy Policy.

This site uses Akismet to reduce spam. Learn how your comment data is processed.

  1. Jo Ha

    Thanks a lot, this is great news.

    I have one question:
    How do I have to configure my arquillian.xml file when using Payara arquillian-payara-server-4-remote?
    Do I keep my Glassfish configuartion (container qualifier=”glassfish”…) or do I need to switch to “payara”?

    Thanks,
    Jo

  2. Fabio Turizo

    Greetings Jo Ha

    Since the adapters were based on the official adapters for GlassFish 3.1, the configuration settings used in the arquillian.xml file is still the same (including the container qualifier). In the future, we plan to diverge more from the GlassFish settings and introduce our own, so keep an eye on the blog for all of these possible changes.

    Cheers,

    Fabio.

  3. Thomas McWork

    Hello Fabio,

    where can we find the sources of the project?

    Cheers,
    Thomas

  4. Andrew

    Hello Fabio,
    Where can I see the project completely?

    1. Fabio Turizo

      Greetings Andrew,

      There is no particular code project that was created in mind for this article. However, there are a lot of examples that use the Arquillian Container Adapters in Java EE Samples repositories:

      * Java EE 7 samples: https://github.com/javaee-samples/javaee7-samples/
      * Java EE 8 samples: https://github.com/javaee-samples/javaee8-samples/

      All sample projects are configured to use several Java Application Server container adapters, not only Payara Server, so you can cross-test several standard features across vendors. For Payara Server there are 3 specific Maven profiles that can be used to configure the same adapter configurations described in the blog: payara-ci-managed, payara-ci-embedded and payara-ci-remote.

Related Posts

End of Life and End of Support Software 3 minutes
Migration

End-of-Life Technology: How to Drive Innovation Without Compromising Stability

When legacy systems approach end-of-life (EOL), enterprise IT teams typically face the choice of moving forward at all costs […]

Green stylised leaf symbol representing the Spring Framework, shown with a smooth curved shape and a small stem inside a circular or rounded background , with 'spring' written on its right side. 2 minutes
Jakarta EE

Spring Framework 7.0 and Spring Data 2025.1.0 Embrace Jakarta EE 11 Compatibility

The recent releases of Spring Framework 7.0 and Spring Data 2025.1.0 mark an important milestone for the Java ecosystem, […]

Timeline showing Payara Platform Enterprise 4, 5, and 6 support phases (Full, Extended, Lifetime) from 2023–2033, along with JDK 8, 11, 17, and 21 support periods and end-of-life markers. 4 minutes
Thought Leadership

Understanding the Payara Platform Enterprise Software Lifecycle: How We Support Long-Term Stability 

Keeping an application server running smoothly isn’t so much about new features, but more about predictability and consistency. Software […]