wildfly

WildFly Application Server

3,040

2,231

3,040

Top Related Projects

Quick Overview

WildFly, formerly known as JBoss AS, is a powerful, modular, and lightweight application server that implements the Jakarta EE specification. It provides a flexible and scalable platform for deploying Java applications, offering features like high availability, distributed caching, and messaging.

Pros

Lightweight and modular architecture, allowing for efficient resource usage
Supports both traditional Java EE and modern Jakarta EE applications
Offers robust clustering and high availability features
Provides a comprehensive management console for easy administration

Cons

Steep learning curve for beginners due to its extensive feature set
Configuration can be complex for advanced scenarios
Some legacy applications may require modifications to work with newer versions
Documentation can be overwhelming for new users

Getting Started

To get started with WildFly:

Download the latest version from the official website: https://www.wildfly.org/downloads/
Extract the downloaded archive to your preferred location
Open a terminal and navigate to the bin directory of the extracted folder
Run the following command to start WildFly:

./standalone.sh

Access the management console at http://localhost:9990
Deploy your application by copying the WAR or EAR file to the standalone/deployments directory

For more detailed instructions and configuration options, refer to the official WildFly documentation.

Competitor Comparisons

tomcat

7,476

Apache Tomcat

Pros of Tomcat

Lightweight and simple to set up, ideal for smaller applications
Extensive documentation and large community support
Lower resource consumption, suitable for constrained environments

Cons of Tomcat

Limited enterprise features compared to WildFly
Less support for advanced Java EE specifications
Requires additional components for full Java EE compliance

Code Comparison

Tomcat's server configuration (server.xml):

<Server port="8005" shutdown="SHUTDOWN">
  <Service name="Catalina">
    <Connector port="8080" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" />
    <Engine name="Catalina" defaultHost="localhost">
      <Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="true" />
    </Engine>
  </Service>
</Server>

WildFly's server configuration (standalone.xml):

<server xmlns="urn:jboss:domain:8.0">
  <socket-binding-group name="standard-sockets" default-interface="public">
    <socket-binding name="http" port="${jboss.http.port:8080}"/>
    <socket-binding name="https" port="${jboss.https.port:8443}"/>
  </socket-binding-group>
  <subsystem xmlns="urn:jboss:domain:undertow:7.0">
    <server name="default-server">
      <http-listener name="default" socket-binding="http"/>
      <host name="default-host" alias="localhost"/>
    </server>
  </subsystem>
</server>

WildFly's configuration is more complex but offers greater flexibility and advanced features, while Tomcat's configuration is simpler and more straightforward for basic web applications.

spring-boot

74,415

Spring Boot

Pros of Spring Boot

Faster development with auto-configuration and opinionated defaults
Lightweight and modular, allowing for easy customization
Extensive ecosystem with a wide range of starter dependencies

Cons of Spring Boot

Steeper learning curve for developers new to the Spring ecosystem
Can be overkill for simple applications or microservices
Less suitable for large, complex enterprise applications compared to WildFly

Code Comparison

Spring Boot application setup:

@SpringBootApplication
public class Application {
    public static void main(String[] args) {
        SpringApplication.run(Application.class, args);
    }
}

WildFly application setup (web.xml):

<web-app>
    <servlet>
        <servlet-name>MyServlet</servlet-name>
        <servlet-class>com.example.MyServlet</servlet-class>
    </servlet>
    <servlet-mapping>
        <servlet-name>MyServlet</servlet-name>
        <url-pattern>/myservlet</url-pattern>
    </servlet-mapping>
</web-app>

Spring Boot focuses on simplicity and rapid development, while WildFly provides a more comprehensive Java EE environment. Spring Boot's minimal configuration and embedded server make it ideal for microservices, while WildFly's full Java EE support suits complex enterprise applications. The choice between them depends on project requirements, team expertise, and scalability needs.

Convert designs to code with AI

Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.

Try Visual Copilot

README

WildFly Application Server

https://wildfly.org

Fast Startup
Small Footprint
Modular Design
Unified Configuration and Management

And of course Jakarta EE!

Building

Prerequisites:

JDK 11 or newer - check java -version
Maven 3.6.0 or newer - check mvn -v
On *nix systems, make sure that the maximum number of open files for the user running the build is at least 4096 (check ulimit -n) or more, depending on what other i/o intensive processes the user is running.

To build with your own Maven installation:

mvn install

Alternatively, you can use the Maven Wrapper script that downloads and installs (if necessary) the required Maven version to ~/.m2/wrapper and runs it from there. On Linux, run

./mvnw install

On Windows

mvnw install

Starting and Stopping WildFly

Change to the bin directory after a successful build

$ cd build/target/wildfly-[version]/bin

Start the server in domain mode

./domain.sh

Start the server in standalone mode

./standalone.sh

To stop the server, press Ctrl + C, or use the admin console

./jboss-cli.sh --connect command=:shutdown

Check 'Getting Started Guide' in the WildFly documentation for more information about how to start and stop WildFly.

Documentation

https://docs.wildfly.org/

Contributing

Please see the instructions available in the contribution guide.

Build vs. Dist directories

After running mvn install, WildFly will be available in two distinct directories, build and dist.

The build directory contains a build of WildFly that is based on Maven artifact resolution for module configuration
The dist directory, on the other hand, contains a full distributable build of WildFly

Using the build directory makes iterating with subsystem or module development easier since there is no need to rebuild the whole of WildFly or copy JAR files around on every change.

The dist directory is better suited when a full build of WildFly is needed for development or test purposes.

Running the Testsuite

The testsuite module contains several submodules including the following:

"smoke" -- core tests that should be run as part of every build of the AS. Failures here will fail the build.
"api" -- tests of features that involve end user use of the public JBoss AS 8 API. Should be run with no failures before any major commits.
"cluster" -- tests of the WildFly HA clustering features. Should be run with no failures before any major commits.
"domain" -- tests of the domain management features. Should be run with no failures before any major commits.
"integration" -- tests of a WildFly standalone server's internals. Should be run with no failures before any major commits.
"spec" -- tests of features that only involve end user use of the Jakarta EE spec APIs. Should be run with no failures before any major commits.

For basic smoke tests, simply: mvn test

To run all the tests

mvn install -DallTests

Using Eclipse

Install the latest version of eclipse
Make sure Xmx in eclipse.ini is at least 1280M, and it's using Java 11
Launch eclipse and install the m2e plugin, make sure it uses your repo configs (get it from: http://www.eclipse.org/m2e/ or install "Maven Integration for Eclipse" from the Eclipse Marketplace)
In eclipse preferences Java->Compiler->Errors/Warnings->Deprecated and restricted set forbidden reference to WARNING
In eclipse preferences Java->Code Style, import the cleanup, templates, and formatter configs in ide-configs/eclipse in the wildfly-core repository.
In eclipse preferences Java->Editor->Save Actions enable "Additional Actions", and deselect all actions except for "Remove trailing whitespace"
Use import on the root pom, which will pull in all modules
Wait (m2e takes a while on initial import)

License

Apache License 2.0