Install text file as HTML

[dion]

FWIW,

here's a HTMLized version of the install document that was committed
recently.

(See attached file: Install.html)
--
dIon Gillard, Multitask Consulting
Work:      http://www.multitask.com.au
NetRexx: http://www.multitask.com.au/NetRexx.nsf

Title: Struts

Introduction This document contains notes that have been accumulated on getting the Struts applications (documentation and example) running in a variety of servlet container environments. Bluestone Universal Business Server You need UBS version 7.2 to run war file applications. The UBS 7.2.2 evaluation is located here: http://www.bluestone.com/SaISAPI.dll/SaServletEngine.class/products/downloads.jsp If you're using version 7.2.1, you need to download the WAR file patch, located in the product enhancement section of Bluestone's website http://www.bluestone.com/SaISAPI.dll/SaServletEngine.class/products/wfe.jsp After installation of the correct version and/or patch of UBS 7.2, you need to modify your apserver.txt file to point to the correct directory for your war file applications. Look for the section that says something similar to the following: [SaServletEngine.class] session_affinity=1 type=1 program=/SaServletEngine.class file_path=f:\webapps host=localhost:20000 Use the directory specified by the "file_path" variable, or modify it to point to your own custom webapp directory. Copy the "struts-documention.war" and "struts-example.war" files into that webapp directory, and start the UBS (read documentation distributed with UBS for information on how to start it if necessary). Your webapps are now accessible from the following URL's: http://localhost/<PLUGIN>/SaServletEngine.class/struts-example/ http://localhost/<PLUGIN>/SaServletEngine.class/struts-documentation/ "<PLUGIN>" represents the plugin you are using for your specific webserver. For apache on Windows, it might be "cgi-bin/SaCGI.exe", for IIS on Windows, it might be "scripts/SaCGI.exe" or "scripts/ISAPI.dll". Consult the UBS documentation for more information. Orion Application Server In the steps below, $ORION_HOME refers to the directory in which you have installed Orion, and $STRUTS_HOME is the directory in which you unpacked the Struts binary distribution. Modify the file "$ORION_HOME/config/application.xml" to define the two new applications, by adding the following declarations, immediately following the <web-module> directive for the default web application: <web-module id="strutsDoc" path="$STRUTS_HOME/webapps/struts-documentation.war"/> <web-module id="strutsExample" path="$STRUTS_HOME/webapps/struts-example.war"/> Modify the file "$ORION_HOME/config/default-web-site.xml" (or the configuration file for any other Orion web site) to include the following declarations, after the declaration for the <default-web-app> if any: <web-app application="default" name="strutsDoc" root="/struts-documentation"/> <web-app application="default" name="strutsExample" root="/struts-example"/> After you start Orion, you should now be able to access these applications (assuming you haven't changed the port number from the default of 80) at: http://localhost/struts-documentation http://localhost/struts-example Versions of Orion up to at least 1.0.3 have a bug related to ServletContext.getResource() calls that prevent the Struts example application from working out of the box. This manifests itself as a JSP error when you try to access the example application, with the following message: javax.servlet.jsp.JspException: Missing resources attribute org.apache.struts.action.MESSAGE followed by an error traceback. There will also be an initialization error message in the "$ORION_HOME/log/global-application.log" log file. To work around this problem, you can take the following steps: Go to the "$STRUTS_HOME/webapps" directory, where you will note that Orion has automatically expanded each web application into an unpacked directory structure. Go to the "$STRUTS_HOME/webapps/struts-example/WEB-INF" directory, and copy the file "struts-config.xml" one directory up (that is, into "$STRUTS_HOME/webapps/struts-example". Modify the "$STRUTS_HOME/webapps/struts-example/WEB-INF/web.xml" file, changing the value of the "config" initialization parameter (for the action servlet) from "/WEB-INF/struts-config.xml" to "/struts-config.xml". Restart Orion, and you should be able to access the example application. Note that this workaround has a negative security-related side effect: your "struts-config.xml" file can now be retrieved by remote clients at the following URL: http://localhost/struts-example/struts-config.xml Therefore, you should be sure you do not store sensitive information (such as database passwords) in this file. Resin Stand-Alone In the steps below, $RESIN_HOME refers to the directory in which you have installed Resin, and $STRUTS_HOME is the directory in which you unpacked the Struts binary distribution. These instructions have been tested with the default resin.conf settings in the 1.2.2 release (16-Jan-2001). Copy the Struts applications (*.war) from $STRUTS_HOME/webapps to your $RESIN_HOME/webapps directory. Restart Resin if it is already running. You should now be able to access the Struts applications (assuming you are using Resin's default port number of 8080) at, for example: http://localhost:8080/struts-documentation When developing your own applications, you can create a new folder under $RESIN_HOME/doc and modify the file "$RESIN_HOME/conf/resin.conf" to recognize your application, for example: <web-app id='/struts-myapp' /> Resin will then read your application's configuration from WEB-INF/web.xml Tomcat 3.1 (or later) Stand-Alone Copy "struts-documentation.war" and "struts-example.war" to your $TOMCAT_HOME/webapps directory Restart Tomcat if it is already running Tomcat 3.1 (or later) with Apache These instructions assume you have successfully integrated Tomcat with Apache according to the Tomcat documentation. Copy "struts-documentation.war" and "struts-example.war" to your $TOMCAT_HOME/webapps directory Restart Tomcat if it is already running Tomcat will generate a file "$TOMCAT_HOME/conf/tomcat-apache.conf" that will be used by Apache. This file is regenerated every time you start Tomcat, so copy this file to a safe place (such as your Apache configuration directory; on Unix systems this is usually "/usr/local/apache/conf". If you are running Tomcat 3.1, Tomcat will not have generated the entries for your new applications. Add the following lines to the "tomcat-apache.conf" file that you have saved, replacing $TOMCAT_HOME with the path to your Tomcat home directory: Alias /struts-documentation "$TOMCAT_HOME/webapps/struts-documentation" <Directory "$TOMCAT_HOME/webapps/struts-documentation> Options Indexes FollowSymLinks </Directory> ApJServMount /struts-documentation/servlet /struts-documentation <Location "/struts-documentation/WEB-INF/"> AllowOverride None deny from all </Location> Alias /struts-example "$TOMCAT_HOME/webapps/struts-example" <Directory "$TOMCAT_HOME/webapps/struts-example> Options Indexes FollowSymLinks </Directory> ApJServMount /struts-example/servlet /struts-example <Location "/struts-example/WEB-INF/"> AllowOverride None deny from all </Location> On all versions of Tomcat, the generated file above does not know anything about extension mappings defined in a web.xml file, so the "*.do" URIs that go to the controller servlet will not be recognized. To fix this, add the following line to the saved version of "tomcat-apache.conf", after the corresponding line for the .jsp extension: AddHandler jserv-servlet .do Ensure that the saved version of "tomcat-apache.conf" is referenced in your Apache "httpd.conf" configuration file. A typical use would have the following line at the bottom of "httpd.conf": Include /usr/local/apache/conf/tomcat-apache.conf In order to recognize "index.jsp" as a default page for web applications, search in your "httpd.conf" for a "DirectoryIndex" directive. If you have one, add "index.jsp" to the end of the list, so that it might look like this: DirectoryIndex index.html index.jsp DirectoryIndex index.jsp If you do not have such an entry, add one like this: Restart Apache to make it aware of the new applications. You should now be able to access the applications from a browser like this: http://localhost/struts-documentation http://localhost/struts-example Weblogic 5.1 (service pack 8) Obtain and install the Xerces XML parser (problems have been reported with the Sun reference implementation). Put xerces.jar in your WebLogic system path. Obtain and unpack the Struts binary distribution (this procedure assumes it was extracted to C:\jakarta-struts). Add an entry to weblogic.properties for each of the Struts web applications that you would like to configure. For example, to make the struts-example application available, add the following line to weblogic.properties: weblogic.httpd.webApp.strutsexample=c:/jakarta-struts/webapps/struts-example.war You do not need to include struts.jar or any of the application specific classes in the WebLogic classpath, since this will be done automatically (unless deploying an unpacked web archive- see below). Start WebLogic server and point your web browser to the struts application. For example, to connect to the example application added in step 3: http://localhost:7001/strutsexample This example application depends on the Struts specific resource file ApplicationResources.properties to be present on the classpath. However, WebLogic only extracts *.class files from the archive so this file will not be found, resulting in an error the first time it is needed- something similar to: javax.servlet.ServletException: runtime failure in custom tag 'message'. Steps 6 & 7 will need to be performed for this application, and any other that relies on ApplicationResources.properties. Extract ApplicationResources.properties from the *.war file, and manually copy it to the respective package in the _tmp_war_ directory WebLogic created for this application. Again referring to the struts-example application, this would be: c:\jakarta-struts\webapps\WEB-INF\_tmp_war_strutsexample Restart WebLogic. You will now be able to run the application: http://localhost:7001/strutsexample The above steps should be followed for applications deployed as *.war files. For unpacked web applications, configuration involves adding both struts.jar and /WEB-INF/classes to the WebLogic classpath. For this reason, I would suggest deploying applications as war files to WebLogic. However, the same example application can be successfully deployed in extracted format by modifying weblogic.properties (assuming the war was extracted to directory webapps/struts-example): weblogic.httpd.webApp.strutsexample=c:/jakarta-struts/webapps/struts-example/ c:\jdk1.3\bin\java -ms16m -mx64m -classpath c:\weblogic\lib\weblogic510sp8boot.jar; c:\weblogic\classes\boot; c:\xerces\xerces.jar -Dweblogic.class.path=c:\weblogic\lib\weblogic510sp8.jar; c:\weblogic\license; c:\weblogic\classes; c:\weblogic\myserver\serverclasses; c:\weblogic\lib\weblogicaux.jar; c:\jakarta-struts\lib\struts.jar; c:\jakarta-struts\webapps\struts-example\WEB-INF\classes -Dweblogic.system.home=c:\weblogic-Djava.security.manager -Djava.security.policy=c:\weblogic\weblogic.policyweblogic.Server And starting WebLogic with the updated WebLogic classpath. For example: