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

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.'"

Comments

"The JBoss Application Server is now more."

[Cammi]

Umm .... what?

Re:"The JBoss Application Server is now more."

[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:"The JBoss Application Server is now more."

[Anonymous Coward]

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

Re:"The JBoss Application Server is now more."

[VortexCortex]

"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:"The JBoss Application Server is now more."

[Anonymous Coward]

Wrong. Red Hat is developing the new release in partnership with DuPont aka E. I. du Pont de Nemours.

Re:"The JBoss Application Server is now more."

[Anonymous Coward]

Wrong, its "noir moore", a retelling of the James Bond universe in 40's noire format.

Re:"The JBoss Application Server is now more."

[Local ID10T]

Wrong, its "noir moore", a retelling of the James Bond universe in 40's noire format.

That actually sounds interesting...

Re:"The JBoss Application Server is now more."

[fnj]

They must mean "no more".

Re:"The JBoss Application Server is now more."

[Jane Q. Public]

"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."

[Anonymous Coward]

No no, it's no Moiré. All those damn interference patterns have finally been cleared up.

Re:"The JBoss Application Server is now more."

[Anonymous Coward]

Hah hah. But the word on Twitter is that announcement is refers to Nomar Garciaparra, who's been tinkering with open source software since his days as shortstop for the Red Sox and Dodgers.

JAVA !! WE OWN THE WORLD !! AND YOU !!

[Anonymous Coward]

Thanks Java, for letting so many own so many !!

The World

should be ' no more'

[Anonymous Coward]

make more sense as: The JBoss Application Server is no more. But as "...now more" works too. It means that the project now 'more' because it will benefit from an unleashed community.

Huh?

[Anonymous Coward]

"What we wanted to do was cement the idea that JBoss is a portfolio of middleware products and not just the application server."

Can anyone translate that statement from Bullshitspeak to English?

Re:Huh?

[IMightB]

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:Huh?

[Anonymous Coward]

What bullshit speak? Sounds pretty straightforward to me. They want you to think of middleware when you hear JBoss, not just an application server. Not sure how it could get any clearer than that.

Re:Huh?

[HiThere]

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 upon projects managed by Red Hat.)

OTOH, I'm not a Java user anyway, so this doesn't directly impact me. Perhaps those more involved with JBoss could offer a better explanation. But it would be difficult to offer one that didn't say that this demonstrated Red Hat exerting unilateral control over JBoss. (Unless, of course, the summary has been written in a horribly biased way.)

Re:Huh?

[Anonymous Coward]

You see, there are those of us who run these machines, let's call them servers. We make sure that anything that runs on it is going smoothly and resources are well assigned.

It can happen that we, who run these "servers", are unfamiliar with the terminology used by business wankers who have no idea of resource limits or how a server operates and who expect to be able to just dump some giant turd on it and have it run.

I just stick to Tomcat

[roman_mir]

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:I just stick to Tomcat

[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.

Re:I just stick to Tomcat

[roman_mir]

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:I just stick to Tomcat

[Kenneth Stephen]

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 projects don't require an architect. 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, and thats where an exclusively specialist team often doesn't deliver what the customer needs.

To draw an analogy, one can have a jam session with a handful of musicians, without requiring a conductor. But if you have hundreds of musicians (like an orchestra does), a conductor is required to deliver a quality performance.

Why is this relevant to your post? Simply put, it is easy to work without EJB's or other aspects of JEE and implement everything a servlet container. But when it gets to big applications, and you are architecting an application, JEE makes it so much easier to deliver quality.

Re:I just stick to Tomcat

[Bill, Shooter of Bul]

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:I just stick to Tomcat

[roman_mir]

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:I just stick to Tomcat

[Kenneth Stephen]

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:I just stick to Tomcat

[theshowmecanuck]

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 integrating with other systems if needed. Even in smaller applications this is important. If you can't think like an architect, you won't be able to write this kind of code.

Re:I just stick to Tomcat

[Bill, Shooter of Bul]

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" applications that I don't understand.

Re:I just stick to Tomcat

[Anonymous Coward]

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.

well it's how many layers it has. the more layers, the more you can bill. that's why EE lives. that's how anything is complex and how you can get to a point where a freshly rolled out electronic prescription system needs one and a half years of work and couple of million euros to change a text field from 100 characters to 1000. because while the "enter-price" system is supposed to make things more flexible, it doesn't.

Re:I just stick to Tomcat

[roman_mir]

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 have to scale it, in what sense is it going to be scalable.

Your idea is the exact backward idea that if somebody is trying to architecture something, they have to go the specific predetermined J2EE way. In reality what you end up with is a very rigid construct that is less likely to be scalable and maintainable than an application that is in fact designed with the context of the application in mind.

J2EE is basically a copying machine, it doesn't require architectural skills at all, that's the point of it.

Re:I just stick to Tomcat

[roman_mir]

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 doing is replicating the entire application across a set of servers and pushing the session objects into every node, that's the gist of their ability to 'scale'. It only scales vertically, it misses what ideas like MapReduce provide (for example), horizontal scalability.

Also J2EE recycles the same approach to data treatment from project to project, so everything is as slow as the slowest data access component (so they insert more and more layers between their entity beans and the physical database in hope they'll boost the performance) and in reality in most cases what is needed is an actual architectural solution that takes into account the specifics of the business problem, but that is completely avoided, totally neglected by the so called 'architects' that stick to the cut and paste J2EE paradigm. They completely forgot (if they ever knew) what the hell architect is supposed to do in the first place.

This is by the way how big shops like Oracle end up charging even more money by breaking the legs of the architectural team and then handing them yet another crutch, something like AquaLogic Data Services (Oracle Data Services now).

Today you can take a look at any so called 'enterprise' application and see tons and tons and tons of 'infrastructure' and almost no actual logic and in reality everything is just data in a database somewhere, and all the layers of manipulations and transformations are supposedly designed to 'scale' and in fact they are the bottleneck, they are the reason that the systems are slow.

But hey, it's enterprise, so you can always rely on the idiots that buy it to throw more money at the hardware when this shit inevitably grinds to a halt.

Re:I just stick to Tomcat

[Bill, Shooter of Bul]

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:I just stick to Tomcat

[Anonymous Coward]

The grandparent simply does not understand JEE. Actually, in my career I have met very few people that really do understand JEE (there are a lot of idiots - as grandparent calls them - in JEE, but also in general in the Java world). However, there is a reason for its existence. It is definitely not the right technology for all use cases, and the full JEE is only relevant in an "Enterprise" environment. The things that you use on a Tomcat server (if you do it well) are basically a subset from the JEE technology.

In the first place, JEE is a set of standards, a set of specifications, a set of APIs that offer a whole range of functionality. An example of this is the servlet specification: a certain version of the spec specifies which methods/interfaces must be available in the application server for a given web application. For example Tomcat implements that spec, and if you go check the features, you will notice that each version of Tomcat supports a specific version of the servlet specification. Another example are the APIs, like JPA: the Java Persistence API. The JPA is only an API: it specifies a bunch of functionality that must be available to implement the persistence layer of your application. An application server that supports the JPA API must internally implement that API. Of course, it is also possible to take a library like Hibernate or OpenJPA that implements that API and bundle it with your application (I do not consider this good practice though). Other examples of APIs are: JAXB (Java Binding api, to support serialization), JAX-RS (api to support REST services), JTA (support for transactions), JMS (Java Message Queues). The Java EE spec defines a bunch more of those APIs.

So, the full Java EE spec (e.g., JEE5, JEE6 and the upcoming JEE7) is basically a bundle of specifications to support different kinds of areas that are needed in an enterprise environment. An application server is basically an environment to run JEE applications, and offers an implementation of all those APIs to the JEE application. A JEE application server can be certified to implement a specific version of the Java EE spec, and this certification provides some guarantee that the application implements the spec properly. So the idea behind this is that all web applications are written according to the specs defined in the Java EE spec. That means that the packaged web application could be deployed on any application server that implements that Java EE spec. (at least, in theory; in practice, there might be some bumps because of implementation differences in those application servers)

(Note that the full Java EE spec is quite large since up to Java EE 6 nothing was ever dropped from the spec. However, starting with JEE6 something called "profiles" has been introduced: a profile indicates a subset of the full Java EE spec. So it's possible to create -and certify- an application server that only supports e.g. the web profile of JEE6, which is mainly focused on standard web applications.)

Why is there so much hate against Java EE? Well, the older versions of the Java EE standard (everything before JEE5), required a lot of repetitive boilerplate code, a lot of layering and a lot of xml configuration for a full Java EE application. However since the JEE5 version, a lot of effort was put into relying much more on configuration by convention, and into using annotations (also injection -CDI- was introduced). Since JEE5 a lot less code is required for making similar applications compared to older versions of the standard.

The grandparent is right that in some way the full Java EE spec puts all web applications into a similar shape. He is also right, that this does not give you the most performant application, that it also does not give you the most elegant solution, and that it might not give you the most scalable solution. In addition to that, every part in the Java EE spec must be approved by committee, so it really does take a while before things like NoSQL databases are supported in the standard. So, it also mea

Re:I just stick to Tomcat

[roman_mir]

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 previous projects.

There is nothing about J2EE or any other set of crutches sold by various tool companies out there that make it any less complex to integrate systems together, in fact whatever needs to be done to integrate components and projects within complex 'enterprise' infrastructure is often more convoluted and complicated than it needs to be and on the background it just uses some Free source library that may, for example, turn some silly Java beans into a set of XML documents with a factory provided by a library that would reflect and instantiate some objects.

A proper architect would put together a solution that only has what is minimally required at any point of time to achieve the current objective. All other considerations are moot, since it's an 'enterprise' environment, every project will have to take care of its own integration and once that is done, the same path can be followed by other projects that may come in later.

Re:I just stick to Tomcat

[Anonymous Coward]

An enterprise solution should be documented well enough for other projects to extend it and integrate with it.

Sure, we all know how well that works.

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 previous projects.

Obviously you do not work in the same environments I work in. The clients I work for, work with several external parties, not only one, and getting access to people or documentation from previous projects is not easy, if at all possible.

There is nothing about J2EE or any other set of crutches sold by various tool companies out there that make it any less complex to integrate systems together, in fact whatever needs to be done to integrate components and projects within complex 'enterprise' infrastructure is often more convoluted and complicated than it needs to be and on the background it just uses some Free source library that may, for example, turn some silly Java beans into a set of XML documents with a factory provided by a library that would reflect and instantiate some objects.

Sure. Whatever. Although I do agree with the point that a lot of the enterprise stuff is often more convoluted and complicated than it needs to be. And that was a bigger problem with the old J2EE versions, but got a lot better starting with JEE5.You keep on refering to it as J2EE. The last J2EE version is the 1.4 version from 2003. That's 10 years ago. It evolved since then.

A proper architect would put together a solution that only has what is minimally required at any point of time to achieve the current objective. All other considerations are moot, since it's an 'enterprise' environment, every project will have to take care of its own integration and once that is done, the same path can be followed by other projects that may come in later.

Sure, we all know how that works: every architect thinks that his solution for integration is the best and the "proper" way, and you end up with a mix. Either way.. I do realize that a lot of people in the Java world feel the same way like you do about Java EE. I think the recent versions don't deserve the bad name from the older J2EE versions. And in a lot of situations there is simply no need for the full Java EE stack.

Re:I just stick to Tomcat

[roman_mir]

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 J2EE solution is preferable, and it's not. There is nothing preferable about it, if you are providing web services nobody on the other side cares what servlet container, what application server, whatever the hell you are using, as long as you are providing the APIs that expose business functionality they need and that is all it is.

It is all about functionality and the integration, and J2EE or JEE5 or anything for that matter is not a substitute at all for an actual document describing behaviour of a the system and the proper API calls that invoke that behaviour.

If your complaint is that you can't get documentation and knowledge passed from one project to another, and simultaneously you are complaining about lack of standards between project teams because you can't rely on your architects to have standards, then you are making my point exactly: J2EE is a crutch that is used to replace an actual architectural thought.

Without documentation and without passing knowledge from one project to the next all you have is the code and the user base to ask them what the code may be doing. If all you have is the code and the user base and no documentation and nobody who worked on other projects can tell you anything then your idea of 'enterprise' is quite disjointed. What is it, a disjointed set of things that happen in vacuum without any thought or standard of implementing a product?

Maybe you should be thinking about that first of all, while you are going through the code, and whatever the code is, whatever the container is around the code, without documentation on use cases, business requirements and system testing you are not better off just because there are some EJBs thrown into the mix.

You can't deduce the actual workings of the code by a cursory observation of its container.

You can't assume that the exposed APIs, be they web services calls or anything for that matter even will do what something that their names suggest (and nothing else or anything at all).

Enterprise systems more than anything require documentation, the technology underneath is irrelevant, it's the approach that is enterprise, not the tech.

This is perfect example...

[Parker Lewis]

... 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.

Jboss != Jboss AS != WildFly

[cuby]

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.