The first step is to build the HTTP server config. A more elegant file naming method than what is shown in the linked document involves creating descriptive application folder locations for each virtual application so you could have conf/app_marketing/httpd.conf, log/app_marketing/access_log, and /app_marketing/index.html but for brevity, I will just number the instances in this guide. This approach is successful if the new http server is defined with isolated files and folders such as cgisock, sidd, ./htdocs2, etc. for its own run. Copy your httpd.conf to httpd2.conf, then make all the edits shown in the build document so the web server has unique ports/IPs, folders, and files it needs for run time. You will perform a second round of steps using the deployment manager after the command line tasks are completed. Note that the deployment manager is a repository and the plugin data will be overwritten by it so the webserver1 data is used only to make sure its starts without errors. You could leave the folders blank and test after all steps are completed.
After all of the command line configuration is completed, you should test the web server to see if it works using curl, wget, or a browser. The web server should be started if you used the build document. Since webserver2 is a copy of webserver1, testing static content using your favorite testing tool is a better idea. Some web apps keep all static content in the enterprise application resource so check your access and error log files to ensure requests are coming through and they are logged.
You may further test the J2EE application if your virtual host (vhost) already enables the new server's hostname and port combination to run the application. This example doesn't show such a configuration but if you are removing an existing vhost and using this guide to isolate it then, a curl test on the application would work smoothly at this point because the definition would already exist in the plugin file.
Move on to the next step ff the new web server, webserver2, passes these basic tests.
The web server is working but it is just a copy of the data in webserver1 and since you wanted process level isolation for a different application so you must also go to the Deployment Manager to make the application specific changes, pushing out the remaining configuration from the management console. After all shell level configuration is done, proceed to the WebSphere deployment manager in System Administration -> Nodes. Create an unmanaged node pointing to the host of the http server.