On a recent project I had problems deploying a web application built on the Struts 2MVCframework to a fresh WebSphere installation. I wasted a lot of time labouring under the incorrect assumption (for once) that the architectural changes I had introduced in the latest sprint were the cause of my troubles.
But it turned out to be an environmental issue. We were deploying Struts 2 as a servlet filter and out of the box WebSphere does not support HTTP requests that are served by a servlet filter. A custom property called com.ibm.ws.webcontainer.invokefilterscompatibilty must be set for the web container. I guess I should have just deployed straight to the UAT environment!
Here is the procedure for setting the com.ibm.ws.webcontainer.invokefilterscompatibility custom property:
In the administrative console click Servers > Application Servers >server_name> Web Container Settings > Web Container.
Under Additional Properties select Custom Properties.
On the Custom Properties page, click New.
On the settings page, enter com.ibm.ws.webcontainer.invokefilterscompatibility in the Name field and true in the Value field.
Click Apply or OK.
Click Save on the console task bar to save your configuration changes.
On my current assignment we are developing a multi-tennant web application and are giving the individual tennants the ability to customize the look and feel of the application. We are using Jackrabbit to host the style sheets, images and scripts that for each of the look and feels.
Initially I tried to deploy Jackrabbit as using the Shared J2EE Resource deployment model on WebSphere 6.1. Due to a leathal cocktail of stupidity and environmental constraints I couldn’t get it working earlier in the project and decided to settle for the Application Bundle deployment model.
Now we need to have more that one instance of the application running in the test environment and we’ve had to finally figure out how to get the Shared J2EE Resource deployment model up and running.
It turned out to be a lot easier than I exepcted. In order to get Jackrabbit working I just needed to customize the ra.xml deployment descriptor from jackrabbit-jca-2.2.x.rar by changing the <transaction-support/> element to from XATransaction to NoTransaction.
This change is necessary because Jackrabbit does not support local transactions and actually raises an exception when called by WebSphere.
Rather than have to customise this by hand I a put together the Maven POM below to build custom RAR for me. You must place the ra.xml deployment descriptor in src/main/rar/META-INF.
The SpringBeanJobFactory allows you to inject properties from the scheduler context, job data map and trigger data entries into the job bean. But there is no way out of the box to inject beans from the application context.
So I came up with the factory bean below that extends the SpringBeanJobFactory to add auto-wiring support:
You can add Google Analytics to a site generated with the Maven Site Plugin as by adding a <googleAnalyticsAccountId/> element containing your Web Property ID.
Almost 90 years after it happened, I’ve been forced to recognise partition for the first time in my life.
And the irony is that it is the Irish government that is forcing me to do it. I’ve had to add some validation logic to a drop down list for an e-government web application I’m working on. The drop down list only contains 26 counties!
I am developing an Spring 3.0 based web application that I intend to deploy to Google App Engine. But I’ve been banging my head against a brick wall for a day now trying to figure out why my ${xxx} expressions are not evaluating correctly.
The source of the problem seems to be a bug with Google App Engine. It would appear that even though I am using a Servlet 2.5 deployment descriptor that Google App Engine is behaving as if it was Servlet 2.3.
In Servlet 2.3 JSP expression language was not evaluated by default and it had to be explicitly enabled using the following below. However, since Servlet 2.4 the default behaviour is to evaluate the JSP expression language.
<%@ page isELIgnored="false" %>
So adding the above directive to my JSP page sorted my Google App Engine woes. But not before I’d developed some nasty bruising on my forehead.
If you want to create an archive (.zip, .tar.gz, etc.) file as part of a Maven 2 build you need to use the Assembly Plug-in. Furthermore, if you want to install it into your local repository or deploy it to a remote repository you will need the assistance of the Builder Helper Plug-in.
But if you are building a multi-module project you need to do it properly or you can severely mess up your build. I’ve just spent the last 2 weeks going round in circles trying to figure out why we couldn’t build our project from the root project. In the end it turned out to be the fact that I was incorrectly using the assembly goal instead of the singlegoal. This was causing Maven to fork and try to build all the project dependencies again. To us it looked like our dependencies were not getting installed into the local repository and it was going out to get the last good snapshot build of the components from our remote repository which were 2 weeks out of date by this time.
Of course. Once I found the solution a little light bulb went off and I remembered I’d already seen this problem before. About two years ago in fact.
Here is a sample POM snippet that assumes an assembly descriptor with an id of bin and a format of .tar.gz:
