Title: New in OpenEJB 3.0
<a name="NewinOpenEJB3.0-EJB3.0"></a>
# EJB 3.0

OpenEJB 3.0 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
 - Intercpetors
 - Java Persistence API
 - Service Locator (ala SessionContext.lookup)
 - POJO-style beans

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:
  - Web Services (JAX-WS, JAX-RPC)
  - CORBA

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

<a name="NewinOpenEJB3.0-ExtensionstoEJB3.0"></a>
# Extensions to EJB 3.0

<a name="NewinOpenEJB3.0-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="NewinOpenEJB3.0-ExtendedDependencyInjection"></a>
## Extended Dependency Injection

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.0 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 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="NewinOpenEJB3.0-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 = locale=en_US style=MEDIUM Mar 1, 1954
    homeDirectory = /home/esmith/


<a name="NewinOpenEJB3.0-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="NewinOpenEJB3.0-JavaEE5EARandApplicationClientsupport"></a>
## JavaEE 5 EAR and Application Client support

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

<a name="NewinOpenEJB3.0-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.

<a name="NewinOpenEJB3.0-MostconfigurableJNDInamesever"></a>
##  Most configurable JNDI names ever

<a name="NewinOpenEJB3.0-GeneralImprovements"></a>
# General Improvements

<a name="NewinOpenEJB3.0-OnlineDeployment"></a>
##  Online Deployment
<a name="NewinOpenEJB3.0-SecurityService"></a>
##  Security Service
<a name="NewinOpenEJB3.0-ConnectionPooling"></a>
##  Connection Pooling
<a name="NewinOpenEJB3.0-ConfigurationOverriding"></a>
##  Configuration Overriding
<a name="NewinOpenEJB3.0-FlexibleJNDINameFormatting"></a>
##  Flexible JNDI Name Formatting
<a name="NewinOpenEJB3.0-CleanerEmbedding"></a>
##  Cleaner Embedding
<a name="NewinOpenEJB3.0-Tomcat6Support"></a>
##  Tomcat 6 Support
<a name="NewinOpenEJB3.0-Businesslocalsremotable"></a>
##  Business locals remotable

If you want to make business local interfaces remotable, you can set this
property:

      openejb.remotable.businessLocals=true

Then you can lookup your business local interfaces from remote clients.

You'd still have to ensure that the you pass back and forth is
serializable.