Is WebBeans and JBAS 5.1 Production Ready?

[meetoblivion]

I guess it's pretty obligatory to ask, but in other peoples' opinions, is web beans ready for the real world? Can we, or even should we, deploy a production ready application that uses webbeans as its DI framework?

I ask for two reasons.

1. we have buy in from a business user to deploy a new simple app for image management for our ecomm platform.  I chose to go w/ JSF, and decided on using webbeans to simplify the programming model.  The management app is only expected to be deployed to a couple of internal users (figure no more than 5), but the public side (which also uses WB) is going to be completely public.  This is just a simple servlet w/ rewrite capabilities to some vendor software that we have from many years ago; to give us some shorter url's for the images.  There's easier ways I'm sure, like a filter, but I chose to not throw it into the vendor's stuff.  The hardware's going to be pretty beefy boxes, 2x IBM 3550's w/ SLES 10.2 HA Clustering and JBAS5.1 in the standard all deployment, with some other apps running on them as well.

2. I have an issue open in JIRA, that apparently is now in the JBAS queue.  JBAS-7032 When I deploy an EAR that's structured like: EJB, WAR or EJB, WAR, WAR with no classes in WAR (and WAR may reference a Servlet in the in EJB), emb jopr gets knocked out.  seems to happen even when i move the web only classes into the war.  Both/all 3 have beans.xml in them.  This issue doesn't concern me much because we don't expect to use the console much, but I can see our WSA's raising a flag on it.

[gavin.king]

I would say you are pretty safe, assuming that:

• you've done some prototyping and verified that the Web Beans preview has all the features you need, and


• you are going to write good tests for your own application.

The nature of this kind of software is that if it's going to break, it breaks well before you go into production. So as long us you don't deploy untested code, you're safe.

However, there are definitely bugs in the Web Beans preview, and the spec has definitely changed since it was released. So you should go in expecting to run into things that aren't perfect.

Therefore, if you want to be absolutely sure, you should wait for JBoss 5.2, which will feature a totally production ready implementation of 299.

Currently we target 5.2 for September, but I imagine that it could be a month or so late.

[meetoblivion]

my main production-type issue is probably performance.  i figure since most things are going to be bound in JNDI there's not much of a bottleneck in a map.  we're expecting it to hit QA early next week and spend about 4 days there.

should i be concerned much about my JBAS issue?

[gavin.king]

John Ament wrote on Jun 19, 2009 02:43:


my main production-type issue is probably performance.

we're expecting it to hit QA early next week and spend about 4 days there.

Then you will soon know if you have an issue. Seriously, the likelihood that Web Beans would be your performance bottleneck seems incredibly remote.

should i be concerned much about my JBAS issue?

Um only you can tell us that. Does your app work?

[asookazian]

Gavin King wrote on Jun 19, 2009 03:11:


Seriously, the likelihood that Web Beans would be your performance bottleneck seems incredibly remote.

Typically the db/data tier is the performance bottleneck in most CRUD apps.

But has the significant overhead involved with Seam's injection/interceptors been optimized in Web Beans' DI?

Why inject all context variables for every business method in a component if you really only need one of them injected for a particular public method, for instance?  This should be configurable...

[pmuir]

John Jameson wrote on Jul 08, 2009 01:10:

Gavin King wrote on Jun 19, 2009 03:11:


Seriously, the likelihood that Web Beans would be your performance bottleneck seems incredibly remote.

But has the significant overhead involved with Seam's injection/interceptors been optimized in Web Beans' DI?

Yes it has, injection occurs at object instantiation only.