Dusting off the “Bad Smells in Code” presentation!

Recently, I dusted off a presentation (i.e. re-skinned and reused) that I had done back in year 2000 about “Bad Smells in Code” that was derived from Martin Fowler’s book Refactoring: Improving the Design of Existing Code. While the Refactoring book itself was a little too prescription oriented for my liking, the chapter about code smells was very good in my opinion. I look upon code smells as fairly common classic mistakes made in developing code that you are best advised to avoid – they are usually indications that something is not right in paradise and needs a closer look, and possibly some refactoring (i.e. clean-up) is in order. This blog entry focuses on object-oriented code smells.

An administrator cannot always add a portlet to a Quickr place!

This is an issue that flummoxes Quickr newbies, and I had a couple of new team members run into it today. Figured that others run into this issue as well. Essentially, the natural expectation for most people is that as a Quickr administrator, they would be able to add portlets/components to any place irrespective of whether they created it themselves or whether somebody else created it. While you don’t have to be the owner of a team place, you do need to be member of the team “managers” role. If you are not in the manager role and you are not the team place owner, then you cannot add a portlet!

Missing log4j log files with DailyRollingFileAppender when they should roll over?

Yes, I am back with a blog entry after quite a gap here! I have been knocked out sick for 5 weeks now and I am sick of being sick! Better now and hoping to be back at a 100% soon. Enough excuses – onto the subject of this blog entry. We use Log4j’s DailyRollingFileAppender in a WebSphere Portal environment to generate daily log files for various custom portlets that we have deployed. This worked just fine on some WPE v6 test servers with multiple portlets logging to the same log file, and the daily rollover occurring every midnight. However, on some other WPE v6 test servers running the exact same applications, while logging did work the daily rollover did not. Instead of us having multiple log files with date timestamps in their names, we would only have today’s log file – the previous log files would simply disappear! This issue results from the fact that the DailyRollingFileAppender (DRFA) tries to rename the log file during rollover. However, when the rename fails, it ends up overwriting the log file, hence losing information. On checking the application server’s SystemErr.log, we found an error each midnight similar to -

log4j:ERROR Failed to rename [logfilename] to logfilename.2008.01.11].

This appears to be a fairly common issue with log4j 1.2.x in Java application servers running on Windows. While there is no good resolution for this issue there is a workaround that works pretty well.

Looking for a few good WebSphere Portal developers for our Austin office – do you have what it takes?

I am looking for competent WebSphere Portal developers and a Portal administrator to join the Xtivia team in Austin. It certainly is not easy to find people that can pass our technical screens. So do apply if you think you have strong skills with WebSphere Portal and you are looking for a challenging position in a growing Portal practice where you can make a difference. Team members take on responsibility for architecture, design, and development of portal and business applications built using various commercial/open-source Java technologies. The work environment is informal and requires flexibility, self-motivation, quick ramp-up, and desire to excel. As you can tell from some of my blog entries, you will be continually challenged and will require you to use your strong troubleshooting and problem-solving skills.

To apply send an email to our recruiter with your resume! Or email if you want more information about the job openings.

WebSphere Portal Portlet Error – Unsupported major.minor version 49.0

Today was a fun day getting the base JSR 168 polls portlet created – I actually got involved doing pair programming with a team member who is new to the Portal world. We chose to create this portlet as a basic JSR168 portlet without Struts or Faces support – the rationale being that we may want to target this portlet at platforms other than WebSphere Portal as well that may not provide the required support for anything other than a basic JSR168 portlet. We did the development in Rational Application Developer (RAD) on my Vista laptop and today pushed me over the edge with Vista. I had RAD crash on me a few times, and now I am convinced that I need to make the time over my winter holidays to just go ahead and downgrade to XP – yes, I am ready to admit defeat on the Vista front and move on with life! Anyway I digress – back to the topic at hand. We got the portlet skeleton coded up and the war file built, and attempted to deploy the portlet on WebSphere Portal v6.0.1.1. And WebSphere Portal rejected the portlet war file with this message -

EJPAQ1316E: Could not process the selected file from the browse button as a WAR file. Make sure it is a WAR file and try again.