Application overview

Assuming you have accumulated lots of archival data CDs from your computer, each of them includes rich of information you ever collected. The collection of those archived CDs is your valuable knowledge asset, and certainly you want to manage them carefully and orderly for easy references in the future. The DataCDInfo sample application is about to assist you with this task.

With this application, you can register a user, and then login to add records for your archived CDs. You can record detail information that is not suitable to label on CD surface, such as detailed list of data CD content, archived date, and size of the CD.

This application pre-defines some admin roles who will be able to view overall recorded CDs and help retrieve user's forgotten password.

In short words, DataCDInfo is a simple CRUD(Create, Retrieve, Update and Delete) application, which adopts Struts1, JPA, JTA, and security annotation techniques.

Application contents

DataCDInfo uses the typical Java EE application structure, which includes an EJB module, an Web module and an EAR module.

The EJB module

The EJB module includes the major business logic of an application. It consists of JPA entity beans, a stateless session bean, a stateful session bean and some exception classes.

Two JPA entity beans: DataCDBean and OwnerBean, which represents Data CD records and Owner records respectively. The relationship bewteen OwnerBean and DataCDBean is 1...*, one owner could have multiple Data CDs.

The DataCDInfoJTAImpl is a stateless session bean which implements the business logic of DataCDInfo application, including login, registration/unregistration of the owner, and add/update/removal of data CD records. DataCDInfoLocal and DataCDInfoRemote is the local and remote business interface respectively.

The DataCDInfoAdmin is a stateful session, in which there is an EXTENDED persistence context. By default, a container-managed persistence context is of type TRANSACTION. The EXTENDED persistence context can only be initiated within the scope of a stateful session bean.

The DataCDInfoAdmin defines two roles "superadmin" and "admin" with security annotation @RolesAllowed. In the code, the role "superadmin" can access all three methods, while the role "admin" can only access "listOwners" method. Another way to define the access is via EJB deployment descriptor ejb-jar.mxl. The configurations in ejb-jar.xml file will override the ones in code already.
As shown below, the role "admin" also has access to method "listAllDataCDs" besides the method "listOwners" defined in the code because of configuration in its ejb-jar.xml.

ejb-jar.xml

A persistence unit is defined via META-INF/persistence.xml as shown below.

persistence.xml

Icon

If the persistence context requires some non-transactional operations, such as table sequence generation, you have to define a non-jta-data-source as well. Otherwise, you will encounter an exception like org.apache.openjpa.persistence.RollbackException: The transaction has been rolled back.

The Web Module

All Struts1 objects are in the Web module. A typical Struts1 web application uses a configuration file to initialize its resources. Those resources include ActionForms to collect input from users, ActionMappings to direct input to server-side Actions, and ActionForwards to select output pages.(Quoted from Struts1 documentation).

The DataCDInfo application web module consists of:

Struts1 ActionForm: DataCDForm and OwnerForm.

Those two ActionForm classes extend Struts1 ValidatorForm in order to utilize the convenient validation feature provided by Struts1.

You might have noticed that these two classes are very similar to the JPA entity beans. The design is one of requirements in Struts1, so that the view model is separated from the backend business model. To convey data between Struts1 form view and business logic beans, you can use org.apache.commons.beanutils.PropertyUtils method.

Struts1 Action: DataCDActions and OwnerActions

Those two Action classes extend Struts1 MappingDispatchAction, so that business related actions could be in the same Action class. For more details, check the API doc of MappingDispatchAction.

Those two Action classes wrap form data and call the corresponding business operations to persist the data into database.

Struts1 uses the standard globalization way that Java language provides to present messages for different locale.

The sample includes message resources files for both en_US and zh_CN locales. You can extends the locale support by adding additional locale resource files to the resources directory, and then run a new build for later deployment.

Struts1 configuration files: struts-config.xml and validation.xml

The struts-config.xml file is the main configuration file of a Struts1 application. All mandatory informations of a Struts1 artifact such as ActionForm, Actions, ActionMapping, and Validator, should all be defined in this file.

The{{validation.xml}} file defines the validation rules used by the application. Struts1 provides a simple validator for number and date verification.

Struts1 view JSPs: view/jsp/*.jsp

The common Struts1 taglibs are used in those JSPs. They are part of standard Struts1 view technologies. Struts1 supports several different view technologies, such as Velocity, Tiles, and etc.

Besides the artifacts of Struts1, there are some other artifacts used for DataCDInfo admin logic operations:

DataCDInfoAdminServlet – A servlet used to call security-controlled business methods defined in DataCDInfoAdmin stateful session bean.

admin/. – The presentation files of DataCDInfo admin operations

auth/. – The files used to FORM authentication. By default, the DataCDInfo application uses BASIC authentication. If you want to see what a FORM authentication looks like, you can modify web.xml as follows:

The EAR module

The EAR module contains database creation scripts and the application deployment plan. The application deployment plan will override the duplicate configurations defined in the EJB module and Web module.

In the application deployment plan, there are definitions about the web context root and the security realm used to authenticate the admin operations.

Web module definition in geronimo-application.xml

The DataCDInfo application uses the default geronimo security realm geronimo-admin, which is a .properties file-based realm. To enable "superadmin" role used by this application, these .properties files in /var/security must be modified before starting Geronimo server:

Add a new group in <geronimo_home>/var/security/groups.properties

Set the password for the new user in <geronimo_home>/var/security/users.properties

Icon

The plain text password will be encrypted when the geronimo server restarts.

Two datasources are defined in the deployment plan. jdbc/DataCDInfoDS is for JTA scenarioa, and jdbc/NoTxDataCDInfoDS for non-JTA.

Datasources in geronimo-application.xml

To map the application security roles to Geronimo security roles, the deployment plan must include configurations as below:

Security Roles Mapping in geronimo-application.xml

Besides the default deployment plan, there is another plan for MySQL database. You can enable the database by using deploy command:

Run Application

Using geronimo admin console to deploy the application.

Running DataCDInfo

If you just use "admin" role(for example, use "system" account defined in the geronimo-admin realm) to pass the authentication of DataCDInfo Admin resources, you will see an exception like this when trying to view the owner's password.