his applies to all the version of tomcat and this feature enabled for NimsoftSD and helped a lot to improve their application performance.

What is GZIP?

It is a compression format created by Jean-Loup Gailly and Mark Adler. Version 0.1 was first publicly released on October 31, 1992.

GZIP is based on the DEFLATE algorithm, which is a combination of LZ77 and Huffman coding. DEFLATE was intended as a replacement for LZW and other patent-encumbered data compression algorithms which, at the time, limited the usability of compress and other popular archives.

How does it helps in improving performance of my web page?

Modern browser like Internet Explorer, Firefox, Opera etc supports gzip compressed content. These browsers are capable of uncompressing gzip data into plain text. Servers like Apache, Tomcat, JBoss etc supports gzip compression too. Hence if gzip is enabled in such servers, the response if first compressed and then send to client. Hence this increase performance by many folds.

How to enable GZIP in my tomcat server?

Here is how to enable GZIP compression on Tomcat: edit file /conf/server.xml and add to the HTTP Connector configuration something like this:

compression="on"

compressionMinSize="2048"

noCompressionUserAgents="gozilla, traviata"

compressableMimeType="text/html,text/xml"

An example of a HTTP Connector configuration with compression enabled could be:

<Connector port="8080" maxHttpHeaderSize="8192"

maxThreads="150" minSpareThreads="25" maxSpareThreads="75"

enableLookups="false" redirectPort="8443" acceptCount="100"

connectionTimeout="20000" disableUploadTimeout="true"

compression="on"

compressionMinSize="2048"

noCompressionUserAgents="gozilla, traviata"

compressableMimeType="text/html,text/xml"/>

Fixing 'too many open files' error

Once in a while we stumble upon 'too many open files' error in log files especially for java application servers. What this means is that you have hit a limit on number of open file descriptors (fd)/file handles assigned for the process or user the application server is running as.

Let's use tomcat for our example.

So to get the number of fd's used by tomcat we run

$ pgrep tomcat

12345

$ sudo ls /proc/12345/fd | wc -l

2040

Don't use `lsof | wc -l` to get the number of fd's. `lsof` lists much more than the number of fd's in use. If you look at the FD column you'll see memory mapped files, current working directory, root directoy, the text segment of the running process etc listed which don't utilize file descriptors.

To see the fd limit run `ulimit` as the application user

$ sudo -u tomcat sh -c 'ulimit -n'

2048

One can also check for soft limit(-S) and hard limit(-H)

$ sudo -u tomcat sh -c 'ulimit -Hn'

2048

To see the system wide fd limit

$ cat /proc/sys/fs/file-max

148922

Or

$ sysctl fs.file-max

fs.file-max = 148922

To find the current system wide fd usage

$ cat /proc/sys/fs/file-nr

1184 0 148922

Or

$ sysctl fs.file-nr

fs.file-nr = 1184 0 148922

The first field shows the number of allocated fd's, second field gives the number of allocated but unused fd's and the last field shows the maximum number of fd's. So in the above example 1184 fd's are allocated and all are in use.

So once you hit a limit the next step, obviously, is to increase it a bit. So let's do that.

For example to change the limit for tomcat user append the below lines to /etc/security/limits.conf

tomcat      soft    nofile  1024

tomcat  hard    nofile  3072

We can also put

ulimit -n 3072

in the shell script (startup wrapper script or rc script) that invokes the application server to change the limit for that process as all processes spawned from the shell will inherit the limit.

To increase the system wide limit we have to change the kernel runtime parameter fs.file-max and save it in /etc/sysctl.conf

# echo 'fs.file-max = 200000' >> /etc/sysctl.conf

# sysctl -p

# sysctl fs.file-max

fs.file-max = 200000

A tale of two servers

The Apache httpd web server and the Apache Tomcat server are two very popular products in use for delivering web content.

About the Apache httpd server

The Apache httpd web server grew out of the NCSA web server. At its core, httpd implements the HTTP protocol specification. It was primarily designed to serve static files to browsers. Over the years, many features have been added and the core web server can be extended through the use of modules. Some popular modules include:

• mod_rewrite : this module provides a powerful mechanism for the administrator to rewrite URL requests that come in or get sent out of httpd
• mod_cache : this module provides a top-level module framework for caching web content
  
• mod_ssl : this module adds strong encryption to httpd using the OpenSSL toolkit
• mod_dbd : this module adds a database connectivity layer to httpd
• mod_mime : this module allows the administrator to control actions within the server based on MIME types and file extensions, it allows for the defining of handlers and filters for output

The Apache httpd web server ships with over 70 modules and there is a repository of 3rd party modules to extend it even further (currently with 490 modules.)

About the Apache Tomcat server

The Apache Tomcat server is a project that started at Sun Microsystems as the reference implementation of the Java Servlet and Java Server Pages Specifications. The Tomcat code base was donated by Sun to the Apache Software Foundation in 1999. As the Java Servlet and JSP specifications develop and mature, Tomcat's versatility grows and expands. As implied, the Tomcat server is run in a Java virtual machine and requires, at least, a JRE (Java Runtime Environment) to run although it is more commonly run using a JDK (Java Development Kit.) Tomcat should run anywhere a JDK is available (Linux, Windows, UNIX, etc.).

Tomcat also implements the HTTP protocol and can be extended to execute non-Java scripts, such as Python, PHP and Ruby.

For the remainder of the article, the Apache httpd web server will be referred to as "Apache" and the Apache Tomcat server will be referred to as "Tomcat."

The relationship between Apache and Tomcat

Both Apache and Tomcat implement the HTTP protocol for serving files to browsers. Both can be extended to serve dynamic content using many popular scripting languages. So what are the differences? Why would you choose one over the other? To answer that, let's look at the strengths.

• There is no module to allow Apache to directly execute Java code. Since Tomcat is a Java application executing in a Java virtual machine, Java becomes the native language of the web applications it serves.
  
• It can be argued that the integration of scripting languages like PHP and Python is better with Apache than with Tomcat but this isn't easily proven or refuted.
  
• Apache generally has a smaller memory footprint than Tomcat and serves static content faster using fewer resources.
  
• Virtual hosting, aliasing and URL rewriting are, generally, easier to configure in Apache.

Because of these points, people usually use Apache for supporting scripting languages and serving static content and use Tomcat for Java applications. Where they merge together is in the use of an Apache module, mod_jk for the 1.3.x and 2.0.x versions of Apache and mod_proxy_ajp for the 2.2.x version of Apache. The module allows Apache to proxy requests between the browser and a Tomcat server seamlessly through the use of a binary protocol, with persistent connections, to streamline communications, making it the preferred mechanism for connecting the two servers.

Another way to connect Apache and Tomcat is to use the mod_proxy_http module in Apache 2.2.x. This is a generic HTTP proxy and does not provide the benefits of the mod_jk/mod_proxy_ajp modules.

The combination of Apache and Tomcat provides for a powerful and scalable web server architecture

Integrating PHP into Tomcat

You can integrate PHP into Tomcat. To do so, you'll need PHP4 so you can build the servlet SAPI. To date, I have not found a servlet SAPI for PHP5.

To successfully build PHP and the Java jar file, you must patch PHP's configure script before you can configure PHP itself. You must also patch one of the Java class files if you are using a recent JDK.

Patching the Java class file

The file you need to edit is in the sapi/servlet directory in your PHP source tree. Edit the servlet.java file. You are going to change a variable name so it does not clash with a reserved word in Java. The variable is only used on lines 66, 70 and 71.

Change the 'enum' variable to 'xenum', as highlighted below:

if (!request.getMethod().equals("POST"))

Unknown macro: { result = request.getQueryString(); }

else {
Enumeration '''xenum'{{ = request.getParameterNames();
String concat = "";
result = "";

while (}}'xenum'{{.hasMoreElements()) {
String name = (String)}}'xenum'{{.nextElement();
String value = request.getParameter(name);

Patching the }}configure{{ script

The PHP }}configure{{ script has never been updated for the latest Java Servlet API specification. In the specification, the servlet jar file was renamed from }}servlet.jar{{ to }}servlet-api.jar''. To build PHP's servlet SAPI module, you need to update the configure script to check for the existence of servlet-api.jar. Edit the configure file and search for SERVLET_CLASSPATH. The reference you're looking for is around line 8,445. You need to add some "if" blocks in the "else" branch, like this:

if test "$withval" = "yes"; then
SERVLET_CLASSPATH=.
else
'if test -f $withval/common/lib/servlet-api.jar; then'
'SERVLET_CLASSPATH=$withval/common/lib/servlet-api.jar'
'fi'
if test -f $withval/common/lib/servlet.jar; then
SERVLET_CLASSPATH=$withval/common/lib/servlet.jar
fi

The highlighted if block needs to be added.

Configuring PHP

The relevant configure parameters for PHP are:

• --with-javaOPS:=path to JDK : this is where your JDK is installed
  
• --with-servletOPS:=path to Tomcat : this is where Tomcat is installed

The make and make install steps should should be error-free. If not, then you need to fix those problems first.

Installation

The make install step above should copy the phpsrvlt.jar jar file from the PHP build tree to Tomcat's common/lib directory. If it doesn't then you need to do that manually.

Tomcat's web.xml needs to be updated to include the servlet mappings. A web.xml exists in the sapi/servlet directory of the PHP source tree with the proper mappings. Copy them into the appropriate Tomcat xml file.

Finally, you need to create a symbolic link in the lib/php directory where you installed PHP. Create a linked named php4.so pointing to libphp4.so as follows:
<code>
ln -s libphp4.so php4.so
</code>
Now, you need to restart Tomcat.

Testing

Add this code to a file in Tomcat's webapps/ROOT directory:
<code>
<?php
phpinfo();
?>
</code>
and access this file from a browser. You should get PHP's standard phpinfo page.

More functions and features provided by OpenSSL

For the following examples, here's a list of the files and what they represent:

1. cert.p12 = a PKCS#12 encoded certificate and key pair. This is one of the formats used by IIS.
   
2. cert.crt = a PEM encoded certificate. This is one of the formats used by Apache and the Load balancers.
   
3. cert.key and cert2.key = a PEM encoded key. This is one of the formats used by Apache and the Load balancers.
   
4. cert.csr = a certificate request. This is what gets sent to the CA for signing.

All examples assume you have OpenSSL installed somewhere on your PATH.

Converting from PEM (Apache/Load balancer) to PKCS#12 (IIS)

openssl pkcs12 -export -out cert.p12 -inkey cert.key -in cert.crt

Converting from PKCS#12 (IIS) to PEM (Apache/Load balancer)

This is a 2-step process. The first extracts the cert. The second extracts the key. Since the PKCS#12 certificate was encrypted during export, you'll need to provide that password. You'll be prompted for another password during the key extraction step. This will encrypt the resulting key but you can remove the password, as detailed later.

openssl pkcs12 -clcerts -nokeys -in cert.p12 -out cert.crt
openssl pkcs12 -nocerts -in cert.p12 -out cert.key

Removing a password from a key

openssl rsa -in cert.key -out cert2.key

Adding a password to a key

openssl rsa -in cert.key -des3 -out cert2.key

Displaying the contents of a Certificate Request

openssl req -in cert.csr -text

Displaying the contents of a self-signed certificate

openssl x509 -in cert.crt -text

Apache and mod_rewrite

The mod_rewrite module provides a very helpful, very powerful tool for the administration of web sites. As the name implies, it provides a mechanism to rewrite URLs. Here are a few examples where mod_rewrite comes in handy:

• client redesigns their web site and the programming framework uses different URLs than the previous site but the client needs to maintain "friendly" top-level links, such as http://www.client.com/products and http://www.client.com/support
• client removes a lot of content and would like to use a generic "not found" page to inform the user instead of a regular "404 Not found" page
  
• restrict access to certain content based on an environment variable
  
• set a cookie based on the URL
  
• the client has SSL certificates installed on the web server (not the load balancers) and needs to do redirects to HTTPs for certain pages, additionally, they would like to do this in Apache instead of processing the request with the more heavy-weight Tomcat/Jboss/Weblogic app layer.

The manual for mod_rewrite is available online at http://httpd.apache.org/docs/2.0/mod/mod_rewrite.html and contains many examples.

It is important to remember that the rewrite engine checks patterns first, then checks the condition(s) to see if the pattern should be applied. This is a little backwards from traditional thinking where conditions are checked before applying the logic associated with the conditions.
This example was taken from a client with the following requirements:

• a 3rd party site contains a link to a Opsource-managed web site
  
• any requests coming from the 3rd party site should be allowed through
  
• requests coming from the 3rd party site would be distinguished by a special URI string
  
• all other requests to the site should be denied

The following rewrite rules were put in place. Again, the RewriteRule is checked *before* the RewriteConds are checks. In this case, the RewriteRule is looking at ^.* which matches everything.:

RewriteEngine On
#RewriteLog "logs/tac_rewrite.log"
#RewriteLogLevel 4

RewriteCond %{HTTP_REFERER} !^https://www\.heisenbug\.cop/portal/site/index\.jsp
RewriteCond %{REQUEST_URI} !/286482b67b05ad585cfc99996f5158d7
RewriteCond %{HTTP_REFERER} !^http://www\.mysupersite\.cop.*
RewriteRule ^.* /denied/denied.html [L]

The "RewriteEngine On" simply turns on the rewrite processing engine. The Rewrite log directives specify a log that only the rewrite engine uses and the level of information printed in the log. The first RewriteCond rule checks the environment variable HTTP_REFERER, which is the referring web site, is not set to the 3rd party site. This variable is sent by the browser when you click a link on a page. The second RewriteCond rule checks that the special string is, again, not set in the URI. The third RewriteCond rule checks that the referer variable is not the Opsource-managed site itself. This is necessary for when the user clicks links on the Opsource-managed site.  If any of these conditions are true, the user is redirected to a denied page. The [L] at the end of the ReWriteRule means "stop processing any more rules, this is the last rule."

This seems counterintuitive but fulfills all our requirements because only traffic that comes from the 3rd party web site or contains the special URI string will not be redirected to the denied page, in effect, the proper resource will be delivered to the browser. It should be noted that the HTTP_REFERER and the URI string (used in this example) are easily faked and this should *not* be used as a means of securing a web site. The client was made fully aware of this and they opted for it since they only wanted to prevent "casual" browsing.

Requirements:
(This guide assumes the following)
Apache 2.2 and Tomcat 7.0 installed and working with defaults settings

• Step 1: Login to the server with Apache 2.2 installed on it
  
• Step 2: Down load the following file mod_jk
• Step 3: Copy the file mod_jk.so to the following folder (%Apache root%\modules)
  
• Step 4: Edit the httpd.conf file (%Apache root%\conf\httpd.conf)
  
• Step 5: Add the following code to the bottom of the file

LoadModule jk_module modules/mod_jk.so

JkWorkersFile conf/workers.properties

JkLogFile logs/mod_jk.log

JkLogLevel error

JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "

JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories

JkRequestLogFormat "%w %V %T"

JKMount /*.jsp example

#example can be renamed but (worker.list=) must be updated in the workers.properites file

• Step 6: Make a new file called workers.properties at (%Apache root%\conf) with the following code
  

  Icon

  Make sure to add host IP and port, and remove <> sections

# Define worker 'example'

worker.list=example # Must be same name as name at the end of JKMount in apache's httpd.conf file

# Set properties for worker 'example' (ajp13)

worker.example.type=ajp13

worker.example.host=<server IP of tomcat server, can be localhost if tomcat is installed on the same server>

worker.example.port=<port number for Tomcat AJP/1.3 connector, Default is 8009>

worker.example.cachesize=10

worker.example.cache_timeout=600

worker.example.socket_keepalive=1

worker.example.recycle_timeout=300

• Step 7: Make a .jsp page to test
  
• Step 8: Use the following code make a file called test.jsp and save (%Tomcat Root%\webapps\test)

<html>

<head>

<title>Tutorial: HelloWorld</title>

</head>

<body>

<h1>Testing Page Load from Tomcat</h1>

JSP page loading from Tomcat

</body>

</html>

Now you are done, any request for a .jsp page that comes into Apache will be served by Tomcat.

Each application server has a slightly different process for enabling remote JMX Access. It's best to consult with your application server for specific instructions.

For a default tomcat install, one can simply add the following line at the top of server/tomcat/bin/catalina.sh after initial comments (remember, many customers or admins modify start up scripts to a great extent, but the principle of enabling JMX remains same)

CATALINA_OPTS="-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=12345 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false"

One can then use JConsole (jconsole is available in openjdk software) to connect to <IP>:12345, where IP has to be replaced with host IP.

Note: You should ensure port 12345 is opened from where the host is monitored. So, if you are would like to monitor JMX values from a third party monitoring such as zenoss, make sure port is opened to zenoss.

Wondering why we used CATALINA_OPTS instead of JAVA_OPTS?

Read the comments in catalina.sh

JAVA_OPTS   (Optional) Java runtime options needs to be used when the "start","stop", or "run" command is executed.

CATALINA_OPTS   (Optional) Java runtime options used when the "start"  or "run" command is executed.

You may encounter following error during tomcat shutdown:

Error: Exception thrown by the agent : java.rmi.server.ExportException : Port
already in use: 12345;nested exception is:    java.net.BindException: Address already in use

To avoid error like this when shutting down tomcat, Port 12345 need not be in use while the instance is shutting down.

We are therefore using CATALINA_OPTS and disabling the exceution of this option during tomcat shutdown via "stop" in catalina.sh.

After the following lines in catalina.sh

elif [ "$1" = "stop" ] ; then

  shift

  FORCE=0

if [ "$1" = "-force" ]; then

    shift

    FORCE=1

  fi

Change

"$_RUNJAVA" $JAVA_OPTS $CATALINA_OPTS \

to

"$_RUNJAVA" $JAVA_OPTS \

This was actually a bug reported in apache site, you can find details for this issue at:

Tomcat shutdown bug while using JMX port

If you need JMX monitoring enabled via zenoss, please refer the following article:

Monitoring Using ZenJMX

System Requirements

• Tomcat 6 or higher
  
• The application's web.xml has must have <distributable/> tag.

Network Requirements

• Have multicast enabled for tomcat to communicate.

Configuring Tomcat for Cluster

1. Add the cluster config inside the <Host> tag. I have attached the cluster config text to this page.
   
   • The only changes that needs to be made is the (name="<Put_application_Name_Here>"). Put the .war file name.
2. export the server.xml file to the servers that are part of the cluster.
   
3. restart all tomcat instances.

Moving SSL Certs from IIS to Apache

These instructions will help you convert SSL certificates generated for IIS to private key, and cert files you can use on unix, or Apache for windows.

First Export your IIS certificate into a pfx file (this is something you should do anyways for backup)

• Run mmc.exe
  
• Click the 'Console' menu and then click 'Add/Remove Snap-in'.
  
• Click the 'Add' button and then choose the 'certificates' snap-in and click on 'Add'.
  
• Select 'Computer Account' then click 'Next'.
  
• Select 'Local Computer' and then click 'OK'.
  
• Click 'Close' and then click 'OK'.
  
• Expand the menu for 'Certificates' and click on the 'Personal' folder.
  
• Right click on the certificate that you want to export and select 'All tasks' -> 'Export'.
  
• A wizard will appear. Make sure you check the box to include the private key and continue through with this wizard until you have a .PFX file.

Next run openssl to extract the private key, and the cert file.

Export the private key file from the pfx file

openssl pkcs12 -in filename.pfx -nocerts -out key.pem

Export the certificate file from the pfx file

openssl pkcs12 -in filename.pfx -clcerts -nokeys -out cert.pem

This removes the passphrase from the private key so Apache won't prompt you for your passphase when it starts.

openssl rsa -in key.pem -out server.key

It's very common for web applications to send redirects after a form POST submission, as it works around the dreaded page-refresh = double form submission problem that can cause nightmare scenarios like double credit card charges and the like. A redirect is a response by the web server asking the web browser to load another page. Unlike URL's embedded in HTML, redirects cannot be "relative", meaning they must be fully qualified with scheme, host, and port parts if required.

As I'm sure most everyone is aware, hardware SSL accelerators offload the cpu-intensive SSL operations and allow a web application to deal strictly with HTTP. Effectively the accelerator is encapsulating and de-encapsulating the SSL "headers" for the web application. As a result, the web application is unaware of operating in an HTTPS context, and in fact has no way to identify that customer browsers are operating in such a context except through external configuration of some sort. It's not possible to automatically identify that a hardware accelerator is in place if you're writing code that lives in the web application space.

Finally, despite the fact that redirects cannot be relative, it's very common to try and support specifying them relatively in software. This is done by having web frameworks automatically handle the generation of the final redirection URL, using knowledge the web application has about the context it's running in. Normally this allows for things like transparently moving the web application from host to host (dev to test, or test to staging, etc) without having to re-specify every redirect in some configuration file or build a facility in the web application to allow 'smart' redirect writing. Since a web application can have potentially many redirects, this is a Good Thing.

The fact that a web application behind a hardware SSL accelerator cannot identify that it's running in an HTTPS/SSL context means that when redirects are automatically generated by a framework, the URLs are generated incorrectly. The scheme portion is generated as http, resulting in a page such as:

https://www.customer.com/app/blah.do?somestuff=whatever

redirecting to:

http://www.customer.com/foo/bar.do?baz=bat

There are two potential problems here. Either http traffic is not accepted by the web application, in which case the second URL fails to load, or http traffic is accepted but the person has moved from a secure context to an insecure context. Not only is this a potential problem for application security, Internet Explorer will pop up a nasty dialog saying that you've just been redirected to an insecure context and your life secrets may be leaking into the ether. Neither scenario is very good for customers.

One supported solution is to somehow affect the framework's redirect URL generation facility so that it writes them correctly in the first place, without a ton of configuration. It turns out that this is possible in Tomcat, and since Tomcat is the embedded servlet engine for JBoss, Weblogic, and more, it becomes a transitive solution for most (all?) of our customers running in a Java environment.

As you might be aware, web applications sometimes run behind a proxy. The SSL accelerators we use aren't proxies, so it doesn't exactly spring to mind to treat them like proxies, but if we do our eyes naturally move to a portion of the Tomcat configuration regarding proxies. Specifically, you can specify the proxy's name, port, and most importantly the scheme the proxy uses to talk to clients. We can use this ability to configure Tomcat to behave as if we're running in an SSL context without actually incurring the CPU/configuration cost of running SSL directly on the web servers. Doing this is a very simple change:

1) Find the server.xml config file for your app server. It should mention Tomcat/Catalina stuff, if it doesn't you're in the wrong file.

2) Find the section of the file with a <Connector ...> tag referring to the port your app server runs on. In JBoss this is done with a variable, and in Tomcat the port is specified directly (usually as 8080). This tag should not be commented out, and many are. XML comments are the same as HTML, and read <!- stuff commented out ->. So if that's wrapped around the tag you're looking at, you've got the wrong tag.

3) Once you've found it, add three attributes to this tag:

proxyName="www.yourcustomer.com"
proxyPort="443"
scheme="https"

4) Restart your app server and test that the change works. I reccomend using Firefox and the LiveHTTPHeaders plugin to see what's going on directly.

It'd be nice if you didn't have to set the proxyName, since this is a configuration setting you'll have to change depending on whether the application is running on a staging URL or not, but unfortunately Tomcat will not honor the scheme setting if you don't. You may also find some reference to setting secure="true" in Googling around about this problem. Don't do it. That tells Tomcat to really turn SSL on, at which point it starts to look for certs and keystores and just generally goes down the path we're trying to avoid with the SSL accelerator in the first place.

(How to setup tomcat in windows to use a data source to connect to MSSQL database)

Requirements:

(This guide assumes the following)
Tomcat 7.0 installed and working with defaults settings
MSSQL setup and working with an account that can access the database

Icon

For these examples:
"test" is used for resource name and "testDB" is used for the connection name: This can be changed but make sure to change all of them.

• Step 1: Log into the server running Tomcat
  
• Step 2: Download the following file JDBC Drive for SQL
• Step 3: Place the file sqljdbc4.jar in the following folder (%Tomcat Root%\lib)
  
• Step 4: Edit the server.xml file (%Tomcat Root%\conf)
  
  • The following code should be added in the <GlobalNamingResources> section

<Resource name="test" auth="Container"

type="org.apache.catalina.UserDatabase"

description="User database that can be updated and saved"

factory="org.apache.catalina.users.MemoryUserDatabaseFactory"

pathname="conf/tomcat-users.xml" />

<Resource name="jdbc/testDB" auth="Container" type="javax.sql.DataSource" />

<ResourceParams name="jdbc/test">

<parameter>

<name>factory</name>

<value>org.apache.commons.dbcp.BasicDataSourceFactory</value>

</parameter>

<parameter>

<name>maxActive</name>

<value>5</value> <!-- consult Tomcat docs for this value's meaning -->

</parameter>

<parameter>

<name>maxIdle</name>

<value>5</value> <!-- consult Tomcat docs for this value's meaning -->

</parameter>

<parameter>

<name>maxWait</name>

<value>10000</value> <!-- consult Tomcat docs for this value's meaning -->

</parameter>

<parameter>

<name>username</name>

<value>DB User Name</value> <!-- Change "DB User Name" to user name of account used to access SQL -->

</parameter>

<parameter>

<name>password</name>

<value>DB Password</value> <!-- Change "DB Password" to password of account used to access SQL -->

</parameter>

<parameter>

<name>driverClassName</name>

<value>com.microsoft.sqlserver.jdbc.SQLServerDriver</value>

</parameter>

<parameter>

<name>url</name>

<value>jdbc:sqlserver://IPAddress:1433/DBName</value> <!—Change "IPAddress" to the IP address of the DB server or the DB cluster IP address, Change "DBName" to the database name you want to connect to, 1433 is the default port change if using something else -->

</parameter>

</ResourceParams>

• Step 5: Update the context.xml file (%Tomcat Root%\conf)
  This code need to be in the <Context> section

<Resource name="jdbc/testDB" auth="Container" type="javax.sql.DataSource"

maxActive="100" maxIdle="30" maxWait="10000"

username="DBUser_Name" password="DB_Password"

<!-- Change "DBUser_Name" to user name of account used to access SQL, Change "DB_Password" to password of account used to access SQL   -->

driverClassName="com.microsoft.sqlserver.jdbc.SQLServerDriver"

url="jdbc:sqlserver://IPAddress:1433;databaseName=DBName"/>

<!-- Change "IPAddress" to the IP address of the DB server or the DB cluster IP address, Change "DBName" to the database name you want to connect to, 1433 is the default port change if using something else -->

• Step 6: The following .jsp page can be used to test the connection, Name the file dbtest.jsp
  Viewing the file in a browser should show a list of numbers, these are numbers of the rows in what database you are connecting to.

<html>

<head><title>Enter to database</title></head>

<body>

<table>

<%@ page import="java.util.*" %>

<%@ page import="javax.sql.*;" %>

<%

java.sql.Connection c1;

java.sql.Statement s1;

java.sql.ResultSet rs1;

java.sql.PreparedStatement pst1;

DataSource testDB;

c1=null;

s1=null;

pst1=null;

rs1=null;

javax.naming.Context initCtx = new javax.naming.InitialContext();

javax.naming.Context envCtx = (javax.naming.Context) initCtx.lookup("java:comp/env");

testDB = (DataSource) envCtx.lookup("jdbc/testDB");

try{

if(testDB == null) {

javax.naming.Context initCtx1 = new javax.naming.InitialContext();

javax.naming.Context envCtx1 = (javax.naming.Context) initCtx1.lookup("java:comp/env");

testDB = (DataSource) envCtx1.lookup("jdbc/testDB");

}

}

catch(Exception e){

System.out.println("inside the context exception");

e.printStackTrace();

}

c1 = testDB.getConnection();

String sq1= "select * from master.dbo.sysdatabases"; <!-- This is the query that will run on the database --> 

pst1 = c1.prepareStatement(sq1);

rs1 = pst1.executeQuery();

while( rs1.next() ){

%>

<tr>

<td><%= rs1.getString("dbid") %></td> <!--This is the string the will be displayed on the web page   -->

</tr>

<%

}

if(pst1!=null) pst1.close();

if(rs1!=null) rs1.close();

if(c1!=null) c1.close();

%>

</body>

</html>

To test: On the tomcat server open IE and go to http://localhost/<site folder>/dbtest.jsp

For based on these examples ("jdbc/testDB") is what clients would need use for DataSource in there code to connect to the configured data base.

OpenSSL

OpenSSL is a widely used library and toolkit for integrating encryption into products, like the Apache httpd server. Besides being a library somewhere in the system directory tree, it comes with a set of command-line tools to help you create and manage keys, certificate requests, certificates and revocations. The main tool is the command 'openssl' which if invoked with no other parameters, acts like a shell, allowing you to type in special OpenSSL commands to perform various operations.
There is a distinct and important relationship between keys and certificates. A certificate is a bunch of data that has been encrypted by a key. A key is some data that has been encrypted by a password. I can see the wheels turning and you're about to ask "why are we using a password to encrypt what is essentially another password? Why don't we just use our password and get rid of the key?" The truth is that people are terrible at creating passwords. Unless you use passwords like "0a4215ff7dc1ce10edc065233f4c07d8bc9330db1194b3648c97919a655cde288b0d6bd23329338b7ab2e6b1f2b42e727461a782a6757431d3e95c5812f759b6" then chances are, your passwords can be guessed using password crackers in a matter of seconds, probably in less than 1 second. The other truth is that computers are capable of generating keys that are mathematically superior to anything usable by a person. Computers aren't restricted to just letters, numbers and a few special characters. This allows computers to generate complex passwords that are more secure for use in cryptographic operations.
The keys and certificates are part of something called public key cryptography. This is similar to safety deposit boxes in bank vaults. When you get a vault box, there are 2 locks on the door. You are issued a key for one lock and the bank has its own key for the second lock. To open the door, you must have both keys. Now, let's extend this. You have a safe with 2 locks. The key to one of the locks you keep to yourself and never share it with anyone. This is your private key. For the other lock, you create a bunch of identical keys and share them with friends and family. These are public keys.
The process of getting a SSL certificate for use with a web site is simple:

• you generate a key
  
• using the key, you generate a certificate request (CSR) that contains data about the company and web site
  
• the CSR is sent to a Certificate Authority (CA) to be signed
  
• the CA signs the CSR, turning it into a certificate
  
• the certificate is returned and installed in the web server or SSL accelerator

Some important things to note about this process:

• a password is generally used to generate the key but this is not required
  
• the CA does not know nor do they require the password used to generate the key
  
• the certificate you are issued contains information about the CA who signed it
  
• each browser ships with the public key the CA, which is used to verify the information contained in the certificate

Keys

The first step in the process involves generating a key. There are, in general, three types of keys used, RSA, DSA and DH (Diffie-Hellman.) The most commonly used for SSL certificates are RSA keys. Additionally, keys can be of many sizes, specified in bits. The more bits in the key, the stronger the encryption it can afford you. You generate the key using the openssl shell. The 'genrsa' command is used for creating a RSA key. You can specify the encryption to be used to encrypt the key, a good algorithm is triple-DES or des3. You also need to specify an output file using the "-out" option, otherwise openssl will print the key to your screen. OpenSSL will prompt you for the password to use to encrypt the key.
Generating a key with a passphrase. The default key size is 512 bits:

$ openssl genrsa -des3 -out jeff.key
Generating RSA private key, 512 bit long modulus
.......++++++++++++
........................++++++++++++
e is 65537 (0x10001)
Enter pass phrase for jeff.key:
Verifying - Enter pass phrase for jeff.key:

In some cases, it is desirable to create a key that has no password. This also means the key is not encrypted, which has important security implications. If someone gets a hold of a key that has no password, they can use it to decrypt your certificate, which will allow them to read all the encrypted traffic. At OpSource, many SSL certificates are stored on the SSL accelerators built into the load balancers. Having the certificates on the load balancers requires having the key as well. Using a key with no password allows for easier installation on the load balancers. To generate a key with no password, simply leave out any encryption options. In the following example, we specified a key size of 1024 bits.
Generating a key with no passphrase:

$ openssl genrsa -out jeff.key 1024
Generating RSA private key, 1024 bit long modulus
.......................++++++
.........++++++
e is 65537 (0x10001)

The remaining examples use existing keys are using one that has no password. If you use a key that has a password, then you will be prompted to enter that password at the beginning of the listed process because the key needs to be decrypted before any other processing can take place.

Certificate Requests

As mentioned, the second part of the process is to generate a certificate request (CSR). The CSR will contains various pieces of information about the company as well as the hostname of the site. When creating a CSR, you can either use a pre-existing key or you can generate a new one as part of the process. A single key can be used for multiple CSRs. The most important part of the CSR is the Common Name. This must match the hostname for the site as used in URLs. If it does not, then browsers will display a security error to the end user, saying that the hostname in the URL does not match the name in the certificate. The exception to this rule is what's known as a wildcard certificate. A wildcard certificate is used for subdomains of a site. For example, a site that uses the following URLs:

• testing.app.company.com
  
• qa.app.company.com
  
• www.app.company.com

can all be secured with a wildcard certificate. To generate a CSR for a wildcard certificate, you need to prepend a *. to the hostname in the Common Name field. Using the example above, the Common Name would be *.app.company.com.
The OpenSSL command for generating a certificate request is the 'req' command. Additionally, since you'll be generating a new request, you need to add the "-new" option, otherwise, it'll expect you to provide an existing request. As before, you need to use the "-out" option and a file name or the CSR will be printed to your screen.
Generating a certificate request using an existing key:

$ openssl req -new -key jeff.key -out jeff.csr
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.

----
Country Name (2 letter code) [GB]:US
State or Province Name (full name) [Berkshire]:Virginia
Locality Name (eg, city) [Newbury]:Herndon
Organization Name (eg, company) [My Company Ltd]:OpSource Inc.
Organizational Unit Name (eg, section) []:Operations
Common Name (eg, your name or your server's hostname) []:www.someserver.com
Email Address []:client@opsource.net

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

The resulting file can be sent to a Certificate Authority for signing. They will then issue a certificate that can be installed in the web server or a load balancer. Remember, the key needs to be matched with the certificate so when submitting the certificate to your system administrator, remember to give them the key as well.

Self-signed Certificates

Certificate Authorities charge money for each certificate they sign. Costs can range from $150 for a single certificate good for 1 year to over $1,000 for a single certificate good for 5 years. Wildcard certificates generally cost much more. So what happens when you have a site that doesn't require a valid certificate, such as a development site or a QA site. These types of environments are generally not public-facing and don't require a valid certificate signed by a CA. In those cases, you can generate a self-signed certificate. This is a certificate that has been signed by itself and not a CA. These certificates will always generate an error in the browser. The process of generating them is similar in that you need a key (either pre-existing or generated during the process) and you generate a request but you then use OpenSSL commands designed for certificate management to sign the certificate. Generating the request and signing it are easily done at the same time. The specific OpenSSL options for this are the "-x509" option and the "-days" option, which allows you to specify how long the certificate is valid for.
Generating a self-signed certificate using an existing key:

$ openssl req -new -key jeff.key -x509 -days 365 -out jeff-selfsigned.crt
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [GB]:US
State or Province Name (full name) [Berkshire]:Virginia
Locality Name (eg, city) [Newbury]:Herndon
Organization Name (eg, company) [My Company Ltd]:OpSource Inc.
Organizational Unit Name (eg, section) []:Operations
Common Name (eg, your name or your server's hostname) []:www.someserver.com
Email Address []:client@opsource.net

This process can be shorten even further. This command performs everything necessary, from generating a 1024-bit key to the final certificate ready to be used. The "-nodes" tells OpenSSL to generate a key with no encryption and the "-keyout" is to tell OpenSSL what file to write the key to.
Generating a self-signed certificate and a new key that has no passphrase:

$ openssl req -newkey rsa:1024 -nodes -keyout jeff.key -x509 -days 365 -out jeff-selfsigned.crt
Generating a 1024 bit RSA private key
......................................++++++
...................................++++++
writing new private key to 'jeff.key'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [GB]:US
State or Province Name (full name) [Berkshire]:Virginia
Locality Name (eg, city) [Newbury]:Herndon
Organization Name (eg, company) [My Company Ltd]:OpSource Inc.
Organizational Unit Name (eg, section) []:Operations
Common Name (eg, your name or your server's hostname) []:www.someserver.com
Email Address []:client@opsource.net

Summary

The OpenSSL toolkit is a powerful combination of libraries and commands. The libraries allow developers to add strong encryption to products while the commands allow administrators to generate and manage keys, certificate requests and certificates. You can even establish a Certificate Authority with the OpenSSL toolkit, though there are some very important logistics surrounding physical, computer and network security, as well as management of certificates make this difficult to do properly.
The process of obtaining a SSL certificate for use with web sites is simple. The commands are few but the responsible handling of resulting keys, certificates and passwords are important and proper care needs to be exercised.