CE 3.0 provides backward compatibility to Java EE 5 compliant applications. If you have applications running on Geronimo 2.x successfully, you can easily port them to Geronimo 3.0. However, there are a few updates you need to consider as followed.
Classloading options in the deployment plan
- hidden-classes The deployment codes in Geronimo 3.0 will covert hidden-classes configuration to import-package style. For exmaple,
- non-overridable-classes Geronimo 3.0 does not support the element in the deployment plan.
- private-classes Geronimo 3.0 does not support the element in the deployment plan.
- inverse-classloading Geronimo 3.0 does not support the element in the deployment plan.
DB initialization at deployment time
To initialize a database using deployment plan file,
org.apache.geronimo.connector.DatabaseInitializationGBean in 2.X should be changed to
JavaMail session generation and resource lookup
There are following changes regarding Java Mail configuration in Geronimo 3.0.
- To generate JavaMaill sessions using deployment plan file,
org.apache.geronimo.mail.MailGBeanin 2.X should be changed to
- To configure JavaMail SMTP transport protocal using deployment plan file,
org.apache.geronimo.mail.SMTPTransportGBeanin 2.X should be changed to
- JNDI names of mailGBean should start with
java:prefix. For example: should be changed to
The following table lists the changes of some components name from Geronimo 2.x to 3.0.
Servlets expecting multipart request
In Servlet 3.0, an annotation @MultiPartConfig has been introduced to indicate that the servlet expects request of type multipart. You need to enable the feature in your deployment plan file as followed:
Changes regarding EJB component
In Geronimo 3.0, resources are imported and exported using different elements in deployment plan.
For a standalone EJB module
If your EJB application is a standalone module, you need to export its package in the deployment plan file under name space of
http://geronimo.apache.org/xml/ns/deployment-1.2. For example:
While for any modules which call the deployed EJB, you need to import the EJB package in the deployment plan using the same name space. For example:
For a web application referring EJB interfaces
If your web application refers to a standalone EJB module, you need to specify the artifact id of the EJB module in the deployment plan file of you web application. For example:
For an EJB module embedded in EAR
If an EAR application contains an application client module, an EJB module and web application module. If the application client refers to one of ejb interfaces using following code:
Although the ejb.jar is defined in its class-path using
manifest.mf file, the EJB interface is not in its class path. You need to package the ejb module into the EAR using the following structure:
If you want to use shared libraries, make sure you specifies the value of
baseDir attribute for gbean reference class. See Using shared libraries in your applications for more details.