Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
Java Red Hat Software Software IT

Red Hat 'Fedora-izes' JBoss With New WildFly Java Application Server 40

darthcamaro writes "The JBoss Application Server is no more. Just like Red Hat killed Red Hat Linux in 2003 to make way for Fedora, the same is now happening with JBoss and the new WildFly project. 'There was of course the application server, there are a number of JBoss commercial products, there was the community site, etc., so when you asked someone "What is JBoss?" the answer was varied,' Jason Andersen, director, product line management, at Red Hat, explained. 'What we wanted to do was cement the idea that JBoss is a portfolio of middleware products and not just the application server.'"
This discussion has been archived. No new comments can be posted.

Red Hat 'Fedora-izes' JBoss With New WildFly Java Application Server

Comments Filter:
  • by Cammi ( 1956130 ) on Friday April 19, 2013 @07:39PM (#43499577)
    Umm .... what?
    • by Anonymous Coward

      I think they mean "know more". As in, the JBoss Application Server is know more. Long live the Gnu/Linux WildFly Application Suite Formerly Non as JBOSS. (Non is pronounced 'known'). Hope that clears it up.

      • Re: (Score:2, Funny)

        by Anonymous Coward

        That's ridiculous. Obviously they mean "now moor." As in, it's a Muslim invader of Spain a millennium ago.

    • "JBoss Application Server is now more."
      It means the price went up. Unsurprisingly since it has to do with 'Enterprise' -- That means two things at once: Expensive and Fantasy Utopia that is every nerd's dream.

    • by fnj ( 64210 )

      They must mean "no more".

  • I stick to Tomcat, never mind EJBs, don't need them. The fewer components and compilation steps the better AFAIC. You have to choose what to use for a connection pool and have a good grip on your own transaction handling of-course, but that's really not a problem, it's blown out of proportion.

    • by Anonymous Coward

      I stick to Tomcat, never mind EJBs, don't need them. The fewer components and compilation steps the better AFAIC. You have to choose what to use for a connection pool and have a good grip on your own transaction handling of-course, but that's really not a problem, it's blown out of proportion.

      [Professional Java EE dev]

      Tomcat is great if you've just got one or a couple of websites, but when you've an enterprise with multiple points-of-access (websites, APIs, tills, manual entry, etc), the convenience and flexibility offered by an EE system are simply unmatched.

      • I disagree, I actually built an EJB container long ago, so no lack of understanding of what that is, however AFAIC it is all about truly architecting a solution that fits the purpose, the 'one size fit all' ideology of EJBs is fine of-course, for 'enterprise', which is synonymous with 'no original thought is allowed', but if you want an actual good solution you don't do it this way.

        • Building an application server requires a different skillset and mindset than building an application does. Being a specialist in a product / technology is a wonderful achievement, and will make you very good at implementing designs. However, putting together the design and looking at the bigger pictures and making sure that the system works well together, and addresses maintainability, scalability, performance constraints, and reliability concerns requires the mindset and skill of an architect. Most small

          • If you wouldn't mind indulging my curiosity, what metrics would you look at to determine "how big" an application is? Cost can't be the sole factor.

            • Its generally the complexity of the requirements that makes something big or small. You're right - cost may not mean "big". For example, specialist skills like SAP or the latest buzzword technology can drive up the cost because its costs more to staff those developers. In general though, the more complex the requirements, the more it costs to develop the application.

              • So Java EE, and hence an Architect, are required for applications with complex requirements.

                I have to admit, the Enterprise is very foreign to me. I've always heard about things required "for Enterprise", but the concept is pretty nebulous. I used to mean that meant scaling only. Look at what modern large internet companies have achieved on a shoe string budget and with open source, I doubt that any of them have any "Enterprise" software at their core. So, I think there must be more to "Enterprise" applic

                • Don't pay attention to that, J2EE is a crutch, it is an attempt to replace an actual architectural thought with a copy paste solution. It's not worth the trouble, it creates more problems than it solves and it forces people into a rigid pattern of thought that does not actually allow them to look at the real business problem they are trying to solve. The architect is reduced to a typist with J2EE, every step is predetermined, the so called 'scalability' is not in fact achieved, the only they it ends up do

                  • That's what the cynic in me thinks. However,I still have this slim hope that some people actually have some higher reasons for all the infrastructure.

                    • Let me cut through the thick layers of bullcrap.

                      The difference between 'enterprise' and anything else is .... money that will be spent, nothing else.

                      An enterprise solution should be documented well enough for other projects to extend it and integrate with it. The server infrastructure does not make it easier to integrate two solutions together than would any API that is just as documented, the teams that work on different projects do not work in vacuum, they have access to people and or documentation from

                    • Saying that you are working in a shop different from mine... obviously. Yet I worked for large communication companies, banks, insurance companies, mid sized manufacturer, utilities, and some others as a contractor. Today I build my own software and sell it to retail chains.

                      Saying that your shop is different because they work with several external parties... first of all it's hilarious that you believe only you work with people that work with other people.

                      Secondly this does nothing at all to show how a J2

          • Yes, and I spent years building applications that used various types of servers and as I said, after about a decade of that I prefer Tomcat.

            • So what you are saying is that this is you:

              Being a specialist in a product / technology is a wonderful achievement

              And this is not you:

              When you get work at an enterprise level - when building an application costs (development costs only - not deployment, hosting, or operational costs) million+ dollars, you need an architect

              Even in application developers, I prefer someone who can think like an architect. They will produce more robust code that lasts/is relevant longer, that is more extensible and capable of

              • But when it gets to big applications, and you are architecting an application, JEE makes it so much easier to deliver quality.

                - this is just a false statement, that's why you are confused.

                It is easy to deliver the same shit over and over with J2EE, that is true, however there is much LESS architectural thought going into designing applications that follow exactly the same predetermined path because of the constraints, limits and specific requirements of the J2EE paradigm than if you actually throw away that crutch and start thinking about the real problem at hand, what is the application you are building, how exactly will you hav

  • ... of a bad summary: do not explain what will be the "fedorization" process, do not explain why "JBoss is no more", and in the middle change to try describe what is JBoss.
  • by cuby ( 832037 ) on Saturday April 20, 2013 @11:25AM (#43503785)
    JBoss started as a Java application server (AS). At some point it got much bigger and now is more like the Apache community. Lots of projects like Hibernate and Infinispan are part of it.
    In the AS side of things, there were already 2 kinds of releases. Like Fedora, you have the 6 months(?) releases supported by the community and then, from time to time, you get the stable Red Hat EL to be used by clients with support contracts. WildFly will be much like fedora in this sense. Jboss AS will continue for the ones with support contract. Until now, if you used JBoss in a serious task, there was almost no difference in the quality between paid and unpaid versions, from now on, I think it will be a different story.

Nothing makes a person more productive than the last minute.