I have used Red Hat JBoss Enterprise Application Platform (EAP) in many projects. As a Java developer, I have worked with ATG and we have used the application server Red Hat JBoss Enterprise Application Platform (EAP) extensively for building applications and deployments.

We use Red Hat JBoss Enterprise Application Platform (EAP) in our application development. We have utilized Red Hat JBoss Enterprise Application Platform (EAP) as an application server for deployment purposes. For local running and operating particular applications locally, we have extensively used Red Hat JBoss Enterprise Application Platform (EAP). I have primarily worked as an application developer.

When we used Red Hat JBoss Enterprise Application Platform (EAP), it was mostly in monolith applications. It is a very cost-effective, efficient way of deploying and managing Java applications. The main important aspects are the flexibility and scalability of Red Hat JBoss Enterprise Application Platform (EAP). It runs on various platforms, from small devices to large servers, and we can easily scale down and scale up.

The integration with external applications, web servers, or other systems is very straightforward in Red Hat JBoss Enterprise Application Platform (EAP). We have robust security features. Additionally, there are excellent Red Hat JBoss Enterprise Application Platform (EAP) community resources available, which provides documentation for troubleshooting deployment issues.

Scaling could be improved, and more features could be added for MLOps deployment and microservices deployment. Integration with various cloud platforms and Jenkins-type features would be beneficial if Red Hat JBoss Enterprise Application Platform (EAP) could implement them. The product would grow significantly because Red Hat JBoss Enterprise Application Platform (EAP) supports Java, which is widely used as a programming language. It is particularly convenient for deployment and clustering purposes.

I have used Red Hat JBoss Enterprise Application Platform (EAP) in numerous projects.

I have not personally used the support team, but they maintain a strong community. In any technology, having a community makes things easier. Users can find discussions about common problems, solutions, and documentation within the community.

I am not certain about the pricing details as the client or company handles those aspects. Since it is Red Hat, I believe it must be free.

Red Hat JBoss Enterprise Application Platform (EAP) is one of the excellent application servers that organizations can utilize extensively. It uses open JDK and is part of the Red Hat team's software portfolio, offering very competitive pricing.

It operates on Linux, which is a stronger platform than Windows. The deployment processes are very efficient and fast. The entire package is very effective, especially when using Red Hat JBoss Enterprise Application Platform (EAP) on Mac, which offers numerous scaling options that can be configured easily.

It serves as an excellent application server and can be used with Jenkins. It is particularly efficient when used on Mac for development purposes.

On a scale of 1-10, this solution receives a rating of 7.

My main use case for JBoss is the administration of the application mostly.

My use case implies installation, configuration, and setting JBoss EAP on different systems such as Linux, Windows and configuring the standalone or domain. This implies working with the web console, automation tools, and CLI. Additionally, it involves securing it, implementing authentication, RBAC or Role-Based Access Control, SSL, TLS, and so on. Performance tuning, thread pool management, logging, and clustering are mostly what I have done with the product.

JBoss has positively impacted my organization by enabling deployment with enterprise extensions that were needed, particularly for integration with directory services. The difference came in implementation, and it offers a significant role in deployment that is scalable, especially when using a clustering way of working with it.

Specific outcomes include improved deployment times due to modular architecture leveraging lazy loading, which affects the time taken to deploy archive, war, or ear files, and the deployment success rate without server restarts. This impact has significantly enhanced stability and reduced downtime. Lower memory consumption during deployment has been apparent thanks to subsystem isolation, while asynchronous deployment handling has reduced spikes and led to fewer errors with better validation overlay support in cases of failed deployments or rollback events. Additionally, I have enabled quick fixes without full redeployments, particularly with frequent overlay-based updates.

In my experience, the best features JBoss offers include the modular architecture where the services are loaded when needed, and the cross-platform compatibility that allows it to run on any operating system that supports Java. The high availability and clustering, distributed support, session replication, and load balancing using Infinispan stand out. The security enhancement such as native support of OpenID Connect or JAS for flexible authentication is another outstanding feature. Others include flexible deployment modes and control of session affinity, which is fine-tune control over load balancer stickiness strategies for managing web sessions. Furthermore, global directory support allows for easily adding shared modules to deployments without class path. It stands out because it is a full-stack platform for building today's cloud-ready Java applications that are scalable and secure, blending enterprise-grade features with open-source flexibility. It is the top choice for organizations that need reliability today.

For underrated features, server group in domain mode allows grouping servers and applying configuration or deployments across them simultaneously. Not many people know about the CLI scripting with batch mode or Vault and Credential stores, where sensitive configuration values can be stored without hardcoding them into XML files. Additionally, built-in metrics and subsystem isolation, where every subsystem logging, messaging, or web services can be tuned independently, provide fine-grained control over performance and behavior. This is why subsystem isolation is important, and many administrators have not utilized it that way.

JBoss can be improved significantly, especially regarding deployment overlays that need updates to apply quick fixes or environment-specific changes without redirecting the archive. Enhancements in CLI scripting for automatic deployments or rollbacks and having an automated way of updating in the future for pack changes and version transitions are critical. More details about the update progress of package installations, artifacts downloading, as well as automation for modules and configurations applied are needed. Additionally, features for drifting and reverting would be worthwhile. We leverage domain mode with server groups to enforce synchronized rollout strategies across clusters without downtime or config drift.
Subsystem isolation doesn’t just reduce memory usage it allows us to apply GC tuning and diagnostic tracing at the service level, not the container level.
Our CLI scripting has been backed by pre-validated batch execution pipelines, eliminating human error during hotfix rollouts and version transitions.
Using overlays in conjunction with marker files, we've created an audit-friendly patching workflow that doesn't require full archive redeployments.
Changes in the future need to align with today's directions regarding the most evolutionary topics of Jakarta EE progression. As Jakarta EE progresses, newer specifications such as Jakarta Data and Jakarta NoSQL or AI-assisted diagnostics are necessary.
We’ve integrated JBoss metrics output with Prometheus exporters, enabling real-time subsystem-level observability and predictive scaling alerts.
By aligning with Jakarta EE's modular progression, we've positioned our stack to adopt emerging specs like Jakarta NoSQL without disruptive upgrades.
JBoss’s flexible threading model allowed us to apply workload-specific executor policies, preventing starvation in high-concurrency deployments.
More straightforward updates and rollbacks need to be done with the CLI, alongside improved observability, such as native support for OpenTelemetry or enhanced DevOps tools with command-line interfaces and automation features. Support for YAML-based configuration is crucial, especially in a GitOps deployment style, along with cloud-native enhancements such as integration with Kubernetes, OpenShift, or newer technologies.
I would like to see JBoss reassess its executor configuration controls and consider offering default workload profiles such as I/O-bound, CPU-heavy, or async-first—to optimize threading strategies out of the box.
On the cloud-native side, it’s important to validate container readiness and expand operator-driven automation for Kubernetes, especially focusing on CRD evolution and stateless rollout support. I would also recommend improving workflow transparency by providing clearer feedback during pack updates, including artifact download status, config sync logs, and rollback outcome visibility.

I have been using JBoss for more than 10 years.

JBoss has remained reliable and fully functional across workloads, and I haven’t encountered any critical failures that would impact operations—especially when compared to prior solutions like Oracle WebLogic. Its resilience continues to make it a dependable backbone for enterprise middleware needs.

JBoss's scalability is effective. Its architecture is elastic, meaning it can handle growing workloads smoothly, whether it's scaling up for high demand or scaling out across clustered nodes. This elasticity makes it ideal for dynamic environments where resource usage can vary.

With newer Java versions, memory management has become noticeably more efficient. Improvements in garbage collection and memory recovery mean the platform performs well under load, with less risk of memory leaks or bottlenecks. This leads to better application stability and faster response times, especially during peak usage.

I would describe the experience as reliable and professional especially valuable when you're running JBoss in production and uptime matters. My experience with JBoss customer service and support has been dependable overall. When using the Red Hat-supported version, the service team was responsive and knowledgeable. For issues involving configuration, security realms, or integration quirks, I usually received clear guidance and practical solutions. The response time was more reasonable than questionable and in most cases, the support escalated technical problems efficiently when needed.
That said, for more complex or niche setup scenarios, I sometimes had to dig through documentation or lean on community channels like forums or GitHub discussions.
The support is solid, but having technical familiarity helps speed things along.

Before JBoss, I used Oracle WebLogic. I switched primarily because Oracle changed their solution's availability as well as the way they handled licenses, which became unfriendly for customers, leading to extensive discussions regarding licensing costs. Therefore, the most crucial factor for switching was the company direction of Oracle.

When using JBoss in standalone mode, installation is quick and simple you can get it running with minimal effort, especially for development or testing. It’s also great that it works on any operating system that supports Java and compatibility isn’t usually an issue. However, things can get more complex when you start configuring domain mode, especially if you’re setting up host controllers, managing server groups, or trying to centralize control across multiple servers. Integrating with other services by setting up LDAP for authentication or configuring secure connections it requires more time and planning. Once preparing it for production use, tuning the JVM, thread pools, logging levels or isolating subsystems requires deeper understanding. Support-wise, JBoss offers a lot of documentation, but beginners might find it a bit hard to follow at first.
The community is active and helpful, especially on Red Hat channels, but solving specific issues sometimes means a bit of experimentation.
if you're planning to use JBoss seriously, make sure you invest time in learning the architecture, automate where possible using command-line scripts and start monitoring from the first implementation day. Those choices can make the difference between a smooth experience and a frustrating one.

We implemented JBoss using our in-house team. Our engineers were already familiar with Java-based middleware and deployment strategies, we didn’t need to rely on an external vendor. That gave us more control over the setup process, especially around automation, performance tuning, and integration with existing services. It also saved us from additional consulting costs and helped us tailor the implementation to fit our environment exactly as needed.

We’ve seen a marked reduction in downtime and a major boost in system stability, resulting in fewer outages. One of the biggest wins has been the cost savings especially compared to Oracle WebLogic thanks to JBoss’s more affordable licensing model, particularly when bundled with Red Hat or OpenShift.

Its scalable design, whether deployed as a standalone system, clustered setup or through modular subsystems, JBoss has allowed us to tailor infrastructure to match demand. Using deployment overlays and scripting, we've sped up rollouts and maintained performance through smart JVM tuning.

Overall, we calculated a payback period of just around 5 months and a few days which speaks volumes and it’s been a strategic move with clear financial benefits.

My advice is to carefully review the licensing options before setting up JBoss. While using the free version WildFly, most companies go for the paid Red Hat JBoss version, which comes with extra features and support. The setup itself isn’t expensive, but getting it right often involves extra costs for team training, automation setup and performance tuning. For could environments loke OpenShift or Kubernetes it is important to make sure your licensing covers that so you don’t run into surprises later.
It’s smart to plan ahead and look beyond the software cost your return on investment will likely come from less downtime, smoother deployments and better scalability.

Before choosing JBoss, I evaluated other options, but the only one that adequately covered all needed aspects from different customers was Oracle WebLogic.

My advice for others looking into using JBoss is to understand the architecture before deploying and to differentiate between standalone and domain mode. Automating early and using command-line based scripts is essential. Monitoring everything, tuning JVM and thread pools, and using deployment overlays for quick fixes to minimize downtime through patches is crucial as well. Careful planning regarding licensing is the most important factor for customers.

It is crucial to invest time into learning the security standards for authentication and encryption in JBoss. This flexibility offers more than legacy JS solutions.

On a scale of 1-10, I rate JBoss an 8 out of 10.

Our product is agnostic, so we have been using JBoss as our default app server. We have been using it for over ten years.

JBoss is more flexible and keeps up with modern technologies, supporting newer versions of different libraries. This is crucial as the lifecycle of these technologies is short, and staying up to date is essential to avoid issues.

They are trying to make it less heavyweight since app servers often deliver a lot of functionality. Still, if we aren't leveraging them, they can be too much for certain use cases. Making it lighter and more modular would probably be beneficial.

We have been using JBoss for over ten years.

I haven't dealt with their support or customer service. Some of our clients have bought support, but I haven't heard anything about its quality, so I cannot comment.

We deploy on app servers chosen by clients, including WebSphere and WebLogic, which are more expensive.

JBoss has a very easy way of setting up. We use it since it doesn't cause a lot of issues.

We just use JBoss and sometimes buy support for certain things. We are not affiliated with any vendors.

Having automation around JBoss is very beneficial. It allows for quick deployment and rolling out new applications easily. This flexibility translates to a lower total cost of ownership.

JBoss is the cheaper option out of the three when compared to WebSphere and WebLogic. Though I haven't done a detailed price comparison, the licensing fee is cheaper, and due to its flexibility, the maintenance is easier and cheaper.

We also considered WebSphere and WebLogic.

JBoss is definitely a flexible option and achieves what other app servers do but with more ease and support of new technologies.

I rate JBoss nine out of ten.

We are currently using Ansible for Jira installations and all the management tasks. We perform some tasks manually, however, Ansible helps in automating some of these processes.

I find JBoss to be lightweight and easier to manage compared to WebSphere. It allows for simple modification of applications and provides better clustering capabilities. The setup was straightforward and suitable for enterprise-level needs.

I would like to see improved booting of applications altogether on one page to manage all data instances from one location, similar to an AWS console.

Additionally, access and sessions could be improved in the scalable device.

I have used the solution for over three years.

I would rate the stability around eight out of ten. It is quite stable for our needs.

Scalability is a concern because it is not online, which limits online processes. This aspect can be improved.

Red Hat support is good. We receive support from RDS and Red Hat, and the response time and quality meet our expectations.

There are no competitors. WebSphere is still there, and we also use it alongside JBoss.

The setup was simple.

The price is somewhat high for an enterprise, however, it depends on organizational negotiations. Additionally, Red Hat support can be costly.

I evaluated WebSphere.

Overall, I would rate the solution around seven out of ten. Despite some concerns, I would still recommend it.

I use it for Java server applications.

I work on an output management system. There are products that use JBoss as the Java server. It's a product from another vendor called the 'M' series. They use JBoss as the server behind it.

It's good. You choose JBoss when you need a Java server. The benefit is that it's fast, reliable, and well-established.

It was the choice of the customer, and they have no issues so far. It's a very well established product.

The price could be improved. Customers don't want to buy the license easily. It's nice that there is Wildfly, which is basically the same as JBoss, just without the price.

I have experience with JBoss because we just had it in a project.

The stability is good. I would rate it a nine out of ten.

The end users are around 300 for this application. It is used on a daily basis.

In general, I would prefer Wildfly. If I want a free version, I would go for WildFly.

And the support is also a factor. If you can do it on your own, you take Wildfly. If you need support, you can take JBoss.

It might be yearly. I am not sure.

In the past we evaluated IBM WebSphere, Oracle, and Tomcat. WebSphere system is a pain. Oracle is way overpriced, though. That's my opinion.

JBoss's performance is on par with its competitors.

Overall, I would rate the solution an eight out of ten. If other users need support, I would recommend JBoss. If they don't, they should just go with WildFly.

JBoss is a state-of-the-art Java server with a difficult support package. If you want to do a Java application, JBoss is usually a very good choice.

I use the solution in my company since we have developed an application that runs on the application server, JBoss, and another application server, such as Oracle WebLogic Server or WebSphere. In my company, we developed an application for the bank, and we deployed it under JBoss, WebSphere, or Oracle WebLogic Server.

The most valuable feature of the solution for me stems from the fact that our company can develop applications on JBoss, and we didn't see anything like it compared to WebLogic and WebSphere. The facility to install and handle JBoss is much lighter than the other application servers.

My company had faced some issues where our questions were not answered, and we did not receive proper solutions the way we wanted. The technical support of the product can be improved. Response time for support could be a bit better.

The price of the product is an area of concern where improvements are required. The product could be made cheaper.

I have been using JBoss for eight years. My company has a partnership with Red Hat.

Stability-wise, I rate the solution an eight out of ten.

My company did not face any issues related to scalability. Scalability-wise, I rate the solution a seven out of ten.

My company works with banks of both small and big sizes.

I rate the technical support a seven out of ten.

In comparison with the other products I have used in the past, I like JBoss's simplicity, lightness, and cost. Considering what my company used to use both solutions for, JBoss was better than WebLogic.

The product's initial setup phase is easy.

For the product's deployment and maintenance, our company has a system engineer who maintains both our instances associated with JBoss and supports the bank engineers.

The product offers a good return on investment.

I rate the product price as eight on a scale, where one means it is a very cheap solution, and ten points mean that it is a very expensive tool.

In terms of how JBoss supports enterprise Java standards and positively impacts our company's project, I can say that we use it, and we didn't have any issues. In our company, we have been able to do a posting of the application on the other application servers.

My company has not faced issues with the integration of the product with other software tools or infrastructures.

The product fits our company's requirements.

I recommend the product to others.

I rate the tool an eight out of ten.

We use JBoss mainly for application deployments and application servers.

JBoss is not as reliable and stable as WebLogic.

I have been using JBoss for four years.

Once installed and deployed, the solution is stable and works fine in the production environment.

When we need to scale, we install different instances of JBoss. We don't rely on clustering or specific features in JBoss.

WebLogic is a more reliable and stable tool than JBoss.

The pricing of JBoss is more reasonable than that of WebLogic.

Customers use JBoss instead of WebLogic. Although WebLogic is more feature-rich, its licensing is very high compared to JBoss. I am satisfied with JBoss's management and monitoring capabilities. I would recommend JBoss to other users.

Overall, I rate the solution a nine out of ten.

JBoss is a middleware product. The customers use it to make connections between front-end applications and databases.

Red Hat provides the product and the support. We get good support from the support team. It is one of the benefits.

The product could be cheaper. The solution recently increased the prices.

I have been working with the product for 6 months to a year.

The tool is stable. The customers are buying the product.

The tool is scalable. We can install additional servers. We can extend our cluster horizontally.

The support is fast and reliable. It is very good. If we raise a support ticket, the support team will solve the problem somehow.

The deployment is not that complex. It is easy.

We pay a yearly subscription fee. There are no additional costs associated with the product.

I recommend the tool to others. Overall, I rate the solution an 8 out of 10.