JBoss Reviews

For our application to deploy, we used to set up different platforms. We are certifying JBoss support as well for the deployment.

JBoss's configuration is straightforward and easy. It is easy to edit one standalone dot XML file with all the 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.

I have been using JBoss for three to four years.

I rate JBoss a seven out of ten for stability.

JBoss is a scalable product and 100 people were using it in our company.

The initial setup of JBoss is easy. However, the clustering part was a little bit complex.

I recommend people to use JBoss because it is easy to set up and install.

Overall, I rate JBoss an eight to nine out of ten.

The product is basically middleware. What we have is several applications running on JBoss. Basically, it is very old and there we have those services exposed. Our target is to move them to ERPC, or something more modern, like REST or ESPC, or a combination of both.

What we currently have here, still, is SOAP services, which is a very old middleware. They also are using it for scheduling some items such as some recurrent procedures. They have a queue manager as well.

I've only been with this client in the last six months, however, the middleware has been the backbone for them for several years. The organization depends on it. The business depends on it.

The solution is stable.

You can scale the solution.

There's good documentation and a pretty good community surrounding the product.

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.

I've been using the solution for the last six months. It has been since June. Prior to that, I only had small chunks of time with some JBoss systems. If I would gather them all, it would be about eight months of collective experience with the product.

From what I have seen, the solution is stable. Even when it was migrated to the cloud to AWS, as it was first on-premises, it was capable of dealing with heavy loads. We never saw one of the instances crashing. We haven't seen a problem related to JBoss. The client is more concerned about how old the code is and of course, they want it to move to the cloud. That's why we started to move it to AWS. Now we're dockerizing in JBoss and taking it to GCP due to the fact that the target, at the end of the day, is to modernize everything. Whether if it remains in Google Cloud as a containerized set of applications, or it's split on services or have them both parallel migrating to services, it seems like it will remain stable.

On scalability, we have enough instances in production. I have not heard about any issues with scalability. It should be easy enough to do.

As far as I know, there are three or four applications that are using the middleware. And there are some other applications that use it as well. I have three and they are like portals. 

I haven't really reached out to technical support in the past. If there's technical support needed on the code, typically I can check it out.

They have a strong community. I haven't had a need to reach out to them, however. They have good documentation for JBoss. It's available as long as you have an account and you can get the information that you might need for troubleshooting.

The solution already existed. I'm not sure if they had a different solution prior to this.

We arrived at this project. The solution was already set up. We haven't been implementing anything, we've been cleaning up all the projects. We've been making improvements on it. The solution already existed. Of course, there are things that can be leveraged, like the organization or the structure into the project. But no, the solution was already there. We have been dealing with it and parallel. We have been building a proposal to the client for migrating into small services.

I'm not sure of the exact pricing, however, my sense is that it's expensive as the client no longer wants to pay for it and would like to move away from it or onto the cloud.

What is currently being evaluated is what to use to replace this solution. The client is looking for a change.

For splitting the services into small microservices or small services, we are proposing the use of Quarkus which is a modern set of tools and of the same type as Red Hat, or Java. We are proposing Quarkus as the platform for building the services. Of course, we'll be using Java 11 for the services. We already have developed something on GRPC, and there's also the option to use REST. What we have found is less problematic when it comes to migrating, is to do a bunch of code is Quarkus precisely due to the fact that it allows us to use a lot of capabilities from Java's enterprise edition. Quarkus is the more modern technology that we have found for making it easier to make a transition.

We're just customers. We are currently migrating an application that was developed, on JBoss, and we are taking it to the Cloud.

The project was started on JBoss 6.2, however, now that we are mounting it in the Cloud, we're using JBoss EAP 7.3. The client doesn't want to pay more rights to RedHat. Now we're moving JBoss to WildFly, which is really easy. It's just to avoid the licenses. 

The deployment version is on-premises. The productive version is still on AWS on-premises, on some virtual machines that the company paid for. However, when it comes to the cloud, we are installing it in Google Cloud. We are moving it. We have these deployments in parallel.

I could recommend this solution as I have seen that it's stable. There are some things that are still done in an old-fashioned way, however, it's still stable and you can find the connotation for that. You can have the option to use it in the cloud. We are using containers already for tables in the cloud. My advice would be simply to have it really clear why you want to use it. Alternatively, if you are going to have a really heavy application where you need everything together, of course, JBoss is a good option.

I would rate the solution at a nine out of ten.

We primarily use the solution for business processes and mostly from the level of approval, within the organization.

The product integrates well with Java applications.

The software is basically decently placed, commercially as well as for production.

The solution is quite stable. 

It's perfect for the needed usage of the customer.

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.

I've been using the solution for five or six years. 

The stability is very good. There are no issues with bugs or glitches. the performance is good. 

The solution is scalable. It's not locked to any specific server, so the licenses are flexible.

Technical support is okay. The support comes from the GSS, the global support center of Red Hat. The problem is that support is always via email. They do not give support via telephone. Email support takes a bit of a time, however, they do give you some sort of solution. There is no typical SLA.

The solution is a little complex in terms of implementation. It is not a straightforward thing, as there is integration with multiple things which makes it not a straightforward implementation.

In terms of maintenance, it all depends upon the case and the departments. For one implementation unit, you need at least one person.

Licensing is flexible. It comes in a subscription model, so it doesn't actually lock to a specific server. That's one of the good things. Licensing costs vary from company to company. It depends on the requirements and size. Definitely, it is better than the proprietary cost. Everything is included under the license. there are extra fees. 

I don't remember the version we're using, however, it'll be the latest version at that time of implementation. These are on an in-house data center.

It's pretty easy to implement from the Java perspective, however, equally challenging to integrate with other applications or different databases. 

I'd rate the solution nine out of ten.

JBoss is a product that we implement for our clients. It is used as an application server and a web server. 

The most valuable feature is the UI.

This is a lightweight server.

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.

We have been using JBoss for a couple of years.

We have not had any problems with the stability.

This is a scalable product.

Our application support team will contact JBoss support if they have an issue, but so far they have not needed to. We have not seen any major or critical problems.

We also have Oracle WebLogic in the company and some of the developers prefer to use JBoss. Three or four of our applications use JBoss and the remaining ones, which is most of them, use WebLogic.

In terms of memory, it is better than Oracle WebLogic.

Our in-house team is responsible for deployment and maintenance. We have one person from the infrastructure team to help install and tune it. A second person performs day-to-day troubleshooting on it.

Once we deliver and deploy the server, there is another team to support the application.

This price of JBoss is cheaper than similar solutions like Oracle WebLogic. We pay for a maintenance license, but it is not expensive.

JBoss is what we settled on when we were searching for alternatives to WebLogic.

My advice is that for anybody who is searching for a lightweight application or web server, JBoss is one of the options that I recommend. We plan to continue using it.

I would rate this solution a seven out of ten.

I use the platform mainly for presentations and meetings. It is also used to implement web applications.

JBoss has made it very easy to implement web applications.

The meetings in JBoss are very easy, and we can see what's there on our laptops and mobiles. We can also comment over there.

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.

I have been using JBoss for around six months.

It is a stable solution. I would rate it a ten out of ten.

I do not have much insight into scalability. At present, we have around six users.

It is easy to set up.

I would rate the solution a ten out of ten. I would recommend this solution to others.

JBoss is used for our main applications, it is our core system. All the core systems that we use are on JBoss and we use mod_proxy combined with WildFly to do the load balancing. Additionally, we use automation using Red Hat Ansible Tower, and for a web server, we use Red Hat for the entrance.

The solution is easy to use. 

If I use Red Hat JBoss and Red Hat web server, I can do more configuration. I use the AP server to control my webserver. I don't have to always log in to the webserver and change configuration or do all the changes. I can do all the configuration on the AP server, only using JBoss.

The solution could improve by providing more integration.

I have been using JBoss for approximately five years.

I have found JBoss to be much more stable than some solutions from IBM.

We have two users of JBoss in my organization.

I have been satisfied with the technical support, the speed at which they respond is good.

JBoss is easy to install.

We have two engineers in our company and they do the implementation and maintenance of the solution.

I would recommend this solution to others.

I rate JBoss an eight out of ten.

I am working on a deal where JBoss is being renewed. It is a legacy version. The use case is around a financial institution that enables banks to do peer-to-peer transactions. Finance is the core business of the companies I'm working with.

It is a Java-based product, so it is pretty straightforward. It is pretty easy from a developer's perspective. It is also pretty reliable and scalable.

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.

It is pretty reliable.

We have seen big enterprises using JBoss. So, it doesn't matter what the size of the organization is. JBoss can fit regardless of the size.

In terms of the number of users, in the organization I'm working with, there are 20 developers and a couple of infrastructure guys. They have a lot of developers in this particular organization.

There are no concerns in terms of support. They received support directly from Red Hat.

It is pretty straightforward from my perspective. The deployment duration depends on what you're trying to do with this solution, but it is pretty straightforward and can be deployed in a couple of hours.

They went for what they were comfortable with, and they weren't much interested in new solutions.

Its recommendation depends on the vision of the organization. We need to have that understanding first before we provide them some sort of solution. It will depend on what they already have in place or what they're planning to do. Customers are moving to the cloud, and there are other alternatives out there, but of course, it will depend on understanding the journey of the customer.

I would rate JBoss an eight out of ten, just for how common it is to use Java as a language.

I have seen a few implementations where the JBoss application server is used. Initially, the applications were hosted on licensed servers like IBM WebSphere and BEA WebLogic. But, due to the license cost, we advised our client to shift to an open source application server. With open source, we had a choice of going with Apache Tomcat and JBoss. We chose JBoss as it's far more scalable, secure and comes with support from the vendor.

The server supports Windows as well as Linux OS, which is an added advantage. JBoss seems to be a well-rounded application server in the market which supports scalability and is easy to set-up and to deploy.

Compared to IBM and BEA, JBoss provides the best support in the virtualized environment, and it also comes with multiple configurations which help in easy roll-out of the applications.

The application deployment sometimes can be a tedious task if you are a novice.

The earlier application servers - IBM/BEA - had a very huge license cost. Moreover, the cost went up as we wanted to scale the application for more users. 

Also, the application servers comes with poor support in virtualized environment.