As with any major refactoring it took a little longer than expected, but now the the final release of JBoss AS 5 is available for download This release marks the end of a 3+ year marathon of redesigning the popular open-source application server over a completely new kernel architecture, the JBoss Microcontainer. Check out the release notes.

When will be a jboss.com release ?

When will be a jboss.com release ?

We're planning to release JBoss EAP (Enterprise App. Platform) 5.0 in the first half of next year - that will include JBoss AS 5.0.0. Rich Sharples JBoss, a division of Red Hat

Thanks for the quick answer. Can you tell me if you plan to backport any of the new features (and/or bug fixes) of AS 5.0.0 to the 4.[23].x branch?

Thanks for the quick answer.

Can you tell me if you plan to backport any of the new features (and/or bug fixes) of AS 5.0.0 to the 4.[23].x branch?

Well appropriate bug fixes would naturally be fixed in both branches. One feature that *might* get ported into EAP 4.3 is the new embedded console : http://www.jboss.org/community/docs/DOC-12807 but that's nothing more than an idea at the moment. Was there anything you had in mind ? - Rich

Thanks for the quick answer.

Can you tell me if you plan to backport any of the new features (and/or bug fixes) of AS 5.0.0 to the 4.[23].x branch?

Well appropriate bug fixes would naturally be fixed in both branches.

One feature that *might* get ported into EAP 4.3 is the new embedded console :

http://www.jboss.org/community/docs/DOC-12807

but that's nothing more than an idea at the moment.

Was there anything you had in mind ?

- Rich

That would be nice too, I was thinking more in adding the bits that provide support for mod_cluster.

Is JBoss even relevant anymore? We are moving off JBoss to a simplified Tomcat and best of breed stack (Spring, ActiveMQ, etc.). Seems like the monolithic JEE container concept is abating. I'd be interested in what others are doing...

Zealous developers who go with Tomcat seem to spend a lot of time integrating extra libraries and features with it. I'm not sure if that's improving their job security or they have lots of free time. And then they still really don't have a very good deployment or management platform for your web application. When it comes to building installations, the less fiddling with the default application server setup the better, especially when introducing new developers and testing. So in this regard I like the JBoss approach to have everything available by default. It's not really "monolithic" in that it integrates pretty well with any other stack and allows you to remove or replace any component or stack if you want.

Zealous developers who go with Tomcat seem to spend a lot of time integrating extra libraries and features with it. I'm not sure if that's improving their job security or they have lots of free time. And then they still really don't have a very good deployment or management platform for your web application.

When it comes to building installations, the less fiddling with the default application server setup the better, especially when introducing new developers and testing. So in this regard I like the JBoss approach to have everything available by default. It's not really "monolithic" in that it integrates pretty well with any other stack and allows you to remove or replace any component or stack if you want.

I completely agree. Glassfish or JBoss are much better than Tomcat.

How could you compare full J2EE servers with Tomcat ? Tomcat is just a servlet engine and don't came with the full J2EE stack (JMS, EJB...) Many companies started with minimal HTTP needs, and used Tomcat for such purposes, do you need a tank to kill a fly ? When come the need of JPA/EJB, some added OpenEJB to serve this need and keeping their current architecture. Developpers wishes are one, but we all know IT/Admins didn't like to change a known architecture, because they are experienced with it. In fine, many companies act as ASP and could have to exploit/admin tens of servers instances on the same physical machines and here memory/cpu resources are very important. I'm very interesting in a minimal JBoss AS 5.0 configuration, it's micro-kernel should help, with just Servlet support, so something very similar to a Stock Tomcat. I'd like to check its memory/cpu usage and start/stop time and see if they could be usefull in my ASP situation with about 50 Tomcat instances on the same physical machine. Link / Wiki welcome

Is JBoss even relevant anymore? We are moving off JBoss to a simplified Tomcat and best of breed stack (Spring, ActiveMQ, etc.). Seems like the monolithic JEE container concept is abating. I'd be interested in what others are doing...

You need to unlearn your previous notions of what constitutes JBossAS. Spring got really popular addressing complexity by ignoring JEE. By contrast, JBoss invested in the standardization process, ultimately simplifying the specifications. So we're proud to deliver an Application Server that's both compliant and built upon a pluggable architecture. Here's some good homework: http://java.dzone.com/articles/a-look-inside-jboss-microconta - Ales' introduction to JBoss MicroContainer, the component framework that transparently binds AS modules. http://www.infoq.com/news/2008/06/jboss-as5-rc1 - Dimitris discusses the overhaul done to make AS agnostic to any particular component model. A great real-world use case is Bob's work over at http://oddthesis.org, where he details the steps he took to add Rails support to AS and get all sorts of enterprise features (eg. clustering) for free in the process. Finally, my work in EJB3 can be summed up: * Get metadata describing a deployment * Make the appropriate EJB containers from the metadata * Rely on other pluggable services for integration (Security, Transactions, JNDI, JPA, etc), as abstracted out by MC. Assuming you don't have code written to JBossAS internals, then you keep your services pluggable elsewhere. That's the opposite of a monolith. S, ALR

Spring got really popular addressing complexity by ignoring JEE.

Actually, I want to clarify this statement; here I was referring to JEE5, which AS5 supports. SS has made contributions to JEE6. S, ALR

Spring got really popular addressing complexity by ignoring JEE.

Actually, I want to clarify this statement; here I was referring to JEE5, which AS5 supports. SS has made contributions to JEE6.

S,
ALR

Yeah, they have...A lot of filibuster.

Here's some good homework:

http://java.dzone.com/articles/a-look-inside-jboss-microconta - Ales' introduction to JBoss MicroContainer, the component framework that transparently binds AS modules.

IMHO , the MicroContainer is the most interesting feature on JbossAS 5. If I correctly understood, using MicroContainer I am able to integrate in only one AS the following: - EJB3 pojos; - Spring pojos; - OSGi modules. Is it correct?

I am able to integrate in only one AS the following:
- EJB3 pojos;
- Spring pojos;
- OSGi modules.

Is it correct?

Yes. MC's components (ControllerContext impls) range from beans (EJB containers are beans), mbeans, aliases to deployments. Since it's a single entry (MC's Controller) that controls them, you can define various dependencies among them. e.g. injection mixture; mbean pojos e.g. deployment depending on a bean & vice-versa

Is JBoss even relevant anymore? We are moving off JBoss to a simplified Tomcat and best of breed stack (Spring, ActiveMQ, etc.). Seems like the monolithic JEE container concept is abating. I'd be interested in what others are doing...

It's interesting how other developer communities all seem to desire exactly the opposite: i.e. instead of cobble-together-your-own-stack they want a pre-integrated full-stack solution. Examples: Ruby on Rails, .Net, Grails, etc. I really don't understand what productivity is gained by having to waste time piecing together all these standard things that everyone needs.

Is JBoss even relevant anymore? We are moving off JBoss to a simplified Tomcat and best of breed stack (Spring, ActiveMQ, etc.). Seems like the monolithic JEE container concept is abating. I'd be interested in what others are doing...

Abating? Could you supply some hard evidence that this is true, instead of just conjecture? Many of the application servers are moving or have moved into a pluggable microkernel style architecture, so customers have flexibility over what they choose to run – which essentially gives them the best of both worlds. The lightweight option as you’ve described, while perfectly acceptable for some projects, is not necessarily good for every business -- especially when cost, support, indemnity, productivity, etc. are at the top of the list of must-haves for the managers responsible for ensuring the project completes on time and contributes some value to the business or the customers that use it.

It's interesting how other developer communities all seem to desire exactly the opposite: i.e. instead of cobble-together-your-own-stack they want a pre-integrated full-stack solution. Examples: Ruby on Rails, .Net, Grails, etc.

I really don't understand what productivity is gained by having to waste time piecing together all these standard things that everyone needs.

I have the same feeling. Some people are making a lot of noise how bad the application server is and how good and wonderful Tomcat is, only to add at least JSF, JPA, JTA, JMS and JavaMail to their Tomcat installation right away. Of course, this means paying the overhead of maintaining all the separate libraries that come with, updating each of those separately, scanning bulletins for critical problems on each of them. Next to that, or rather, before that, comes the process of testing whether some randomly chosen JTA implementation interoperates correctly with the chosen JPA implementation, etc etc. Simply downloading Jboss, Glassfish or Geronimo gives you all of this in a complete single download. Easy to install, easy to maintain, easy to update and more powerful than a custom stack based on Tomcat, which always seems to be missing stuff somewhere.

Gavin,

It's interesting how other developer communities all seem to desire exactly the opposite: i.e. instead of cobble-together-your-own-stack they want a pre-integrated full-stack solution. Examples: Ruby on Rails, .Net, Grails, etc.

Glad you mentioned this. I have had the same observations myself. The clear trends outside Java EE make me think this is a result of bad experiences with early commercial J2EE application servers and consequent Spring "marchitecture" rather than a genuine preference towards more flexibility/greater control... Cheers, Reza

I really don't understand what productivity is gained by having to waste time piecing together all these standard things that everyone needs.

YES, I agree totally with Mr. Gavin King. I have been a J2EE independent consultant/developer for 5 years running, but am NEVER interested in investing my efforts & time learning these pre-integrated stack solutions. Now with Ubuntu Linux, JEE 5, EJB 3.0, JBoss 5.0, PostgreSQL 8.1.3, I already have all I need right under the hood. Cheers.

A truly heartfelt congratulations to the JBoss team on a great job! Rock on, the server-side Java community needs your thought leadership more than ever... So what are the plans around Java EE 5 certification? Also, what about the embedded container? FYI, we will be porting the EJB 3 in Action example code to JBoss 5 ASAP. We currently have example code for JBoss 4.2. Will @EJB work in the Servlet container now? Best regards, Reza

So what are the plans around Java EE 5 certification?

It passes. See release notes.

Also, what about the embedded container?

I know that there has been more internal buzz about it now that AS5 is done. But I'll let those who are working on it leave more detailed comments.

Will @EJB work in the Servlet container now?

Yup. All working. Give it a go. Stan

Also, what about the embedded container?

We're fleshing out how we'd like to proceed. This is a feature strongly desired by the community, and we've noticed. Design discussions are at: http://www.jboss.com/index.html?module=bb&op=viewforum&f=266 S, ALR

:)

What kind of release is this with no supporting documentation? Even the 5.0.0.CR2 documentation links (see http://www.jboss.org/jbossas/docs/) all point to a blank screen that says: "Sorry, you don't have access to this resource" bleh...

If you go from the AS page to the documentation link you end up here: https://www.jboss.org/community/docs/DOC-12898

If you go from the AS page to the documentation link you end up here: https://www.jboss.org/community/docs/DOC-12898

Thanks for the pointer.

Hi, is there a notion of dependent redeployments in jboss 5, finally? I.e. if I have two deployment units, B depending in and using the classes of A and then trigger a redeployment of B, jboss should unload B, then A and then load A and afterwards B again. This would dramatically decrease turn arounds time during development. Regards, Holger

is there a notion of dependent redeployments in jboss 5, finally? I.e. if I have two deployment units, B depending in and using the classes of A and then trigger a redeployment of B, jboss should unload B, then A and then load A and afterwards B again. This would dramatically decrease turn arounds time during development.

B is depending on A, and you re-deploy B. Why should A be unloaded? The other way around makes sense to me, either A is depending on B or you re-deploy A. And the answer is yes. ;-) 1) You can use jboss-classloading.xml to express your class(loading) dependencies. 2) Or you can use jboss-dependency.xml where you define generic dependencies. For 1) check jboss-cl project, it's tests for use cases or JIRA's JBCL-10. Same with 2), but this one is in jboss-deployers project. This wiki page helps a bit: https://www.jboss.org/community/docs/DOC-13178 Check our MC home page for the exact links to source code, JIRAs, user forums, ... If you get stuck, simply post it on the MC user forum, and I'll be glad to help you. ;-)

Hi Ales, JBoss Mc is a great piece of code and seems very interesting, both in JBoss J2EE land but also useable in 'standalone' and custom configuration. The OSGI part in trunk didn't seems up to date with others parts, is it something we could expect some updates soon ? Regards

JBoss Mc is a great piece of code and seems very interesting, both in JBoss J2EE land but also useable in 'standalone' and custom configuration.

Thanks.

The OSGI part in trunk didn't seems up to date with others parts, is it something we could expect some updates soon ?

Like I answered you on the DZone :-), wrt articles, I'll go step by step. The OSGi part in trunk is the OSGi core api facade over MC api. With JBoss5.0.0.GA out, I'll have more time to get back to that code. :-) But you can already use some of the features of OSGi - classloading resolution, contextual services injection. If you go to our MC/OSGi user forum and explain me what exactly you need, I'm sure we can work it out. ;-)

Ups, you're right, I mixed it up .. Thanks for your reply. This is great news! OSBL will switch to JBoss 5 right after its next release! Holger

Congratulations! I'm looking forward to try it out. Alexei.