Blogging Roller

Open-source vs Weblogic and WebSphere

2012-01-10T10:33:53+00:00

Survey says 80% of New Relic's Java customers choose open source app servers over expensive bloat-ware.

Server wars: Open-source Java vs Weblogic and WebSphere | Software, Interrupted - CNET News: Overall, it's not surprising that users who are deploying their applications to the cloud are more likely to use open source, if for no other reason than that licensing is far simpler. Additionally, there are Amazon Machine Images (AMIs) available for most open source stacks, making it very easy to choose open source over a traditionally licensed application server.

Roller 5 and WebSphere 8 (beta)

2011-02-09T22:18:55+00:00

In my quest to get Roller running on the latest in Java EE servers, the last server I tacked was the WebSphere Application Server. Unlike Glassfish and JBoss, WebSphere's Java EE 6 offering is not available in final form yet. Java EE 6 support is coming in WebSphere 8. So, for this exercise I used the WebSphere 8 beta, which was made available in July 2010. In this blog I'll describe how I approached the problem what I learned along the way.

Deployed the Java EE version of the Roller WAR

If you remember my back to my post on Glassfish, I ended up with two WARs, one for Tomcat and one for Java EE. Then in my post on JBoss, I had to add a special WAR just for JBoss. Fortunately for WebSphere, I was able to use same "Java EE" WAR that I used on Glassfish. It didn't work the first time I tried, but with some code changes and installation guide adjustments, I was able to make it work. Here's a quick summary of the problems I hit:

Problem 1: Commons Logging

I was able to deploy Roller successfully via the WebSphere console, but when I tried to load the Roller setup page I got a 404 error. I looked for the Roller log and found nothing. Something was preventing Commons Logging or Log4J from working properly. After some googling, I learned that this has been a problem on WebSphere for some time and there's an easy (but annoying) fix. I had to add a property file to Roller and ask those installing Roller to add a property file to their WebSphere installation, details are here (ROL-1895).

Problem 2: Filter compatibility

I had logging working but that didn't really help me figure out what was going wrong. Eventually, I remembered the WebSphere Filter Compatibility issue. Servlet Filters are a standard feature of the Servlet API for years, but for some reason they are turned off by default in WebSphere. The solution is to set the com.ibm.ws.webcontainer.invokeFiltersCompatibility flag to true via the WebSphere console and so that's what I did. It worked.

Problem 3: Struts mapping

Once I got beyond the setup page, the Roller bootstrapping page would not load. After some investigation I found that the Struts filter was not being executed. Roller was using the mapping /* meaning that all requests go through Struts. When I changed that to *.rol, which is the extension we use for all Struts actions, things started working. That's what we should have been doing anyway, so I made the change and moved on.

Wrapping up...

In the end, I was able to make Roller's Java EE WAR work on WebSphere and that's a good thing. I really don't want to have a separate WAR for each app server. As I did for the other three servers, I added detailed step-by-step installation instructions for WebSphere to the Roller 5 Install Guide (2MB PDF), with screenshots.

Roller 5 and Java EE 6

2011-01-05T08:15:53+00:00

It's hard to believe, but I've been dorking around with Roller, the blog software that powers this site, for almost 10 years now. I started in summer 2001. In the past couple of years, I've had a lot less time to work on Roller. I devoted some of that time to mentoring student developers, which was fun and rewarding. I also spent time making Roller more consumable for developers by making it easier to build, run and deploy to modern Java app servers, which was not really fun but was definitely educational, bloggable even.

Roller 5 as Java EE 6 case study

Making Roller work on the new crop of "modern" Java EE 6 servers was an interesting experience and the story makes a pretty good case study in Java EE application portability. I've put together a short series of blog posts to tell the story and this is the first, an overview. In subsequent posts I'll explain the changes I had to make to get Roller working on:

	GlassFish 3 (released June 2010)
	JBoss 6 (released December 2010)
	WebSphere 8 (beta released July 2010)
	Tomcat 6 and 7 (not Java EE but Roller just has to work on Tomcat)

There are other Java EE 6 servers out there and there's a good summary of them on The Aquarium; those are just the ones I had time to explore.

Overview of Java EE 6 changes

There were three categories of things I changed to accomodate Java EE 6 servers. The first is changes to the Roller code base to make Roller work on all of my targets. Most of these changes were in way Roller uses calls the Java Persistence APIs (JPA), needed because of differences in the JPA implementations used by each server. GlassFish uses EclipseLink JPA and JBoss uses Hibernate JPA. On WebSphere and Tomcat, Apache OpenJPA is the implementation. Fortunately, nowhere did I have to use any conditional code or introduce special behavior for any platform.

The second category of changes is additions to the Roller install guide to mention the special settings required to make Roller work on all targets. On some platforms, special behaviors must be enabled for Roller, for example the "filter compatibility" flag on WebSphere. I added a section to the install guide for each server and documented the details there.

The third category is changes to the Roller build process to create special versions of Roller for some servers. Unfortunately, due to Tomcat not being a full Java EE server and some JBoss classloader issues, I'm not able to provide one Roller release that runs on all servers. The latest Roller 5 release candidate comes in three flavors, one for Tomcat 6/7, one for JBoss 6 and one for "Java EE" which is the one intended for use with Glassfish 3.1 and WebSphere 8.

Up next: GlassFish 3

In the next post I'll tell you what I had to do to get Roller running on Glassfish 3 with EclipseLink JPA.

Apache Roller 5.0 RC3

2011-01-04T08:00:00+00:00

On the last day of 2010, I made available the third release candidate for Apache Roller 5.0. The main difference between this new candidate and the previous one is that the new RC3 runs on Java EE 6 servers: Glassfish 3, JBoss 6 and Websphere 8 (currently in beta). Making this happen took a lot more work than I expected and I'll blog about that over the next couple of weeks as it is an interesting case study in Java EE 6 portability.

Here's the announcement:

Apache Roller 5.0 Release Candidate RC3 is now available for testing.
Note that this is NOT a release of the Apache Software Foundation or
anybody else; this release candidate is for testing purposes only and
not recommended for production.

   What's new in Roller 5.0:
   https://cwiki.apache.org/confluence/display/ROLLER/What's+new+in+Roller+5.0

   Change list (issues resolved since 4.0)
   http://bit.ly/gAhDWR

   Issues resolved since last release candidate (RC3)
   http://bit.ly/dZ27Nx

   Signed binary and source files. Also, documentation in PDF form
   http://people.apache.org/~snoopdave/apache-roller-5.0/

The biggest change in RC3 is the new support for Java EE 6 application
servers: Glassfish 3, JBoss 6 and Websphere 8 (beta). I've been able
to verify that Roller runs on all of those servers, and I updated the
installation guide to explain in detail how you install on Glassfish,
JBoss and WebSphere.

If you would like to help out then please test RC3, discuss the
problems you encounter here and file specific bugs with steps to
reproduce in the Roller JIRA bug tracking system.

Thanks,
Dave

That announcement is available here: http://markmail.org/message/my5wbld2xqvhqpyg