<taglib>  <taglib-uri>/myTags</taglib-uri>  <taglib-location>/WEB-INF/tlds/myTagLib.tld</taglib-location></taglib>

For details, see Packaging and Deploying a Custom Tag Library

If you remove a tag library declaration, it does not automatically remove the corresponding JAR file from the WEB-INF/lib directory.

Specifying the Default URI Within the Taglib Element

The Tag Libraries Property Editor is primarily used to indicate which tag libraries have been added. It also enables you to change the URI mappings of the tag libraries. Each entry corresponds to a taglib element in the deployment descriptor. Refer to the URI mapping at the top of your JSP file to use the specified tag library. The URI reference also ensures that custom tag library code completion works. For more information, see Using Tag Libraries.

Use the Tag Libraries Property Editor to add, edit, or remove references to the tag library JAR file from the selected web module. The addition or removal of items using this property editor does not affect the tag library JAR file in the WEB-INF/lib directory.

If you choose Add JSP Tag Library from the selected web module's contextual menu, an entry for each tag library is created in the deployment descriptor.

Using the IDE to Edit the web.xml File in the Source Editor

If you know the deployment descriptor XML syntax, you can edit the web.xml file directly by double-clicking the web.xml icon. When you save your changes, the IDE automatically parses the file. It then displays any errors in the Output window on the XML Parser tab. You can also edit the file using an external text editor.

---

Using the Integrated Servers

The IDE is installed with two integrated servers, Sun ONE Application Server 7 and Tomcat. Both servers appear under the Installed Servers node in the Server Registry on the Explorer's Runtime tab. By default, the IDE uses Sun ONE Application Server 7 to compile and execute web components such as JSP pages and servlets.

You can use the IDE to perform the following actions:

• Deploy and delete web modules and web module groups
• Set general properties for installations of the server
• Start, restart, and stop the server
• Edit the configuration file for the server

For more information about the integrated servers, see the Sun ONE Application Server Integration Module help set and the Tomcat Plugin help set in the online help.

Test Running Web Modules

Before you can run a web module, you must first deploy it by right-clicking the WEB-INF node and choosing Deploy from the contextual menu. The IDE deploys the web module to the context that is designated by the Context Root value on the WEB-INF node's property sheet. The context root must have a leading forward slash, for example, /test. This context root is used to form the web module's document root. For example, if a web module's context root is /test, the document root might be http://host:8080/test.

When you initiate the Deploy action the IDE saves the files, recompiles any servlets, and then deploys the web module. Note that the JSP files are not compiled until they are actually loaded at run time.

Once you have deployed a web module, you can test run the module within the IDE by using the Execute action. This action executes the application from a client web browser using the specified default browser.

You can set a web module's execution properties on the Execution tab of the WEB-INF node's property sheet.

If you want to execute several web modules as a group, you must first create a web module group. For details, see Creating and Executing a Web Module Group. A web module group is an IDE-specific construct. It enables you to specify a set of web modules to deploy together on a web server with a single action. Each module in the group must have a unique context root. The context root ensures that requests are properly sent to the correct module by the web server.

As you execute web modules and web module groups, you can use the HTTP Monitor. It enables you to examine the flow of record data. See Using the HTTP Monitor to Debug a Web Application for more information.

Configuring the Server

When you deploy or execute a web module, the IDE automatically updates the server's configuration file. For more information about server configuration, see "Administration Server" in the Sun ONE Application Server Integration Module online help and "Editing the Tomcat Server Configuration File" in the Tomcat Plugin online help.

Setting Up the Web Server Environment for Database Access

PointBase is installed with the Sun ONE Studio 5 software in the subdirectory that contains the Sun ONE Application Server 7 software. If the IDE and Sun ONE Application Server 7 were installed separately, the server may or may not include PointBase software. If it does not, you must download and install PointBase software manually. See "Using Databases With the IDE" in the Sun ONE Studio 5, Standard Edition Getting Started Guide for information about starting the PointBase Server and setting up database connectivity. The same chapter also contains information about using other JDBC enabled databases with Sun ONE Application Server 7.

If you are using Tomcat, you must do one of the following to make a database driver available to the Tomcat servlet container:

• Copy the driver to the web module's WEB-INF/lib directory.
• To add a driver as a shared resource to the internal Tomcat server, copy it into the s1studio-install-directory/jwsdp/common/lib directory. Note that files in this directory are shared among all users of this IDE installation.
• To add the driver as a shared resource to an external Tomcat installation, copy the driver into the tomcat-install-directory/common/lib directory.

See the External Execution Process property description in the "Setting Tomcat Installation Properties" section of the Tomcat 4.0 Plugin online help for details.

Note that adding a database driver to your system class path does not necessarily make it accessible to your web server.

You can test communications using your database driver with the Database Explorer in the IDE. This practice ensures that the driver you are using works properly with both the Java language and the IDE.

Executing a Single Web Module

To execute a single web module, right-click the module and choose Execute from the contextual menu. The web module executes and is displayed in your selected default browser. The execute action instructs the browser to request the root of the web module. This action causes the server to attempt to serve a welcome file within the root directory. You can set the welcome files by editing the Welcome Files property in the property sheet for the web.xml file. If the server cannot find a welcome file, it simply lists the contents of the directory.

Note that if you have not yet deployed the module or if you have made changes to the module, you must first deploy the module by right-clicking the WEB-INF node and choosing Deploy from the contextual menu. This deploy action causes the IDE to take the following actions:

• Save all the modified files in your web module.
• Recompile the class files (JSP pages are recompiled when they are obtained and used by the web server).
• If the web server is not running, start the server for the deployment. Note that the Admin Server must be running if you are using Sun ONE Application Server 7. Otherwise, the IDE cannot start the web server and you will receive an error message, such as "connection refused." If the IDE needs to start the web server for deployment, it will stop the server upon completion of the deployment process.
• Deploy the module to the server directory that is specified by the Context Root value on the WEB-INF node's property sheet. For example, if the Context Root value is /catalog, then the URL for the web module is http://host:port/catalog.

You can use the HTTP Monitor to track the requests to the web module and the data flow inside the web application. See Using the HTTP Monitor to Debug a Web Application for more information. If problems occur, check the Output window that appears upon execution.

Class Path Construction

When a web module is executed in the server, a class path is constructed. The class path ensures that all necessary classes and libraries in the web module can be located. By default, the order of web module elements in the class path for servlet execution is:

1. WEB-INF/classes

2. Any JAR files in WEB-INF/lib

3. Other classes or libraries, depending on your server's implementation of class loading

Creating and Executing a Web Module Group

The IDE provides a mechanism to deploy several web modules together so they can be run at the same time. You create a web module group node in the IDE and add web modules to it. Then you use the deploy and execute actions.

To create and execute a web module group, you perform four main tasks:

1. Create a web module group object by right-clicking a mounted filesystem, choosing New from the contextual menu, and choosing All Templates. In the New wizard that appears, expand JSPs & Servlets and select Web Module Group. Click Next and complete the steps in the wizard. A web module group node appears in the root directory of the mounted filesystem.

The web module group node should be placed outside a web module. This placement ensures that the web group is not inadvertently included when being packaged for deployment.

2. Set a URL mapping for each of the web modules to be loaded as part of the web module group by right-clicking on the web module group node and choosing Add Web Module from the contextual menu.

3. (Optional) Open the property sheet for the web module group node and specify a Target Server for the web module group. If no target server is specified, the default web server is used.

4. Right-click the web module group node and choose Deploy. After the IDE completes the deploy action, right-click the web module group node and choose Execute.

See "Creating a Web Module Group" in the JSP/Servlet online help for details on these tasks.

You can set a target server for an individual web module. You perform this task by editing the Target Server property for that web module. However, a component of that web module might be executed while the web module is running as part of a web module group. In this case, the web module runs within the server specified by the Target Server property for the web module group. For more information, see "Setting WEB-INF Properties" in the JSP/Servlet online help.

Executing on External Servers

You might have your own installation of Sun ONE Application Server 7 or the Tomcat 4.0 web server on your system. You can set your own installation as the default web server. Alternatively, you can specify that your installed server be used for a designated web module. For more information, see the section on setting the Target Server property in "Creating a Web Module Group" in the JSP/Servlet online help.

See the Sun ONE Studio 5, Standard Edition Getting Started Guide for information about using an external Sun ONE Application Server 7. For an external Tomcat 4.0 web server, configure the IDE's Tomcat plugin module to use that instance rather than the internal server. See "Adding a Tomcat 4.0 Installation" in the Tomcat Plugin online help for details.

The integration with the Tomcat web server has two modes of operation:

• Full mode. HTTP monitoring and JSP and servlet debugging features are enabled. The IDE adds some elements to the server's server.xml configuration file.
• Minimum mode. HTTP monitoring and JSP and servlet debugging are not available. The server's configuration file is modified only to add the deployed module's context path.

---

Debugging Web Applications

The IDE provides two tools for debugging web applications:

• The HTTP Monitor
• Source-level debugging for both JSP files and servlets

Using the HTTP Monitor to Debug a Web Application

The HTTP Monitor is a lightweight tool that can be used as an alternative or a complement to source-level debugging. It is provided by the IDE for collecting data related to the execution of JSP files and servlets in the servlet container. The data records generated by the HTTP Monitor streamline the work involved in debugging JSP files and servlets. The HTTP Monitor records information about each request that comes into the server. This data includes incoming and outgoing cookies, session information maintained on the server, the servlet environment information, and HTTP headers.

The HTTP Monitor provides a view into the data flow among web application components of the web application. You can use the monitor to examine the properties of the HTTP requests. You can also use it to inspect any data maintained on the server whenever a request is processed by a JSP page or a servlet. For example, you can find out if:

• The JSP page or servlet received any form data with the request. If so, you can determine what the values were.
• An HTTP session was associated with the request. If so, you can determine what attributes were set before or after the JSP page or servlet was activated.
• The JSP page or servlet received or created any cookies.

If you discover a bug while test running, use the HTTP Monitor to view data records associated with requests leading up to it. You can quickly find out if the problem was caused by a JSP page or servlet not receiving the data it expected. In this case, you can determine which resource started the problem. By using the Edit and Replay feature, you can tweak requests before resending them. This technique enables you to determine if sending different data fixes the bug. Often this knowledge is enough to identify the lines of code causing the problem. If not, you might narrow down an individual JSP page or servlet to step through with the source-level debugger. For details, see Source-Level Debugging.

Once you have fixed the bug, use the HTTP Monitor again to replay the request or requests that exposed the problem. This technique can save time if reproducing the steps involves entering data through a browser, for example.

The HTTP Monitor enables you to save recorded request data. If you find a problem you do not have time to fix immediately, save the relevant records and go through the process described above later. You can also, for example, save a sequence of requests representing an application sanity test. You can then run it every time you change something.

In summary, use the monitor to:

• View data, store information for future sessions, and replay and edit previous requests
• Determine which component is sending or receiving incorrect data before you begin source-level debugging

For details on error sources in web applications, see Common Errors in Web Applications. For details on source-level debugging, see Source-Level Debugging.

Deploying the HTTP Monitor

Before you can use the HTTP Monitor on a web application, you must perform the following steps to make the monitor available to the server:

1. Copy IDE-install-directory/modules/schema2beans.jar and IDE-install-directory/modules/ext/httpmonitor.jar to the web module's WEB-INF/lib directory.

1. In the Deployment tab of the property sheet, display the property sheet for the Deployment Descriptor node (WEB-INF/web.xml), click the Filters value field, click the ellipses (...) button to display the Filters dialog box, and click Add.

2. In the Add Filter dialog box, set the Filter Logical Name to HTTPMonitorFilter or a similar descriptive name.

3. In the Filter Class text field, type the following:

org.netbeans.modules.web.monitor.server.MonitorFilter

4. Click Add under the Filter Mapping table to display the Add Filter Mapping dialog box and click OK to accept the default of /*.

5. Click Add under the Init Parameters table to display the Add Init Parameter dialog box.

6. In the Init Param Name text field, type netbeans.monitor.ide.

7. In the Init Param Value text field, type the following (replace the variables with the actual values):

name-of-host-that-runs-IDE:port-of-internal-HTTP-server

If you are unsure of the port number, open the property sheet for the HTTP Server node in the Runtime tab of the Explorer window. The Port property shows the port number.

8. Click OK to dismiss the Add Init Parameter dialog box and click OK to dismiss the Add Filter dialog box.

Remember to remove the JAR files, the filter, and the filter mappings before you deploy to a production server.

Starting the HTTP Monitor

The HTTP Monitor consists of a top level window within the IDE, and a server-side component that runs on the execution server. To open the HTTP Monitor, choose HTTP Monitor from either the IDE's View menu or Debug menu. For more information, see "Monitoring Data Flow on the Web Server" in the HTTP Monitor module online help.

Viewing Monitor Data Records

The HTTP Monitor consists of two panels. On the left, the HTTP Monitor records panel contains a tree view of known records. On the right, the HTTP Monitor records display panel presents the data associated with the selected monitor record.

In the tree view, the All Records category contains two subcategories: Current Records and Saved Records. Individual monitor data records reside in either of these subcategories. Entries in Current Records are available only during the current IDE session. Current monitor data records persist across restarts of the web server. They are only cleared on a restart of the IDE or when deleted. Entries in Saved Records persist until deleted.

Sometimes, a data record is created as the result of one resource dispatching the request to another resource. An example of this situation is a JSP forwarding to a servlet. In this case, the record is shown as an expandable node in the tree. To see how the request was processed by any other resources activated by the forward or include actions, expand the node.

Monitor data records in all categories can be sorted according to various criteria using the buttons above the tree view. For details on sorting criteria, see "Using the HTTP Monitor Toolbar" in the HTTP Monitor online help.

For each selected monitor data record, corresponding information appears in the HTTP Monitor records display panel. The records display panel consists of these panes:

• Request. Shows the request URI, method, query string, parameters or posted data, protocol, client IP address, scheme, exit status, and list of request attributes before and after the request.
• Cookies. Shows a list of incoming and outgoing cookies. For incoming cookies, information includes the cookie name and the cookie value. For outgoing cookies, information includes the name, the value, the expiration time, which domain the cookie should be sent to. Outgoing cookie information also includes which path the cookie should be sent to and whether it requires a secure protocol.
• Session. Shows status of any HTTP session associated with the request before and after the request's processing. The pane describes whether the session was created as a result of the request's processing. Session properties such as ID, creation time, last accessed time, and the maximum inactive interval are displayed. It also shows session attributes set before and after the request's processing.
• Servlet. Shows the name of the servlet as configured, class name, package name, and optional servlet information. It also displays relative and translated paths.
• Context. Shows the name of the servlet context created from the web module and the absolute path to the context. This pane displays all the context attributes set when the request started processing. It also shows any initialization parameters given to the request.
• Client and Server. Shows data about the application that generated the HTTP request. The data includes which protocol it used, its IP address, and if the information is provided, which application was used. The pane displays what locales, encodings, character sets, and file formats the application supports. It also shows data about the servlet engine that processed the request. This data includes the Java version, platform, host name, and port number of the HTTP service.
• Headers. Shows the HTTP headers that came in with the request. The headers are constructed by the HTTP client, for instance, a browser. The exact nature of headers varies from client to client. They usually include information such as the nature of the client, for instance, software and operating system. They also contain language preferences and the file formats the browser accepts.

Replaying Requests

You can replay HTTP requests associated with the Current Records and Saved Records subcategories of the All records tree view. Replaying a request makes the server process a request identical to the request that was recorded. The response is shown in the IDE's default web browser, just as it is when you execute a web module.

This feature can simplify the process of testing the correction to a bug. For example, you might have found a bug and modified some code in a resource that processes form data. To verify the correction, you would usually load the form into the browser, enter data, and submit it. Using the Replay action on the original request record, you could bypass the need to reenter the data. Another example would be if you needed to step through several requests before you could reproduce a bug. The bug might be in a resource that is part of the implementation of a checkout. Moreover, users cannot enter the checkout unless they have placed something in the shopping cart. In that case, you could replay several recorded requests. This action would place the web application in a state where the bug correction could be confirmed.

See "Editing and Replaying Requests in the HTTP Monitor" in the HTTP Monitor online help for details.

Editing and Replaying a Specified Request

The Edit and Replay dialog box enables you to edit a number of properties prior to resending the request information. These properties include the request parameters and/or the query string, the cookies, and the headers. An option is also provided to send the request to a different server, if it fully supports the HTTP Monitor.

You can use the Edit and Replay dialog box to send requests to a different server.

Use the Edit and Replay feature to:

• Check if a web component that is not functioning works with different input
• Change items such as the locale setting of the client without having to modify your browser's settings

Specifying Session Cookies for Replay Requests

If you replay a request, the HTTP Monitor, by default, uses the session cookie that the browser is sending, if it sends a cookie. The monitor does not use the session cookie recorded with the request. You can control this behavior so the recorded cookie, or a cookie you specify, is used instead. See "Editing and Replaying Requests in the HTTP Monitor" in HTTP Monitor online help for details.

Source-Level Debugging

When a JSP page is executed as part of a web application, a servlet is actually what is executed. The JSP page is translated into a servlet, called the generated servlet. The generated servlet is then compiled and run. When using Sun ONE Application Server 7 or the Tomcat server, the IDE maintains a mapping between lines in the original JSP source and lines in the generated servlet. This feature enables you to debug JSP pages from either:

• The perspective of the JSP file itself
• The source of the servlet into which the JSP file was translated

Source-level debugging consists of several enhancements to the standard IDE debugging environment. These enhancements enable JSP and generated servlet files to be viewed simultaneously. Breakpoints set in one are automatically reflected in the other. However, breakpoints removed from the generated servlet are not removed from the corresponding JSP source file.

A JSP file, with all its statically included files, maps to a single servlet file. (See Using the <%@include%> Directive for details.) Specifically, one line in the JSP file maps to one or more lines in the servlet file. The servlet also contains code generated for all JSP pages, with no explicit representation in the JSP source.

Using the Debugger

To debug your application using the IDE's source-level debugging features, you set breakpoints, view the generated servlet, and start the debugger, as described in the following sections.

Setting Breakpoints

Setting breakpoints in a regular servlet or class file is no different from debugging other Java classes. For JSP pages, you can set breakpoints in either the JSP source file or in the generated servlet.

If you set a breakpoint in a JSP source file, it is automatically reflected in the generated servlet. (Remember that no one-to-one-line correspondence exists between the two files). If you set a breakpoint in a generated servlet, it is reflected in the JSP page with one exception. If the breakpoint is in part of the servlet derived from a statically included JSP page, it is not reflected. Removing a breakpoint from the JSP file removes the corresponding breakpoint in the generated servlet. However, the reverse is not the case.

Viewing the Generated Servlet

From the Explorer, click the Filesystems tab. Select the JSP source file. Right-click to display the contextual menu. If the JSP file has not yet been compiled, that is, the View Servlet action is not enabled, choose Compile from the contextual menu. Once the JSP file has been compiled, choose View Servlet from the contextual menu.

The Source Editor opens with a view of the generated servlet code. If the JSP file is already opened in the editor, you can also view its generated servlet from the editor's contextual menu. Right-click inside the editor window, and select the Show code in servlet action.

By default, the generated servlet file appears in a new tabbed pane of the Source Editor.

Note that the generated servlet is not automatically updated if you make changes to the JSP source. After you make changes, run the View Servlet or the Show code in servlet action again to see the new version.

Starting the Debugger

Start the debugger by selecting the resource you would like to debug in the Explorer. Then choose the Start item from the IDE's Debug menu. It is not necessary to stop and restart the debugger to debug a different resource. With the web module running, either follow a link in the browser window, or type the URL directly into the browser's location field.

When debugging a helper class that cannot be run on its own, you must start the debugger on a different resource, for example, on the web module's WEB-INF node.

To debug a web module group, select the WEB-INF node from any web module within the web module group. Then choose Start from the Debug menu.

For more information about standard debugging in the IDE, see "Debugging a Program" in the Core IDE online help.

When you start the debugger, the HTTP Monitor window appears. See Using the HTTP Monitor to Debug a Web Application for more information on using the HTTP Monitor to aid in debugging.

Setting JSP Debugger Options

You can customize your JSP debugging sessions through the IDE's global options as follows:

• Specify the class of files in which errors are to be shown with the JSP source file and generated servlet file open. From the Options window, expand the Building node. Select the JSP & Servlets node. Then in the Properties pane, choose Show in Servlet Source or Show in JSP Source from the combo box for the JSP Compiler Errors option.
• Designate whether to skip static HTML lines between JSP tags in the JSP source, as well as the corresponding lines in the generated servlet source when debugging. Static HTML lines are lines that do not contain any JSP element or scripting language. From the Tools menu in the IDE's menu bar, choose Options. Then expand the Debugging and Executing node. Then choose JSP & Servlets Settings. In the Properties pane, set Skip Static Lines to True.

For details, see "JSP Debugger Options" in the JSP/Servlet online help.

Viewing Both JSP and Servlet Files During Debugging

You can view the JSP source file and its generated servlet file side by side during debugging. This features helps you detect JSP errors during the debugging cycle. You can set breakpoints and step through code with both files in sync.

Open the generated servlet in the Source Editor. (See Viewing the Generated Servlet for details.) With the JSP file still selected in the Explorer, choose Open from the contextual menu. By default, the JSP source file code appears in a new tabbed pane of the Source Editor. At this point, you can see the servlet code or the JSP code, but not both at the same time. Right-click the current view in the editor, and choose Clone View from the contextual menu. This action opens a new Source Editor window with a view on the same JSP code.

Now two editor windows are displayed side by side. One window provides a view of the JSP code. Another window offers a view of the servlet code. You must compile the JSP file in order to show the changes in the generated servlet. For details, see "Viewing JSP and Servlet Files During Debugging" in the JSP/Servlet online help.

---

Packaging Your Web Applications

During development, a web module is typically executed in its unpacked form. This practice makes it easy to update frequently. However, when you are ready to deploy to a production environment, you can package the web module into a Web ARchive (WAR) file. This practice facilitates the transfer process. When you create a WAR file from the IDE, the IDE, by default, includes all files in the web module's filesystem except those files with the .java extension. For directions on using the IDE to package a web module directory into a WAR file, see "Packaging a Web Module" in the JSP/Servlet online help.

In the IDE, you can:

• Create a WAR file from a web module
• Specify WAR packaging options
• View the contents of WAR files generated from web modules
• Mount WAR files as web modules

Building a WAR File From a Web Module

You can build a WAR file from a web module in one of two ways:

• Select the root of the web module in the Filesystems Explorer. Then choose Export WAR File from the Tools menu
• Right-click the web module's WEB-INF node. Then choose Export WAR File from the contextual menu.

Then you must specify a name for the WAR file. All files under the web module filesystem are included in your WAR file by default.

For additional information, see "Packaging a Web Module" in the JSP/Servlet online help.

Specifying Options

Packaging options for web modules appear on Archive tab of the WEB-INF node property sheet. You can add files that are external to the web module to the WAR package. Files can be added from any filesystem mounted in the Explorer. Possible choices include all files, all files except .java (the default option), and all files except .java, .jar, and .form. Alternatively, you can specify a regular expression such as .*txt or Pro.*. You can choose either the predefined filter or a regular expression, but not both the filter and the expression. Note that the regular expressions used for filters are not the same as UNIX regular expressions. For details, see "Editing Web Module Archive Properties" in the JSP/Servlet online help.

Viewing Contents

You can view the contents of a WAR package using the WAR Contents window. Files included in a WAR package are determined by properties set using the Archive tab of the WEB-INF node's property sheet.

The WAR Contents window lists the files to be included when the web module is exported as a WAR file. It also provides path and extension information for each file.

By default, the list is sorted alphabetically by path name. Sort the list alphabetically for another column by clicking the header for that column. For more information, see "Viewing the Contents of a WAR File" in the JSP/Servlet online help.

---

Packaging and Deploying a Custom Tag Library

For a JSP page to reference a custom tag library, the tag library must exist within the web module containing the JSP page. When you are using a tag library within a production web module, it is a good idea to package it as a JAR file. This practice makes it easier to use your tag library in other web modules. The tag library can be added to a web module in any of the following ways:

• Using the Add JSP Tag Library menu action to add a JAR file from the Tag Library Repository
• Using the Add JSP Tag Library menu action to add a JAR file from the filesystem
• Copying and pasting a JAR file from another web module or filesystem.

When you use one of these methods to add a tab library JAR file to a web module, the IDE also mounts the tag library in the Filesystems pane of the Explorer.

Packaging a Tag Library as a JAR File

You package a tag library into a JAR file to make it easier to deploy. To create the tag library JAR, choose Create Tag Library JAR from the tag library's contextual menu. When you create a tag library JAR, the IDE creates a file with a .jar extension. It also creates an associated jarContent file, which adds additional classes or packages to the library. The jarContent file is also referred to as the recipe file.

For information on the properties of the newly created JAR file, see "JAR Recipe Nodes in the Explorer" in the JSP/Servlet online help.

Deploying a Tag Library Using the Tag Library Repository

You can deploy a tag library using the Tag Library Repository.

To add a tag library from the Tag Library Repository to a web module, choose Add JSP Tag Library from the WEB-INF node's contextual menu. Then choose the Find in Tag Library Repository item, which displays the Tag Library Repository Browser dialog box. Select one or more items from the list, and click the OK button. The appropriate JAR files for the selected tag libraries are added to the WEB-INF/lib directory along with any necessary entries in the deployment descriptor.

When the tag library JAR files are added to the web module, they are also mounted in the Filesystems tab of the Explorer

Deploying a Tag Library by Adding a JAR File From the Filesystem

If a tag library JAR is in another web module or mounted filesystem in the IDE, you can use the Add JSP Tag Library > Find in Filesystem action. This action locates the JAR and copies it into the WEB-INF/lib directory of your web module. You can add a tag library JAR file from any mounted filesystem to a web module. Right-click the WEB-INF node. Choose Add JSP Tag Library, then Find in Filesystem. If necessary, the deployment descriptor is automatically updated to include an entry for the tag library. This entry is used to map the tag library to a URI for your JSP pages to use in accessing the tags

Deploying a Tag Library by Copying and Pasting a JAR File From Another Module or Filesystem

If there is a tag library JAR in another web module or mounted filesystem in the IDE, you can choose the Copy action from the contextual menu on the Explorer's WEB-INF node. Then paste the JAR file into the WEB-INF/lib directory of your web module. When copying and pasting a tag library JAR file into a web module's WEB-INF/lib directory, a taglib element in the deployment descriptor might be created. In most cases, the IDE adds the Taglib element automatically. You can verify that the correct information is present. To perform this task, follow the instructions in "Packaging and Deploying a Custom Tag Library" in the JSP/Servlet online help.

---

Including a Web Module Within a J2EE Application

When using the IDE, you can create a J2EE application from an existing EJB module or web module. Alternatively, you can create the application from an Explorer filesystem or package node. In both cases, after instructing the IDE to create the new application, the new J2EE application's node appears in the Explorer. Then you can begin adding modules to the application.

A J2EE application is composed of EJB modules, or web modules, or both. You create J2EE applications in the IDE, either from an existing EJB module or from a filesystem in the Explorer. After creating an J2EE application, you can add web modules to it.

For details on adding a web module to a J2EE application, see "Adding an EJB or Web Module to a J2EE Application" in the J2EE Application Assembler online help.

For more information on assembling web modules into a web application, see Building J2EE Applications.