Setting up Apache and mod_proxy_html for my web application

Recently I had to set up Apache HTTP Server as a proxy to our web application running on WebLogic. Should be a simple task, except the application has a different context path when served by Apache. This is how it's set up:

Web App context path in WebLogic: http://localhost:8013/mywebapp
Web App context path in Apache: http://localhost:8080/some/extra/path/elements/mywebapp

With this configuration, the web application generate urls like http://localhost:8080/mywebapp/some/link, which causes problems since that path doesn't point to the web application. The correct url should be http://localhost:8080/some/extra/path/elements/mywebapp/some/link. After doing some research, I found the mod_proxy_html Apache module. This module parses the HTML from the web application and based on a specified rule set, it replaces urls in the HTML with rewritten, correct urls.

After following the initial configuration tutorial, I only got a message in the log saying "No links configured: nothing for proxy-html filter to do". Aparently, the documentation I read was a bit outdated, and after doing a google search, I found an article explaining some extra steps needed to get things up and working. Together with another useful guide, I was able to set things up producing the result I wanted.

This set up is not specific to WebLogic. It should work with other containers as well, such as Tomcat, Jetty etc.

Problem with Git on Windows

Just a little tip from a Git newbie using Windows and msysGit. Yesterday I couldn't push changes to my GitHub repository. I have no idea why... Maybe it had something to do with the size and number of files in the change set? Anyway, I kept getting error messages saying "unable to read from standard input" and "remote end hung up unexpectedly". After struggling with the problem for a while, I tried switching from PuTTY plink.exe to TortoiseSVN TortoisePlink.exe as the SSH client (export GIT_SSH="C:\Program Files\TortoiseSVN\bin\TortoisePlink.exe"), and for some reason, everything started to work again.

If anyone know why this problem occured, and why it was solved by switching SSH client, please let me know.

JSR-286 specification is ready

The Portlet 2.0 specification has been released. Maybe a bit overdue, but I guess late is better than never. As I have pointed out in an earlier post, I'm working on a Portlet 2.0 plugin for Struts 2. The basics are in place, but there's still a lot of work to be done. But do try it out if you want!

Experimenting with JSR286 (Portlet 2.0) support in Struts 2

I've started playing with portlet 2.0 support in Struts 2, and the experimental JSR286 plugin currently supports both basic event and resource serving, which are two of the most anticipated features of the new portlet specification. In parallel, I've adapted the maven-jetty-pluto-embedded artifact to support Pluto 2.0, so I can easily develop and test directly with Maven or my IDE.

This is still very experimental, but feel free to give it a try. I've also created a very basic sample portlet that uses the plugin which you can check out and build. Note that you might have to build Pluto 2.0 from source unless you find it in a Maven repository somewhere.

Please drop me a line if you find anything that doesn't work, or if you want to discuss implementation and features.

Struts 2 Portlet in JBoss Portal

I have been asked if Struts 2 portlets can be deployed in JBoss Portal, and if yes, how to deploy Struts 2 portlets to JBoss Portal.

The answer to the first question is of course yes. Since Struts 2 Portlet is a JSR168 framework, it can be deployed to any portlet container supporting the JSR168 standard, including JBoss Portal.

To answer the second question, I had to browse through the JBoss Portal reference guide, and found that you have to write two custom deployment descriptors.

For the Struts 2 sample portlet application, I added the following:

portlet-instances.xml

<?xml version="1.0" standalone="yes"?>
<!DOCTYPE deployments PUBLIC
   "-//JBoss Portal//DTD Portlet Instances 2.6//EN"
   "http://www.jboss.org/portal/dtd/portlet-instances_2_6.dtd">
<deployments>
   <deployment>
      <instance>
         <instance-id>StrutsPortletInstance</instance-id>
         <portlet-ref>StrutsPortlet</portlet-ref>
      </instance>
   </deployment>
</deployments>

struts2-portlet-object.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE deployments PUBLIC
   "-//JBoss Portal//DTD Portal Object 2.6//EN"
   "http://www.jboss.org/portal/dtd/portal-object_2_6.dtd">
<deployments>
   <deployment>
      <parent-ref>default.default</parent-ref>
      <if-exists>overwrite</if-exists>
      <window>
         <window-name>StrutsPortletWindow</window-name>
         <instance-ref>StrutsPortletInstance</instance-ref>
         <region>center</region>
         <height>1</height>
      </window>
   </deployment>
</deployments>

I added both files to the WEB-INF folder of the application.

With both files added, put the war file in the deploy folder of your server, and your portlet should appear on the default page of the portal.

Consult the documentation for a description of these files, and the relations between the names and ids in them.

I would rather not have to specify the instances, page and placement of the portlet in a descriptor in the portlet application itself, but that is how it was described in the documentation.

Update:
It appears that these descriptors are indeed optional. You can deploy a plain Struts 2 Portlet (or any JSR168 portlet for that matter) and do all the required steps in the portal administration.

Struts 2 Portlet in WebSphere 5.1

At work I recently wanted to build a Struts 2 Portlet to see if I could deploy it in WebSphere Portal 5.1. As you know, Struts 2 requires Java 5 to run, and as you might also know, WebSphere Portal 5.1 only runs Java 1.4. Retrotranslator to the rescue! I added the retrotranslator-maven-plugin from the Codehaus Mojo project, and set it up to run the translate-war goal:

<build>
  <plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>retrotranslator-maven-plugin</artifactId>
    <version>1.0-alpha-2</version>
    <executions>
      <execution>
        <goals>
          <goal>translate-war</goal>
        </goals>
        <configuration>
        <classifier>jdk1.4</classifier>
        <attach>true</attach>
          <advanced>true</advanced>
        </configuration>
      </execution>
    </executions>
  </plugin>
</build>

I also had to include a couple of new dependencies introduced by Retrotranslator:

<dependencies>
  <dependency>
    <groupId>backport-util-concurrent</groupId>
    <artifactId>backport-util-concurrent</artifactId>
    <version>3.0</version>
  </dependency>
  <dependency>
    <groupId>net.sf.retrotranslator</groupId>
    <artifactId>retrotranslator-runtime</artifactId>
    <version>1.2.1</version>
  </dependency>
</dependencies>

I had to use the 1.0-alpha-2 version of the plugin, otherwise I got an obscure java.lang.ClassCastException: java.lang.String cannot be cast to java.lang.Boolean failure...

Unfortunately, that was not quite enough. When running the portlet, I would get an exception about a missing javax.xml.namespace.NamespaceContext class which XWork aparently needs. It appears that this class is included in the Java 5 libraries, but not with Java 1.4. I found it in the jaxp-api.jar in the Sun Java Web Services Developer Pack 2.0. I placed this jar in the %WAS_HOME%/java/jre/lib/ext folder (I tried putting it in the web application, but that didn't work... Classloading in JEE application servers has always been fun...). I also had to exclude any web application dependencies that included Xerces, Xalan or xml-apis.

No guarantees that this works for you though. But I guess as long as you don't break any of the limitations retrotranslator has, you'll be fine.

Struts 2 Portlet Tutorial

I have made available a new Struts 2 portlet tutorial in the Struts 2 Plugin Repository wiki. The tutorial is work in progress and is currently based on the 2.1.1-SNAPSHOT of Struts 2.

The tutorial is using the Struts 2 portlet archetype which includes much of the stuff I have written about in this blog to (hopefully) improve portlet developmet productivity.

Please try it out and let me know of any issues you encounter.