JBoss Reviews

We use JBoss exclusively for API integration and do not use it for other purposes. Our focus is solely on providing services and configuring ACLs.

Certain works are being done very well with JBoss due to its peer configuration. The various styles of services offered by JBoss are very useful for our company and other companies as it becomes difficult for businesses to afford too many services running on different computers. In short, JBoss is a good product. We use several instances, such as Java instances, and also install numerous services within the solution.

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.

I have been working with the solution for four years.

For our company, JBoss is a stable tool. However, I won't be able to speak for other people.

JBoss is a scalable tool.

Regarding the setup of JBoss, it is a standalone setup, which is straightforward. So, we are not using a domain setup. The solution's deployment was done four years ago. Additionally, the solution's setup is done on Openshift, which is a cloud-based platform.

Since the solution is freeware, our customers don't need to pay any licensing fees. The only element that requires payment is RHEL.

We use Git as a version controller, with the help of which the developers do coding and then commit their changes for a game. We have been using Git for four years.

I recommend JBoss to people who want to start using the solution. It is not a complicated tool to use. We are deploying different services over different instances. So, we reduce the cost over the one server, which we use to provide more than 600 services. Overall, I rate this solution a ten out of ten.

JBoss is an on-premises solution we use in a banking setting.  It is used to manage servers and applications. There are two modes: domain and development. We can monitor and control all types of deployments in JBoss.

We have around 20,000 to 30,000 users on the same application and everything is going via the JBoss. We were using JBoss 1.0 when I first installed it, but they've probably included some more security patches in the latest version. 

We can deploy the applications on the JBoss server, so it is easy to manage. It's also easy to add new certificates to the config.

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. 

I've been using JBoss since I joined the company three years ago. 

I haven't had any complaints in production, but in development and UAT, I've noticed that some of the applications are not deployed properly, and errors need to be fixed.

I used Tomcat when I worked for a cement manufacturer in India. They were a small-scale company, so we preferred Tomcat server. When I started working in finance, the bank suggested we go with JBoss. JBoss is easier to handle, and it can take on a much larger load compared to Tomcat.

Setting up JBoss is more complex relative to Tomcat. We need to follow the set of steps because it's not like we are installing a single system. Several separate systems need to be connected using the common prompt. There will be a common for that. After generating, we need to connect with the other ID with the main deployment controller.

There is one deployment controller, and we need to connect the separate server nodes using that. I use a trial-and-error process for the JBoss installations for the development. We follow the steps and document everything. After we do it once, it's not complex the second time because we know all the steps we need to follow. 

We don't use outside consultants. It's open source, so we do some R&D and a process of trial and error in the development environment. There is no help JBoss or a consultant. The banking team works with the development team to get it done.

I rate JBoss seven out of 10. I would recommend Tomcat for a small-scale use case. It's easy to maintain and deploy, and the UA interface is simple. JBoss is more appropriate for large industries. Though it is complex to maintain, JBoss is well balanced and can handle larger loads.

We used JBoss as our application server on the recommendation of the lead developer. JBoss's compatibility with Java EE, modularity, and support for clustering met the diverse needs of our applications. The management console and developer-friendly features simplify configuration and maintenance. JBoss provided a reliable and efficient runtime environment for our Java-based applications.

The most valuable thing about JBoss is how easy it is to install and manage it on-premise, making the process simple. The application setup is neat and easy to follow. Although we used to manually check log files, integrating a monitoring tool later on improved efficiency. Overall, JBoss is user-friendly and adapts well to changing monitoring requirements.

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.

I used JBoss for a previous project at my company.

JBoss stability depends on the administrator's familiarity with adjusting Java's memory settings. If you're not familiar with it, the application might not be very stable. But once you understand how to allocate the necessary memory, JBoss runs reliably.

JBoss is scalable. It supports configuring both load-balanced and clustered architectures, enabling scalability for the applications it hosts. Approximately 5,000 people used it at our company.

It takes less than an hour to deploy JBoss. Deploying it was a bit manual. We downloaded JAR files from the JBoss community edition website, ran a script on Linux, and manually copied and configured the Java application using the provided templates. It worked, but the process could have been smoother, especially compared to modern containerized deployment methods. Three lead engineers were responsible for setting up and maintaining the application servers.

We didn't pay for a license because we used the JBoss community edition, which is free.

I would recommend JBoss to others. Overall, I would rate it as a 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 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.

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.

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.