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.
Head of Operations at MIT (Micro Informatique & Technologies SA)
Real User
Top 10
2024-04-30T09:21:40Z
Apr 30, 2024
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.
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.
The version of JBoss we used, which was quite old (version 4), lacked a user-friendly web console or portal for easy server management. It would be beneficial to have a console for configuration to simplify the administrator's tasks. In terms of monitoring, the old version was somewhat limited in flexibility, lacking the ability to easily adjust configurations.
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.
Business developer manager at Ambetronics engineers Pvt ltd.
Real User
Top 20
2023-04-04T07:22:00Z
Apr 4, 2023
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.
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.
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.
Technical Lead at Netlink Software Group America Inc
Real User
2022-06-24T16:25:00Z
Jun 24, 2022
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.
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.
Application Server Manager at Centro Nacional de Registros
Real User
2021-12-21T11:47:00Z
Dec 21, 2021
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.
Head of Department at a transportation company with 10,001+ employees
Real User
2021-04-08T11:06:33Z
Apr 8, 2021
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.
Information Technology Consultant at a computer software company with 11-50 employees
Reseller
2021-03-26T20:56:49Z
Mar 26, 2021
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.
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.
Red Hat JBoss Enterprise Application Platform (EAP), a market-leading, fully certified Java EE platform, gives you a single platform to quickly develop and deploy applications. Use traditional Red Hat JBoss EAP to gain business agility with your existing applications and reduce the costs of proprietary platforms.
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.
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.
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.
The version of JBoss we used, which was quite old (version 4), lacked a user-friendly web console or portal for easy server management. It would be beneficial to have a console for configuration to simplify the administrator's tasks. In terms of monitoring, the old version was somewhat limited in flexibility, lacking the ability to easily adjust configurations.
The solution's pricing could be improved because it is not cheap.
The only thing I would change is the logging. The login logs are not very good. The login process could be improved.
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.
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.
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.
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.
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.
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.
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.
The solution could improve by providing more integration.
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.
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.
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.