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.'"
"The JBoss Application Server is now more." (Score:3, Funny)
Re: (Score:1)
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)
That's ridiculous. Obviously they mean "now moor." As in, it's a Muslim invader of Spain a millennium ago.
Re: (Score:3)
Wrong, its "noir moore", a retelling of the James Bond universe in 40's noire format.
That actually sounds interesting...
Re: (Score:2)
"That actually sounds interesting..."
No, no no. It's "Nieu Moore". Michael's having a fat little baby.
Re: "The JBoss Application Server is now more." (Score:1)
No no, it's no Moiré. All those damn interference patterns have finally been cleared up.
Re: (Score:3)
"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.
Re: (Score:2)
They must mean "no more".
Re: (Score:3, Insightful)
Here's how I understand it. Tomcat would be "just an application server" stuff that runs on top of tomcat would be the middleware. So JBOSS includes a application server and a bunch of other useful stuff. JBOSS is/used to be a pay-redhat to use it, and therefore never really gained a big community. Redhat is just renaming it and releasing it to the Fedora community in hopes that it gains more users and therefore should translate into pay-redhat for support.
Re: (Score:2)
Well, as I understand it (uncertainly) this is saying that they want to make the application previously known as JBoss more specific to Red Hat products.
I've got a lot of uncertainty that that's actually what they were saying. They might have just been putting everyone on notice that they had control of it, and could do what they want.
In any case, it results in my being less willing to trust Red Hat to manage projects that I depend upon. (Or, to put it more correctly, it makes me less willing to depend upo
I just stick to Tomcat (Score:2)
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.
Re: (Score:1)
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.
Re: (Score:1)
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.
Re: (Score:2)
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
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
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
Re: (Score:2)
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
Re: (Score:2)
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.
Re: (Score:1)
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
Re: (Score:1)
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
Re: (Score:1)
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.
Re: (Score:2)
And this is not you:
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
Re: (Score:1)
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
This is perfect example... (Score:1)
Jboss != Jboss AS != WildFly (Score:4, Interesting)
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.