You can create, configure, and manage servers so that you can test your project
resources. After you complete your testing, you can publish your applications onto your
servers.
Learn about testing and publishing on a server
You can test an application that is running on the development workbench before publishing the application to the directories of an application server. Publishing involves copying files (application, resource files, and deployment descriptor files) to the correct location for the server to find and use them. Read this page for information on how to integrate the workbench with a server.
Testing and publishing on your server
The testing and publishing tools provides runtime environments where you can test JSP files, servlets, HTML files, web services, enterprise beans, Java™™ Persistence API, Java classes and many more artifacts.
Limitations and troubleshooting tips for server tools
Various known problems and limitations apply when you are working with WebSphere® Developer Tools. Issues include, among others, limitations with Web Project Wizard and limitations with desktop firewalls.
Learning more about WebSphere Developer Tools Server Tools
General workbench issues
Effectively manage your servers and the workbench by reviewing associated issues. Issues include, among others, servers not stopping from the Servers view, limitations of servers due to invalid characters, and workspace migration issues.
Secured server
You can encounter a variety of issues with secured servers. Issues include, among others, limitations with desktop firewalls or administrative console login failures when running in secure mode.
Server connections
You can encounter a variety of issues with server connections. Issues include, among others, long delays when establishing RMI connections or the server port being in use when you restart your development environment.
Issues with adding, removing, or publishing applications to the server
You can encounter problems and limitations when you try to add, remove, or publish an application to the server. Issues include, among others, publishing failures due to duplicate class errors and trying to publish an application from the work bench that was installed by the administrative console.
Invalid profile name
This topic describes how to resolve a Profile name is invalid error message.
Universal Test Client: Internal browser does not support IPv6 address
If you specify an Internet Protocol version 6 (IPv6) address for the host name of the server, the internal browser might have problems displaying content, such as from the administrative console.
Issues associated with the administrative console
You can encounter issues when you are using the administrative console. Some limitations can also apply to the administrative console.
Migrating projects with a target runtime set to WebSphere Application Server
The targeted runtime settings specify the application server and its version level of where you intend to run the project; for example, if the goal is to run the project on a WebSphere Application Server V8.5, set the targeted runtime settings to WebSphere Application Server V8.5. When you specify the targeted runtime settings for a project, you can define the class path to the server. When you migrate a Java EE project from one workspace to another, the project may need to be set to a new target runtime because the server is no longer available. For example, if the current workbench has a WebSphere Application Server V9 and the project to migrate is target to WebSphere Application Server V8.5.
Defining server preferences
You can define preferences using the server tools.
Installing Liberty repository assets
You can install Liberty repository assets by using WebSphere Developer Tools. Assets that you can install include feature assets, open source integration assets, product sample assets, runtime assets, add-on assets, and config snippet assets.
Creating, editing, and deleting servers
You can create a server to identify the runtime environment that you want to use for testing your project resources. When creating a server, you also create a pointer from the workbench to an existing installation of an application server.
Configuring servers for testing and publishing
A server is a definition that identifies where an application is going to be tested or published and points to a specific runtime environment, such as a WebSphere Application Server on a local server or on another server. Select the server that you want to configure:
Managing servers
You can use the server tools views to manage servers. You can start and stop servers, deactivate and activate servers, and manage a server configuration.
Testing applications on a server
You can use the workbench to test one or more projects on a server.
Debugging applications on a server
You can debug applications on a server to detect and diagnose errors in your application. Use the TCP/IP monitor view to view data sent and received over the ports of the server. In addition, use the debugging tools in the workbench to control running your application on the server by setting breakpoints, suspending threads, stepping through the code, and examining the contents of the variables. You can debug artifacts, such as JSP files, on a server without losing the state of your application.
Publishing settings for WebSphere Application Server traditional
Publishing involves copying files (application, resource files, and deployment descriptor files) to the correct location for the server to find and use them. You can either publish your application on the server or run your application within the development environment without copying the application into the directories of the server.
Publishing settings for a Liberty server
You can publish your application on a Liberty server, or you can run your application within the development environment. Publishing your application involves copying files such as application files, resource files, and deployment descriptor files to the correct location for the server to find and use them.
Creating a Liberty feature
You can write features by using WebSphere Developer Tools and install them into an existing Liberty server. You can also package your features for delivery.