Avoid Frustration

The Struts Bridge does not appear to be set up to support ActionMessages by default. To get them to work, you must add the following lines to your struts-portlet-config.xml file:

<config>
    <render-context>
        <attribute name="org.apache.struts.action.ACTION_MESSAGE"/>
        <attribute name="org.apache.struts.action.MESSAGE"/>
        ....
    </render-context>
</config>

These will allow the messages to pass properly to your JSP pages.

Here is a summary of everything I currently know about which versions of the JDK, Tomcat, Struts, and the Struts Bridge are compatible with one another - along with download links for each. If something's not on this list, that doesn't mean it doesn't work - it just means that I haven't tried it. If you are using a configuration not listed here (even if it's just Tomcat without Struts or the Bridge), please comment so I can add it to the list to make it more complete.

JDK	Tomcat	Servlet Spec	JSP Spec	Struts	Struts Bridge
1.5.0	5.5.x	2.4	2.0	1.3.5	n/a
1.5.0	5.5.x	2.4	2.0	1.2.9	n/a
1.5.0	5.5.x	2.4	2.0	1.2.7	1.0
1.4.2	5.5.x (with compatability package)	2.4	2.0	1.2.7	1.0
1.4.2	5.0.x	2.4	2.0	1.2.7	1.0
1.3.1	4.1.27	2.3	1.2	?	?

Here is a complete list of everything you need to do to get a Struts Bridge app running in Vignette Portal:

1. Add the following jars to WEB-INF/lib if they are not there already:
   

   portals-bridges-struts-#.#-#.#.jar
   portals-bridges-common-#.#.jar
   vgn-portal-jsrextensions.jar

   The first two are included with Struts Bridge, and the third is available as a download from global.vignette.com.
   
2. In portlet.xml, add an XSD to portlet.xml and namespace prefixes (change <portlet-app> to <portlet-app xmlns:p="http://java.sun.com/xml/ns/portlet/portlet-app_1_0.xsd">) and add the p: prefix to each tag in the file (i.e. change <portlet> to <p:portlet>).
   
3. In portlet.xml, change the value of the ServletContextProvider init-param to com.vignette.portal.bridges.ServletContextProviderImpl
4. In portlet.xml, change the value of portlet-class to com.vignette.portal.bridges.struts.StrutsPortlet - if you use the general StrutsPortlet, the links won't work.
5. In portlet.xml, reorder the elements according to the XSD. Vignette is more strict than some other portals, and will balk if the elements are not in the proper order. For reference, the order is as follows:
   

   
   <portlet-app>
      <portlet>
          <description/>
          <portlet-name/>
          <display-name/>
          <portlet-class/>
          <init-param/>...
          <expiration-cache/>
          <supports/>
          <portlet-info/>
      </portlet>
   </portlet-app>
   

   
   
6. Create a war file of the app, and run the Vignette repackaging tool to add entries to the web.xml. After you've done this once, you can unpack the war file and put it back in your original copy of the code, so you don't have to run the repackaging tool each time you want to deploy a change.
   
7. Manually add the webapp Context to server.xml, instead of using automatic webapp detection - otherwise Vignette will only see it 50% of the time. For reference, a simple Context tag looks like this: <Context path="/examples" docBase="examples" debug="0" reloadable="true"/> (put inside a Host tag)
   
8. By default, the portlet app is not accessible as a regular webapp, for security purposes. If you would like to access the app directly as a webapp, comment out the filter and filter-mapping tags in web.xml.
   

I had a good amount of trouble to get Tomcat logging the way I wanted to. Although I can't say for sure, by default it seemed to log errors anywhere from the console to at least three different types of logs in tomcat/logs. In any case, what I wanted was to get all of the logs in one place - since that's sort of the point of logs.

Here is the 15-second version of how to get Tomcat to log just about everything to one file:

1. Download commons-logging and put the commons-logging-1.1.jar file into your tomcat common/lib.
2. Download log4j and put the log4j-1.2.13.jar file into your tomcat common/lib.
3. (from Geoff Mottram) Save the following to a file log4j.properties in your tomcat common/classes. The only thing you should need to change is the line log4j.appender.R.File, to point to the file location you want.
   

#
# Configures Log4j as the Tomcat system logger
#

#
# Configure the logger to output info level messages into a rolling log file.
#
log4j.rootLogger=INFO, R

#
# To continue using the "catalina.out" file (which grows forever),
# comment out the above line and uncomment the next.
#
#log4j.rootLogger=ERROR, A1

#
# Configuration for standard output ("catalina.out").
#
log4j.appender.A1=org.apache.log4j.ConsoleAppender
log4j.appender.A1.layout=org.apache.log4j.PatternLayout
#
# Print the date in ISO 8601 format
#
log4j.appender.A1.layout.ConversionPattern=%d [%t] %-5p %c - %m%n

#
# Configuration for a rolling log file ("tomcat.log").
#
log4j.appender.R=org.apache.log4j.DailyRollingFileAppender
log4j.appender.R.DatePattern='.'yyyy-MM-dd
#
# Edit the next line to point to your logs directory.
# The last part of the name is the log file name.
#
log4j.appender.R.File=/usr/local/tomcat/logs/tomcat.log
log4j.appender.R.layout=org.apache.log4j.PatternLayout
#
# Print the date in ISO 8601 format
#
log4j.appender.R.layout.ConversionPattern=%d [%t] %-5p %c - %m%n

#
# Application logging options
#
#log4j.logger.org.apache=DEBUG
#log4j.logger.org.apache=INFO
#log4j.logger.org.apache.struts=DEBUG

#log4j.logger.org.apache.struts=INFO

Maybe those more intelligent than me can get svnant (Ant tasks for the Subversion version control system) working, but I can't at this time. When I tried, I received the error that neither the Subversion command line tools nor JavaHL could be found.

In lieu of that, I recommend using ant's basic command-line execution tasks to execute Subversion tasks, like so:

       <exec executable="svn">
         <arg line="checkout"/>
         <arg line="https://myserver/svn/myproject/"/>
         <arg line="."/>
     </exec>

If ant's command-line tools are included in your PATH, then this should work just fine.

For about a day and a half, I received the following Tomcat error:

org.apache.jasper.JasperException: Unable to initialize TldLocationsCache: no !/ in spec
at org.apache.jasper.compiler.TldLocationsCache.init(TldLocationsCache.java:253)
at org.apache.jasper.compiler.TldLocationsCache.getLocation(TldLocationsCache.java:224)
at org.apache.jasper.JspCompilationContext.getTldLocation(JspCompilationContext.java:526)
at org.apache.jasper.compiler.Parser.parseTaglibDirective(Parser.java:422)
at org.apache.jasper.compiler.Parser.parseDirective(Parser.java:492)
at org.apache.jasper.compiler.Parser.parseElements(Parser.java:1552)
at org.apache.jasper.compiler.Parser.parse(Parser.java:126)
...

Apparently there is only one other person on the Internet who has run across this, and rebooting Tomcat fixed it for him, but not for me. Occasionally, I would also get this error:

java.lang.ClassNotFoundException: org.apache.jsp.testtld_jsp
at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
...

Somehow, this error was caused by an invalid context path. Here is the entry I had in my server.xml:

<Context path="/ui-portlet-admin"
 docBase="myproject\#build\webapp" debug="0" reloadable="true"/>

The problem was that Tomcat didn't like the # sign in the document path, so it wasn't generating work files. As a result, it couldn't generate the work files, and so something about the TldLocationsCache wasn't working. In any case, once I renamed the "#build" directory to "build" and changed the path entry, it worked fine.

I had to set up two versions of Tomcat running on two separate JREs in order to test compatability for some code that was experiencing errors. Here are some quick steps to do this setup on Windows for Tomcat 5.0/JDK 1.4 and Tomcat 5.5/JDK 1.5:

1. Download Java SDK 1.4.2_12 and install into C:\j2sdk1.4.2_12
2. Download Java SDK 1.5.0_08 and install into C:\jdk1.5.0_08
   
3. Download Tomcat 5.0.28 and install into C:\tomcat-5.0.28
4. Download Tomcat 5.5.17 (the .zip, not the executable installer) and install into C:\tomcat-5.5.17
5. Change the installations so that they do not both run HTTP on port 8080. In each installation's conf/server.xml, find the tag that says <connector port="8080"> and change it to a different port number. I changed them to 5028 and 5517 respectively, since those correspond to the Tomcat version numbers.
6. Change the installations so that the servers themselves do not both run on port 8005. In each installation's conf/server.xml, find the tag that says <server port="8005"> and change one of them to a different port number. Since you won't ever typically refer to this port number anywhere, it doesn't have to be memorable. I changed one to 8006 and left the other as 8005.
7. Create a startup script for each Tomcat, to set the appropriate environment variables and start the process. Here's my Tomcat 5.0 startup script; the 5.5 one is analogous, with each environment variable changed appropriately.
   

   
   set CATALINA_BASE=C:\tomcat-5.0.28
   set CATALINA_HOME=C:\tomcat-5.0.28
   set CATALINA_TEMP=C:\tomcat-5.0.28\temp
   set JAVA_HOME=C:\j2sdk1.4.2_12
   C:\tomcat-5.0.28\bin\catalina start
   

   
   
8. Create a shutdown script for each Tomcat. These will be identical to the startup scripts, but with the "stop" option passed to catalina instead of "start."
9. Run both startup scripts, then check http://localhost:5028 and http://localhost:5517 to make sure that each is running, and that each really is running on the proper version of Tomcat (check the version number displayed on the first screen.

Keep in mind that having two different JREs in active use can wreak havoc with Java-based applications. In particular, most will either check the system JAVA_HOME environment variable to see where Java lives, or else they'll have their own configuration for where to look. If you experience problems (particularly "unsupported major/minor version 49.0" or the like) I'd recommend checking to see what JRE the application is trying to use.