1.0 Introduction
2.0 Known problems
2.1 Adding module files to an Enterprise Application project
2.2 Alternate deployment descriptor (alt-dd) elements in enterprise applications
2.3 Java build path settings for EJB/Web/Application Client projects
2.4 Spaces not supported in JAR URIs within an EAR
2.5 Enterprise application project names should not contain DBCS characters
2.6 Binary projects are read-only
2.7 Automatic removal of WebSphere bindings with delete
2.8 Resource locking due to JSP validation
2.9 'Invalid project description' error when using a non-default project location for a new J2EE project
The J2EE perspective contains the views that you would typically use when you develop resources for Enterprise Application, EJB, Web, and Application Client projects. This readme file describes some known problems, limitations, and workarounds that are associated with J2EE development tools in WebSphere Studio. Some other items related to J2EE views and J2EE Web projects are documented in the readme file for Web tools.
When importing one of the module file types (EJB JAR, WAR, RAR, and Application Client JAR file) into an Enterprise Application project, you must use the correct import wizard and import the module file into the appropriate project type. Do not import into the Enterprise Application project. If the module file is imported into the Enterprise Application project, you will not be able to add the module to the application using the Application deployment descriptor editor.
The use of alt-dd's is currently not supported in WebSphere Studio. The workaround is to edit the deployment descriptors of the contained modules.
It is recommended that whenever possible, you accept the default settings of the Java build path for the J2EE project types. To set up dependencies between projects contained in an Enterprise Application, use the JAR Dependencies editor or the Java JAR Dependencies property page instead. This will keep the Class-Path attribute of the MANIFEST.MF file (used for server runtime) sychronized with the project Java build path (used for Java compilation).
In general, libraries required by a module must be either contained in the Enterprise Application, or visible to the server. Therefore caution should be used adding external libraries to the project build path, because the project may not run on the server. For example, suppose you have a library off_the_shelf.jar that you want to reference in an WEB module. You can either:
- Add off_the_shelf.jar to the Enterprise Application using the file system import wizard; then use the JAR Dependecy editor to make the WEB module depend on the JAR, or
- Use the Java build path properties for the WEB project to add the JAR to the build path; the server must then have visibility to the JAR.
To accomplish this for unit test, edit the server configuration and add the JAR to the classpath.
Spaces are not supported in the URI for modules or utility JARs in an enterprise application. The "Class-Path:" attribute of a MANIFEST.MF file in a JAR or module is a space delimited list of relative paths within an EAR. A JAR would not be able to reference another JAR in the EAR if the URI of the referenced JAR contained spaces.
When you create an enterprise application project, it is recommended that you do not give it a name that contains DBCS characters.
Binary projects created by EAR import (available as an option on the import wizard) are intended to be read-only. You should not try to modify the contents of a binary project. You can, however, delete the binary project and replace it with a source version from a repository. Most actions should be disabled for binary projects. If you use binary projects, try to avoid any actions which modify the contents of the project or JAR.
When you delete an object that contains WebSphere bindings, the binding object is also automatically deleted. For example, if you delete a security role with bindings in the Security page of the application deployment descriptor editor, the security role bindings are also deleted. If you a security role with the same name, be sure to re-bind it if necessary.
If a Web project has recently been validated by the JSP Validator, it is possible that any library JAR files or class files referenced by that project may still be in use. As a result, it may not be possible to delete or move individual JAR or class files (for example, if you chose to delete the /WEB-INF/lib directory). If a JAR file in EAR project is referenced by a Web project as a Java JAR dependency, it may not be possible to delete the EAR project or JAR within it. To "release" these resources for file-management activities, close the Web project and then re-open it.
When you create a new J2EE project (including Java, enterprise application, Web, EJB, application client, and connector projects), you cannot use a project location that is already used by another project in the workbench. If you choose a project location that is used by another project, the wizard displays an "Invalid project description" error dialog or message. If after you receive this message you then select a valid project location by clicking the Browse button, the project creation will still not finish. The workaround is to click Cancel and reopen the project creation wizard.
Return to the main readme file
(C) Copyright IBM Corporation 2000, 2003. All Rights Reserved.