Skip navigation


The is the EJB 3.0 standalone bundle that comes already embedded with the JBoss 4.0.4.GA AS installer distribution. We have implemented most of the features of the Final Draft of the EJB 3.0 specification. Only a few minor ones remain (shareable resources for instance). This standalone distribution also comes with 3 new tutorials: ssl, entity security, and Quartz MDBs.


EntityManager Security


We've had some EntityManager security based on JACC for awhile, but have kept it secret (in other words, we finally documented it). This new feature allows you to set permissions on CRUD actions on the EntityManager.


Quartz MDBs


We've also implemented a Quartz Scheduler JCA Resource Adapter. This adapter allows you to use JCA Message Inflow to write and configure MDBs that can directly receive Quartz Jobs. These Jobs are configured via the MDB's activation config spec. I'll write a blog about this when I get a chance.


The EJB 3.0 RC7 standalone distribution is only usable with JBoss 4.0.4.GA. The EJB 3.0 implementation that comes packaged with the JBoss 4.0.4.GA installer is the same as the standalone EJB 3.0 RC7 distribution with two exceptions. The standalone distribution has been patched to fix the EJBTHREE-573 JIRA bug. Also the JBoss Remoting jar has been patched to fix the SSL problems in the 4.0.4.GA release. If you don't need these fixes, then installing with the installer is fine.


New EJB 3.0 Book

Posted by bill.burke May 9, 2006


Next week, O'Reilly will publish Enterprise JavaBeans 3.0, 5th Edition by Bill Burke (myself) and Richard Monson-Haefel. It is a comprehensive guide to EJB 3.0 covering everything from Session and Message Driven beans to the new Java Persistence API. About a year ago, O'Reilly asked me to take over the series from Richard. Although EJB 3.0 has drastically changed in many areas, particularly entity beans, Richard had written such a good book that it could easily be adapted (well not too easily) for the new specification.




The book teaches you EJB 3.0 by implementing the Titan Cruises Reservation System. All EJB 3.0 topics are covered including:



  • Stateless and Stateful Session Beans
  • Message Driven Beans
  • EJB Interceptors
  • EntityManager configuration and API
  • The rich Java Persistence object to relation mapping
  • Java Persistence's tight integration with EJB
  • All the new injection annotations and XML equivalents


The new JAX-WS web services programming model and annotations are also covered. Since I'm not well versed in this subject, I asked Jason Greene, a Senior Developer working on JBoss's web services implementation, to write the chapters that discuss this subject. Thanks Jason!


The book also includes a JBoss Workbook. Each chapter of the main book has a parallel workbook chapter that walks you through example programs you can download, compile, and run on the JBoss 4.0 application server using JBoss's EJB 3.0 implementation. This workbook is a great way for you to see EJB 3.0 in action.


Have Fun




Synergies and Cultures

Posted by bill.burke Apr 17, 2006


I just wanted to jot down some of my thoughts about the acquistion. After a week to digest this I came away with the following feeling.


About 3 years ago JBoss Inc. started the process of recruiting other open source projects. Ben Sabrin and I went out to the TSS symposium in 2003 to recruit Gavin King of Hibernate. Later, others at JBoss enticed Bela Ban (JGroups), Tom Baeyens (JBPM), and Mark Proctor (Drools) to join. Basically, the pitch to all of these guys were:



  • We are stronger together than apart
  • We have synergy in product offerings
  • We have the business infrastructure so that you can focus on tech
  • Our brand will boost your visibility and user base
  • Our sales force will sell your software
  • Customers will feel safer with a larger entity


Last week we became the acquired rather than the acquiring. I think I know how Gavin, Tom, and Mark felt now and why they wanted to join JBoss. Red Hat gives us some of the same benefits that we gave Hibernate, JBPM, and Drools except on a much larger scale.


Marc also shared with us an IRC chat log he had with about 230 Red Hat employees about the acquisition last week. This IRC reminded me a lot of "the core" email list we have internally at JBoss: a lot of opinionated individuals that aren't afraid to ask hard questions or be critical of others. With other companies I've worked for in the past, individuals would be scared to question management decisions or voice controversial opinions at such a meetings fearing that they would rock the boat. Red Hat employees had no such qualms. Its obvious these guys care as much about their company as we do ours. The fact that Red Hat, as a company, would have an open internal IRC chat with Marc tells me alot about the openness of the culture we are joining. I'm glad Marc and Red Hat shared this IRC log with us JBossians. As one of our developers said internally, "This IRC makes me happy on several fronts.".


I hope Red Hat employees see this blog and know that there is at least one JBossian very excited about this acquisition. I think we're gonna mesh quite nicely and I hope I get to meet a lot of the tech guys soon.








EJB 3.0 RC6 Release

Posted by bill.burke Apr 14, 2006


RC6 has already been shipped with JBoss 4.0.4CR2 application server. I was on vacation when this went out and just got to putting the binaries together for the standalone distribution.




Things of note?

  • @WebService/jsr181 support. @WebServiceRef isn't supported yet though. A tutorial was added for it. Thanks Thomas/Jason.
  • Embedded EJB3 has security support now thanks to Carlo de Wolf
  • lots of bug fixes, see the release notes for more detail


At Java One last year, I did a presentation on the JBoss architecture. One of the things I talked about was our deployer architecture and how you could define your own proprietary package format that could automatically be deployed/hot-deployed into your environments. I gave the Spring Framework as an example of what you could provide


I had wanted to create a Spring Deployer for over a year, but never had time to do it. Luckily, a few weeks after my presentation, I received an email from a random person named Ales Justin asking if the Spring Deployer was available. I told him it wasn't, that I had no time to develop it. He responded with "I'll do it!". Let me tell you, I get these offers to help about once a week. I give these people a few pointers then usually, almost always, never hear from them again. I pointed Ales to a few example Deployers and told him he was on his own. About a week or so later, he came back with a finished Spring Deployer. What he had seemed to work, so I gave him CVS access. He asked, "What next?" I told him, "why don't you integrate Spring with EJB 3.0 and provide a custom injection annotation for EJBs for Spring deployed object?" He said ok, and later in August 2005, the Spring integration project was begun


Well, we originally wanted to launch this project by writing an article for The Server Side about the project. Ales did this and submitted it to TSS. Unfortunately, TSS seems to be more interested in publishing issues about JBoss rather than anything positive we might be doing for the Java community and the article fell through the cracks. Ales became busy, and we never got the article out.


Strangely enough, even without an announcement, one WIKI page, a downloadable SourceForge distribution, and a User Forum, produced over 1000 downloads of the project. Ales reworked the project using the new EJB 3.0 PFD spec and released another version last week. We gave up with TSS and went to Java Developers Journal instead, and you should see Ales's article printed in the February edition.


So, what about the project you ask? Well, here are the links


I'm pissed at myself for not calling attention to this project earlier, but it seems a lot of you have already found it




Have Fun



It definately feels like Ground Hog Day. Didn't I just release EJB 3.0 a few days ago? Well, some user feedback produced a few bug fixes. You can download RC5 at sourceforge.


Finally, after almost 4 months of development, Thanksgiving, Christmas, consulting priorities, and children being born, JBoss EJB 3.0 RC4-PFD is finally out and available for use. This is a major release with over 68 tasks complete. We are about 99% compliant with the EJB 3.0 Proposed Final Draft and a lot of major and minor bugs have been fixed. You can download the standalone release on sourceforge. This distribution works with JBoss4.0.3SP1 application server. JBoss 4.0.4RC1 will be out soon with a full app-server distribution. You can view documentation at, or just download the standalone distribution which has doco as well as 30+ tutorials.


A lot has changed in this release both in the specification and the way JBoss implements EJB 3.0. Check out the EJB 3.0 WIKI for details on how to migrate from an older version of JBoss EJB 3.0. It is going to be an annoying process to migrate because of all the minor annoying little changes here and there, but please have patience. Since our WIKI is editable by anybody, please help us out to expand these guides! BTW, if you get really upset with some of the default JNDI binding changes, please send your hate mail to Gavin King and Christian Bauer.


Special thanks goes out to Gavin King for putting up with all my bitchin' and whining in the late hours of the night. And always, Emmanuel Bernard for doing a kick ass job on the Hibernate side of things.


Have Fun,




Training EJB 3

Posted by bill.burke Jan 19, 2006
This week, I am doing a JBoss Advanced training down in Orlando. When I got to the sight, I was pleasantly surprised to learn that they were an EJB 3.0 shop. It seems they have a few products coming out later this year and decided on EJB 3.0 to implement this new project. Here's some of the things they said:


We were required to be standards based and did some research before the project began and jumped on EJB 3.0 because all the XML alternative approaches just seemed too unproductive


There is no possible way we could have accomplished as much as we did in so short of time if we had gone the EJB 2.1 route. Our developers were amazingly productive using EJB 3.0


The moral of the story is that the more people I talk to about EJB 3.0, the more I learn that it is a vast improvement over the older specification and that the spec is headed in the right direction. I'm trying to extract a testimonial from these guys, so you should see something soon on this.


Ya know? It is refreshing to speak to people that are actually trying out this technology, instead of just blindly denouncing this because they are emotionally attached to some of the EJB-alternative frameworks out there. Anyways...



I've always hated checked exceptions and always preferred using RuntimeExceptions. I usually find that I rarely have the ability in my code to recover from a particular exception thrown by a particular method and adding a checked exception to the throws clause would just require ugly try/catch blocks for my users.


There are occasions though in some methods, I still want to throw a RuntimeException, but want to make it known to users that it is possible to recover from a particular exception. At first, putting these exceptions in JavaDoc seemed like the best idea, but, what if I want to catch a particular exception? I have to look in the JavaDoc to see what runtime exceptions are thrown. I also can't ask my IDE to automatically create a typed try/catch block for me. So...What about declaring RuntimeExceptions in the throws clause? Is this a good convention?


Maybe this is an old practice, maybe not. I first came across this idea of putting RuntimeException exceptions in the throws clause during the EJB 3.0 expert group when all EntityManager exceptions are RuntimeExceptions but there were a few cases where it would be interesting to catch an exception thrown from an EntityManager method. Again, since the RuntimeException would be available in the throws clause, an IDE could automatically generate the try/catch block for me when coding. Is this a good idea or not? Let me know.




Due to our first blog about JBoss EJB 3.0 successes and the fact that TSS picked up that blog, the success stories are starting to pile in. This particular testimonial is from Ron Hatcher of the Millfield Group in the UK. Look for more testimonials to pop up here in the next few weeks. If you have your own EJB 3.0 testimonial, please




The Millfield Group plc. is a financial services company with over 1500 advisers, including independent financial advisers, independent mortgage advisers and other specialist advisers in our regional offices throughout the UK. We have adopted JBoss as our strategic platform for enterprise development and have now begun releasing EJB3 based applications into production.


Our recent EJB3 implementation is the first application to take advantage of our evolving service delivery platform - Jupiter. It is based on a three tier physical architecture with Windows/IIS web servers, Solaris/JBoss application servers, and Windows SQLServer database servers. This structure is quite common (and has been for some time). The difference now is the effectiveness that the JBoss EJB3 implementation brings to the whole development process.


Our Jupiter platform provides a core set of services and business objects that are generic across our business domain. These services and objects are then used by applications that 'orbit' around it. Currently these applications invoke the core services by accessing stateless session beans, but these will expand to include web-services and Message Driven Beans in the future.


The first application - Leda - is a mortgage referrals system. Estate agents use it to refer their home buying clients to mortgage selling financial advisors. We use the Front Controller/Dispatcher mechanism to manage the presentation tier, and use a single dispatcher for each use case in the system (there are approximately 12). Our initial user group has been restricted to 250, however we are planning to bring an additional 750 users online in the very near future.


While building the application, I was very pleased with the ease of implementation of the entity model. Although we have built hibernate based applications in the past, the EJB3 entity beans really take all the headaches away from the persistence mechanism.


We did encounter a few issues during the initial build -

  • Lazy Loading - The lazy loading mechanism is very awkward in the context in which we use our entity beans. Although there are many ways to solve this, we opted to have different methods on the session bean facade to load children as required.
  • Integration - We found that integrating the EJB container into the JBoss application server was a manual job. Even as late as 4.0.3.RC2, we had some issues with the integration 'out of the box'. Presumably this has been resolved now, but we keep our JBoss version in CVS, to ensure any configuration can be easily rolled out across the development team and out into the environments.
  • Tomcat - We have had to simulate EJB session bean access in servlets as described in the EJB3 documentation. This wasn't difficult to do, but may present a problem when the specification is finalised. Also, we needed to patch the tomcat server to allow us to use generics and Java 5 style for loop iterators.
  • SQL-Server - Lastly, SQL-Server seems to have minor issues in the JDBC world - these are not specific to EJB3 or JBoss. We are now using the Jtds JDBC driver, and with a small amount of 'tweaking' it is working very well.


There has been much written recently about EJB3 persistence, annotations, and dependancy injection from an implementation perspective, but I feel the real benefit here is in the whole development file-cycle. In the EJB2.1 world, we adopted the many of the Sun Architectural patterns to get the performance and usability we required from the platform, but these mechanisms required a translation from the business requirements and business model to the implementation. Our current development aims to solve this problem by using JBoss Jbpm.


As a financial services company, we are required to implement and use many regulatory processes. These can be quite complex, and code to implement them quickly becomes complex and hard to maintain.


Our first regulatory application - Callisto - uses Jbpm to manage the business process, and invoke our EJB services as required. This allows for the implementation code to be narrowly focused on a specific step in the business use case, and moves any process related code out of the equation. Using this technique, we effectively automate our business process with very little interpretation between the business spec and the final implementation.


Our initial testing has shown this approach to be extremely effective in quickly building applications, and keeping the code very clean and maintainable. Again, we experienced a few issues so far with Jbpm.

  • Process archive - the Jbpm process archive extension has collided with the EJB3 persistence archive (.par) this is not a major issue, but should obviously be addressed.
  • Documentation - we found the documentation for Jbpm to be a bit fragmented, but with a few experiments, we managed to get it going fairly quickly.
  • API stability - As we are implementing Jbpm 3.0, we are currently concerned that the API changes for 3.1 may be problematic for us.


All in all, I am very pleased with our success to date using EJB3 and Jbpm, and am confident that this will support our platform development efforts for some time to come. Our current plans involve implementing two more modules in the next 12 months, and expanding the user-base of the platform to 10,000. I would like to take this opportunity to thank all of the JBoss contributors for providing a great environment, and also to our EJB developers Richard King, David Oliver, and Victoria Weston.



One of our users on the EJB 3.0 forum, Chris Malan, talked a few days ago about an EJB 3.0 application he was about to go into production with in the next few weeks. I asked him if he wanted to write a little bit to describe his application and he graciously accepted. Thanks Chris! If you, dear reader, also have an EJB 3.0 success story please post it on our forums or Contact me directly and I'll see about putting it out on our blog. Also, stay tuned for other EJB 3.0 and JBoss Seam testimonials. We have a few in the pipeline from a few small and large customers that we'll be announcing shortly.

Have a look at 24/7 Roadservices Australia It runs on shared hosting at Ala cartejava with JBoss-4.0.3 as the application server. The database is MySQL.

For the next few days (today is the 27th Ocotber, 2005) it will still be in a test phase and everyone can enter dummy transa ctions using imaginary credit card details.

And it is a totally EJB3 application.

The development tools were Eclipse 3.1 with the JBoss 1.5 Milestone 1 IDE. During development it was tested in JBoss-4.0.3R C2 and PostgreSQL.

This application uses of course the POJO data objects new in EJB3. It also uses Session beans, Servlets, a few utility classes like one called UserNamePasswordHandler for logging in and a Filter to control access to "secured" content - the staffpage. The only jsp page is the staffpage. There is also a StaffBean (not a data object) which occupies a place between the staffservlet and the relevant Session Bean. The servlet gets a request, forwards it to the st affbean which forwards it to the Session Bean and gets a response, either as a String or a List of objects. The servlet send s a redirect and the staffpage reads the response to its request from the staffbean. The staffpage is almost pure html. Th ere is of course the obligatory JavaScript form checking.

This application uses the MVC architecture. As far as a framework is concerned, it uses a pure J2EE EJB3 framework as far a s that is possible. No Struts or anything else. Of course, much of the functionality is JBoss specific as the full EJB3 spe cification has not yet been decided upon.

All user response pages (only two) are directly generated by a servlet.

To prevent concurrency problems all database access that will result in database changes requires a transaction. We do not anticipate heavy use at all; if there are 10 users at the same time trying to buy the product the owner will be just too ha ppy. Shared hosting is of course also not the way to go if one anticipates heavy use. Be that as it may, there is a pool o f 20 database connections, more than enough for many times that number of concurrent users.

When it went "on air" I had all the office staff (eight) go on and attempt a transaction without help. There were no proble ms, except for one secretary who could not recognise the end-point of the online credit card transaction. However, my inter est has been aroused. I think I'll get it to run on one machine of the local network, use JMeter from another and send the servlet requests to create contracts and see with how many it can keep up. In the real world I suspect the network (Interne t) will be the bottleneck long before the software falls over.

Problems? A few. At first I could not get the application to create the database tables and keep them when the server shut down. Someone on the EJB3 forum suggested:

<property name="" value="update"/>

It works perfectly for both PostgreSQL and MySQL.  Then there were problems with the .par archive andI packaged even the ent

ity classes (POJOs) in the .ejb3.  That worked.  However,

the final package structure looks like this:




        <display-name>247 Roadservices</display-name>

        <description>The 247Roadservices Application</description>














This structure worked from the word go when deployed at Alacartejava.

Note that this is really a simple application that doesn't do wonderful things. It takes form input from a user, transfers t he user to a secure payment site, comes back from the payment site when a link is clicked after successful payment and write s everything to the database and gives the user his contract ID no. It gets data from the payment site behind the users bac k as a get request. It verifies that this comes from the payment site's IP address. I know about IP spoofing, but one's car registration no needs to be real for this product to work. Who would commit fraud and supply real contact details?

Did JBoss fall short in any way? Not with this application. I am sure this application did not give JBoss a good work-out. I have a few EJB2.1 applications running at Alacartejava. This one seems faster, especially the form pages which are creat ed by a servlet. Is JBoss-4.0.3 faster than the older versions or is this application on newer hardware? I don't know.

There is of course a log-in page for admin staff without even a link to it. Various things can be done on the admin page. In fact, most of the J2EE functionality is to be found on this page.

Well, that's it folks, A simple J2EE EJB3 application that was created on the cheap and runs for about US$55 quarterly. And everything works.

One caveat; don't install JBoss-4.0.3 and expect to run EJB3 applications in it at Alacartejava. Look one place lower down in the drop-down list and install JBoss-4.0.3EJB3.

What about EJB3? Much, much better than EJB2.1. The ability to extend classes (not used with this application but extensiv ely used with a real estate application I am working on - base class Property, extended classes Residential, Commercial etc) is heaven-sent. I managed something similar with 1:1 tables/classes in EJB2.1, but it was much more work. The thinking par adigm is now almost purely Java (Object Oriented) as opposed to thinking in database terms (tables, columns and rows and rel ationships). I became aware that things are now different to what it was in EJB2.1 while coding. Maybe one can say EJB2.1 was closer to the database and EJB3 is almost pure Java programming.

Chris Malan


Some interesting features that were added were JCA RA support for MDBs. With Embeddable EJB 3.0 we've made it easier to deploy and of course, we fixed a bunch of bugs. You can view the release notes here


This is old news, but we never really made any noise about it so I thought I should blog about it. Adrian Brock has completed version 1.0 (and 1.0.1) of the JBoss Microcontainer. Adrian actually prefers to do real work than blog, so he left this job to me, JBoss's Chief Marketect.


JBoss Microcontainer is a complete Inversion of Control, Dependency Injection lightweight container. It allows you to configure POJOs through XML and has lifecycle for these POJOs as well so that they can be treated as services. It does not require the JBoss Application Server to use and can be used in any application whether it be a J2EE app or a plain Java ap.


The JBoss Microcontainer starts JBoss on an evolution to embeddable Java EE. The idea is that all JBoss Java EE and JEMS services will be embeddable and runnable in environments outside of the JBoss Application Server including: JUnit tests, Swing applications, standalone Tomcat, and even other vendor application servers. If you have downloaded JBoss Seam or JBoss Embeddable EJB 3.0 you are already using the JBoss Microcontainer as it is being used to initialize and configure basic services used by these frameworks like a transaction manager, JNDI, JCA-based datasources, and JMS. Over the next few months and quarters you will see more and more JBoss services be converted into POJOs and configurable and usable in non-app-server environment. This will culminate with the release of JBoss 5 sometime in 2006.


The first version of the JBoss Microcontainer is just a plain, but advanced, IoC container. Later versions will allow you to layer additonal kernel-like services like advanced classloading through our Unified Class Loader architecture, as well as a rewrite of JBoss Deployers so that you can package and deploy your components and have them be loaded and bootstrapped by the Microcontainer. Currently though, here's some features that I think are simple, but pretty cool.



  • Complete property and constructor dependency injection.
  • Support for lists, maps, sets.
  • Services on demand. Basically, a declared POJO will not be allocated or initialised until it is referenced. This is similar in idea to the Microsoft Services Manager where you can disable, enable, or provide automatic startup of various services.
  • A complete state machine. A POJO/service will not be initialized until all of its dependencies have gone through their lifecycle. This state machine is pluggable.
  • Define dependencies based on the state of the referenced dependency. This allows you to handle certain cases like circular dependencies.
  • Construction based on factory methods. When creating a bean, you can have it be created by calling a static method or member method of an existing bean. The container doesn't always have to be responsible for allocating the instance of the bean.
  • Pluggable XML. You can plug in your own schema's that do your own definition of property values. (not yet documented).


So why is JBoss creating its own IoC container when there are a bunch of other frameworks out there that do similar things? Well, to be brief, it would be suicide for us to depend on a third party to provide such a core piece of our infrastructure. For basic IoC, this doesn't really matter, but when we start to layer things like classloading, packaging, deployment, and most importantly management, this will become more and more important to us. Really, JBoss Microcontainer was written as the next iteration of the old JBoss JMX Microkernel so that we could evolve the JBoss Application Server. So, JBoss MC's primary customer is JBoss 5 AS, JBoss Seam, and Embeddable EJB 3.0. JBoss Microcontainer is there for you the community to use if you are interested in it which is why we are calling attention to it and promoting it a little.


Anyways, check it out. Adrian write some pretty high quality code and I have learned a lot from him over the past years. If you didn't know already, Adrian also maintains and leads our current JCA, JTA, and JMS implementation as well, so he's a pretty busy (and talented) guy. Great work Adrian!




A maintenance release of JBoss EJB 3.0 and our Embeddable EJB3 container are available. You can view the release notes on



JBoss EJB 3.0 RC1 - JBoss AS integration

We are getting closer to offering a professionally supportable release of EJB 3.0 with JBoss EJB 3.0 RC1. There are a lot of bugs fixed and and a lot of the features that are in the EJB 3.0 Public Draft have been implemented. We have also done even tighter integration with Hibernate 3.1. You can now inject a Hibernate Session or SessionFactory using the @PersistenceContext annotation. Hibernate Sessions will be managed and behave exactly like injected EntityManagers. You can view the release notes and download from here.



Use full EJB 3.0 out of the application server!

JBoss EJB 3.0 supports an embeddable version that can be run outside of the application server in standalone applications, junit tests, Tomcat, or even other non-jboss application servers. This is an alpha release as there are a few issues we haven't fully worked out yet as you will see below. You can find out more information about it here and can download it here.


Supported Features:

  • Local JNDI
  • Transaction Manager
  • JMS
  • Local TX datasource/connection pool
  • Stateful, Stateless, Service, Consumer, Producer, and MDBs
  • EJB 3 Persistence
  • Hibernate integration



  • We have only sparsely tested the embedded stack. Consider it an alpha release
  • The Embedded stack is based off of CVS HEAD, not JBoss 4.0.x. Future versions will be based off of 4.0.x code.
  • We have done no pruning of jar files so the distribution disc size is a little large.
  • Documentation is sparse. Hopefully the tutorial examples are enough to get started.
  • We have not tested yet in other application servers, only within standalone Tomcat. No reason why it shouldn't work though
  • We cannot yet take advantage of services like JNDI, TM, JMS, etc... when running in other app servers
  • When embedding into Tomcat, you still require a JBoss specific JNDI implementation. Tomcat's JNDI is read-only.
  • EJB/JBoss Security is not available yet.
  • XA Connection pool is not available yet.
  • EJB Timer service not supported
  • Distributed remote communication is not supported yet.
    • Even though @Remote interfaces are supported, you can only communicate through local colocated connections.
    • You cannot access JMS remotely. Only locally. Thus, you have to lookup the "java:/ConnectionFactory".
    • JNDI is not available remotely







Filter Blog

By date: