NetBeans: WebApps
Uses of Tomcat in the NetBeans IDE
Version: 0.1
Author: Petr Jiricka, Sun Microsystems/NetBeans
- Abstract:
- This document describes in sufficient technical detail how the Jakarta Tomcat server is used in the IDE, and discusses
the possibility and needs to use different versions of Tomcat or other servers.
- Document History:
- [7-Sep-2001] : version 0.1 : Initial revision
- Contents:
- 1. Introduction
- 2. Uses of Tomcat in the IDE
- 2.1 Tomcat as a Server Plugin
- 2.2 Tomcat as IDE internal server
- 2.3 Tomcat as JSP parser
- 3. Bundling Tomcat in the IDE
- 4. Using other versions of Tomcat than 3.2
The role of the Tomcat server in the IDE is not widely understood. This documents attempts to explain how the IDE makes use of Tomcat, what is the mechanics of integration of Tomcat with the IDE, how the IDE can grow as Tomcat grows, and what are the possibilities for future interactions between Tomcat and the IDE.
There are a variety of uses of the Tomcat server in the IDE. This chapter explains all the different roles Tomcat plays in the IDE.
Currently version 3.2 of Tomcat is bundled and used in the IDE, for all roles. It may be desirable (and feasible) for the future to use a different version of Tomcat for each role.
The most prominent use of Tomcat is the use of Tomcat 3.2 as a plugin for the server integration architecture. The plugin handles execution, compilation, testing, debugging and monitoring of web applications on an instance of Tomcat 3.2 server. The plugin runs a Tomcat instance as an external process and takes care of all communication between the IDE and the external Tomcat instance. The plugin is an independent separate module, which means that the IDE can succesfully run without the plugin (note that the Tomcat server classes are still necessary). All features of the Web Application support, which do not depend on the server integration architecture (such as the JSP file editor and the deployment descriptor editor) continue to work without the plugin.
As the server integration architecture allows several server plugins to coexist in the IDE, multiple versions of Tomcat can be supported in the IDE at the same time (by providing plugin for each version).
Tomcat server is used by the internal HTTP server module (httpserver in the OS CVS). The main role of the httpserver module is to provide access for external processes to code developed by the user inside the IDE. Such access is vital for example for testing applets (where applet viewer downloads code from a HTTP code base) or for testing RMI and JINI applications (similar use as applets). But it is also used by other software which needs to somehow communicate with the IDE - as an example, the HTTP Monitor sends data about the running application to the IDE through the internal server. Tomcat 3.2 is used as the actual engine which serves external HTTP requests. So in this case Tomcat server runs inside the IDE VM.
Also, this instance of Tomcat is independent of the instance used as a server plugin.
In some instances, it is desirable to find out information about JSP pages and about elements the pages are composed of. As an example, if the JSP compilation framework knows which
<jsp:useBean> tags a particular page contains, it can force compilation of the appropriate JavaBean files before the JSP is compiled.
Another example is the JSP editor, which needs to know which tag libraries are imported into a JSP using the
<%@taglib%> directive. That way, it can distinguish whether a particular tag (e.g.
<db:connect>) is a JSP tag declared in a tag library, or whether this tag belongs to the content language of this JSP (i.e. HTML or XML). Based on this distinction, it can provide different coloring for JSP tags than for content language tags. This also helps to provide the code completion feature for custom tags.
Last example of use of JSP parse information is the use by the JSP debugger. Consider a file which is included in multiple JSP files using the
<%@include%> directive. When the user sets a breakpoint in this file, the debugger in fact needs to set breakpoins in the servlet files compiled from the including JSP files. So it needs to find out which JSP files include a particular file. Again, parsing JSPs helps to provide this information.
Parsing of JSP files is carried out by the part of the WebApps support independent of the server integration architecture. The actual parsing engine used is the Tomcat 3.2 JSP parser, bundled with the IDE.
It is desirable that the parsing engine used by the IDE supports the highest version of JSP specification that the IDE supports. That way JSP pages which comply to the highest version, but do not comply to the lower versions, will be handled correctly. So in a version of the IDE which supports JSP 1.2, parser which also supports JSP 1.2 must be used for correct operation.
Currently, the IDE bundles Tomcat version 3.2. Only the very core of Tomcat (e.g. Tomcat jar files) are bundled. These are files
/modules/ext/webserver.jar and
/modules/ext/jasper.jar. Not distributing the whole Tomcat causes some problems, for example that expert users which are familiar with Tomcat are not able to use all Tomcat features, such as Apache integration. Another disadvantage is that Tomcat documentation does not come with the IDE, so users who want to use advanced Tomcat features have little chance to learn about them. Also, the Tomcat configuration file is stored separately from the installation, which makes maintenance of Tomcat more difficult.
Having Tomcat under /modules/ext/ will also be a disadvantage when we want to support or bundle multiple versions of Tomcat - where should the second version be put ? It would have to be a different place than /modules/ext/, which would create asymmetry. For the future, a different solution for bunding Tomcat needs to be found.
In the future it may be desirable to use higher versions of Tomcat in the IDE as the Tomcat server evolves. The advantages are obvious - support for higher versions of Servlet/JSP specifications, taking advantage of new features added to Tomcat, more stable releases. We may even want to provide integration with multiple versions of Tomcat, so we support both users which use the newest technologies, and users which prefer proven software.
It is important to think about which uses of Tomcat in the IDE will benefit from using higher versions, which may benefit from the ability to use multiple versions of Tomcat, and for which the particular Tomcat version is not important. It is also important to know to what extent the individual roles that Tomcat plays are separable.
As for using Tomcat as a server plugin, it is desirable that multiple versions of Tomcat are supported at the same time (through multiple plugins), and that the Tomcat server does not need to be bundled in order to be supported for WebApps development (use user's installation instead). Currently this is fully feasible thanks to the server integration architecture.
While the internal HTTP server uses Tomcat, the actual version of Tomcat used in this case is not important. The only limitation is that the server used must be a lightweight embeddable server which supports servlets (not necessarily the latest version of the spec; it also does not need to support JSPs). As this use of the Tomcat is independent of the other uses, there is no limitation as to which version of the server must be used for this feature. The only limitation is that the core of the server must be bundled with the IDE - the JSP support does not need to be bundled.
The JSP parser will benefit from using the highest possible version of Tomcat. In FFJ 3.0 the parser used is Tomcat 3.2, for FFJ 4.0 we may need to switch to Tomcat 4.0 parser. One advantage of using Tomcat 4.0 parser would be that in this version, the parser is a separate software independent of the Tomcat core, so only this part of Tomcat needs to be bundled with the IDE.
There is one problem in the current IDE JSP parsing architecture which needs to be solved: currently the parser is tightly integrated with the WebApps core module, and the Tomcat parser is required to be included in the classpath od the WebApps core module. This will likely cause problems to server integration plugins which rely on another version of Tomcat than the one used for parsing, and depend on the WebApps core module. These plugins will experience class version clash problems. A possible solution is to separate the JSP parser from the core WebApps module. The WebApps core module would provide infrastructure for plugging in a JSP parser, but the parser itself (which would include the revevant Tomcat classes in its classpath) would be implemented as a separate module, depending on WebApps core. This module would register itself as 'the JSP parser' in the WebApps core module.
This shows that it will be possible to easily replace Tomcat by another Tomcat version (or a different server, if it has the necessary features) where appropriate, but for some features to work it will still be desirable to bundle the Tomcat server with the IDE.
