| = New in OpenEJB 3.0 |
| :index-group: EJB |
| :jbake-date: 2018-12-05 |
| :jbake-type: page |
| :jbake-status: published |
| |
| == 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. |
| |
| = Extensions to EJB 3.0 |
| |
| == 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. |
| |
| == 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. |
| |
| [source,java] |
| ---- |
| 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; |
| } |
| ---- |
| |
| == 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. |
| |
| [source,properties] |
| ---- |
| blog = http://acme.org/myblog |
| birthday = locale=en_US style=MEDIUM Mar 1, 1954 |
| homeDirectory = /home/esmith/ |
| ---- |
| |
| == 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. |
| |
| == 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. |
| |
| == 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. |
| |
| == Most configurable JNDI names ever |
| |
| = General Improvements |
| |
| == Online Deployment ## Security Service ## Connection Pooling ## |
| Configuration Overriding ## Flexible JNDI Name Formatting ## Cleaner |
| Embedding ## Tomcat 6 Support ## Business locals remotable |
| |
| If you want to make business local interfaces remotable, you can set |
| this property: |
| |
| [source,properties] |
| ---- |
| 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. |