Red Hat JBoss Enterprise Application Platform (EAP) can be improved by integrating different services related to Azure and AWS, and the open-source application and the EAP orchestrator Kubernetes platform must be more specifically usable for every user.

The support for Red Hat JBoss Enterprise Application Platform (EAP) could also be better than it is now.

View full review »

Regarding support and better documentation or customization, I like what I have seen. However, I saw some areas of improvement in the documentation. From a support point of view, whatever support we get from IBM for Red Hat JBoss Enterprise Application Platform (EAP) and for Red Hat, we are fine. We are a bank, and there are very specific agreements to have this support. I do not want to say 24 hours, seven days, but we need it right away. So nobody is fooling around at this level because we are a bank.

View full review »

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.

View full review »

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.

View full review »

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.

View full review »

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.

View full review »

I cannot speak to how Red Hat JBoss Enterprise Application Platform (EAP) can be improved.

View full review »

I think documentation may need improvement for Red Hat JBoss Enterprise Application Platform (EAP).

Additionally, the support feature can be improved.

View full review »

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.

View full review »

The tool's documentation could be improved to explain its usage and functionalities clearly. Having accessible documentation would save time for leaders like me when juniors seek information about it. The documentation should be self-explanatory and guide users on how to utilize the tool. 

View full review »

There is not much ability inside of the solution. The world is going beyond different micro and data-type things like Microsoft Office, so we are not seeing much ability within the solution. 

View full review »

The only thing I would change is the logging. The login logs are not very good. The login process could be improved.

View full review »

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.

View full review »

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

View full review »

The stability of the solution could improve with Microsoft Windows.

View full review »

Logging-related issues in JBoss require improvement. Also, another problem in the solution is that once the developer finishes coding, minor changes are often required when deploying Red Hat Fuse. Though the developer already knows these changes, there may be some dependency problems and the need to install JAAS. The other issue in JBoss is related to instances being stuck.

View full review »

Sometimes the console has a glitch. For example, we might send some commands to stop the servers and we get some logs or some errors from the console. After some minutes the services stop yet the console doesn't refresh the status. 

Sometimes I miss the JDBC resources full administration from GlassFish. In GlassFish, you define the pool and if you have three or more domains you can deploy to each domain. However, in JBoss, you have to define each pool in every configuration. Sometimes you have to do extra work to define this JDBC force and that is something that sometimes is very annoying.

View full review »

JBoss is not as reliable and stable as WebLogic.

View full review »

The solution's documentation could be better.

View full review »

The solution sometimes crashed and had some compatibility issues with the DevOps JAR file.

JBoss's next release should include a one-click solution for clustering or straightforward installation.

View full review »

The documentation could be better. When we have questions, we need to check multiple websites. There isn't one place listing a set of common problems and how to fix them. 

View full review »

JBoss is too much for what we need. When it was developed, it made sense. I liked having all of these services and all of these applications mounted on vehicles due to the capability. We could have several clusters in one JBoss instance. Nowadays, that solution is kind of too much maybe. We're not using very distinctive capabilities.

If the client decides to keep on JBoss instead of migrating to services, to the different architecture, the next steps would be to take more advantage of the new features, changing the code to a Java 11 style. Of course, they need to modernize the services, and consider migrating to new stuff that is available already for items like REST. Or even the use of stuff like GraphQL.

In general, the support of the ERPC would be really good due to the fact that, so far, I have not seen it. I have not even tried GraphQL, however, having any of these new technologies for exposing services would be really, really good for JBoss, That's what is moving forward in the industry.

View full review »

We haven't come across any missing features. 

The initial setup is a bit complex. 

I'd like the product to move more towards the cloud.

The frequent updates, and the life cycle, should be a little longer. They keep on changing versions and versions should have a longer life.

Even if the client buys an extended life cycle, they should support the customers who are loyal customers and extend all their possible support to the client when a customer is buying a subscription as well as extended life cycle support. The OEM should want to give additional extended support to the customer because.

View full review »

The support should be bundled with the Red Hat OS support because as it is now, these are two separate costs. Having the support combined with Red Hat support would be an improvement.

View full review »

I don't know much about these aspects. However, it would be great if the product came with a feature where the remarks made on the board can be saved on an individual's laptop to make it more user-friendly.

View full review »

The solution could improve by providing more integration.

View full review »

It can have automation features. Everybody is focused right now on automation. In terms of saving cost, automation is always the first thing that comes to light.

View full review »

The deployment of data sources could be improved.

View full review »

Level of customization is low as compared to other competitive products.Runtime diagnostics and DR (Disaster Recovery) features are limited as compared to Weblogic and Websphere. Since oracle now has Weblogic , they are introducing integration of other products like coherence into it. View full review »

The solution's pricing could be improved because it is not cheap.

View full review »