JSF, Portal 6 and pain.

My current project is using JSF with WebSphere Portal 6.0 and RAD 7.0.  I can’t recall being so frustrated while coding.  Coding is usually my favorite part, not this time.

One of the gems so far is outlined in this technote on IBM’s site:  Cannot pass values between Action and Render phase in portlets using JSF in Portal 6.0.

Request scope managed beans do not persist during render phase on JSF JSR-168 Portlets in Rational® Application Developer (RAD) version 7.x Symptom a) After submitting changed control - such as the h:inputText element - to a JSF action, an output field does not show the changed value. b) Constructors of custom JSF components are called twice. c) A pager which shows for example the third page jumps back to the first page

Cause

The JSF specifications do not explicitly address the interaction between the portal action and render phases. In the previous JSF portlet bridge from RAD 6 (this was deprecated but it is still usable) heavy use was made of the session for getting information from the portlet action phase to the render phase. This is generally not advisable. To workaround this problem and also to address another issue that existed which could arise during “refresh” scenarios (an action event in a first JSF portlet causing new content displayed for this first portlet. A subsequent action in a second portlet will cause the first portlet to “refresh”) the new JSF portlet bridge from RAD v7.x uses portlet render parameters to pass information between phases. An unintended side affect is that in some situations the request scope managed bean will not work in v7.x. Resolving the problem The new JSF portlet bridge will create render parameters for the following objects: •Objects of type java.lang.String •Objects that implement java.io.Serializable. You might need to modify certain fields to use the keyword transient so that they get not serialized. This is necessary if you do not have or access to the source code or the field is accessed via a method which creates the instance on demand. •View state. A JSF view is not serializable by default but the JSF API provides a mechanism to be able to get state that can be serialized. So, to make request scope beans usable for a portlet render phase (and a refresh) they must be made Serializable.

So IBM’s implementation requires everything to be serializable.  Oh joy.

The last several projects I’ve worked on have used Spring MVC and I really wish I was using it now…..

Obscure JSF error in WebSphere Portal

On the project I am working on now we are using IBM’s JSF implementation for portlets.  I am happily (or as happy as I can be while using JSF) coding along.  I add a dropdown (selectOneMenu) to my jsp and backing bean.

But when I try to render the portlet I keep getting this error:

[1/27/09 19:25:24:955 EST] 00000070 SystemErr     R java.lang.IllegalArgumentException: “{2}” Conversion Error setting value ”{0}” for ”{1}”.
at com.sun.faces.util.Util.getSelectItems(Util.java:647)
at com.sun.faces.renderkit.html_basic.MenuRenderer.getOptionNumber(MenuRenderer.java:573)
at com.sun.faces.renderkit.html_basic.MenuRenderer.renderSelect(MenuRenderer.java:534)
at com.sun.faces.renderkit.html_basic.MenuRenderer.encodeEnd(MenuRenderer.java:473)
at com.ibm.faces.renderkit.DefaultAjaxRenderer.encodeEnd(DefaultAjaxRenderer.java(Compiled Code))
at javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java(Compiled Code))
at com.ibm.faces.renderkit.html_extended.Utils.encodeComponent(Utils.java(Compiled Code))

It took me forever to figure out, but the issue was caused by mistyping my backing bean name in the jsp.

I had typed this:

<h:selectOneMenu id=”menu1″ styleClass=”selectOneMenu” value=”test”>
<f:selectItem itemValue=”ViewAll” itemLabel=”View All” />
<f:selectItems value=”#{claimList.selectProviders}” />
</h:selectOneMenu>

Instead of:

<h:selectOneMenu id=”menu1″ styleClass=”selectOneMenu” value=”test”>
<f:selectItem itemValue=”ViewAll” itemLabel=”View All” />
<f:selectItems value=”#{claimsLists.selectProviders}” />
</h:selectOneMenu>

The correct code has an ’s’ on end of the backing bean name.  Messing that up caused the cryptic error and a lot of time troubleshooting.

Of course, you maybe asking “Why are you typing that in instead of just using the GUI to build your code?”.  Well, like most things, it doesn’t always work as designed.  RAD (Rational Application Developer) for whatever reason stopped liking my backing bean.  It shows up in the GUI, but none of the public methods are availble in the “wizard”.  I don’t have time to troubleshoot it, so I’ve been coding the connection to the backing bean by hand.

The Big Kahuna, Installing WebSphere Portal 6.1 on CentOS 5.2

One of the contributing factors to my purchase of the server and the selection of CentOS was to allow me to install a test WebSphere Portal 6.1 instance to play around on.  I am happy to report a relatively painless installation.

I downloaded portal from IBM’s PartnerWorld.  It consisted of 7 cd ISO’s which I burned to disk.  My first attempt to install was with the GUI Wizard that ships with the product.  For whatever reason, the wizard would not run. Since I wanted a working portal and didn’t really care about a working wizard I switched to a command line installation without wasting anytime troubleshooting the wizard.  Besides, all the cool kids use the command line anyways.  I don’t recall how the long the installation took, but it was completely uneventful.

The thing that caused me the most annoyance with the whole install was getting the plugin for Apache to work so I wouldn’t have to go through the portal http/https ports.  The App Server documentation indicated that their is a plugin for Apache 2.2, but finding the executable was damn near impossible.  I knew from the documentation and various web posts that the name of the file was mod_was_app22_http.so.  Again, I usually don’t do much administrative work at the App Server level but I found the IBM jungle impenetrable.

After much searching I did finally find the download that was the AppServers “Extras” upgrade.  At the time I didn’t think to save the link, but incase anyone searching for mod_was_app22_http.so ends up here; I found in the download file: 6.1.0-WS-PLG-LinuxX64-FP0000021.pak.

Secret Squirrel time, SSL for Apache 2.2 on CentOS 5.2

As with most of the things on the new server, getting the basics have been a breeze. Nothing worth writing about.  The stuff I do write about will be as much for me to document (ewwww!, no self respecting developer likes to document anything ) what I’ve done as it is to share the info.

The first thing I needed to do was to generate a self signed certificate.  A quick Google search turned up more than enough results, so I won’t bother re-inviting the wheel and write about it again.

Where I ran into problems was when I tried to get ssl working with a virtual host.  Yes, I know the issues related to ssl and virtual hosts.  I have a handful of websites that will run off of the server and I wanted them to all be set up the same.  My plan was to make them all virtual hosts and have nothing resolve the the default site.  The seannewby.com site is the only domain that will be configured for ssl.

I had set up the virtual hosts using CentOS’s gui tools.

My httpd.conf file looked like this well close (Just like Sgt Friday, some of the values have been changed to protect the innocent; ME):

Listen 80

#
# Use name-based virtual hosting.
#
NameVirtualHost 192.168.1.50        

# Virtual host seannewby.com
<VirtualHost  192.168.1.50>
 	DocumentRoot /home/www/sites/seannewby.com
 	ServerName www.seannewby.com
         ServerAlias seannewby.com
	DirectoryIndex index.php index.html index.htm index.shtml
</Virtualhost>
# Virtual host hamsandwich
<VirtualHost  192.168.1.50>
 	DocumentRoot /home/www/sites/hamsandwich.com
 	ServerName www.hamsandwich.com
         ServerAlias hamsandwich.com
	DirectoryIndex index.php index.html index.htm index.shtml
</VirtualHost>

And my ssl.conf file had a ton of stuff in it.  The key entries for the virtual host looked like this:

Listen 443
<VirtualHost _default_>

	# General setup for the virtual host, inherited from global configuration
	#DocumentRoot "/var/www/html"
	#ServerName www.example.com:443
	SSLEngine on

	....Lots of stuff removed....	

</VirtualHost>

Now, if I remember correctly, I was able to get to the default site (the apache documentation) through ssl at this point.

I experimented with different values in the ssl.conf file doing things like this:

Listen 443
<VirtualHost 192.168.1.50:443>

	# General setup for the virtual host, inherited from global configuration
 	DocumentRoot /home/www/sites/seannewby.com
 	ServerName www.seannewby.com
         ServerAlias seannewby.com
	SSLEngine on

	....Lots of stuff removed....	

</VirtualHost>

or this:

Listen 443
<VirtualHost www.seannewby.com:443>

	# General setup for the virtual host, inherited from global configuration
 	DocumentRoot /home/www/sites/seannewby.com
 	ServerName www.seannewby.com
         ServerAlias seannewby.com
	SSLEngine on

	....Lots of stuff removed....	

</VirtualHost>

I was in full fledged hackapalooza mode and I don’t remember all of the different variations I tried, just that they didn’t fully work.  Sometimes https://www.seannewby.com worked, but http://www.seannewby.com would display an error saying the site only accepted https traffic.

Other errors included an one in Firefox stating the server gave an incorrect ssl response that was too long.  I also frequently saw the warning “Combining * with non * virtual host not supported.  Starting with uncertain results” when restarting apache.

I’m sure any apache pros are shaking their heads right now, but I’m a Newby (yes, that really is my name) so I’ll use that as my excuse.  Besides, I’m much more of a developer; admin, not so much.

Anyways, the Apache warning led me down the path to finally get it working. I needed to include port information on all of the VirtualHost tags.  This is what the working config looks like.

httpd.conf:

Listen 80

#
# Use name-based virtual hosting.
#
NameVirtualHost 192.168.1.50:80        

# Virtual host seannewby.com
<VirtualHost  192.168.1.50:80>
 	DocumentRoot /home/www/sites/seannewby.com
 	ServerName www.seannewby.com
         ServerAlias seannewby.com
	DirectoryIndex index.php index.html index.htm index.shtml
 	LogLevel debug
 	HostNameLookups off
</Virtualhost>
# Virtual host hamsandwich
<VirtualHost  192.168.1.50:80>
 	DocumentRoot /home/www/sites/hamsandwich.com
 	ServerName www.hamsandwich.com
         ServerAlias hamsandwich.com
	DirectoryIndex index.php index.html index.htm index.shtml
</VirtualHost>

ssl.conf (note the addition of the NameVirtualHost:

Listen 443

##
## SSL Virtual Host Context
##
NameVirtualHost 192.168.1.50:443
<VirtualHost 192.168.1.50:443>
 	DocumentRoot /home/www/sites/seannewby.com
 	ServerName www.seannewby.com
         ServerAlias seannewby.com
	DirectoryIndex index.php index.html index.htm index.shtml
	....Lots of stuff removed....
</VirtualHost>

Now, I’m sure there are more tweeks I could make, like removing the IP address altogether, but it works now, so I’ll probably leave it.

Picking an Operating System, enter CentOS

Seeing as I want to use this almost entirely as a server, I was pretty sure that I would be using some flavor of linux as the operating system.  Given the price advantage to anything Windows based, especially any of the Windows server offerings, Windows was a non-starter.

I did briefly entertain the idea of using openSolaris, but decided I wanted to go with an operating system that had a large active community.  Not sure if openSolaris is there yet, and didn’t want to spend/have the time to spend trying to get it to work.  I wanted to be able to Google and find answers.

Initially I was leaning towards using Ubuntu.  It is the most popular distro according to distrowatch and has a large community.  Another priority of mine for the OS was that it have a long support window, I don’t want it to be at End Of Life in 6 months.  I’d like to be able to the server up and running and not have to worry about upgrading the OS to the latest bleeding edge.  Ubuntu met this requirement in that certain releases are marked as Long Supported versions.

However, while performing additional research on the various linux distros, I happened upon CentOS (Community Enterprise Operating System).  CentOS is created from the source of a “prominent north american enterprise linux vendor”.  In other words, CentOS is almost an exact copy of Red Hat Enterprise Linux.  The major difference being that all the Red Hat logos are replaced with with CentOS logos because Red Hat does not allow for the logos to be redistributed. According to distrowatch, CentOS is the 8th most popular flavor of linux.  Big enough to allow me to find answers to various issues.  And according to Wikipedia, CentOS is the most popular of the rebranded RHEL versions.

For me, the identical binary nature of CentOS to RHEL has a distinct advantage.  Since professionally I work almost exclusively with IBM WebSphere software, specifically Portal, and IBM certifies WebSphere to run on RHEL.  With CentOS I should run into fewer issues setting up test instances of IBM software.  This was a big enough of an advantage that I went with CentOS 5.2.

With CentOS I get php 5.1.6, mySql 5.0.22, apache 2.2.3, tomcat 5.5.23.  All reasonably current.  The only one that causes me some concern is the level of php.  It looks like there are some php apps that require php 5.2, we shall see if that causes me any problems.

I was able to get it set up with out any issues whatsoever.  Things are much easier than they were 7 years ago, the first time I messed around with linux.  Even the software Raid was a breeze.

Next steps, more config and getting some software installed.

The new server

Like I posted earlier, Dell’s sale on their low range servers piqued my interest in messing around with a server again.

These are the details on the server:

• PowerEdge SC440
• Dual Core Intel® Pentium®E2180, 2.0GHz, 1MB Cache processor
• 800MHz FSB
• 4GB DDR2, 667MHz, 4X1GB Dual Ranked DIMMs memory
• 80GB 7.2K RPM Serial ATA Hard drive

All that for $299, plus shipping charges. The base configuration only had 1gb of ram. Since I work with WebSphere Portal and wanted to use this as a test server, I upgraded to 4gb of ram. It was only $100 and anyone who has worked on portal knows how much it likes server memory. The more the merrier.

It is similar to the one reviewed here: http://www.trustedreviews.com/networking/review/2006/12/26/Dell-PowerEdge-SC440/p1.

It has a nice metal case and is quiet while running. It would not make a good desktop pc as it has limited PCI slots and you would not be able to put a good video card in it.  But for what I want to do, a play/test server, it is perfect.  You really can’t beat the price for server quality hardware.

The only area it was lacking is in the storage department.  To solve that issue I went over to newegg and picked up two Western Digital 1 terabyte drives.  They have been installed in a RAID 1 configuration so I have a terabyte of (reasonably) worry free storage.

Bring out your dead!

BUT I’M NOT DEAD. I’M FEELING BETTER. I FEEL HAPPY! I FEEL HAPPY!

The site is back from the dead.

It has been a long time since I’ve done anything with the site. Realistically, it hasn’t been available most of the time because of failing connections between apache and tomcat. I never really had time to check it to make sure it was up.

Anyways, I had been running the site on a server I rented from 1and1.com. I never had any problems, but the server was ancient. 1.7ghz celeron processor, 256mb of RAM and a 40 gig hard drive. A few weeks ago dell had a sale on some of their low end servers and I picked one up. 2Ghz dual core intel processor, 4GB of RAM and an 80 gig drive for $299. Picked up two terabyte drives and threw those in as in RAID 1. Changed my cable account so I could have a static ip and run servers. Shazam, the site is back.

I’m going to try and do a better job keeping up with things and keeping them up to date. Still have some work to get it to where I’d like it.