C H A P T E R 2 - Web Application Framework Apps Tab Overview

This chapter provides an overview of the Web Application Framework Apps tab (formerly Sun ONE Web Apps tab) and explores each of this tab's primary nodes.

The Web Application Framework Apps tab presents your Web Application Framework application in an intuitive and logical view.

The following figure shows the Web Application Framework Apps tab and its three primary nodes.

You will spend most of your time in the Application Classes node where you will select Web Application Framework components to configure properties and add events and custom code. This document explores each of these nodes in detail.

Web Application Framework Apps Root Node

The node at the top of the Web Application Framework Apps tab is the anchor node under which you mount one or more Web Application Framework applications. When you have two or more Web Application Framework applications mounted, they are considered separate applications that will be deployed as such (as separate WAR files).

Web Application Framework Apps Root Node Contextual Menu Commands

When you select the Web Application Framework Apps Root Node and right-click, the contextual menu displays menu items described below:

To create a new Web Application Framework application, select the Sun Java Studio Enterprise 6 menu option File | New (or click the New toolbar button, which should be the first icon at the top left of the Sun Java Studio Enterprise 6, located just below the File menu option). The Choose Template panel is displayed. The Choose Template panel contains all of the available Sun Java Studio Enterprise 6 template wizards.

The Web Application Framework wizards can be found in the Web Application Framework node. Expand this node and select Application. Alternatively, you can click the New Web Application Framework App toolbar button found on the toolbar located at the top of the Web Application Framework tab. A subset of this toolbar might also be visible on the Sun Java Studio Enterprise 6 main toolbar (just under the menu options). All of these techniques invoke the same wizard. Creating a new Web Application Framework application effectively mounts the new application.

If you have a Web Application Framework application (version 2.x) that was previously created, but is not mounted in the Sun Java Studio Enterprise 6, and you want to have it mounted, you can do so by clicking the Mount Web Application Framework toolbar button which is located just to the right of the New Web Application Framework Apps toolbar button.

There is also a Sun Java Studio Enterprise 6 File menu option and a right-click action on the root node of the Web Application Framework Apps tab. This node is called Web Application Framework App. Using any of these techniques launches a file system browser/chooser dialog. You can navigate the file system on your computer or network to where the desired Web Application Framework application is located. Folders that are the root of a Web Application Framework application will be displayed with the Web Application Framework application icon (three overlapping rectangles). Select the Web Application Framework application that you want and click the Mount button found in the dialog window. Your Web Application Framework application will be appropriately mounted into the Sun Java Studio Enterprise 6.

Currently, this action opens a browser window to the Web Application Framework web page. The intent of this action is to target a website that would be repository of third party Web Application Framework components that could be downloaded for use in your Web Application Framework application. Such a repository does not currently exist. For more details on creating third party Web Application Framework components, consult the Sun Java Studio's Web Application Framework Component Author's Guide.

Web Application Framework Application Node

Directly under the Web Application Framework Apps root node there will be zero, one, or more mounted Web Application Framework application nodes. Each mounted Web Application Framework application node is depicted by a yellow cube with a green globe in the center of the cube. The name of these nodes is the display name of the Web application. The display name is an actual element entry in the deployment descriptor file (web.xml) located in the WEB-INF directory of the Web application. The actual file system directory name might be something entirely different. This is known as the web context name of your Web application. It is also the web documents root directory.

Web Application Framework Application Node Contextual Menu Commands

This node has several contextual menu commands. You will use a few of these actions to prepare your Web Application Framework application for execution.

You will probably not use the Execute action for this node since this action does not directly execute any Web Application Framework page components in your Web Application Framework application.

The Execute action launches a browser window and attempts to load the index.html file in the documents root of your Web application. If a file named index.html does not exist, it loads the welcome file that is declared in the deployment descriptor file (web.xml) located in the WEB-INF directory of your Web application.

A default welcome file is created when you create a Web Application Framework application. It is a simple HTML file with a standard welcome message. This default welcome page is named index.html and is located in the Documents folder of your Web application. You can customize this file, but it is not a mandatory component of a Web Application Framework application.

If there is no index.html file in the documents root directory, and there is no welcome file declared in the deployment descriptor, a standard directory listing of the documents root is displayed in the browser window.

The index.html or welcome page can be configured to redirect to a particular Web Application Framework page component in your Web Application Framework application (login page, main menu page, and so on).

This performs the same behavior as the Execute action, except that it forces the application to be redeployed to the target server, and the server to be restarted. This ensures that any changes are picked up, rather than using the Web application components that might be in memory. If the application needs to be compiled, it compiles (compile all) the application as needed before it is deployed and executed.

The deploys the Web application to the target server where it can be executed. Use this action when you have made a change to the Web application and want to perform a test run. If the application needs to be compiled, it will compile (compile all) the application as needed before it is deployed.

If you have created a custom or acquired a third party Web Application Framework component library, this action allows you to navigate to its file system location and select it. The component library will be copied to your application's WEB-INF/lib directory and the IDE mounts it. The library must be a Web Application Framework component library. This action is expecting a certain configuration file (complib.xml) contained within the JAR file that declares it to be such. For more details on creating third party component libraries, consult the Sun Java Studio's Web Application Framework Component Author's Guide.

It might take the Sun Java Studio Enterprise 6 some time to recognize the new library file addition. This time interval is a property of the Filesystems root node in the Filesystems tab. You can configure this to be a shorter interval if you choose, but do not make it so frequent that the IDE performance is hindered. Alternatively, you can manually force the Sun Java Studio Enterprise 6 to refresh its folder state by right-clicking the folder node that is the parent of the new file addition (WEB-INF/lib in this case), and select the Refresh Folder action.

This compiles files in the current directory that are new or have changed since the last compile. The up-to-date check is done by comparing timestamps between the source (.java) and products (.class) of the compile. This command does not compile the files in subfolders.

This compiles only those files that are new or have changed since the last compile, including the files in subfolders.

This deletes the .class files in the folder and recompiles the source files. This command does not remove .class files or compile source files in subfolders.

This deletes all .class files within a folder and its subfolders and then compiles all files within the folder and subfolders.

This searches through the web.xml file for the element entries that identify a particular package as a module package. It is a refresh action for module identification.

This changes the display name of your Web application. The display name is an actual element entry in the deployment descriptor file (web.xml) in the application's WEB-INF directory.

This packages your application using the file name you specify and copies to the location you choose. Use this action when you need to create a deployable WAR file for your application so you can run it in a servlet container external to the Sun Java Studio Enterprise 6 (for production deployment, to test run in another container, or to send to another developer for testing).

This unmounts (removes) the Web Application Framework application from the Sun Java Studio Enterprise 6 environment (Filesystems, Project and Web Application Framework Apps tabs). It does not actually delete it from disk.

This provides access to standard Sun Java Studio Enterprise 6 tools and is outside the scope of this document.

Web Application Framework Application Node Properties

This is the default content type for pages that are executed in the Web application. The content type can be changed programmatically as needed for specific pages.

This is the servlet context--the first piece of the URL following the server:port.

This context root is populated with the value you supplied for the web context name in the Web Application Framework application wizard. You probably will not need to modify this property.

This is the display Name of the Web application. The display name is an actual element entry in the deployment descriptor file (web.xml) located in the WEB-INF directory of the Web application.

This identifies the path of the web module group file to which the Web Application Framework application belongs. See the IDE's online help for more information on creating web module groups.

This is used by the Export WAR File action. You can specify any additional files (that might not be in the Web applications directory structure) to be included in the generated WAR file.

This is used by the Export WAR File action and can be used to exclude certain types of files from the generated WAR file. It is common to exclude the Java source files (.java) from the WAR file so that the application source code is not published to the production server.

The Tools | Options menu opens the Options window. The debugger types are listed under the Debugging and Executing node. These debugger types are the possible options for this property. You can create a custom debugger type based upon one of the current types if required.

The Tools | Options menu opens the Options window. The executor types are listed under the Debugging and Executing node. These executor types are the possible options for this property. You can create a custom executor type based upon one of the current types, if required.

This determines which servlet container will handle the execution of the Web application. The default for this property is Default Web Server. The default Web server is configured in the Runtime tab under the Server Registry node. Only servers that are registered in the Sun Java Studio Enterprise 6 can be selected for this property. You can change the server that handles the execution of a single Web application without the need to change it globally for all other Web applications.

Settings & Configuration Node

The Settings & Configuration node has many resources for configuring the design time and runtime environment of your Web Application Framework application.

Settings & Configuration Node Contextual Menu Commands

Settings & Configuration Node Properties

Settings & Configuration Subnodes

General Node

The General Node is an area for miscellaneous type Web application configuration.

General Node Contextual Menu Commands

General Node Properties

The General node currently has two properties that control the runtime behavior of the applications.

When set to True, this ensures that, during your design/test cycles, each test run launches the browser and sends a unique URL to guarantee that your browser does not use a cached version of your page. This is accomplished by appending a named-value pair that has a unique ID per test run. The default value is false, which means do not use unique URLs.

When set to True, this forces you to implement session timeout handling code for your Web Application Framework application. Failure to do so results in session timeout exception messages being displayed in the browser when successive test runs are attempted. To avoid these messages, you must ensure that every browser instance sharing the same process space is closed (this might also include mail clients, as is the case with Netscape).

The following figure shows the friendly HTTP session timeout message displayed in the browser.

To see the actual stack trace of an HTTP session timeout, view the HTML source of the message.

<!-- Exception stack trace -->

<!--

javax.servlet.ServletException: This session has timed out

at com.iplanet.jato.ApplicationServletBase.onSessionTimeout(ApplicationServletBase.java:1222)

at com.iplanet.jato.ApplicationServletBase.fireSessionTimeoutEvent(ApplicationServletBase.java:1079)

at com.iplanet.jato.ApplicationServletBase.fireSessionEvents(ApplicationServletBase.java:834)

at com.iplanet.jato.ApplicationServletBase.processRequest(ApplicationServletBase.java:609)

at com.iplanet.jato.ApplicationServletBase.doPost(ApplicationServletBase.java:474)

at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)

at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)

...

The other option is to implement session timeout handling logic that redirects the user to the login page. To implement the session timeout handling you want for your Web Application Framework application, override the onSessionTimeout event in your application's application servlet class (jatotutorial.JatoTutorialAppSerlvletBase in the tutorial example). For more details on handling session timeouts, consult the Sun Java Studio's Web Application Framework Developer's Guide.

When the Strict Session Timeout property is set to false (the default), session timeouts are ignored and the test run is completed as requested. Automatic session timeout handling is accomplished by using a context parameter (jato:enforceStrictSessionTimeout) in the deployment descriptor (web.xml) which is passed into the ModuleServlet class at runtime, as shown in the following figure.

If this parameter is false or does not exist, then the Web Application Framework application handles the session timeout by ignoring it and displaying a message at the bottom of the resulting page notifying the developer to explicitly handle session timeouts.

File Upload Node

The file upload node has several properties that enable your application to perform file uploads. This feature requires your application to be run in a Servlet v2.3 compliant servlet container.

File Upload Node Contextual Menu Commands

File Upload Properties

When set to true, the filter will mark temporary files for deletion when the VM exits. This setting might be used as a fallback strategy, but there is no guarantee that the container's VM will exit gracefully and delete these files. Furthermore, creating and marking hundreds or thousands of files for deletion will certainly add to the memory burden of the container. Instead, applications should delete temporary files when they are through with them. Note that deleting files from the container might require granting the delete file privilege in the container's security policy.

When set to True, the remaining uneditable properties will become enabled (editable).

This is the maximum byte size of uploaded file content. For example, if a user uploads three files in one request, each one of the files might not be larger than this limit. Note that this limit is a soft limit, meaning that if uploaded content exceeds this limit, the content will be discarded but the request will still proceed normally, allowing for handling of the size violation by the application. This limit defaults to 1 MB, but developers should customize it to be as small as possible for their applications.

This is the maximum byte size of uploaded file content before an error occurs and normal request processing is stopped. For example, if a user uploads three files in one request, if one or more of the files exceeds this limit, all files will be discarded and the filter will signal an error condition. Upon a hard size limit violation, the filter will issue an HTTP redirect to an error handler URL.

The redirect URL can be configured via the Request Failure Redirect URL property. If no redirect URL has been specified, the filter throws an exception to immediately end the request. This limit defaults to 2 MB, but developers should customize it to be as small as possible for their applications.

This is the URL to redirect the client to if the file upload size limit is exceeded, or parsing of the request fails. This parameter might be an arbitrary URL either within or outside of the current application. The URL is sent as an HTTP 302 redirect.

This is the maximum byte size of the entire incoming request. If a request violates this limit, request processing stops and the input stream is discarded. The filter then handles the violation as it would for a content size hard limit violation. This limit defaults to 4 MB, but developers should customize it to be as small as possible for their applications.

This is the directory in which to create temporary files. If this parameter is not specified, the JDK's default temp directory will be used.

When set to True, the filter saves uploaded file content into temporary files in the temp directory. Otherwise, uploaded file content is stored in memory only in multipart content objects.

Logging Node

The Logging Node enables very basic and easy to use tracing in your Web Application Framework application. This feature leverages the behaviors of the com.iplanet.jato.util.Log class. Context parameters in the deployment descriptor file are used by Web Application Framework to enable/disable logging automatically. The Web Application Framework has some built-in log statements for tracing and debugging, but it is up to you to add logging with the proper log levels to your own application code.

Logging Node Contextual Menu Commands

Logging Node Properties

The properties of the Logging node all affect the deployment descriptor file (web.xml file in the Web application's WEB-INF directory). This allows you to change the logging behavior without recompiling the application.

This controls whether the output of com.iplanet.JATO.Log CLASS will be sent to the server console in addition to the standard servlet context log (Output window in the Sun Java Studio Enterprise 6 or the console window for the server).

This allows the developer to enable a default subset of the log levels, all of the levels, none of the levels, or a custom subset of the log levels.

The Enabled Log Level editor can be displayed by clicking the ellipses button in the Enabled Log Levels property sheet value box.

2003-08-07 14:07:19 [JATO_TRACE] Servlet[jatotutorial_main@3098834]: Enabled log levels: MANDATORY | STANDARD | VERBOSE_DEBUG | TERSE_DEBUG | JATO_TRACE | JATO_QOS_TRACE | APP_TRACE | WARNING | ERROR | CRITICAL | USER_LEVEL_1 | USER_LEVEL_2 | USER_LEVEL_3

2003-08-07 14:07:19 [JATO_TRACE] Servlet[jatotutorial_main@3098834]: Setting parameter "jato:echoLogToSystemOut" = "true" (java.lang.Boolean)

2003-08-07 14:07:19 [JATO_TRACE] Servlet[jatotutorial_main@3098834]: Setting parameter "jato:jatotutorial.main.*:moduleURL" = "../main" (java.lang.String)

2003-08-07 14:07:19 [WARNING] Servlet[jatotutorial_main@3098834]: The servlet "jatotutorial_main" is NOT enforcing strict session timeouts. Be sure to turn on strict session timeout handling or implement the onSessionTimeout() event before putting this application into production.

2003-08-07 14:07:19 [JATO_TRACE] Excluded method "jatotutorial.main.LoginViewBean.beginChildDisplay" from registration

2003-08-07 14:07:19 [JATO_TRACE] Excluded method "jatotutorial.main.LoginViewBean.endChildDisplay" from registration

This is a customizable string that identifies a log message that is being traced via the logging API built into the framework. This prefix string is prepended to the trace statements. For example, if the string *>*>*> were entered as the prefix, then a trace statement would appear as follows:

2003-08-07 14:07:19 *>*>*> [JATO_TRACE] Excluded method "jatotutorial.main.LoginViewBean.beginChildDisplay" from registration

Messages logged using the appMessage method are written to the message buffer. The contents of the message buffer are written to the end of the HTML page being displayed.

Following is an example of a message being logged to the message buffer using the appMessage method in the beginComponentDisplay event of the LoginViewBean class.

public void beginComponentDisplay(DisplayEvent event)

    throws ModelControlException

    appMessage("this message is being logged to the Message Buffer");

The appMessage method is convenient for quick troubleshooting of your applications. Most often this method would be used in ViewBean and TiledView classes and is an instance method of all the container view classes. This is just one of many places this logging method can be implemented.

If Show Message Buffer is enabled, the contents of the message buffer are displayed. Otherwise, the buffer is ignored. This makes it simple to enable these messages in the development environment and disable in the production environment.

Deployment Descriptor Node

The Deployment Descriptor node is just a link to the web.xml file in the application's WEB-INF directory. This file is what identifies the application as a Web application. The deployment descriptor file contains various configurations that the servlet container uses to manage your Web application (not just Web Application Framework web applications) at runtime. The deployment descriptor contains information such as display name, context parameters, servlet mappings, taglib declarations, and much more. The Web Application Framework tools allow the novice Web application developer to ignore the tedious details of configuring this file properly. However, the J2EE savvy developer can manipulate this file either directly by opening the file in a text or XML editor, or by using the property sheet in the Sun Java Studio Enterprise 6 when this node is selected.

Deployment Descriptor Node Contextual Menu Commands

This opens the deployment descriptor in the Sun Java Studio Enterprise 6 editor. Caution should be exercised when modifying this document. Some of the entries are managed by the Web Application Framework tools. Improper modification of such entries could prevent the tool from recognizing those entries properly.

Deployment Descriptor Node Properties

All of the properties directly map to the element entries of the deployment descriptor. The Web Application Framework tools module does not add any specific properties above and beyond what is already provided by the Sun Java Studio Enterprise 6 Web module. See the Web module documentation for more details concerning the deployment descriptor file node properties.

Component Libraries Node

The Component Libraries node lists all of the Web Application Framework component library JAR files that are mounted in the WEB-INF/lib directory of your Web Application Framework application. Every Web Application Framework application contains the Web Application Framework Standard Component Library (WAF SCL).

You might eventually create your own reusable Web Application Framework component library, or you might purchase one from a third party component vendor. When you place the component library JAR file in your Web Application Framework application's WEB-INF/lib directory, the Sun Java Studio Enterprise 6 recognizes and mounts the new library, and it is listed under this node.

This list of component libraries are for quick referencing of which component libraries are accessible in your Sun Java Studio's Web Application Framework application and cannot be modified in any way. For more details on Sun Java Studio's Web Application Framework component authoring, consult the Sun Java Studio's Web Application Framework Component Author's Guide.

Component Libraries Node Contextual Menu Commands

This is identical to the action with the same name for the Web Application Framework App Base Folder Node (see [action] Add Component Library above).

Component Libraries Node Properties

Component Libraries Subnodes

All of the subnodes of the Component Library node are either the Web Application Frameworkk Standard Component Library (included with the Web Application Framework installation), third party Web Application Framework component libraries that you have obtained and add to your Web Application Framework application, or custom Web Application Framework component libraries that you have created and added to your Web Application Framework application. For more details on Web Application Framework component authoring, consult the Sun Java Studio's Web Application Framework Component Author's Guide.

Design-Time Resources Node

Design-Time Resources Node Contextual Menu Commands

A new JDBC datasource can be created by right-clicking the JDBC Datasources node and selecting Add Datasource. Once a datasource is created, it can be deleted, but it cannot be modified.

Design-Time Resources Node Properties

Design-Time Resources Subnodes

The Design-Time Resources node contains two subnodes: the JDBC Datasources node and the Templates node.

JDBC Datasources Node

The JDBC Datasources node contains a list of all the JDBC datasources you created in your Web Application Framework application using the JDBC Datasource wizard. These datasources are only used at design-time to gather schema data for the target databases so that you are able to select tables and columns and stored procedures when building JDBC SQL table and stored procedure models using the wizards. These datasources are not involved in how a database connection is created or obtained by the servlet container and/or your Web Application Framework application during runtime. The appropriate runtime JDBC and JNDI configurations must be performed using the tools provided with your target production servlet container.

JDBC Datasources Node Contextual Menu Commands

This creates a new Web Application Framework datasource based upon the database connections that are configured in the Runtime tab under the Databases node. Make sure there is a database connection created and the database server is running and accessible before you create a new Web Application Framework datasource.

JDBC Datasources Node Properties

JDBC Datasources Subnodes

The only subnodes of the JDBC Datasources node will be the actual Web Application Framework datasources you create.

Web Application Framework Datasource Node Contextual Menu Commands

Once you create a Web Application Framework datasource, the only thing you can do to it is delete it. If you need to modify a Web Application Framework datasource, you must delete it and recreate it.

Web Application Framework Datasource Node Properties

Templates Node

The Templates node is a storage location for all templates that the page/pagelet component wizards use to generate new JSP page/pagelet files. You can add a custom JSP page/pagelet to the list of templates.

Templates Node Contextual Menu Commands

The Templates node is presented as a typical Java package node. It has all of the folder actions that any other folder node would have.

Templates Node Properties

The Templates node is presented as a typical Java package node. It has all of the folder properties that any other folder node would have.

Templates Subnodes

The subnodes of the Templates node can be additional levels of folders and the actual JSP page/pagelet templates.

Sun Java System Identity Server Node

The Sun Java System Identity Server (formerly Sun ONE Identity Server) node has several properties that enable you to configure your application to use Identity Server Security features. These properties are only applicable when the application is deployed using the Sun Java System Application Server (formerly Sun ONE Application Server).

Sun Java System Identity Server Node Contextual Menu Commands

Sun Java System Identity Server Node Properties

The Security Constraints, the Security Roles, and the Mapped Security Roles properties are the same properties displayed on the node for the deployment descriptor file (web.xml in the WEB-INF directory of the Web application). These properties are shown on the Sun Java System Identity Server node for convenience.

This property determines whether the web module is enabled to use the Identity Server Security features or not (True/False). The default value is set to False.

The Security Constraint property shows the number of security constraints defined for the web module. A security constraint is a mapping of a web resource to a group of roles or a transport requirement. The default value is No Security Constraints. To specify the security constraints, click the Security Constraints property value field, then click the ellipses button to display the Security Constraints property editor.

The Security Roles property shows the number of security roles that are defined for the web module. A role is an abstract logical grouping of users that is defined by the application developer or assembler. Security roles can either allow or deny access to different resources within the web module. The default value is No Security Roles. To specify security roles, click the Security Roles property value field, then click the ellipses button to display the Security Roles Property Editor.

The Mapped Security Roles property shows the roles that are mapped to principals (users) or groups in the currently active realm of the web module. This property maps logical J2EE roles to Sun Java System Application Server groups and/or principals. The default value is 0 Roles. To map roles to principals or groups, click the Mapped Security Roles value field, and then click the ellipses button to display the Mapped Security Roles editor.

Documents Node

The Documents node is the Web document root that contains Web resources such as HTML, JSP, CSS, images, and so on.

The following figure shows the Documents Node, the root directory for all Web resources.

Notice that Web Application Framework JSP pages are structured in a directory layout parallel to the packages of the page and pagelet components in the application. This is a recommended convention, but the developer is free to locate the JSPs anywhere within the servlet context directory structure.

There are two key reasons for the parallel directory convention. First, it makes finding JSPs that are using the ViewBeans easier for developers, especially those new to Web Application Framework. It is easier to have the same directory structure for both classes and JSPs since a given page is comprised of both. If a developer knows where one is, he or she immediately knows exactly where the other is. Second, and most important, this parallel directory structure naturally inherits the same namespace scoping rules as the application code. Therefore, if there is more than one module in an application, classes AND JSPs with the same name will not conflict. This allows complete module independence.

An illustration of this would be if you had a menu page (MenuViewBean.java and Menu.jsp) in module1 and a menu page in another module, module 2. Without the parallel directory structure, the two menu JSP files would need unique filenames (Menu.jsp and Menu2.jsp, for example).

Application Classes Node

The Application Classes node contains the complete Java package structure of your Web Application Framework application. Application Classes node is the root package of your application.

Application Classes Node Contextual Menu Commands

The only actions you are likely to need on this node are the compile/build actions.

This compiles only those files that are new or have changed since the last compile, including the files in subfolders.

This deletes the .class files in the folder and recompiles the source files. This command does not remove .class files or compile source files in subfolders.

This deletes all .class files within a folder and its subfolders and then compiles all files within the folder and subfolders.

Application Classes Node Properties

This allows you to hide all non-Module packages (packages that do not have a module servlet which is declared as such in the deployment descriptor). This can be convenient when you have a complex and deep package structure, and you only want to see those packages that have been marked as a Module folder.

Application Classes Subnodes

Possible subnodes of the Application Classes node are standard Java package folders, Web Application Framework module folders (which are also Java packages), and Java classes.

Java Package Folder Node

All folders under the Application Classes node are Java package folders. You are able to design and develop an application that has a package structure that is as complex as you want. Some (at least one) of those packages will be declared as a Web Application Framework module folder. Module folders are discussed in more detail below (see Module Folder Node).

Java Package Folder Node Contextual Menu Commands

This compiles only those files that are new or have changed since the last compile, including the files in subfolders.

This deletes the .class files in the folder and recompiles the source files. This command does not remove .class files or compile source files in subfolders.

This deletes all .class files within a folder and its subfolders and then compiles all files within the folder and subfolders.

This is a container for other menu actions: Command, Model, Module Folder, Page (ViewBean), and Subpage (ContainerView). These options all launch the wizard that guides you through creating the respective components. These actions have the same effect as using the Web Application Framework toolbar buttons (at the top of the Web Application Framework Apps tab), or selecting the Sun Java Studio Enterprise 6 menu option, File | New, then expanding the Web Application Framework node and selecting one of the component creation wizards.

If you right-click a folder node under the Application Classes node, some additional actions are available. The Add menu item is a shortcut to some of the Web Application Framework component wizards.

Some Web Application Framework components are required to be created inside of a module folder (see Module Folder Node). The wizards will prevent you from creating components with this requirement.

This transforms a regular Java package into a Web Application Framework module folder. Selecting this action displays a dialog that provides inputs to convert the standard package to a module folder. If servlet classes exist in the target package, they will be presented as the module servlet candidates, or you can enter a class name to create a new module servlet class.

You can create new module folders by right-clicking the desired base package node (such as Application Classes, jatotutorial, main, or any other package in Application Classes), and selecting Add, then Module. You will be prompted to enter the name of a new module servlet.

Java Package Folder Properties

Non-module Java packages in a Web Application Framework application can be converted into module folders by changing the property from False to True. For more details, see [action] Convert to Module.

The subnodes of a module, or any folder in the Explorer, can be unsorted, sorted by type, name, or name (packages first).

Module Folder Node

A Web Application Framework module folder node is a traditional Java package folder node badged with a small greenish globe in the bottom left corner. The IDE will recognize and badge a Java package folder as a valid Web Application Framework module folder if the folder contains a Web Application Framework module servlet and the module servlet is registered properly in the deployment descriptor file (web.xml in the WEB-INF directory of the Web application). The IDE will automatically manage the creation of valid Web Application Framework module folders for you. The IDE also supports the automatic conversion of Java package folders to Web Application Framework module folders.

A Web Application Framework application node typically contains at least one Web Application Framework module folder. Larger Web Application Framework applications might contain more than one Web Application Framework module folder. The module folder offers developers the opportunity to logically partition larger applications.

A module folder typically contains Web Application Framework components such as pages, pagelets, and models. It might also contain the arbitrary application resources that you can place in any Java package folder. The essential feature of Web Application Framework module folders is that Web Application Framework page components are only executable when they are in Web Application Framework module folders. Web Application Framework pages, pagelets, models, and command components can be created in arbitrary Java package folders, but Web Application Framework page components can only be executed from within Web Application Framework folders.

Module Folder Node Contextual Menu Commands

This compiles only those files that are new or have changed since the last compile, including the files in subfolders.

This deletes the .class files in the folder and recompile the source files. This command does not remove .class files or compile source files in subfolders.

This deletes all .class files within a folder and its subfolders, and then compile all files within the folder and subfolders.

If you right click a folder node under the Application Classes node, some additional actions are available. The Add menu item is a shortcut to some of the Web Application Framework component wizards.

Module Folder Node Properties

Module folders have a property named Module. It is always True when it is a Module. This means that this folder has a ModuleServlet class (MainModuleServlet in this case), and it has some entries in the deployment descriptor (web.xml).

<context-param>

     <param-name>jato:jatotutorial.main.*:moduleURL</param-name>

     <param-value>../main</param-value>

 </context-param>

 <servlet>

     <servlet-name>jatotutorial_main</servlet-name>

     <servlet-class>jatotutorial.main.MainModuleServlet</servlet-class>

     </servlet>

 <servlet-mapping>

 <servlet-name>jatotutorial_main</servlet-name>

     <url-pattern>/main/*</url-pattern>

 </servlet-mapping>

If you were to change the Module property to False, these entries would be removed from the deployment descriptor, and the module folder would become a regular Java package. To convert it back to a module folder, change the property back to True, or right-click the non-module folder, and select the Convert to Module action. For more details, see [action] Convert to Module.

This property facilitates servlet invocation based upon mapping a URL pattern from an end user request to a servlet (the module servlet). For this example, /main/* is the pattern. This means that any URL with the pattern of http://<server>/<servletcontext>/main/<anything-at-all>, invokes the MainModuleServlet servlet class.

The subnodes of a module, or any folder in the Explorer, can be unsorted, sorted by type, name, or name (packages first).