Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

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

timothy posted about a year ago | from the estrangeder-and-estrangeder dept.

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

cancel ×

40 comments

"The JBoss Application Server is now more." (3, Funny)

Cammi (1956130) | about a year ago | (#43499577)

Umm .... what?

Re:"The JBoss Application Server is now more." (1)

Anonymous Coward | about a year ago | (#43499611)

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." (2, Funny)

Anonymous Coward | about a year ago | (#43499633)

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." (0)

Anonymous Coward | about a year ago | (#43499715)

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." (0)

Anonymous Coward | about a year ago | (#43499727)

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

Re:"The JBoss Application Server is now more." (2)

Local ID10T (790134) | about a year ago | (#43499903)

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." (1)

Jane Q. Public (1010737) | about a year ago | (#43501369)

"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." (1)

Anonymous Coward | about a year ago | (#43501785)

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

Re:"The JBoss Application Server is now more." (0)

Anonymous Coward | about a year ago | (#43503381)

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.

Re:"The JBoss Application Server is now more." (2)

VortexCortex (1117377) | about a year ago | (#43499663)

"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." (1)

fnj (64210) | about a year ago | (#43500295)

They must mean "no more".

JAVA !! WE OWN THE WORLD !! AND YOU !! (0)

Anonymous Coward | about a year ago | (#43499653)

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

The World

YUo FAIL IT.. (-1)

Anonymous Coward | about a year ago | (#43499739)

sux0r status, *BSD all servers. Coming fucking confirmed: (Click Here show that FreeBSD code sharing the gay niggers it there. Bring Those uber-aashole

should be ' no more' (0)

Anonymous Coward | about a year ago | (#43499835)

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.

NORTH KOREA'S KIM THROWS TANTRUM !! (-1, Offtopic)

Anonymous Coward | about a year ago | (#43499859)

The illustrious leader has thrown a tantrum over the lack of coverage of his ... uh, hmm, bomb. CNN reports. "We can sell more advertising covering the Boston bombers 24/7. North Korea needs to step up its efforts if it wants to compete."

this is a good news (1)

Hoolang (1946568) | about a year ago | (#43500727)

Java become more and more popular converse shoes [canvasshoes4u.com]

Huh? (0)

Anonymous Coward | about a year ago | (#43501373)

"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? (2, Insightful)

IMightB (533307) | about a year ago | (#43501723)

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? (0)

Anonymous Coward | about a year ago | (#43502077)

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? (0)

Anonymous Coward | about a year ago | (#43505707)

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.

Re:Huh? (1)

HiThere (15173) | about a year ago | (#43504891)

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

I just stick to Tomcat (2)

roman_mir (125474) | about a year ago | (#43502059)

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 (1)

Anonymous Coward | about a year ago | (#43502437)

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 (1)

roman_mir (125474) | about a year ago | (#43502515)

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 (1)

Kenneth Stephen (1950) | about a year ago | (#43503031)

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 (1)

Bill, Shooter of Bul (629286) | about a year ago | (#43503245)

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 (1)

Kenneth Stephen (1950) | about a year ago | (#43503713)

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 (1)

Bill, Shooter of Bul (629286) | about a year ago | (#43504505)

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 (2)

roman_mir (125474) | about a year ago | (#43505149)

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 (1)

Bill, Shooter of Bul (629286) | about a year ago | (#43506691)

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 (0)

Anonymous Coward | about a year ago | (#43508669)

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 means you cannot always play with the newest technology.

Now take a step back and think about an enterprise environment. An enterprise environment means that there are a bunch of web applications, a bunch of services that are delivered by those same web applications. It also means that there is a seperate team that deploys new versions of those applications on the production systems. When a new application must be created in that environment, there are more important considerations than pure performance.

The new application must have a deployment procedure that is very similar to other existing applications: pure Java EE allows the system administrator that deploys the application to specify all required dependencies (database connections, message queues, remote EJB services, ...) at deployment time. In an enterprise setting, this is a requirement because the production environment is completely separate from the test environment, and only system adminstrators have the rights to access the production environment.

When the new application depends on existing services, it is important that it integrates in the same manner with those existing services as the other applications. Consider for example distributed transactions: it is not easy to get this right, and this is something that needs to be supported by the application server itself to get completely right.

It is possible that at some point in the future, other applications start to depend on the functionality provided by the new application. At that point it must be possible to make some functionality of the new application available to other applications. This might include opening up functionality that must enlist in existing transactions started by the caller. It is also important that this is implemented in a similar way as the other applications. (The easy way is to let the other application go straight to the database, but this is not good practice: for maintainability, you really want to offer a remote API through the use of EJBs - enterprise java beans)

The reason that it is important that all those things are implemented in a similar way, is because there is a separate support team that will provide the maintenance of those applications after the initial release. When all applications are built to a similar shape, this will make maintenance a lot... a lot.. easier.

In an enterprise environment, one will typically also standardize on a specific version of a specific application server for applications that require a specific version of the Java EE spec. In that context, it is also import that web applications to not bundle their own versions of the API implementations for stuff that is out-of-the-box offered by the application server: this allows the enterprise to standardize on 1 specific version so that maintenance is once again easier. (e.g. bug with the JPA implementation can be solved through upgrading the deployed application servers, instead of upgrading each one of the deployed web applications)

As to being scalable: most application servers support scaling out-of-the-box. That means that it's possible to set up a cluster of application servers and the web application can fairly easily be clustered over a cluster of machines. If the web application adheres to the JEE standard, this can easily be done at deployment time, and makes it mainly a deployment issue. This is both valid for the web applications themselves, as for the remote EJB services.

I hope this makes everything a bit clearer. In an enterprise environment it's important that all applications are as uniform as possible regarding deployment and all. Of course it will not give you the most performant application, and it will not give you the most elegant and simple code. On the other hand, do not think that all JEE applications are slow memory hungry monsters. It is not difficult to build very performant JEE applications, but that mainly depends on the capabilities of the developer, and sadly there are very few (very) good developers. Aside from that, in my opinion most Java developers think of databases as dumb data stores, and this mindset often results in bad performance of the persistence layer. (That is why there is also currently some kind of move to try to throw everything in a data store --and forget about ACID--; In my opinion, when care is taken about database performance during the development of the application, there are very few use cases where performance of a real database is actually a problem.) By keeping an eye on the performance of the database during development, it is really not that difficult to build performant applications.

(Btw, when referring to the fact that Java EE pushes web applications in a similar model, then that mainly refers to splitting applications in layers which also gives you extra flexibility at deployment. So be clear, it does not directly have an influence on the domain model. It does enforce layering in the sense of: a seperate frontend layer and backend layer, which can be deployed on separate application servers, but also on the same application server. When both are deployed on the same application server, the application server will automatically optimize communication between those sepearate layers to direct local calls.)

Re:I just stick to Tomcat (1)

roman_mir (125474) | about a year ago | (#43515217)

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 (0)

Anonymous Coward | about a year ago | (#43517817)

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 (1)

roman_mir (125474) | about a year ago | (#43522849)

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.

Re:I just stick to Tomcat (0)

Anonymous Coward | about a year ago | (#43504803)

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 (1)

roman_mir (125474) | about a year ago | (#43503279)

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 (1)

theshowmecanuck (703852) | about a year ago | (#43504139)

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 (1)

roman_mir (125474) | about a year ago | (#43505039)

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.

This is perfect example... (1)

Parker Lewis (999165) | about a year ago | (#43503019)

... 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 (3, Interesting)

cuby (832037) | about a year ago | (#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.
Check for New Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...