Skip navigation

With the addition of annotations in JDK 5 and EJB3 in J2EE, I think we have an opportunity to totally ditch XML-based configuration. This includes EJB deployment descriptors and XML-based IoC "lightweight" containers. So how will you do fine-grain configuration of your components? How will you do the Inversion of Control that you-all just can't live without? This is what I want to talk about in this blog.

The Pico Container/Nanning guys put out an interesting concept awhile ago. Why do you have to use XML to configure your components/interceptors/aspects? Why not configure your services and components within pure Java? Configuring things in pure Java allows you to let the Java compiler typecheck your configuration. Sometimes, with XML you have to wait until deploy time/runtime to see if your XML document is valid. This kind of pure-Java-configuration can be done using EJB3 with inheritance, constructors, method overrides, and annotations.


Plain classes as base

The key is to model your beans as plain classes at first. These plain classes will be the base for all your service beans. Let's define a Stateless Bean that is will be used to confirm orders in an e-commerce application via email.



public interface OrderConfirmation {

   public void sendOrderConfirmation(String to, Order order);




public class OrderConfirmationService implements OrderConfirmation


   private String from;

   private String subject;

   private MessageStyle style;

   private javax.mail.Session mailer;


   public (String from, String subject, MessageStyle style) {

      this.from = from;

      this.subject = subject; = style;




   public void setMailer(Session session) {

      this.mailer = session;






   public void sendOrderConfirmation(Order order) {

      Message msg = createMessage(mailer, style, 

                                    from, subject, order);





   private static createMessage(...) {...}



So above we have a security constraint set on our bean method and 4 configurable properties.

  • From and subject are self-explanatory.
  • style is a pojo that defines how our email message will look.
  • mailer is a reference to our Mail session. A reference to a service


Configuring with Inheritance

In this example, we are defining a stateless bean for order confirmation for each one of the business units of our e-commerce application. We will use constructors and method overrides to modify the configuration.



public class ToyStoreOrderConfirmationBean extends OrderConfirmationService


   public ToyStoreOrderConfirmationBean() {


             "Your Toy Order Confirmation",

                new ToyStoreMessageStyle());




   public void setMailer(Session session) {





   public void sendOrderConfirmation(Order order) {





So, the constructor is used to set the configurable objects. We override the setMailer method and inject the Mail Service via the EJB3 @Inject annotation. We only allow "ValuedCustomer"s to get an email confirmation by overriding sendOrderConfirmation and retagging it with a new @MethodPermission.



Ok, so I lied...So you can't use this approach for everything. Here's some example:
  • You can't use this approach for Entity beans. Entity beans are POJOs in EJB3 and must be allocated with with the new operator. So, if you need to override persistence mappings per deployment, you'll have to use XML.
  • There's really no standard way of configuring domain objects like MessageStyles and sharing this standard configuration between various components.

Anyways, that's it for now...

Happy hunting,



I'd like to elaborate on Anil's blog post about JBoss' new Web Services stack and why we went this route instead of Apache AXIS.


More than a year ago, JBoss licensed the J2EE TCK from Sun to get JBoss ceritified. Web Services is an integral part of the J2EE 1.4 specification. At about this same time, the AXIS project was in flux because IBM had forked AXIS for their own proprietary products and left AXIS development entirely. We needed a compliant web services implementation immediately and AXIS 1.1 and 1.2 just wasn't even close to compliance, so we decided to fork AXIS 1.1 (the 1.2 branch was really unstable at the time). After we had passed certification, we did not officially give the code back to the AXIS project, but it remained ASL licensed so its there for the taking if Apache is interested. Since then, we decided to ramp up our own webservices team and create our own stack. This effort is well underway.


Personally, I'm glad this happened. I feel that the LGPL license and JBoss brand will do a much better job at holding our web services community together. As Anil said, Thomas Diesler will be giving a presentation at JBossWorld on our new Web Services stack.


Happy Hunting


JBoss AOP 1.1 Released

Posted by bill.burke Jan 21, 2005
JBoss AOP 1.1 has been released. A lot of bug fixes and features have been added since the 1.0 release. See the release notes below for more detail.


Over the past week, I implemented a prototype of Transaction Recovery for our transaction manager. It is probably a bit naive and doesn't perform very well, but it does seem to work with my very minimal testing. We're looking for somebody to drive this, so if you, dear reader, are interested, let us know.


More information can be found here on our JTA TX Recovery WIKI page.


How's this for irony though? Tuesday night I was finishing up the impl of the prototype when my laptop crashed with the blue-screen-of-death. It took me about 4 hours to get my laptop up long enough to recover the work I had done on TX Recovery. It would have been even more ironic if I wasn't able to recover the code. After a wasted day of setting up email and a development environment on one of my desktops, I'm finally back to being productive.


Happing Hunting,



Filter Blog

By date: