WildFly
View on Wikipediafrom Wikipedia
 |
| WildFly | |
|---|---|
 | |
| Original author | Marc Fleury |
| Developers | JBoss, Red Hat |
| Stable release | 38.0.0.Final
/ October 16, 2025[1] |
| Repository | WildFly Repository |
| Written in | Java |
| Operating system | Cross-platform |
| Type | Application server |
| License | LGPLv2.1 |
| Website | wildfly |
WildFly,[2] formerly known as JBoss AS, or simply JBoss, is an application server written by JBoss, now developed by Red Hat. WildFly is written in Java and implements the Java Platform, Enterprise Edition (Java EE) specification.[3] It runs on multiple platforms.
WildFly is free and open-source software,[3] subject to the requirements of the GNU Lesser General Public License (LGPL), version 2.1.
Origin
[edit]In 1999, Marc Fleury started a free software project named EJB-OSS (stands for Enterprise Java Bean Open Source Software) implementing the EJB API from J2EE (Java 2 Enterprise Edition). Sun Microsystems asked the project to stop using the trademarked EJB within its name. EJB-OSS was then renamed to JBOSS, then JBoss later.[4]
On November 20, 2014, JBoss Application Server was renamed WildFly. The JBoss Community and other Red Hat JBoss products like JBoss Enterprise Application Platform were not renamed.[5]
Features
[edit]Wildfly supports a number of features:
- Jakarta Persistence (JPA)[6]: 77
- Jakarta Enterprise Beans (EJB)[6]: 108
- Distributed transactions - Wildfly implements the Jakarta Transactions API (JTA).[6]: 137–138
- Representational state transfer (REST) services.[6]: 173–174
- WebSocket[6]: 198
- Clustering - Wildfly uses Infinispan as its distributed cache system[6]: 383–384
Licensing and pricing
[edit]JBoss EAP itself is open source, but Red Hat charges to provide a support subscription for JBoss Enterprise Middleware. Before November 2010 JBoss was licensed as annual subscription in bundles of 4 and 32 CPU sockets. As of November 2010 the licensing changed and all cores on the system are now counted. The core bundles licensing is available for 2, 16, and 64 cores.
See also
[edit]
Notes
[edit]- ^ "WildFly 38 is released!". WildFly.
- ^ "JBoss Application Server has a new name..." Wildfly. Archived from the original on 2013-04-23. Retrieved 2013-04-23.
- ^ a b Stancapiano 2017, pp. 8–9, Chapter §1 Introducing Java EE and Configuring the Development Environment.
- ^ Jamae & Johnson 2010, p. 4.
- ^ "Frequently Asked Questions". WildFly. Archived from the original on 2013-09-28. Retrieved 2013-04-23.
- ^ a b c d e f Adamski 2018.
References
[edit]- Adamski, T. (2018). Hands-On Cloud Development with WildFly: Develop, deploy, and configure cloud-based, enterprise Java applications with WildFly Swarm and OpenShift. Packt Publishing. ISBN 978-1-78728-380-0. Retrieved June 20, 2023.
- Marchioni, Francesco (June 1, 2020). WildFly Administration guide. ItBuzzPress. 402 pp.
- Stancapiano, L. (2017). Mastering Java EE Development with WildFly. Packt Publishing. ISBN 978-1-78728-907-9. Retrieved June 19, 2023.
- Marrs, Tom; Davis, Scott (July 1, 2009). JBoss At Work: A Practical Guide. O'Reilly. ISBN 978-0596007348. 306 pp.
- Jamae, Javid; Johnson, Peter (January 28, 2010) [2009-01-20]. "1.1 Introducing JBoss". JBoss in Action: Configuring the JBoss Application Server. Manning Publications. ISBN 978-1-933988-02-3. 496 pp.
- Stark, Scott; Fleury, Marc; Richards, Norman (April 30, 2005). JBoss 4.0 The Official Guide. Sams. ISBN 978-0-67232648-6. 648 pp.
External links
[edit]
| Platforms |
| _waving.svg) | |||||
|---|---|---|---|---|---|---|---|
| Technologies |
| ||||||
| History | |||||||
| JVM languages | |||||||
| Community |
| ||||||
WildFly
View on Grokipediafrom Grokipedia
Overview
Definition and Role
WildFly is a lightweight, modular, open-source application server written in Java, designed for deploying and managing enterprise Java applications.[5][1] It provides a flexible runtime environment that supports the development and execution of scalable, mission-critical systems without the overhead of traditional monolithic servers.[2] In its role as an enterprise application server, WildFly delivers a comprehensive runtime for Jakarta EE applications, enabling features such as web services via Jakarta RESTful Web Services and Jakarta Web Socket, messaging through Jakarta Messaging, and persistence with Jakarta Persistence.[1] This support facilitates the creation of robust, distributed applications that integrate seamlessly with modern enterprise architectures. Originally evolved from JBoss Application Server, WildFly emphasizes modularity to allow developers to provision only necessary components, reducing deployment complexity.[6] Key characteristics of WildFly include its flexibility for cloud-native deployments, such as containerized environments with Docker and Kubernetes, and a low resource footprint that enables efficient operation in resource-constrained settings compared to legacy servers.[6][7] As of November 2025, the current stable version is WildFly 38.0.0.Final, which is certified as a compatible implementation of the Jakarta EE 10 Platform, Web Profile, and Core Profile.[8][9]Relation to JBoss Ecosystem
WildFly serves as the upstream open-source project for Red Hat's JBoss Enterprise Application Platform (EAP), providing the core codebase upon which EAP is built, with EAP incorporating additional enterprise-grade enhancements such as certified configurations, extended testing, and commercial support.[10] This relationship allows EAP to leverage WildFly's innovations while ensuring stability for production use, as EAP versions are derived from specific WildFly releases—for instance, JBoss EAP 8.0 is based on WildFly 28.[3] WildFly's release cycle emphasizes rapid innovation through a quarterly cadence, featuring beta releases that culminate in final versions approximately every three months to incorporate the latest Jakarta EE standards and features.[11] In contrast, JBoss EAP follows a long-term support model with phased lifecycles typically spanning up to seven years, including full support, maintenance, and optional extended life support phases to prioritize reliability and backward compatibility in enterprise environments.[12] WildFly integrates closely with other Red Hat ecosystem tools, notably OpenShift, enabling containerized deployments via dedicated operators, source-to-image builds, and quickstart guides that facilitate running WildFly applications in Kubernetes clusters.[13] This integration supports hybrid cloud strategies, allowing developers to deploy WildFly-based applications seamlessly on OpenShift for scalable, managed operations. In practice, WildFly is commonly employed in community settings for development, prototyping, and testing due to its agility and lack of formal support obligations, whereas JBoss EAP is designated for enterprise production workloads requiring Red Hat's certified support, security patches, and service-level agreements.[14]History
Origins and Early Development
WildFly traces its origins to the JBoss project, founded in 1999 by Marc Fleury as an open-source Enterprise JavaBeans (EJB) container designed to compete with proprietary application servers like BEA WebLogic and IBM WebSphere.[15][16] This initiative emerged during the early days of Java enterprise development, when commercial servers dominated the market with high licensing costs, prompting Fleury—a former French military officer turned software developer—to create a free alternative that leveraged the growing momentum of open-source software.[17] The project quickly gained traction among developers seeking cost-effective solutions for building scalable, distributed applications. Key milestones in the early development of JBoss included the release of version 2.0 in 2001, which achieved full compliance with the J2EE 1.3 specification, enabling comprehensive support for enterprise features such as EJBs, servlets, and Java Message Service (JMS).[18] This version solidified JBoss as a viable production-ready server, emphasizing extensibility through its JMX-based microkernel architecture. In 2006, Red Hat acquired JBoss Inc. for approximately $350 million in cash and stock, integrating the project into its enterprise portfolio and shifting its focus toward commercial support and certification for mission-critical deployments.[19] The project's architecture evolved significantly with the introduction of JBoss Application Server (AS) 7 in 2011, marking a transition from a monolithic structure to a modular design that utilized layered dependencies to enhance boot times, resource efficiency, and overall performance.[20] This redesign addressed longstanding issues with classloading and service management in prior versions, allowing for on-demand loading of components and reducing the server's footprint. Initially licensed under the GNU Lesser General Public License (LGPL), JBoss's open licensing model facilitated widespread adoption by permitting integration with proprietary applications while encouraging community contributions.[21]Rebranding and Modern Evolution
In April 2013, at JUDCon Brazil, Red Hat announced the rebranding of JBoss Application Server (JBoss AS) to WildFly, aiming to differentiate the agile, community-driven edition from the more stable, enterprise-focused JBoss Enterprise Application Platform (EAP).[22] This shift emphasized WildFly's lightweight and flexible nature, positioning it as an open-source reference implementation for evolving Java enterprise standards while allowing EAP to maintain backward compatibility for production environments.[23] JBoss AS 7.1 marked the final release under the original name in late 2012, serving as the upstream foundation for JBoss EAP 6.[24] WildFly 8.0, released in February 2014, became the inaugural version under the new branding and provided full compliance with Java EE 7, including support for the Full Platform and Web Profile specifications. This alignment enabled developers to leverage new Java EE 7 features such as improved concurrency utilities and batch processing directly in the community edition. Subsequent releases advanced WildFly's standards compliance progressively. WildFly 10, released in February 2016, solidified Java EE 7 Full Profile support and introduced requirements for Java SE 8, dropping Java 7 compatibility to enable deeper integration with modern JVM features.[25] WildFly 20, launched in June 2020, transitioned to Jakarta EE 8 compatibility, reflecting the Eclipse Foundation's stewardship of the platform post-Oracle and incorporating enhancements like JSON binding improvements.[26] WildFly 27, released in November 2022, adopted Jakarta EE 10, introducing support for new specifications such as Jakarta Data and Security while discontinuing compatibility with prior Jakarta EE 8 and 9.1 versions.[27] By October 2025, WildFly 38 achieved full Jakarta EE 10 Platform, Web Profile, and Core Profile compatibility, alongside integration with MicroProfile 7.1 for reactive messaging and fault tolerance capabilities.[8] The WildFly Project, hosted at wildfly.org, governs development through an open-source model that encourages contributions from Red Hat engineers and the broader community, ensuring rapid iteration and alignment with emerging enterprise Java needs.[2] This collaborative structure has sustained WildFly's evolution as a leading application server runtime.Architecture
Modular Framework
WildFly adopted a modular, layered architecture starting with version 8, building on the innovations from its predecessor JBoss Application Server 7, to enable finer-grained control over components and dependencies.[28] This design leverages JBoss Modules, an open-source project that implements a classloading system where each module explicitly declares its dependencies, ensuring strict isolation between server implementation classes and application code.[5] By isolating dependencies in this manner, WildFly minimizes the risk of classpath pollution and version conflicts that plagued earlier Java EE servers, while significantly reducing startup time and memory footprint through on-demand loading rather than pre-loading all components.[28] The boot process in WildFly exemplifies this modular philosophy, beginning with a minimal kernel provided by the WildFly Core runtime, which includes only essential services such as unified management and basic deployment capabilities.[29] Upon startup, the server dynamically loads additional modules based on the configuration specified in files like standalone.xml or domain.xml, allowing for a lean initial footprint that expands only as needed for the deployed applications.[28] This approach supports flexible deployment models, including the creation of self-contained "uberjar" distributions via tools like Galleon provisioning, which align well with microservices architectures by packaging only required server layers alongside the application.[5] This modular framework offers key benefits in modern deployment scenarios, providing the flexibility to embed WildFly directly into containers such as Docker images, where lightweight, customizable runtimes are essential.[30] It enhances scalability in cloud environments by enabling efficient resource utilization and horizontal scaling without the overhead of unused features, and facilitates easier extension through the addition of custom modules that integrate seamlessly into the server's service container.[31] In contrast to legacy application servers, which often employed a monolithic structure with shared classloaders that loaded all components upfront, WildFly's design avoids unnecessary bloat by excluding unused modules entirely, resulting in a more agile and maintainable platform.[28]Core Components and Subsystems
WildFly's core components and subsystems form the foundational elements of its modular architecture, enabling the server to handle web serving, data persistence, messaging, caching, security, and management tasks efficiently. These subsystems are configured through the server's XML files or management interfaces, allowing administrators to enable or customize them based on application needs. The modular design ensures that only required components are loaded at runtime, promoting resource efficiency and scalability.[32] The Undertow subsystem serves as the high-performance web server and servlet container in WildFly, responsible for handling HTTP and HTTPS requests, supporting servlets, JSPs, and WebSockets. It includes configurable elements such as buffer caches, byte buffer pools, filters, handlers, servers, and servlet containers, with built-in support for HTTP/2 protocol for improved performance in modern web applications. For instance, HTTP listeners can be defined on ports like 8080 for default web traffic.[33][32] Infinispan provides the distributed caching and clustering capabilities through its dedicated subsystem, offering cache containers for local, replicated, or distributed data storage to enhance application performance and fault tolerance. It supports features like cache invalidation, passivation, and integration with JGroups for cluster communication, making it essential for high-availability scenarios where data needs to be shared across multiple server instances.[34][35] The Hibernate ORM integration, managed via the JPA subsystem, handles object-relational mapping for persistence, allowing Java applications to interact with relational databases using JPA standards. It supports entity management, second-level caching (often backed by Infinispan), and advanced features like lazy loading and query optimization, with configuration options for dialect-specific behaviors and connection pooling.[28][36] Artemis, implemented in the messaging-activemq subsystem, delivers JMS-compliant messaging services for asynchronous communication, supporting queues, topics, and bridges between different messaging providers. It enables high-availability configurations through clustering and shared storage, with configurable acceptors and connectors for inbound and outbound connections, ensuring reliable message delivery in enterprise environments.[37][38] The management layer relies on a Model-Controller architecture, where the server model represents configuration as a hierarchical tree of resources (e.g., /subsystem=undertow), and controllers execute operations to read, write, or validate changes. This is accessed via the HAL web-based Admin Console, available at http://localhost:9990/console, which provides a graphical interface for subsystem management, and the CLI tool (jboss-cli.sh), which supports scripting for tasks like resource inspection and deployment.[32][39] Security is managed by the Elytron subsystem, which unifies authentication, authorization, and SSL/TLS configurations across applications and management interfaces, replacing the legacy PicketBox subsystem for improved flexibility and security. It includes security domains, realms for identity storage (e.g., file-based or database-backed), and role-based access control, with support for mechanisms like SASL and X.509 certificates to secure communications and access.[40][41] Galleon serves as the provisioning tool for creating customized WildFly server images, allowing users to include only necessary subsystems and layers from feature packs like wildfly or wildfly-ee, thereby reducing the overall deployment footprint and startup time. For example, provisioning can exclude unused components like messaging if not required, resulting in leaner distributions tailored to specific application profiles.[42][43]Features
Standards Compliance
WildFly achieves full compatibility with the Jakarta EE 10 platform in version 38, released in October 2025, encompassing the full platform, Web Profile, and Core Profile specifications when running on Java SE 17 or 21.[8] This certification includes key components such as Contexts and Dependency Injection (CDI) 4.0 for managing bean lifecycles and injections, Java Persistence API (JPA) 3.1 for object-relational mapping, Jakarta RESTful Web Services (JAX-RS) 3.1 for building RESTful APIs, and Bean Validation 3.0 for declarative validation of data.[9] The Eclipse Foundation oversees this certification process, ensuring adherence through the Technology Compatibility Kit (TCK), with publicly available test results confirming compliance.[44] In addition to Jakarta EE 10, WildFly 38 supports Eclipse MicroProfile 7.1, which enhances cloud-native development with specifications for health checks (via MicroProfile Health), metrics collection (via MicroProfile Metrics), and configuration management (via MicroProfile Config).[8][45] These features enable microservices to integrate seamlessly with observability tools and dynamic environments, promoting portability across cloud platforms. TCK results for MicroProfile 7.1 are also publicly documented, validating WildFly's implementation. For backward compatibility, WildFly maintains support for legacy Java EE applications through dedicated migration tools, such as the WildFly Server Migration tool, which automates the transition of configurations and deployments from older versions to Jakarta EE namespaces. However, support for pre-Jakarta EE profiles, including Java EE 8 and Jakarta EE 9.1, has been deprecated starting from WildFly 27, with newer releases focusing exclusively on Jakarta EE 10 and beyond to align with evolving standards.[27] This deprecation encourages modernization while preserving interoperability for existing deployments via compatibility layers for protocols like EJB and JNDI.[46]Performance and Management Tools
WildFly incorporates several performance optimizations that leverage its modular architecture to enhance application responsiveness and efficiency. Reactive Streams support is provided through the MicroProfile Reactive Streams Operators implementation, which utilizes SmallRye Mutiny for handling asynchronous data streams in a non-blocking manner.[47] This enables developers to build reactive applications that process data streams efficiently without traditional threading overhead. Low-latency clustering is achieved via the JGroups subsystem, which facilitates group communication with protocol stacks like UDP for reliable, ordered message delivery across nodes, minimizing delays in distributed environments.[48] Additionally, health checks integrated with MicroProfile Health allow for Kubernetes readiness probes, exposing endpoints such as/health/ready to verify application deployment status and ensure pods only receive traffic when fully prepared, thus optimizing resource allocation in containerized setups.[49]
Management tools in WildFly provide robust options for configuration and observability. The WildFly Admin Console offers a graphical web interface, accessible at http://localhost:9990/console, that utilizes the HTTP management API to configure standalone servers or managed domains, including role-based access controls that hide unauthorized resources for enhanced usability.[47] JMX integration exposes management resources in a structure akin to Open MBeans, allowing external tools to monitor server attributes and operations through a standardized interface.[47] For distributed tracing, OpenTelemetry support is available via a dedicated subsystem, enabling the collection and export of trace data to backends like Jaeger, which helps identify bottlenecks in microservices architectures without requiring application code changes.[50]
Security features in WildFly emphasize integrated protections for sensitive operations. Built-in support for OAuth 2.0 and OpenID Connect is facilitated through Elytron's authentication mechanisms, with seamless integration to Keycloak for securing the management console and applications via token-based authorization.[37] Secret management is handled by the Elytron Credential Store, which replaces the legacy vault and securely stores credentials like passwords in encrypted keystores, accessible via aliases to prevent plaintext exposure in configurations.[51]
Scalability is a core strength of WildFly, particularly in clustered environments. Domain mode enables management of multi-server topologies through a central Domain Controller, where server groups ensure consistent configurations across instances and support automatic discovery via protocols like multicast or Kubernetes-specific KUBE_PING.[48] Failover capabilities, powered by subsystems such as Infinispan for session replication, allow seamless redirection of client requests to healthy nodes, maintaining application availability during node failures without session loss.[48]
Deployment and Usage
Installation Process
WildFly can be installed on various operating systems including Linux, Windows, and macOS, provided they support Java and standard archive formats like ZIP or TAR.GZ.[52] The server requires Java SE 11 or later (LTS versions such as 17 or 21 recommended for production use; WildFly 38 is fully tested on Java 21 (recommended LTS) and runs well on Java 17 and Java 25), with sufficient RAM for basic operations and deployed applications.[8][53] Download options include binary distributions available from the official WildFly website, such as the full distribution for standard Jakarta EE support or the preview distribution for experimental features.[24] These come as ZIP or TAR.GZ archives, with the full profile providing a complete set of subsystems and the preview enabling early access to upcoming standards.[52] For project setup, Maven archetypes are provided to generate starter Jakarta EE applications compatible with WildFly, facilitating quick development environments.[54] The basic installation process begins by downloading the desired archive from the WildFly downloads page and extracting it to a directory of choice, such as/opt/wildfly on Linux or C:\wildfly on Windows.[52] Next, ensure the JAVA_HOME environment variable points to the Java installation directory (e.g., export JAVA_HOME=/path/to/jdk-17 in a shell). To start the server in standalone mode, navigate to the bin subdirectory and execute ./standalone.sh on Unix-like systems or standalone.bat on Windows; for managed domain mode, use ./domain.sh or domain.bat instead.[52]
Installation is verified by accessing the default welcome page at http://localhost:8080 in a web browser, which should display the WildFly welcome content if the server starts successfully.[52] Additionally, review the bootstrap logs in standalone/log/server.log (or domain/log/host-controller.log for domain mode) for any errors and confirmation of subsystem initialization.[52] WildFly's modular framework supports custom provisioning with tools like Galleon for lighter installations tailored to specific needs.[55]
Configuration and Application Deployment
WildFly configuration is managed through XML files tailored to the operational mode. In standalone mode, the primary file isstandalone.xml, located in the standalone/configuration/ directory, which defines subsystems, security realms, and server-specific settings for a single instance.[56] For managed domain mode, supporting clustered setups, domain.xml in the domain/configuration/ directory outlines domain-wide policies, server groups, and profiles shared across multiple hosts.[57]
Configurations can be modified at runtime using the Command Line Interface (CLI), accessible via jboss-cli.sh --connect. For instance, to add a datasource subsystem, the command /subsystem=datasources/data-source=ExampleDS:add(jndi-name="java:jboss/datasources/ExampleDS", driver-name="h2", connection-url="jdbc:h2:mem:test") integrates an H2 embedded database.[58] Similarly, for MySQL, after deploying the JDBC driver, /subsystem=datasources/data-source=MySQLDS:add(jndi-name="java:jboss/datasources/MySQLDS", driver-name="mysql", connection-url="jdbc:mysql://localhost:3306/exampledb") establishes connectivity.[59]
JVM tuning, such as adjusting heap size, is performed by editing startup scripts like standalone.conf or domain.conf to include options in JAVA_OPTS, for example, -Xms64m -Xmx512m to set initial and maximum heap to 64 MB and 512 MB, respectively, optimizing memory for application demands.[60]
Application deployment supports multiple methods, including hot deployment by placing WAR or EAR files—zipped or exploded—into the standalone/deployments/ directory, where a scanner monitors for changes every 5 seconds by default.[61] Deployments can also leverage the management API via CLI commands like deploy /path/to/app.war or the HTTP interface on port 9990 for programmatic control.[62] WildFly further accommodates containerized environments with official Docker images available at quay.io/wildfly and Helm charts for Kubernetes orchestration, enabling streamlined builds and deployments using source-to-image (S2I) processes.[63]
The application lifecycle integrates build tools like Maven with the wildfly-maven-plugin for packaging and management. In a pom.xml, goals such as wildfly:deploy upload and activate artifacts to a running server, while wildfly:build provisions a customized bootable JAR including the application.[64] Undeployment occurs via wildfly:undeploy in Maven or CLI commands like undeploy app.war, with the web-based management console providing a graphical alternative for removing applications. Gradle users can achieve similar workflows through community plugins mirroring these operations.[65]