Specifying target servers for J2EE projects
When you develop J2EE applications, the workbench requires that you specify the server runtime environments for your J2EE projects. The target server is specified during project creation and import, and it can be changed in the project properties. The target server setting is the default mechanism for setting the class path for J2EE projects.
In order to support different application servers that use different JDK levels for their Java Runtime Environment (JRE), the workbench requires that projects include a target server setting. For example, if you want to take advantage of the features of JDK 1.4.2, which is used as the runtime environment for WebSphere Application Server V6.0, your applications require different class path entries than those that were used in previous versions of the workbench. By requiring that you specify a target server, the workbench enforces that proper entries are appropriately added for running on WebSphere Application Server V6.0 using the JDK 1.4 runtime environment.
Important: Due to the way that these class path entries are added to your projects, J2EE projects created with the workbench are not compatible with versions of WebSphere Studio Application Developer prior to Version 5.1.1.
When the project is created, the class path of the project is updated with two class path containers. One container is the JDK container and the other is the server container. The JDK container points to the directory that contains the JAR files that are necessary to support the JDK version. The server container points to the directory that contains the multiple public JAR files available in the selected server. The project then compiles based on the required JAR files located in these folders, and you do not need to worry about adding additional JAR files from the server during development. When the project is compiled, the JAR files are included in the class path. You can still add your own JAR files to the class path.
The target runtime environment is specified in the .runtime file in the project's resources. You should not edit this file manually.
All J2EE project creation and import wizards require you to specify the target server for the resulting projects. The list of target servers that you can choose from is filtered based on installed runtimes, the J2EE level of the application, and the J2EE module type. For example, for EJB projects only application servers that support Enterprise JavaBeans are displayed. All projects inside a single EAR file must be targeted to the same server. If you create a new project and add it to an existing EAR project during creation, the project inherits the target server setting of the EAR project.
Note: Utility Java projects that are added to an application are targeted to the same target server as the application. Web library projects that are added to a Web project are targeted to the same target server as the Web project.
To modify the target runtime and default server for an existing project:
In the Project Explorer view of the J2EE perspective, right-click the enterprise application or module project, and select Properties from the pop-up menu. The Properties dialog for the project opens.
Select the Server page on the Properties dialog.
In the Target runtime drop-down list, select the server runtime that you want your project to be developed for. This selection impacts the runtime libraries that are added to your project class path. You can click New to define a new runtime environment that you have installed. The list of runtime environments are defined in your workbench preferences.
Optional: Enterprise applications only: When modifying the target server for an enterprise application, you can select the Include child projects check box to apply your changes to any children modules. This ensures that the enterprise application project and all of its module projects, utility projects, and Web application library projects have the same target server.
Optional: In the Default server field, select a default server to use when deploying the project. Although you would typically set this to the same value as the target runtime, the Default server selection is independent of the Target runtime selection. The default server simply specifies a project preference so you are not prompted for available runtime environments when you deploy the project.
Click Apply to save your changes.
Adding Struts support to dynamic Web projects
You can add Struts support to a dynamic Web project when you create the project or afterward. When you add Struts support, you can customize the Struts version, default Java package prefix, and resource bundle information.
To add Struts support when you create a project, see Creating a dynamic Web project. Adding Struts support to a static Web project is not supported, nor is customizing the Struts feature after Struts support has been added.
To add Struts support to an existing dynamic Web project:
In the Project Navigator, select a project name, right-click the name, and click Properties.
On the Properties page, click Web Project Features, check the Struts support box, and click Apply.
If you want to override the default Struts settings, on the Struts Settings page click the Override default settings box and specify the following settings:
To specify a different version, select from the "Struts version" drop-down menu.
This determines which .jar and .tld files will be copied to the workspace: those for Struts 1.1 (default) or those for Struts 1.0.2.
Note: Whatever version of Struts you select for your project becomes the default for your subsequent Struts projects.
To change the default Java package prefix, edit the "Default Java package prefix" field.
This is the package prefix to be used for Java classes that are generated for you. You may wish to change it if, for example, you have an existing package and would like all generated code to go to that package, or if the default conflicts with a package that you currently use and you do not want the code to be generated there.
To create a resource bundle for your Struts project, make sure that the "Create a Resource Bundle" box is checked and that a Java package name and a resource bundle name are specified.
This setting defines the resource bundle that your Struts application will use. If you specify this option, a resource bundle is created and a reference to it is added to the project's struts-config.xml file. If a resource bundle exists, your application will look up strings there. If you want to enable national language support (NLS) for your Struts application, you simply add another bundle in the translated language to the same directory and name the bundle appropriately; the Struts framework automatically handles the locale change. You may not want a resource bundle created if you have an existing resource bundle that you plan to reuse or if for some other reason it does not make sense to create a resource bundle.
Click Finish. The wizard adds a Struts entry in the web.xml file, creates a Struts configuration file, and adds JAR files to the dynamic Web project.
On the Properties page, click OK.