Thursday April 29, 2010

Several new features for Stateless Beans

As OpenEJB is deployed into more and more production environments we've been hard at work filling out the system to meet demands. The latest overhaul has been around the @Stateless bean pooling options.

At a high level, the new features provide:

  • Availability: guarantee a minimum number of instance in a pool, from startup and through the entire life of the pool.
  • Shrinking: aggressively shrink pools via an inactive bean timeout and/or gracefully shrink pools via VM garbage collection when memory is needed.
  • Freshness: aggressively flush a pool via the bean's SessionContext and/or gracefully expire, and possibly replace, beans via a max age.
  • Using the above features it's possible to build a pool to fit your exact needs. The pool shrinking functionality allows a pool that has reached its maximum size to shrink down over time to its minimum size (which can be zero!) either aggressively or gracefully, keeping resources consumed at a minimum. The freshness functionality allows the entire pool, even the minimum, to be purged and renewed either aggressively or gracefully over time, preventing leaky state from building up over the long life of the pool.

    The new options are: PoolMin, IdleTimeout, PollInterval, MaxAge, ReplaceAged, MaxAgeOffset, and CallbackThreads. Garbage collection functionality is achieved internally through java.lang.SoftReference(s) and nothing is required to enable it, though it can be tuned at the VM level. Pool flushing can be done via the javax.ejb.SessionContext object of Stateless beans which now can be cast to

    All of the above functionality is of course thread-safe. Instances cannot be garbage collected, expired via MaxAge, or flushed while in use. Calling flush() on a "hot" pool will not affect instances in use till they return to the pool. The same applies for any instances that reach their MaxAge while in use -- they are only expired once returned to the pool.

    The above options are properly tuned and balanced as well and will not compete. For example, flushing a pool will not cause any instances created to refill the pool to have the same creation time and therefore expire together in one, very ungraceful, drop. Creation times will be skewed to keep MaxAge expiration spread out. As well MaxAge and IdleTimeout are enforced together such that MaxAge is enforced, instances are transitioned into the "minimum side" of the pool as needed, and the remainder is subject to IdleTimeout. The pool will not timeout a perfectly good instance that could be used to keep the pool at it's minimum.

    Monday April 26, 2010

    How much time have you saved with OpenEJB? Find out!

    Inspired by Matthew B. Jones' blog post sharing his experience saving a whopping 26 person weeks in development with OpenEJB, we've put together a time saved calculator.

    A fun little tool for those that develop with OpenEJB and use a different platform in production. Check it out!

    User Blog: OpenEJB : Rapid J2EE Development & Testing

    Matthew B. Jones writes a great piece, OpenEJB : Rapid J2EE Development & Testing, sharing his team's experience using OpenEJB to aid in the development of their very large JBoss application. His team of 10 has been using OpenEJB since February and by his most conservative estimations has saved 26 man-weeks on deployment time alone. A shocking amount even to our ears.

    Friday March 12, 2010

    Example: Common Troubleshooting flags

    Having trouble with a test? It's bound to happen eventually. We've coded up a little example that employs some of the more common ways to get more information to help resolve issues.

    The heart of the example is the following setup method:

    public void setUp() throws Exception {
        Properties p = new Properties();
        p.put(Context.INITIAL_CONTEXT_FACTORY, "org.apache.openejb.client.LocalInitialContextFactory");
        p.put("movieDatabase", "new://Resource?type=DataSource");
        p.put("movieDatabase.JdbcDriver", "org.hsqldb.jdbcDriver");
        // These two debug levels will get you the basic log information
        // on the deployment of applications. Good first step in troubleshooting.
        p.put("log4j.category.OpenEJB.startup", "debug");
        p.put("log4j.category.OpenEJB.startup.config", "debug");
        // This log category is a good way to see what "" options
        // and flags are available and what their default values are
        p.put("log4j.category.OpenEJB.options", "debug");
        // This will output the full configuration of all containers
        // resources and other openejb.xml configurable items.  A good
        // way to see what the final configuration looks like after all
        // overriding has been applied.
        p.put("log4j.category.OpenEJB.startup.service", "debug");
        // Want timestamps in the log output?
        p.put("log4j.appender.C.layout", "org.apache.log4j.PatternLayout");
        p.put("log4j.appender.C.layout.ConversionPattern", "%d - %-5p - %m%n");
        // Will output a generated ejb-jar.xml file that represents
        // 100% of the annotations used in the code.  This is a great
        // way to figure out how to do something in xml for overriding
        // or just to "see" all your application meta-data in one place.
        // Look for log lines like this "Dumping Generated ejb-jar.xml to"
        p.put("openejb.descriptors.output", "true");
        // Setting the validation output level to verbose results in
        // validation messages that attempt to provide explanations
        // and information on what steps can be taken to remedy failures.
        // A great tool for those learning EJB.
        p.put("openejb.validation.output.level", "verbose");
        initialContext = new InitialContext(p);
        initialContext.bind("inject", this);

    In practice it is not a good idea to enable so many debug flags as the output will be too much. Best to start with one, read the log output, and see if that doesn't give some direction. If not, disable it and move on to the next.

    Wednesday March 10, 2010

    Example: Testing Transaction Rollback

    We've coded up a nice little example project that shows various ways to rollback transactions in unit tests.

    The example also serves to show the various options in EJB that pertain to how to rollback transactions via either a UserTransaction, SessionContext.setRollbackOnly(), or throwing a RuntimeException. The example also shows how to mark a RuntimeException with @ApplicationException to bypass the rollback behavior.

    Here's a snippet from the test case to show how simple it is to test:

     * Transaction is marked for rollback inside the bean via
     * calling the javax.ejb.SessionContext.setRollbackOnly() method
     * This is the cleanest way to make a transaction rollback.
    public void testMarkedRollback() throws Exception {
        try {
            entityManager.persist(new Movie("Quentin Tarantino", "Reservoir Dogs", 1992));
            entityManager.persist(new Movie("Joel Coen", "Fargo", 1996));
            entityManager.persist(new Movie("Joel Coen", "The Big Lebowski", 1998));
            List list = movies.getMovies();
            assertEquals("List.size()", 3, list.size());
        } finally {
            try {
                fail("A RollbackException should have been thrown");
            } catch (RollbackException e) {
                // Pass
        // Transaction was rolled back
        List list = movies.getMovies();
        assertEquals("List.size()", 0, list.size());

    Monday March 08, 2010

    User Blog: Maven, OpenEJB and eviware soapUI

    Magnus K Karlsson has written a nice blog post about using Maven, OpenEJB and eviware soapUI to develop and test JAX-WS Web Services.

    The full chain involves creating the Maven, OpenEJB driven unit tests and eventually deployment into JBoss with further testing driven manually via the eviware soapUI tool.

    Thursday March 04, 2010

    Article: Coarse Grained Unit Testing

    Dr. Dobb's has a great article titled Coarse-Grained Unit Testing: Using OpenEJB and DBUnit to write repeatable unit tests for Java componentswhich shows how to combine OpenEJB with DBUnit to get a very effective testing setup. The article is complete with an example based on the fictitious Blue Star Galactic spaceship company. All source code is available to download.

    Wednesday December 23, 2009

    User Blog: Tomcat, OpenEJB and Jersey, oh my

    Russ Jackson writes on his success getting Tomcat, OpenEJB and Jersey all hooked up and running together. More than anything, it's great to see people exploring this stack. Certainly there are cool things that can be done with the three. A note on the @EJB injection; if there is some way to extend or enhance the injection that Jersey does, it would definitely be possible to add support for @EJB, @Resource, @PersistenceContext and more to Jersey components running in a Tomcat/OpenEJB stack. Wonderful area for contribution if anyone has the itch!

    Monday November 02, 2009

    OpenEJB Eclipse Plugin Alpha Released!

    The first version (1.0.0.alpha) of the OpenEJB Eclipse Plugin has now been released! This release includes:

    * WTP support for the OpenEJB standalone server
    * EJB 2.1 deployment descriptor to EJB 3 annotation conversion wizard
    * Error highlighting and quick fix for problems with EJB3.1 @DependsOn annotation
    * OSGi wrapper to use OpenEJB in Equinox, to help build RCP applications

    The plugin is available for download here: (you can unzip this to a dropins folder) or you can use the update site in Eclipse:

    A video demonstrating how to get started with the Eclipse Plugin is available here:

    Getting started with the OpenEJB Eclipse Plugin from OpenEJB on Vimeo.

    (video made with ScreenFlow)

    Tuesday October 20, 2009

    Apache OpenEJB 3.1.2 Released!

    Apache OpenEJB 3.1.2 has been released! This release is a short 4 months after our prior 3.1.1 release and is largely focused on bug fixes and small improvements with a couple new features. Scanning support for JSF 2.0 ManagedBeans allows for a nice OpenEJB/Tomcat/Mojarra stack. Database passwords listed in the openejb.xml can now be encrypted using our new 'cipher' command line tool. Focus areas of improvements/fixes include @LocalClient support, remote client disconnections and connection caching, AltDD support, Stateful bean caching, and additional JNDI name formatting options.

    The next release, 3.1.3, will likely contain more significant changes. A major CXF upgrade is planned which should bring with it new Web Services features. Exciting new testing techniques are in the works. As well third-party descriptor support is being expanded. Stay tuned to the project blog for details on these developments and more!

    Wednesday August 05, 2009

    Screencast: EJB Unit Testing with Eclipse and OpenEJB (repost)

    We've had some download issues with the original screencast, so we have uploaded it to a video sight and are reposting it to the blog.

    This screencast shows how you can turn the plain, non-javaee version of Eclipse into an EJB testing machine. The tutorial walks you through installing Eclipse, adding OpenEJB to your project's classpath, and creating a simple EJB with a JUnit unit test.

    EJB Unit Testing with Eclipse and OpenEJB from OpenEJB on Vimeo.

    (video made with ScreenFlow)

    User Blog: Effective Unit Testing EJB 3.0 with OpenEJB

    Magnus K Karlsson writes Effective Unit Testing EJB 3.0 with OpenEJB.

    As you state quite well, Mangus, many people have had a bad experience with EJB 2.1 and although simpler EJB 3.0 is not so easily testable without a container. Unless of course you use an embedded EJB container like OpenEJB.

    We greatly appreciate blog posts like yours as many people try and fail with a few approaches before finally finding OpenEJB. So many more people don't even look for a solution. Blog posts like yours go a long way in helping to get the word out.

    Thanks, Magnus!

    Tuesday August 04, 2009

    User Blog: OpenEJB 3.1 JBoss Embedded and EJB 3.0 unit testing

    Nick Mpallas writes in his Nick Says blog an entry titled OpenEJB 3.1 JBoss Embedded and EJB 3.0 unit testing about his month long quest to figure out a way to unit test EJBs. He tries JBoss Embedded first as so many people do and eventually settles on OpenEJB with TestNG and Hibernate.

    Thanks for writing, Nick! We're really excited to see more updates about your progress.

    Monday August 03, 2009

    User Blog: Restarting the embedded OpenEJB container between each test

    Jonas Bandi writes in his CLOSED-LOOP blog a nice entry on Restarting the embedded OpenEJB container between each test. Jonas documents the use of a newer property "openejb.embedded.initialcontext.close" which allows you to destroy the embedded container system after each test.

    Note that Maven users can use Surefire Forking to achieve a similar result that will also clear out any embedded database state as well. That approach basically gives you a fresh VM for every test and the approach we use internally in our build. Haven't done any speed comparisons to see how they stack up speed wise.

    Sunday August 02, 2009

    User Blog: How To Unit-Test EJB 3 0.8 Seconds

    Adam Bien writes in is popular weblog an nice entry called How To Unit-Test EJB 3 0.8 Seconds. As the subject implies he covers using OpenEJB for fast and light EJB 3.0 unit testing.

    Adam has been working on a new project called Project Kenai which aims to take a fresh look at Java EE design patterns. So many J2EE design patterns deal with things which were similified or eliminated altogether in EJB 3.0. It's about time someone came out with some new material.

    Great work Adam! Thanks for ensuring your examples run on OpenEJB!



    Hot Blogs (today's hits)

    Tag Cloud