Using Express Development in Pramati Studio

J2EE architecture defines the typical EJB component development lifecycle as create, assemble, deploy, and run the application. Express Development provides an easy programming archetype by automating the tasks in a typical J2EE development life cycle.

Auto-interface generation

Auto-compilation of interfaces

Auto-packaging

Auto-updation

One-shot deployment

This chapter describes Express Development in Studio and its features in detail.

Advantages of Express Development

For J2EE development, it is necessary to create, assemble, and deploy each J2EE module in an application according to the specification. Express Development allows assembling and updation of changed components to be automated with default values and always keeps the desk root, EJB modules and web modules ready-to-deploy; the default values can be modified.

Beginners can deploy applications without getting trapped in the complicated specifications of J2EE deployment

Allows easy migration from the Express Development archetype to a typical J2EE development archetype by using Export as Archive option

Speeds up development time by keeping a track of all changes and updating them

Takes care of all repetitive steps in a typical J2EE development

Compilation of any one bean file such as, Home interface, Remote interface, bean class, Local interface, and Local Home interface

Clean build of EJB module

Saving bean properties

Status of each event is displayed as a node in the Express Development tab of output panel. The status is shown by means of icons and colors. Each event triggered has processes that are displayed as sub-nodes under the main node. These tasks are marked as they are completed with unsuccessful events displayed in red, and successful ones in blue. For example, clean building a module or file creates a separate node in the tree, and successful completion of the task depends on completion of all sub-nodes. The main node does not change its status until all sub-nodes have been completed. Actions that can be performed in Express Development tab in output panel are:

To copy a text from Express Development tab to a file, select a node, click `Copy Selected' icon, and paste in the file

To search for a text, click `Find Text' icon. Enter the text to be found in the Search for dialog and press enter

To clear all the text in the Express Development tab, click `Clear' icon or right click anywhere in the Express Development tab and select Clear All

To view the subnodes for a tree node, select the node and click `Expand Tree' icon

To collapse a tree node, select a node and click `Collapse Tree' icon

To delete a node and all sub nodes from the tree, right click on it and select `Remove This'

Right click anywhere in the Express Development tab and select `Show TimeStamp' to view system date and time. This is a toggle item and once used, it becomes `Hide TimeStamp'. Click on this to hide the system date and time

To hide Express Development tab, right click on the tab and select `Hide This'. To hide all other tabs except Express Development, right click on the tab name an select `Hide All Except This'. To view all tabs again, right click on this tab and select `Show All'

EJB module is a source root stored directly under desk node in the desk tree hierarchy; it is always in a ready-to-deploy state. EJB module represents an extracted archive view of ejb-jar and provides with all added functions of Express Development.

EJB 1.1: Represents EJB 1.1 JAR which maintains the EJB 1.1 semantics. Beans with EJB 2.0 semantics cannot be added to this module

EJB 2.0: Represents EJB 2.0 JAR with EJB 2.0 semantics. Modules of this type can include both version 1.1 and 2.0 beans

It is always in a "ready-to-deploy" state. The module need not be packaged into a JAR to make it deployable

It is aware of all changes made to its beans, automatically packages the beans, updates packaging and deployment information based on J2EE packaging specifications

It is enabled for multi-server deployment

It can be converted into a JAR on a single click using `Export As Archive' option

It can be opened using Package Tool and all packaging information can be viewed here

It can be opened using Deploy Tool and all deployment information can be modified here

The module supports multiple ejb-names

Changes made to bean properties in one module get reflected automatically in other modules holding the same bean

File structure of EJB module created by Express Development

Creating a bean in EJB module using Bean Wizard, generates the bean class file, bean, its interfaces, and compiles them, automatically. The classes directory of EJB module is set by Studio based on module name and is placed under the desk classes directory specified at desk creation time; it cannot be modified. For example, if the EJB module name is TestEJB, the classes are stored in the directory <Desk-classes-dir>/TestEJB. This is set so that Express Development can maintain physical separation between different modules and treat them as virtual ejb-jars.

Modifying EJB module properties

Packaging information in ejb-jar.xml for a bean under EJB module is generated from the information provided in bean properties of that bean. Any changes made to the packaging information in bean properties is picked up by Express Development. Use Bean Properties panel to change any packaging information. To open Bean Properties panel, right click on the bean properties node in the desk and select Open or double click on the node. The attributes that can be set here are:

EJB references

Resource references

Resource environment references

Environment entries

Transaction attributes

CMP fields for CMP bean

O-R mapping for CMP beans

Finder or Select queries for CMP beans

Modifying packaging properties

Express Development generates ejb-jar.xml file automatically. The ejb-jar.xml comprises of enterprise beans in addition to packaging information, so that the module functions as a complete EJB application and is ready-to-deploy. The ejb-jar file must contain class files of each enterprise bean either by inclusion or by reference. The class files are:

Enterprise bean class

Enterprise bean home and component interfaces

Primary key class if the bean is an entity bean

To view the ejb-jar.xml properties, right click on the EJB module and select ejb-jar.xml. This provides an archive view of the JAR.

This panel allows you to add and make changes to the Security Roles. All other changes to be made should be made in the Bean Properties panel. EJB module displays all the beans to be deployed and their properties such as:

EJB references

Resource references

Security roles

Method permissions

Transaction attributes

Environment entries

Container Managed Fields (CMF)

Container Managed Relationship (CMR) data

Finder or select method

Deleting a bean from the EJB module

Deleting a bean from the desk automatically removes all beans holding relationships with that bean from the ejb-jar.xml for that module. The related beans are not physically removed. This process is repeated until ejb-jar.xml is consistent as per EJB specifications. The XML is updated accordingly and all related deployment information is modified and updated. To reconstruct the JAR, new relationships should be created again using the Relationship Manager or by editing bean sources, manually. To add any removed beans, compile them in the desk. This triggers Express Development to add these beans back to ejb-jar.xml.

Modifying deployment properties for EJB module

pramati-j2ee-server.xml and

pramati-or-map.xml

The deployment information is taken from bean properties. Changes made here all are placed in the appropriate Bean Properties panel. Deployment information can be examined and modified for any target server by opening the EJB module as an archive file in Deploy Tool, and saving this information. To open and modify the module in Deploy tool, select Tools > Deploy, and in the Deploy Tool, select Archive > Open > Module Name.

Configuring EJB module components to be deployed

The EJB module can be configured to include or exclude sub-components to be deployed. Right click on the module and select Properties. In Properties panel, select the Deploy tab.

Here, Beans option in the Include field allows beans to be marked as deployable or non-deployable. Non-deployable beans are ignored by Express Development. Unchecking a bean marks it as non-deployable and removes it from packaging information. Other properties that can be configured are files and folders. In this case, the files and folders to be deployed with the JAR can be selected manually.

Modifying Queries

Information on all queries for EJB 1.1 modules are stored in the queries.props file. This information is also available in Finders node in Bean Properties panel. To modify any query, use this panel. For more information, read `Designing Queries using the Query Manager in Studio'.

Exporting into Java archives

The `Export as Archive' option ask s you to choose the destination. The following files are available in the exported Java archive:

All files under classes directory of the module including packaging and deployment XMLs and queries.props file for EJB 1.1 modules

If the option under Properties > Deploy tab is checked, all classes mentioned in the ejb-reference tab of packaging information along with custom classes that are used as method parameters, exception classes, or return values according to packaging information are picked up based on JNDI names. If JNDI name is missing, the selection is based on classpath. If the classes cannot be found, the operation will not stop

All files under all folders mentioned in the Include Files option in the Properties panel

All non-Java files on the desk in the module

The exported Java archive can be used in the desk like any other ejb-jar created using Package Tool; it is enabled for updation. Right click on the JAR and select Update to pick new packaging information. As per Update Operation semantics for Package Tool, the deployment information does not get updated. For Example, if we change finder or select methods, the update option will not work. `Export as Archive' option should be selected again on the module.

Filtering files for exporting EJB module as an archive

You can filter files to be excluded when an EJB module is exported as an archive. Filters are stored in the file <ModuleName>ExportAsArchiveFitlers.props located under the desk root directory. Files matching any of the provided patterns in this file are removed from the archive, automatically. For example, to exclude all CVS files from an exported archive, edit the files in the module for filters by adding the entry <ModuleName>.<filterNum>=*CVS/* as the pattern to exclude. The default patterns that are used for EJB modules is *.java. The filter files can be edited any time. The changes is pick up the next time `Export as Archive' operation is performed.

A web module is a folder directly under desk node in the desk tree hierarchy and is always in a ready-to-deploy state. Web module represents the archive view of WAR in the desk and provides you with all the added functions of Express Development. There can be more than one web module in a desk but two web modules can not point to the same source root directory in the file system. Web module has the following benefits with Express Development:

It keeps all components updated, with the latest packaging and deployment information based on J2EE Packaging rules

It can be deployed without converting into a WAR

It is always ready for deployment on multiple servers

The web-server picks up JSP files directly from the web module. To update any JSP file, open the file in Editor, make the required changes, and save. The application need not be re-deployed

As a web module points to a source root in the file system, servlets can be stored in any module and then deployed with a web module

It can be converted into a WAR

It can be modified using Package Tool as well as Deploy Tool

File structure of a web module

Files are organized under Web module with the classes directory defined according to the J2EE specification and cannot be modified. It is constructed by <Web module Location>/WEB-INF/classes.

Modifying web module properties

The web module automatically generates web.xml file when required. To modify web component properties:

Right click on the web module and choose web.xml. Redeploy the application so that the server picks up the changes. To modify any packaging and deployment information, right click on the module and select web.xml to open the file.

Deployment information can be examined and modified for any target server by opening the module in Deploy Tool and saving this information

Open Properties panel by right clicking on the web module; select the Deploy tab. All deployable sub-components can be configured here. The Servlets/Filters option allows servlets and filters to be marked as deployable or non-deployable. All available servlets and filters can be deployed on any web module. Class names must be unique. A successful compilation recompiles and adds the servlet or filter to the classes directory of the web module

References can be auto-packaged into the supportingClasses.jar each time the web module is deployed. This can be triggered by using Deploy tab in the Properties panel.

Deploying web module

To deploy a web module, right click on the module node and select Deploy. If the deployment information is incomplete and reasonable defaults are not available for that option, Deploy Tool opens where all pending tasks can be completed. The changes made are saved into the module and corresponding web module files. Changes made to the JSPs are reflected when they are saved, and the module need not be redeployed. If the interfaces of the referenced beans are modified, the module must be redeployed to reflect these changes. This is especially important when references are auto-packaged into supportingClasses.jar as this JAR is updated only on deployment.

Picking Servlets and Filters classes

To pick up Servlets/Filters from a web module classpath and add them to the web.xml file:

Right Click on the web module node and select Properties; select Deploy tab in this panel.

In the Include field, select the option, Servlets/Filters from the dropdown.

Click `Servlets' button to pick Servlets from a JAR under WEB-INF/lib. Clicking `Filters' button allows you to pick Filters from a JAR under WEB-INF/lib. Clicking any of these buttons opens a dialog that scans the JARs and looks for Servlets or Filters.

The Scanning dialog displays Servlets or Filters as they are found. You need not wait for the scanning to end. At any point, you can select the classes required and click OK. This interrupts the process and displays all the Servlets or Filters in Deploy tab.

Servlets or Filters selected from the classpath, appear in the table. Added Servlets and Filters are selected and in Deploy column, to be added to web.xml. To remove them from web.xml, uncheck the Servlet or Filter name.

Exporting web module into web archive

To convert the web module into a physical archive visible in the desk, right click on the module and select Export as Archive. Before exporting into an archive, ensure that a WAR archive node exists in the desk. Selecting Export as Archive prompts for the destination. The files that are added to the archived WAR are:

All files under the web module, including packaging and deployment XMLs, also all files that may not be present in the desk

Selecting `Export as Archive' option under Properties > Deploy Tab adds all classes mentioned in EJB Reference in web.xml along with custom classes that are used as method parameters, exception classes, or return values. These classes are picked up based on JNDI names; if JNDI name is missing, classes are picked from the classpath. The process is not stopped even when these classes are not found

All files and the files under all folders listed in Include folders option

Exported archive can be used in the desk like any other WAR created using Package Tool. It is enabled for updation, and right clicking on the file and selecting Update picks up all the latest packaging information, but deployment information is not updated.

Modifying context root of a web module

When a web module is deployed, the context root is taken as the web module name. To modify the context root, refer to the methods explained in the following sections.

Method1

The first method involves creating a new web module with a name same as the context root name, and then deploying it as follows:

Create a new web module with the same name as context root.

Import all required files into this module and close the desk.

Copy web.xml file of the old web module into new web module. The web.xml file is stored at <install_dir>/<desk_dir>/<webmod_dir>/WEB-INF.

Copy pramati-j2ee-server.xml from the old module into new. This file is stored at <install_dir>/<desk_dir>/<webmod_dir>.

Re-open the desk in Studio.

To deploy the new module, right click on the web module node and select Deploy.

To access the application, run JSP client. For example, http://localhost:8181/context_root/test.jsp, where context_root is the name of the new web module and test.jsp is the JSP client used to access the WAR.

Method 2

This method involves creating a WAR using the Export As Archive option, and changing the context root of the WAR file created.

Create a WAR by right clicking on the Web module node in the Explore Panel and selecting the option, Exporting As Archive

Select Tools > Deploy from the main menu. This starts the server and brings up the Deploy Tool

Open the WAR file in the Deploy Tool

In the WAR file that opens, Select the Web Properties node in the Tool, and modify the context root

Save the Archive by clicking on Archive > Save from the main menu

Deploy the WAR by clicking on Archive > Deploy from the main menu

Access the application by running the JSP client. For example, http://localhost:8181/context_root/test.jsp, where context_root is the name of the new Web module, and test.jsp the JSP client used to access the WAR. Alternatively, right click on the JSP file node in the Explore Panel and select Run. This method allows the new Web module to take advantage of all the Express Development features

Method 3

This method involves creating a WAR, adding it to an EAR and then deploying the application as an EAR.

Create a WAR using the Package Tool or by Exporting the Web module as an archive

Add all the Web contents (JSP files, Servlets etc.) into the WAR, if it was created using the Package Tool. Using the option, Export As archive automatically adds all the contents

Create an EAR using the Package Tool

Add the WAR to the EAR. When the WAR is being added to the EAR, enter the context root when prompted

Deploy the EAR

Filtering Files for Exporting

The exported archive picks up all available files in the Web module for performance reasons. This may result in certain unnecessary files getting packaged, increasing the WAR file size. These files include Java source files, map files used by the Debugger. The Filtering Files option helps avoid this situation, by not including these unnecessary Java source and map files.

Files can be filtered to be excluded when a Web module is exported as an archive. Filters are stored in a file named <ModuleName>ExportAsArchiveFitlers.props located under the Desk Root directory. File matching any of the provided patterns in this file, are automatically removed from the archive.

Always use / to indicate path names. The default patterns that are used for Web modules are *.java, *.map

The filter files can be edited any time. The changes get picked up the next time the operation, Export as Archive is performed. Filter Patterns are not applied on the supportingClasses.jar.

Desk Root

A Desk Root is a virtual representation of a J2EE desk, and is stored. The Desk Root acts as the node containing the entire J2EE application. It represents the archive view of the EAR in the desk and provides the user with all the added functions of Express Development.

Using the option Deploy available on a right click deploys the modules under the Desk Root. Using Deploy as EAR, available on a right click deploys the application as an enterprise archive. If all the settings required for deployment are not provided, the deploy tool comes up so that the user can make the required changes.

Changes made in the Deploy Tool are not persisted when the desk is deployed as an EAR. The application gets deployed with the changed deployment information only for the current deployment. The JSP Pages are also not refreshed automatically in this case. But, When a JSP page is changed and saved, the changes reflect without redeployment.

Exporting into Enterprise Archives

To smoothen the progress of moving from the Express Development mode of working to the typical J2EE mode of working, use the Export As Archive option. This option converts the Desk Root node into a physical enterprise archive (EAR).

To do this, right click on the Desk Root node in the Explore Panel and select Export as Archive. This converts it into a physical archive in the desk. To export the Desk Root into an EAR, the desk must have a folder of the type, enterprise archive.

These archives are complete J2EE archives and comprise the deployment descriptors (XML files) and can be deployed on the Server or opened in Studio to be modified. These archives have an independent existence from their source. Changes here do not get reflected anywhere else.

Validating the Desk Root

The Desk Root can be validated before deploying, to verify that all tasks to be performed by the bean provider, as mentioned in the EJB 2.0 specification, are complete.

To validate the Desk Root, right click on the Desk Root node in the Explore Panel and select Validate. This exports the Desk Root into an enterprise archive (EAR), and then validates the archive created.

Configuring Deployable Modules

The desk can be deployed without all the modules under it. This is especially useful when the desk contains modules that are still being developed, or are incomplete. To do this, right click on the desk tree node and select Properties. In the Properties panel that comes up, click on the Deploy tab, and uncheck the modules that are not to be deployed. The modules that are unchecked are not included in any of the operations - Deploy, Validate, or Export as Archive.

Pending Tasks

Express Development keeps track of user operations and tries to keep the application in a state where all the common, error-prone, manual tasks have been automated. To achieve this, it uses certain user operations like triggers. Example, Bean compilation is treated as trigger. Such triggers result in requests that have to be processed sequentially. Some of these requests may take some time to get executed. This results in stopping all other operations until the request is executed completely. For example, deployment requests may take a long time to execute completely. When the user invokes an operation that requires UI feedback like validation, displaying packaging properties, or exporting as archive, the operation may not be executed immediately because of pending tasks. Pending task are tasks in Studio that are yet to be executed.

The Express Development Pending Tasks Panel in such a case, pops-up in the Status Bar and shows all the pending tasks of the different modules. When the specified tasks are executed successfully, the panel disappears from the Status bar. This panel can also be hidden by clicking on the Hide button.

Troubleshooting Tips

The EJB module, Web module or the Desk Root in the desk may not reflect the specified settings of the application. To solve this, Right Click on the Desk Root/EJB module/Web module > Properties. This brings up the Properties dialog box. Click on the Repair tab and use the Sync State button to forcibly regenerate all the deployment information.