content/openejb-3.1.mdtext

Title: OpenEJB 3.1
* Release Date: October 22nd, 2008
* Partial EJB 3.1 support
* EJB 3.0 support
* EJB 2.1 support
* EJB 2.0 support
* EJB 1.1 support

<a name="OpenEJB3.1-Download"></a>
# Download

<a name="OpenEJB3.1-OpenEJBStandloneServer"></a>
#### OpenEJB Standlone Server 
 * [openejb-3.1.zip](http://www.apache.org/dyn/closer.cgi/openejb/3.1/openejb-3.1.zip)
 ([pgp|http://www.apache.org/dist/openejb/3.1/openejb-3.1.zip.asc], [md5|http://www.apache.org/dist/openejb/3.1/openejb-3.1.zip.md5]
) 
 * [openejb-3.1.tar.gz](http://www.apache.org/dyn/closer.cgi/openejb/3.1/openejb-3.1.tar.gz)
 ([pgp|http://www.apache.org/dist/openejb/3.1/openejb-3.1.tar.gz.asc], [md5|http://www.apache.org/dist/openejb/3.1/openejb-3.1.tar.gz.md5]
) 

<a name="OpenEJB3.1-OpenEJBforTomcat"></a>
####  OpenEJB for Tomcat
 * [openejb.war](http://www.apache.org/dyn/closer.cgi/openejb/3.1/openejb.war)
 ([pgp|http://www.apache.org/dist/openejb/3.1/openejb.war.asc], [md5|http://www.apache.org/dist/openejb/3.1/openejb.war.md5]
) 


<a name="OpenEJB3.1-EJB3.1andotherexamples(sourceincluded)"></a>
#### EJB 3.1 and other examples (source included) 
 * [openejb-examples-3.1.tar.gz](http://www.apache.org/dyn/closer.cgi/openejb/3.1/openejb-examples-3.1.tar.gz)

([pgp|http://www.apache.org/dist/openejb/3.1/openejb-examples-3.1.tar.gz.asc], [md5|http://www.apache.org/dist/openejb/3.1/openejb-examples-3.1.tar.gz.md5]
) 
 * [openejb-examples-3.1.zip](http://www.apache.org/dyn/closer.cgi/openejb/3.1/openejb-examples-3.1.zip)

([pgp|http://www.apache.org/dist/openejb/3.1/openejb-examples-3.1.zip.asc], [md5|http://www.apache.org/dist/openejb/3.1/openejb-examples-3.1.zip.md5]
) 

<a name="OpenEJB3.1-SourceCode"></a>
#### Source Code 
 * [openejb-3.1-src.zip](http://www.apache.org/dyn/closer.cgi/openejb/3.1/openejb-3.1-src.zip)
 ([pgp|http://www.apache.org/dist/openejb/3.1/openejb-3.1-src.zip.asc], [md5|http://www.apache.org/dist/openejb/3.1/openejb-3.1-src.zip.md5]
) 
 * [openejb-3.1-src.tar.gz](http://www.apache.org/dyn/closer.cgi/openejb/3.1/openejb-3.1-src.tar.gz)
 ([pgp|http://www.apache.org/dist/openejb/3.1/openejb-3.1-src.tar.gz.asc], [md5|http://www.apache.org/dist/openejb/3.1/openejb-3.1-src.tar.gz.md5]
) 

<a name="OpenEJB3.1-ReleaseNotes"></a>
#### Release Notes
 * [RELEASE-NOTES.txt](http://www.apache.org/dist/openejb/3.1/RELEASE-NOTES.txt)

<a name="OpenEJB3.1-TestedOn"></a>
#  Tested On

<table>
<tr><th> </th><th> Windows XP (JDK 1.5) </th><th> Windows XP (JDK 1.6) </th><th> Linux (JDK 1.5) </th><th>
Linux (JDK 1.6) </th><th> Mac OSX (JDK 1.5) </th><th> Mac OSX (JDK 1.6) </th></tr>
<tr><td> Embedded </td><td>(/)</td><td>(/)</td><td>(/)</td><td>(/)</td><td>(/)</td><td>(/)</td></tr>
<tr><td> Standalone </td><td>(/)</td><td>(/)</td><td>(/)</td><td>(/)</td><td>(/)</td><td>(/)</td></tr>
<tr><td> Tomcat 6.0.14 </td><td>(/)</td><td>(/)</td><td>(/)</td><td>(/)</td><td>(/)</td><td>(/)</td></tr>
<tr><td> Tomcat 6.0.13 </td><td>(/)</td><td>(/)</td><td>(/)</td><td>(/)</td><td>(/)</td><td>(/)</td></tr>
<tr><td> Tomcat 6.0.10 </td><td>(/)</td><td>(/)</td><td>(/)</td><td>(/)</td><td>(/)</td><td>(/)</td></tr>
<tr><td> Tomcat 6.0.9 </td><td>(/)</td><td>(/)</td><td>(/)</td><td>(/)</td><td>(/)</td><td>(/)</td></tr>
<tr><td> Tomcat 5.5.26 </td><td>(/)</td><td>(/)</td><td>(/)</td><td>(/)</td><td>(/)</td><td>(/)</td></tr>
<tr><td> Tomcat 5.5.25 </td><td>(/)</td><td>(/)</td><td>(/)</td><td>(/)</td><td>(/)</td><td>(/)</td></tr>
<tr><td> Tomcat 5.5.23 </td><td>(/)</td><td>(/)</td><td>(/)</td><td>(/)</td><td>(/)</td><td>(/)</td></tr>
<tr><td> Tomcat 5.5.20 </td><td>(/)</td><td>(/)</td><td>(/)</td><td>(/)</td><td>(/)</td><td>(/)</td></tr>
</table>

<a name="OpenEJB3.1-ChangeSummary"></a>
# Change Summary

Major new features:
  - [EJB 3.1 Singleton Support](openejb-3.1#ejb3.1singletons.html)
  - [EJB Constructor Injection](openejb-3.1#constructorinjection%28proposedejb3.1feature%29.html)
  - [Spring Integration](openejb-3.1#springintegration.html)
  - [Multicast Client-Server Discovery](openejb-3.1#multicastdiscovery.html)

Significant Improvements:
  - EAR-style classpath application discovery groups individual modules as
an EAR allowing sharing of persistence units and improved connector and
custom MDB deployment.
  - Detection of EclipseLink, TopLink, and Hibernate as JPA providers to
automatically adds the right persistence unit property to for wiring in the
OpenEJB TransactionManager.
  - System Property and InitialContext property overriding now applies to
persistence-unit properties and logging levels.
  - Login/logout now possible in an embedded scenario via InitialContext
params and initialContext.close() respectively.
  - Complete overhaul of all client/server connection management
dramatically increases performance.
  - Several new checks added to Application Validation ruleset, some
reworked to give even more details.

<a name="OpenEJB3.1-EJB3.1Features"></a>
# EJB 3.1 Features

<a name="OpenEJB3.1-EJB3.1Singletons"></a>
## EJB 3.1 Singletons

Singletons are a new type of Session bean being added to the EJB 3.1
specification.	As the name implies a javax.ejb.Singleton is a session bean
with a guarantee that there is at most one instance in the application.

Singletons gives you some important things that are missing in EJB 3.0 and
prior versions, such as the ability to have an EJB that is notified when
the application starts and notified when the application stops, allowing
you to do all sorts of things that previously could only be done with a
load-on-startup servlet.  Singletons also give provide a great place to
hold data that pertains to the entire application and all users using it,
without the need for a static.	Additionally, Singleton beans have
multi-threaded capabilities allowing them to be invoked by several threads
at one time similar to a Servlet.

See the [Singleton API](openejbx30:singleton-beans.html)
 and [Singleton Example]
 pages.

<a name="OpenEJB3.1-EmbeddableforTestingandJavaSEusage(proposedEJB3.1feature)"></a>
## Embeddable for Testing and Java SE usage (proposed EJB 3.1 feature)

Over the years, OpenEJB has innovated the art of the embedded/Java SE EJB
container usable as a plain library much the way an embedded databases
work.  In a simple 1, 2, 3 step of 1) add OpenEJB to your classpath, 2) add
a META-INF/ejb-jar.xml containing at minimum "<ejb-jar/>", then 3) use the
org.apache.openejb.client.LocalInitialContextFactory when creating your
client InitialContext, you've got a Java SE EJB container that can be used
in unit tests, your IDE, or anywhere you'd like to drop in EJB
functionality.	Configuration can be done through an openejb.xml file or
can be encapsulated 100% in the test case through the parameters passed to
the InitialContext.  For example, to create a JTA DataSource for JPA usage,
you can simply:


    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");
    p.put("movieDatabase.JdbcUrl", "jdbc:hsqldb:mem:moviedb");
    
    Context context = new InitialContext(p);


See the examples zip for a dozen embedded testing examples that range from
simple @Stateless beans to advanced transaction and security testing.

<a name="OpenEJB3.1-CollapsedEAR(EJBsin.WARs)(proposedEJB3.1feature)"></a>
## Collapsed EAR (EJBs in .WARs) (proposed EJB 3.1 feature)

Along the lines of the Tomcat integration where OpenEJB can be plugged into
Tomcat, we've expanded the idea to also allow your EJBs to be plugged into
your webapp.  We call this innovative feature [Collapsed EAR](collapsed-ear.html)
.  In this style 100% of your classes, including your EJBs, can be packed
into your WEB-INF/classes and WEB-INF/lib directories.	The result is that
your WAR file becomes a replacement for an EAR.  Unlike an EAR, all
multi-packaging and multi-classloader requirements are stripped away and
collapsed down to one archive and one classloader all your components, EJBs
or otherwise, can share.

<a name="OpenEJB3.1-ConstructorInjection(proposedEJB3.1feature)"></a>
## Constructor Injection (proposed EJB 3.1 feature)

For those of you who would like to use final fields, wish to avoid numerous
setters, or dislike private field injection and would like nothing more
than to just use plan old java constructors, your wish has come true.  This
is a feature we intended to add to OpenEJB 3.0 but didn't have time for. 
We're happy to bring it to the OpenEJB 3.1 release and with a bit of luck
and support from people like yourself, we'll see this as an EJB 3.1 feature
as well.


    @Stateless
    public class WidgetBean implements Widget {
    
        @EJB(beanName = "FooBean")
        private final Foo foo;
    
        @Resource(name = "count")
        private final int count;
    
        @Resource
        private final DataSource ds;
    
        public WidgetBean(Integer count, Foo foo, DataSource ds) {
    	this.count = count;
    	this.foo = foo;
    	this.ds = ds;
        }
    
        public int getCount() {
    	return count;
        }
    
        public Foo getFoo() {
    	return foo;
        }
    }


<a name="OpenEJB3.1-GeneralFeatures"></a>
# General Features

<a name="OpenEJB3.1-EJB3.0Support"></a>
## EJB 3.0 Support

OpenEJB 3.1 supports the EJB 3.0 specification as well as the prior EJB
2.1, EJB 2.0, and EJB 1.1.  New features in EJB 3.0 include:

 - Annotations instead of xml
 - No home interfaces
 - Business Interfaces
 - Dependency Injection
 - Interceptors
 - Java Persistence API
 - Service Locator (ala SessionContext.lookup)
 - POJO-style beans
 - JAX-WS Web Services

EJB 2.x features since OpenEJB 1.0 also include:
 - MessageDriven Beans
 - Container-Managed Persistence (CMP) 2.0
 - Timers

The two aspects of EJB that OpenEJB does not yet support are:
  - JAX-RPC
  - CORBA

CORBA support will be added in future releases.  Support for the JAX-RPC
API is not a planned feature.

<a name="OpenEJB3.1-EJBPluginforTomcat6and5.5"></a>
## EJB Plugin for Tomcat 6 and 5.5

OpenEJB 3.1 can be [plugged into](openejbx30:tomcat.html)
 any Tomcat 6 or Tomcat 5.5 server, adding support for EJBs in Web Apps. 
War files themselves can contain EJBs and the Servlets can use new JavaEE 5
annotations, XA transactions, JPA, and JMS.  Webapps can even support fat
java clients connecting over HTTP.

Don't use EJBs?  

No matter, adding OpenEJB to Tomcat gives Servlets several new Java EE 5
capabilities such as JPA, JAX-WS, JMS, J2EE Connectors, transactions, and
more as well as enhancing the injection features of Tomcat 6 to now support
injection of JavaEE objects like Topics, Queues, EntityManagers, JMS
ConnectionFactories, JavaMail Sessions, as well as simpler data types such
as Dates, Classes, URI, URL, List, Map, Set, Properties, and more. In the
case of Tomcat 5.5 which doesn't support dependency injection at all, even
more is gained.

<a name="OpenEJB3.1-SpringIntegration"></a>
## Spring Integration

Add OpenEJB 3.1 to your Spring application to gain the ability for EJBs to
be easily injected into Spring beans (and vice versa) and add Java EE 5
capabilities such as JPA, JAX-WS, JMS, J2EE Connectors, transactions, and
security.

See the [Spring](openejbx30:spring.html)
 page and [Spring Example|OPENEJBx30:Spring EJB and JPA]
 for an example.

<a name="OpenEJB3.1-MulticastDiscovery"></a>
## Multicast Discovery

Add the [openejb-multicast.jar](http://people.apache.org/repo/m2-ibiblio-rsync-repository/org/apache/openejb/openejb-multicast/3.1/openejb-multicast-3.1.jar)
 to your OpenEJB distributions lib/ directory and gain the ability to use
multicast discovery between clients and serves as well as between servers
allowing for request failover to other discovered servers.  Clients can
discover and access servers with a new "multicast://239.255.3.2:6142" url
as follows:


    Properties p = new Properties();
    p.put("java.naming.factory.initial",
"org.apache.openejb.client.RemoteInitialContextFactory");
    p.put("java.naming.provider.url", "multicast://239.255.3.2:6142");
    InitialContext ctx = new InitialContext(p);


<a name="OpenEJB3.1-RunsonOSGi"></a>
## Runs on OSGi

All OpenEJB 3.1 binaries come with complete OSGi metadata and are usable as
a bundle in any OSGi platform.	Look for OpenEJB in the upcoming,
OSGi-based ServiceMix 4 which is built on Apache Felix.

<a name="OpenEJB3.1-CMPviaJPA"></a>
## CMP via JPA

Our CMP implementation is a thin layer over the new Java Persistence API
(JPA).	This means when you deploy an old style CMP 1.1 or CMP 2.1 bean it
is internally converted and ran as a JPA bean.	This makes it possible to
use both CMP and JPA in the same application without any coherence issues
that can come from using two competing persistence technologies against the
same data.  Everything is ultimately JPA in the end.

<a name="OpenEJB3.1-DependencyInjection--Enums,Classes,Dates,Files,ohmy."></a>
## Dependency Injection -- Enums, Classes, Dates, Files, oh my.

Dependency Injection in EJB 3.0 via @Resource is largely limited to objects
provided by the container, such as DataSources, JMS Topics and Queues.	It
is possible for you to supply your own configuration information for
injection, but standard rules allow for only data of type String,
Character, Boolean, Integer, Short, Long, Double, Float and Byte.  If you
needed a URL, for example, you'd have to have it injected as a String then
convert it yourself to a URL.  This is just plain silly as the conversion
of Strings to other basic data types has existed in JavaBeans long before
Enterprise JavaBeans existed.

OpenEJB 3.1 supports injection of any data type for which you can supply a
JavaBeans PropertyEditor.  We include several built-in PropertyEditors
already such as Date, InetAddress, Class, File, URL, URI, Map, List, any
java.lang.Enum and more.

    import java.net.URI;
    import java.io.File;
    import java.util.Date;
    
    @Stateful 
    public class MyBean {
        @Resource URI blog;
        @Resource Date birthday;
        @Resource File homeDirectory;
    }


<a name="OpenEJB3.1-DependencyInjection--GenericCollectionsandMaps"></a>
## Dependency Injection -- Generic Collections and Maps

Support for Java Generics makes the dependency injection that much more
powerful.  Declare an injectable field that leverages Java Generics and we
will use that information to boost your injection to the next level.  For
example:

    import java.net.URI;
    import java.io.File;
    
    @Stateful 
    public class MyBean {
        @Resource List<Class> factories;
        @Resource Map<URI, File> locations;
    }


<a name="OpenEJB3.1-DependencyInjection--CustomTypes"></a>
## Dependency Injection -- Custom Types

You can easily add your own types or override the way built-in types are
handled and claim dependency injection as your own making it a critical
part of your architecture.  For example, let's register a custom editor for
our Pickup enum.


    import java.beans.PropertyEditorManager;
    
    public enum Pickup {
    
        HUMBUCKER,
        SINGLE_COIL;
    
        // Here's the little magic where we register the PickupEditor
        // which knows how to create this object from a string.
        // You can add any of your own Property Editors in the same way.
        static {
    	PropertyEditorManager.registerEditor(Pickup.class,
PickupEditor.class);
        }
    }



    @Stateful
    public class StratocasterImpl implements Stratocaster {
    
        @Resource(name = "pickups")
        private List<Pickup> pickups;
    }


<a name="OpenEJB3.1-TheMETA-INF/env-entries.properties"></a>
## The META-INF/env-entries.properties

Along the lines of injection, one of the last remaining things in EJB 3
that people need an ejb-jar.xml file for is to supply the value of
env-entries.  Env Entries are the source of data for all user supplied data
injected into your bean; the afore mentioned String, Boolean, Integer, etc.
 This is a very big burden as each env-entry is going to cost you 5 lines
of xml and the complication of having to figure out how to add you bean
declaration in xml as an override of an existing bean and not accidentally
as a new bean.	All this can be very painful when all you want is to supply
the value of a few @Resource String fields in you bean class.  

To fix this, OpenEJB supports the idea of a META-INF/env-entries.properties
file where we will look for the value of things that need injection that
are not container controlled resources (i.e. datasources and things of that
nature).  You can configure you ejbs via a properties file and skip the
need for an ejb-jar.xml and it's 5 lines per property madness.

    blog = http://acme.org/myblog
    birthday = 1954-03-01
    homeDirectory = /home/esmith/


<a name="OpenEJB3.1-SupportforGlassFishdescriptors"></a>
## Support for GlassFish descriptors

Unit testing EJBs with OpenEJB is a major feature and draw for people, even
for people who may still use other app servers for final deployment such as
Geronimo or GlassFish.	The descriptor format for Geronimo is natively
understood by OpenEJB as OpenEJB is the EJB Container provider for
Geronimo.  However, OpenEJB also supports the GlassFish descriptors so
people using GlassFish as their final server can still use OpenEJB for
testing EJBs via plain JUnit tests in their build and only have one set of
vendor descriptors to maintain.

<a name="OpenEJB3.1-JavaEE5EARandApplicationClientsupport"></a>
## JavaEE 5 EAR and Application Client support

JavaEE 5 EARs, RARs, and Application Clients can be deployed in addition to
ejb jars.  EAR support is limited to ejbs, application clients, RARs, and
libraries; WAR files will be ignored unless embedded in Tomcat.   Per the
JavaEE 5 spec, the META-INF/application.xml and
META-INF/application-client.xml files are optional.

<a name="OpenEJB3.1-ApplicationValidationforEJB3.0"></a>
##  Application Validation for EJB 3.0

Incorrect usage of various new aspects of EJB 3.0 are checked for and
reported during the deployment process preventing strange errors and
failures.

As usual validation failures (non-compliant issues with your application)
are printed out in complier-style "all-at-once" output allowing you to see
and fix all your issues in one go.  For example, if you have 10
@PersistenceContext annotations that reference an invalid persistence unit,
you get all 10 errors on the *first* deploy rather than one failure on the
first deploy with 9 more failed deployments to go.

Validation output comes in three levels.  The most verbose level will tell
you in detail what you did wrong, what the options are, and what to do
next... even including valid code and annotation usage tailored to your app
that you can copy and paste into your application.  Very ideal for
beginners and people using OpenEJB in a classroom setting.

Some example output might look like the following.  Here we illegally add
some annotations to the "Movies" bean's interface as well as use the wrong
annotations for various types of injection:

    FAIL ... Movies:  @Stateful cannot be applied to an interface: org.superbiz.injection.jpa.Movies
    FAIL ... Movies:  Missing required "type" attribute on class-level @Resource usage
    FAIL ... Movies:  Mistaken use of @Resource on an EntityManagerFactory reference.
                      Use @PersistenceUnit for ref "org.superbiz.injection.jpa.MoviesImpl/entityManagerFactory"
    FAIL ... Movies:  Mistaken use of @PersistenceUnit on an EntityManager reference.
                      Use @PersistenceContext for ref "org.superbiz.injection.jpa.MoviesImpl/entityManager"
    WARN ... Movies:  Inoring @RolesAllowed used on interface org.superbiz.injection.jpa.Movies method deleteMovie.
                      Annotation only usable on the bean class.
    WARN ... Movies:  Ignoring @TransactionAttribute used on interface org.superbiz.injection.jpa.Movies method addMovie.
                      Annotation only usable on the bean class.

    
## JNDI Name Formatting
    
A complication when using EJB is that plain client applications are at the
mercy of vendor's chosen methodology for how JNDI names should be
constructed.  OpenEJB breaks the mold by allowing you to [specify the exact format|OPENEJBx30:JNDI Names]
you'd like OpenEJB to use for your server or any individual application.
Supply us with a formatting string, such as
"ejb/\{ejbName}/\{interfaceClass.simpleName}", to get a JNDI layout that
best matches your needs.
    
# Changelog
    {swizzlejira}
    #set ( $jira =
$rss.fetch("http://issues.apache.org/jira/secure/IssueNavigator.jspa?view=rss&&pid=12310530&status=5&status=6&fixfor=12312761&tempMax=1000&reset=true&decorator=none")
)
    #set( $issues = $jira.issues )
    
### New Features:
    
    {swizzlejiraissues:issues=$as.param($issues.equals("type", "New
Feature").descending("id"))|columns=key;summary}
    
### Improvements:
    
    {swizzlejiraissues:issues=$as.param($issues.equals("type",
"Improvement"))|columns=key;summary}
    
### Tasks & Sub-Tasks:
    
    {swizzlejiraissues:issues=$as.param($issues.matches("type",
"Task|Sub-task").sort("summary"))|columns=key;summary}
    
    
    {swizzlejira}