Configuring the Servlet Container
The servlet container hosts all services, including both servlets written directly with the Servlet API and Web services created from WSDL files using the rwsfgen code generator. HydraExpress Web services are implemented as servlets.
A global
web.xml file located in
<installdir>\conf\servlet sets configuration parameters that apply to all servlet contexts. Individual servlets are configured in a
web.xml configuration file that must reside in a
WEB-INF directory inside your project.
Table 5 shows the deployment structure for servlets and services, including the location of this file.
Table 5 – Servlet container deployment directory structure
Directory Name | Contents |
<installdir> | HydraExpress installation directory |
apps | Agent deployment directory |
\servlets | Contains context directories for all servlets and Web services deployed in the Agent |
\<servicecontextname> | Contains WSDL and configuration files |
\WEB-INF | Contains servlet descriptor web.xml and named objects configuration file objects.xml |
apps-bin (Windows) | Deployment of user-created servlet, named-object, handler and listener libraries. |
apps-lib (Linux/UNIX) |
Configuring the Global web.xml File
The global web.xml file sets configuration parameters that apply to all contexts. The web.xml file, located in the <installdir>\conf\servlet directory, maps common file extensions to mime-types and sets resources to handle global error pages. Many installations require no changes to the global web.xml file.
The global web.xml file does not define a context, so this file should not define or map servlets, filters, listeners, or named objects. The HydraExpress Agent ignores any such definitions or mappings in the global web.xml file.
For more information, see “Context Does Not Load,” in the HydraExpress Servlet Development Guide.
Configuring Individual Servlets in the Context-Level web.xml File
Individual servlets are configured in a web.xml configuration file that is part of the project. For Web service projects, rwsfgen generates the file conf\<servicecontextname>_web.xml, which then gets deployed as <installdir>\apps\servlets\<servicecontextname>\WEB-INF\web.xml. The code below shows the web.xml file for the HelloWorld example:
<web-app>
<servlet>
<servlet-name>GreetingPortService</servlet-name>
<servlet-class>rwsf_webservice_servlet
.createWebServiceServlet</servlet-class>
<init-param>
<param-name>configFile</param-name>
<param-value>handlers.xml</param-value>
</init-param>
<init-param>
<param-name>serviceName</param-name>
<param-value>GreetingPortService</param-value>
</init-param>
<init-param>
<param-name>wsdlFileName</param-name>
<param-value>HelloWorld.wsdl</param-value>
</init-param>
</servlet>
<servlet-mapping>
<servlet-name>GreetingPortService</servlet-name>
<url-pattern>/HelloWorld/*</url-pattern>
</servlet-mapping>
</web-app>
You can use any web.xml file from the examples as a template for extending web.xml files for your services, although in most cases the generated file should be sufficient. For additional information on servlet configuration for Web services, see “About the Servlet Used by the Service,” in the HydraExpress Web Service Development Guide.
For servlets, you can use the web.xml file in <installdir>\apps\servlets\examples\WEB-INF\web.xml as a model. Configuration of servlet projects is discussed in detail in the HydraExpress Servlet Development Guide.
Single-Thread and Multithread Issues
Servlets are inherently multithreaded, so a single instance of a servlet may be invoked from multiple requests threads. However, the servlet container supports a simple mechanism for serializing access to a particular servlet. If a servlet element in the web.xml file contains the attribute single-thread="true", the servlet container only allows one thread at a time to enter the servlet. If a new request arrives for the servlet while a thread is active in the servlet, the new request waits until the active thread leaves the servlet. This slows down the servlet, and may even slow down other servlets in the Agent if many threads are waiting. The container does not prevent threads from entering other instances of the servlet, and other threads in the container remain active when a thread enters a single-thread access servlet.
The servlet element below specifies that only one thread at a time may enter the singleServlet instance.
<servlet single-thread="true">
<servlet-name>singleServlet</servlet-name>
<servlet-class>sync.createSingleServlet</servlet-class>
...
</servlet>
Single-thread access can be useful for debugging purposes or as a temporary wrapper around an application with threading problems. However, because single-thread access does not completely solve threading issues and can reduce performance for the overall servlet container, it may be unsuitable for production applications. Configuring multiple containers, each with a single thread, may offer better performance, as described in
“Configuring Multiple Single-Thread Servlet Containers.”.
Configuring Multiple Single-Thread Servlet Containers
Although the servlet container is inherently multithreaded, code that is not multithread-safe can be hosted in a servlet container provided that the container is configured so that only one thread is active within servlet code at a given time, as described above. To increase performance, configure more than one connector/handler chain combination, each of which defines a single-thread servlet container, and use a load balancer to balance requests between them. Although this solution provides somewhat lower performance than a multithreaded servlet container, this strategy may provide acceptable performance for single-threaded code in a production environment.
The only required change to the configuration of the servlets running in the single-thread containers is the attribute
single-thread=”true”. Otherwise, declare servlets as you normally would, as discussed in
“Configuring Individual Servlets in the Context-Level web.xml File.”.