Home > Documentation > Apache Geronimo v1.1 - User's Guide > Migrating to Apache Geronimo > J2G Migration Tool > Using J2G |
J2G consists of three executable utilities with basic Eclipse IDE UI extensions. The "Configurator" component, and the three major components, each of which have relatively specific functions, and must be run in the order as follows.
The J2G tool set requires at least the following application versions
(these are the versions J2G is known to work on)
The tools in J2G require that the following environment variables be set to the proper locations:
To run this component, navigate to bin, and run j2g-configure
This will automatically copy the contents of the ./plugins, ./properties, and ./compatibility directories to ECLIPSE_HOME/plugins, as well as make changes to (or create, if necessary) ECLIPSE_HOME/configuration/config.ini.
This tool parses through source code (.java and .jsp files) recursively in directories passed to it as command line arguments. While doing this, it replaces any JBoss classes and dependencies for which there are Geronimo equivalents. If there is no equivalent, it will alert the user of this issue which must be resolved either through manual creation of a replacement class or rewriting the segment of code dependent on the JBoss class.
This tool converts JBoss specific deployment descriptors and J2EE standard deployment descriptors (if necessary) to their Geronimo equivalents.
This tool converts JBoss specific resources, such as Java Messaging Services (JMS) Queues, JMS Topics, Java Database Connectivity (JDBC) data sources to their Geronimo equivalents.
It is strongly advised to create a backup of the application source before running J2G
The Source Identification Tool should be started first. It scans the sources and identifies files that need to be changed during the migration process. These files include Java classes (.java files), JSPs (.jsp files), as well as files with an overridden JSP file extension, specified with the argument -jspext. (For example: -jspext html for .html files)
In these files, the tool checks for:
When the tool checks for usage of APIs incompatible with Geronimo, these JBoss classes are automatically replaced with Geronimo compatible classes
JBoss Class | Geronimo Compatible Class |
---|---|
org.jboss.security.SimplePrincipal | org.apache.geronimo.security.realm.providers.GeronimoUserPrincipal |
org.jboss.security.auth.spi.DigestCallback | org.apache.geronimo.j2g.sources.dependence.compatibility.DigestCallback |
org.jboss.security.Nobody | org.apache.geronimo.j2g.sources.dependence.compatibility.Nobody |
org.jboss.security.Anybody | org.apache.geronimo.j2g.sources.dependence.compatibility.Anybody |
org.jboss.security.auth.spi.UsernamePasswordLoginModule | org.apache.geronimo.j2g.sources.dependence.compatibility.GeronimoLoginModule |
org.jboss.security.SimpleGroup | org.apache.geronimo.j2g.sources.dependence.compatibility.GeronimoSimpleGroup |
Any references beyond the table above must be manually corrected so that they are no longer dependent on parts of JBoss. It's important to note that JSP file processing is limited to the identification of problems, and automatic correction is not currently supported.
When the tool validates J2EE naming it detects cases in which a component (a class or JSP) refers to a named object that is not a part of the application being converted (For example: a data source, JMS, or Email provider reference). In simple cases, when a component requests an external resource with a direct, full path and does not have any environment reference, the tool tries to fix this problem automatically by adding the resource reference to the component's deployment descriptor and replaces the direct path with the name of the added reference.
When a source file is changed automatically by the Source Identification Tool, the original version is saved with the .j2g extension and an informational message is printed out. In all other cases, when a problem needs to be fixed manually, the tool simply prints a warning message.
Additional drop-in replacements for JBoss specific classes can be user-defined by modifying <ECLIPSE_HOME>/plugins/org.apache.geronimo.j2g.sources.dependence/class_analogies.properties to include the proper relationship, as well as <ECLIPSE_HOME>/plugins/org.apache.geronimo.j2g.sources.dependence/compatible_sources.properties to include the class name. The source code for these replacement classes must be placed in the directory <ECLIPSE_HOME>/plugins/org.apache.geronimo.j2g.sources.dependence.compatibility for proper inclusion.
Classes that already exist within Geronimo jars can also be added into the class-analogies.properties file. These classes do not need to be placed within the compatibility directory but a dependency will have to be added to the corresponding xml in the converted application.
Below is an example of the default class_analogies.properties file
Below is an example of the default compatible_sources.properties file
To run this component within the Eclipse IDE GUI, the left panel must first be in Navigator view.
Once in the Navigator view, it is possible to right click and select J2G Migration from the context menu.
Within the J2G Migration sub menu, select "1. Source Identification Tool (jsrc2g)", and follow the prompts given.
Output will be displayed in the bottom portion of the Eclipse IDE, within the integrated Console window.
To run this component, execute the following command from the j2g bin directory, with <APPLICATION> representing the path to the application you are converting, and <GERONIMO_HOME> representing the path to Geronimo 1.1.1.
*nix
Windows
Note: To specify multiple sources for conversion, simply separate them with ,s (commas), as follows.
After the tool runs (which may take a few seconds, depending on system speed and the complexity of the application), it will display all warnings and errors to console output. These messages should be interpreted and corrected as seen fit by the user. Once changes have been made, the sources tool can be ran again to verify correctness.
The Descriptors Conversion Tool finds and tries to automatically convert the following deployment descriptors so that they are accepted by Geronimo:
Filename | Purpose |
---|---|
application.xml | J2EE application deployment descriptor |
jboss-app.xml | JBoss specific descriptor for elements such as security domain, class loader configuration as well as some others |
web.xml | Web application descriptor |
jboss-web.xml | JBoss specific descriptor for elements such as security roles, session settings, web service configuration. It is used to integrate a web application into JBoss deployment |
ejb-jar.xml | EJB deployment descriptor |
jboss.xml | JBoss descriptor providing any optional information like custom container configurations for the beans or JNDI names. It is used by JBoss but not described in the respective ejb-jar.xml |
jbosscmp-jdbc.xml | JBossCMP-JDBC configuration file describing CMP-Database mappings, and key generation information |
standardjbosscmp-jdbc.xml | Default JBossCMP-JDBC configuration file |
persistence.xml | Datasource connection configuration file |
Note: Geronimo uses OpenEJB, which requires its own descriptor (openejb-jar.xml). There may be some instances where a jboss.xml is not given. In these cases, the openejb-jar.xml will be created on the top-most level directory in the source path that is specified to J2G.
The standard EJB annotations are supported by both Geronimo and JBoss. There are differences, however, in the attributes provided in some of the annotations.
Below is a list of all standard attribute differences provided that may occur within the specified annotations.
Annotation | JBoss Attribute | Geronimo Attribute |
---|---|---|
Resource | mappedName | name |
EJB | mappedName | name |
MessageDriven | mappedName | name |
Stateful | mappedName | name |
Stateless | mappedName | name |
Any references beyond the table above must be manually corrected so that they are no longer dependent on parts of JBoss.
JBoss has their own EJB annotation extensions. These must be manually corrected as needed
Additional drop-in replacements for JBoss specific annotation attributes can be user-defined by modifying <ECLIPSE_HOME>/plugins/org.apache.geronimo.j2g.descriptors.ejb.annotation/annotation_differences.properties to include the proper relationship. Because the nature of these mappings are not one-to-one, we cannot format the properties in the traditional format of <annotation>=<attribute>. Instead, the proper formatting is as follows:
In the case of a standard EJB annotation
Where <annotation> is a standard EJB annotation
In the case of a standard jBoss specific to Geronimo compatible relationship
Where <j_attribute> is a JBoss supported attribute and <g_attribute> is a Geronimo supported attribute
Finally, in the case of needing multiple attribute mappings for a single annotation
Where <j_attribute> is a JBoss supported attribute and <g_attribute> is a Geronimo supported attribute
Below is an example of the default annotation_differences.properties file
When the tool checks for usage of EJB references incompatible with Geronimo, these JBoss EJB references are automatically replaced with Geronimo compatible OpenEJB references. Here is are the differences specified to change in the persistence.xml (used in EJB 3.0) so that the configurations are consistent.
JBoss EJB | Geronimo OpenEJB |
---|---|
hibernate.connection.url | openjpa.ConnectionURL |
hibernate.connection.driver_class | openjpa.ConnectionDriverName |
hibernate.connection.password | openjpa.ConnectionPassword |
hibernate.connection.username | openjpa.ConnectionUserName |
Any references beyond the table above must be manually corrected so that they are no longer dependent on parts of JBoss.
Additional drop-in replacements for JBoss specific annotations can be user-defined by modifying <ECLIPSE_HOME>/plugins/org.apache.geronimo.j2g.descriptors.ejb/persistence_differences.properties to include the proper relationship
Below is an example of the default persistence_differences.properties file
In order to just suggest to the user that X may be a replacement for Y (this is conditional because this is not a direct translation) the property can be written as <Y> = suggestion:<X>.
To run this component within the Eclipse IDE GUI, the left panel must first be in Navigator view.
Once in the Navigator view, it is possible to right click and select J2G Migration from the context menu.
Within the J2G Migration sub menu, select "2. Descriptors Conversion Tool (jdes2g)", and follow the prompts given.
Output will be displayed in the bottom portion of the Eclipse IDE, within the integrated Console window.
To start the Descriptors Conversion Tool run the following command from the j2g bin directory, again where <APPLICATION> represents the path to the application to be converted
*nix
Windows
The warnings given in the output of this tool will report only unsupported elements that cannot be automatically converted, and must therefore be manually resolved and converted. This process is heavily dependent on the structure of the application being converted, and is therefore beyond the scope of this document.
The Resource Migration Tool converts JBoss specific resources to their Geronimo equivalents. It processes the following types of resources:
To run this component within the Eclipse IDE GUI, the left panel must first be in Navigator view.
Once in the Navigator view, it is possible to right click and select J2G Migration from the context menu.
Within the J2G Migration sub menu, select "3. Resource Migration Tool (jres2g)", and follow the prompts given.
Output will be displayed in the bottom portion of the Eclipse IDE, within the integrated Console window.
To start the Resource Migration Tool run the following command from the j2g bin directory, again where <APPLICATION> represents the path to the application to be converted
*nix
Windows
The tool will output the name of each resource that is to be migrated, as well as informational, error, and warning messages with associated file names and line numbers. If migration of a resource is completed without errors, the tool will output a success message and generate the migrated resource in the same folder as the original one.
As with the other tools, the Error and Warning messages must be manually corrected to complete the conversion process, again which is heavily application specific and is beyond the scope of this document.
Once all of the above tools have been properly executed and there are no more errors or warnings, the converted application may now be built for Geronimo. Again, this is something that is extremely application specific and must be completely custom tailored in each individual situation.
After a successful build, the application should be able to be deployed in a running instance of Geronimo 1.1.1 without issue, however if it is not the errors displayed at deployment time must be resolved and the application must be rebuilt.
Bookmark this on Delicious Digg this | Privacy Policy - Copyright © 2003-2009, The Apache Software Foundation, Licensed under ASL 2.0. |