Entries tagged [ejb]

Friday April 08, 2011

Apache OpenEJB Get-Together, Tours France, April 18th - 21st

Second annual Get-Together. No fees no conference and no sessions. Just an excuse to get-together, code, and have a beer or two.

Hacking Monday - Thursday. Friday and the weekend is for non-technical fun.

Tech-time will likely be focusing on TomEE, Java EE 6 Web Profile and OSGi hacking. If you have something you've been wanting to work on, come on down and I'm sure someone will be available to give you some pointers and get you rolling. Even if you just know you want to work on something but don't know what, I'm sure we can find a nice little project for you. Even the smallest task has a way of taking you in unexpected and fun directions.

Most of us are staying here:


A good second choice:


Jean-Louis' company, Atos Origin, has graciously offered space for daytime hacking fun. Please rsvp to him if you wish to partake as he will need to get you a security badge. His apache address is jlmonteiro@. I've heard rumors of a limited supply of food and coffee on the premises for those that rsvp. So definitely get word to JL!

Evening fun will likely be around the center of Tours. I'll try and twitter our locations, facebook checkin and am happy to give out my cell and google voice to anyone who would love to happen by for a beer. Just email me offline. There are likely some neat social networking tools we could use, feel free to suggest one.

Hope to see you there!

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 java.io.Flushable.

    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.

    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!

    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)

    Thursday June 18, 2009

    Screencast: EJB Unit Testing with Eclipse and OpenEJB

    We've put together the first of hopefully many screencasts to walk you through various aspects of using OpenEJB. 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


    Friday June 05, 2009

    Apache OpenEJB 3.1.1 Released

    The Apache OpenEJB team is excited to announce the release of OpenEJB 3.1.1.

    This release includes some great enhancements for the embedded testing scenarios and general EJB programming. Notable improvements include:

    - Dependency injection for test cases and clients of the embedded ejb container via new @LocalClient annotation.
    - Support for annotating the same interface as @Local, @Remote and @WebService making it possible to exposing all possible EJB views with a single interface.
    - Web Service views securable with @RolesAllowed, @PermitAll and @DenyAll annotations.
    - Ability to easily use alternate sets of deployment descriptors for some or all tests via new 'openejb.altdd.prefix' property.
    - Global lookups from any context simplified via new "openejb:" jndi namespace.

    The release also contains several new examples including Applets invoking EJBs in webapps, Struts with JPA and EJB, secured web services and web services with Perl SOAP::Lite clients and more.

    Wednesday April 29, 2009

    Lookups into the openejb namespace

    To ease the burden in looking up things from OpenEJB's internal JNDI tree, we've added a new "openejb" JNDI URL prefix which can be used in any context to do lookups.

    The following will work in a TestCase or EJB or any code running in the same VM as the EJB Container.

    InitialContext context = new InitialContext();
    TransactionManager tm = (TransactionManager) context.lookup("openejb:TransactionManager");
    DataSource dataSource = (DataSource) context.lookup("openejb:Resource/MyDataSource");

    Tuesday April 28, 2009

    Alternate descriptors for testing

    Inspired by some user blog posts, we've added a new feature so support for altDD (alternative deployment descriptors) can be done in a test or other environment without much work.

    Basically, just set the new "openejb.altdd.prefix" system property or initialcontext property to something like "test", then any descriptors in your META-INF/ directory that start with "test." will override the regular descriptor. So for example with an app like this:

  • META-INF/ejb-jar.xml
  • META-INF/test.ejb-jar.xml
  • META-INF/persistence.xml
  • META-INF/test.env-entry.properties

    Just initialize your test case like so:

     Properties properties = new Properties();
     properties.setProperty("openejb.altdd.prefix", "test");
     InitialContext initialContext = new InitialContext(properties);
    The logical result will be:

  • META-INF/ejb-jar.xml (via test.ejb-jar.xml)
  • META-INF/persistence.xml
  • META-INF/env-entry.properties (via test.env-entry.properties)

    This will work in any environment in which OpenEJB works (embedded, standalone, tomcat, geronimo, etc.).

  • Monday April 27, 2009

    EJBContext.getCallerPrincipal() improvements

    The getCallerPrincipal() method has been improved to always return the username used to login.

    Now any LoginModule implementation can use the new @CallerPrincipal annotation to flag the Principal object they want to be the one returned from getCallerPrincipal() method. The security service will iterate over the Principal objects in the current Subject and return the first one that is annotated as @CallerPrincipal. If no Principal is found with the @CallerPrincipal annotation, the security service will return the first Principal in the Subject as before. All the OpenEJB supplied LoginModules have been updated to use this new annotation.

    If you have implemented your own LoginModule, here's an example of a Principal implementation that uses the new annotation:

    import org.apache.openejb.spi.CallerPrincipal;
    public class UserPrincipal implements java.security.Principal {
        private final String name;
        public UserPrincipal(String name) {
            if (name == null) throw new IllegalArgumentException("name cannot be null");
            this.name = name;
        public String getName() {
            return name;
        // don't forget to implement equals() and hashCode()



    Hot Blogs (today's hits)

    Tag Cloud