Words collide

I think one of the most important virtues of a software professional is being fearless. Someone can lack fear for many reasons:

1) They’re naive

2) They’re stupid

3) They’re experienced

A naive or stupid person is either naturally or consciously ignorant of the risk involved with the activity they’re about to embark on. The first can be forgiven until becomes a trend (in which case they’re starting to become the second).

J.B. Rainsberger once wrote (in JUnit Recipes):

Test until fear turns to boredom.

Taken up a level, it means do the little things that help you become fearless. Don’t just act without fear.

Bridging the Gap – The File Upload saga continues…

Last week on LOST….
What’s the issue with a File Upload control in a WebSphere Portlet (and please, if you’ve done something like this and know an easier way, I’m all ears)?

WebSphere portlets aren’t keen (they don’t listen for) forms that use multi-part encoding. The portlet action gets ignored, your file delivered to the heavens and your customer left feeling blue (IBM Blue?).

So the first part of the two part problem is getting the file up to the server. The second involves what to do with it once it arrives. The image files needs to be persisted to the user’s Member record inside LDAP.

Portal provides a nice facade for dealing with Members. It’s called WMM (WebSphere Member Manager). WMM masks things like attribute mapping and LDAP syntax, it’s just the gate keeper. Works nicely…provided you’re within the Portal context (making a Portlet request).

Let me try tying the two issues together with the solution I devised.

The Portlet now calls an external (from the Portal context) Servlet to grab and parse the file (using Apache’s wonderful FileUpload library from their Commons project).

So now I have the file…how do I get it into a valid WMM context (knowing the receipt of the file came via HTTPServletRequest rather than Portlet Request)?

Here’s a little pattern I tried, using Observer. I call it the PhotoBooth/PhotoLab pattern.

When the portlet’s Session bean instantiates from the Portlet, I create an Envelope. The Envelope contains the user’s unique id and a property to house the image (byte[]). The Envelope is then ‘dropped off’ at the PhotoLab, a singleton with a Map of Envelopes. The Map’s key is the unique ID. So the empty envelope has been left at the PhotoLab. When the FileUploadServlet receives and parses the file, it asks the PhotoLab for the envelope (the key was a parameter passed to the FileUpload servlet). The photo gets placed into the envelope and then guess what happens?

Yep, the trusty old Observer pattern kicks in. When the image setter is called on the envelope, the state gets changed (calling setChanged(); ) and then Observers are notified: The Session bean’s update() method gets called and the envelope is dropped of.

The Portlet now has the photo and can use WMM to persist it when the user clicks ‘Save Profile’ (via PortletRequest)

I’m happy with how it works, I just need to clean up the implementation a little bit. Ted O’Grady did a great job of defining the code’s current state as the Speculative Solution…time to clean that speculation up a bit and get the Durable code in place.

2 Portlet Specs and URL encoding…

Still working on the file upload portlet for my current client. I’ve decided to change gears and parse the request in a servlet rather than the portlet itself. Why? I think it will allow me to create a second form on the Portlet’s JSP and encode it in whatever way I need.

The portlet complies with JSR168, not the WebSphere portlet API. Seeing as it’s portal, I need to encode the URL to the servlet…easy enough.

String servletURL=response.encodeURL("/UploadServlet");

and pass this variable into the form’s action attribute and I’m done.

…except…I get a “Page Not Found” error and the following shows up on the console:

Servlet Request Processor Exception: Virtual Host/WebGroup Not Found ….


So I could go into everything I tried in figuring out why this very simple little example didn’t work but I’ll save you the time and anguish. Turns out the IBM’er beside the IBM’er I was working with knew what the issue was….had he chimed in a little earlier (hint for the future Jimmy), we would have saved a little grief but I’m still grateful for his involvement.

Turns out a JSR168 portlet needs an additional bit of magic to encode a url. You need to use the following:

String servletURL=response.encodeURL(renderRequest.getContextPath()+ "/UploadServlet");

with renderRequest doing the heavy lifting. Add that and you’re gold.



Strings…every application has/needs/uses them. I’m using Rational Application Developer, IBM’s IDE that runs up on top of Eclipse. It’s typical IBM software…big, a little slow and somewhat dependable (I believe that’s classified as a backhanded compliment).

Anyhow, RAD (as the cool people call it) has the standard Eclipse based SOURCE options. One being ‘Externalize Strings’. I’ve seen it on the menu a thousand times but never used it. That changed the other day. I had some spare time and some LDAP Attributes referenced from within the code. I highlighted the string “cn” and clicked “Externalize Strings”…biz…pop…bang, a Wizard pops up and presents me with a screen asking what I’d like to use for a key to reference the string (which, ironically enough…is a String). Smokes starts billowing from the exhaust vent, the drive grinds away and presto…a nice little class for grabbing a resource bundle (populated) for the string. My old reference to “cn”

String commonName = getAttribute("cn");

has been replaced with

String commonName = getAttribute(Messages.getString("TransAltaPumaProfile.cn");

so that’s that…mission accomplished, right?

I read an article recently that asked readers what they spend more time doing, reading software or writing it. You know what…the answer is pretty obvious. We read our code far more often than we write it. That’s my first issue with the output of “Externalize Strings”, it doesn’t read nicely. It takes the reader away from the context of their task. Yes you can name the Class for retrieving strings something more meaningful than Messages. A small gain. The Genericists (I believe I made that word up) will tell you not to be too specific with your message bundle…context lost.

That’s my first issue with it. My second, and more significant, issue is the potential for lost time in debugging a change to the ‘key’ string. Whether you like it or not, Java is a compiled language. There are benefits to living with a compiler. It’s loves to complain. If you accidentally (for those of us who make mistakes) change the “TransAltaPumaProfile.cn” to “TransAltaPumaProfile.cnm”, what does your compiler do? That’s right, nothing. It takes the “you want to play with dirty little strings, go for it…I won’t stop you until runtime…but when one of them comes into my room, to play with my stuff…it better be right” attitude. I thought about this and the first thing that came to mind was, “whoa…bad news…I better take those keys, the magic ingredient to the entire ordeal, and put them in an interface somewhere…really lock ’em down”

Yep, “File/New/Interfac….wait a second” what was I thinking? This was all to satisfy some frail bit of whiz bang provided by my IDE.

So here’s what I did. Wrote an abstract class with some public final static strings on them and referenced those in the code. Now, this line of code:

String commonName =getAttribute(Messages.getString("TransAltaPumaProfile.cn");

looks like this

String commonName = getAttribute(LDAPAttributes.COMMON_NAME);

If I accidentally (for those of us who make the occassional mistake) change “LDAPAttributes.COMMON_NAME” to “LDAPAttributes.COMMON_NAMES”, the compiler (Felix) tells me (Oscar) that I screwed up, that the referenced String doesn’t exist and that I need to seek professional help.

I also like this approach over an interface since I don’t need to declare the implementation of the interface in order to use the String. That’s always bugged me. There’s a certain pipeline application out there with a barrage of Strings held within interfaces. I won’t name names but someone had us do a lot of interface String work on that gig…likely an idea that came to him while out for a ‘jog’ (that’s right, I said jog).

File Upload, Portal, JSF and not being surprised…

I’m writing a portlet that allows a user to modify certain LDAP attributes.  It’s a nice little solution (if I do say so myself), wrapping IBM’s PUMA framework with something a little more durable, a little more generic and a lot less IBM.

The customer would like the user to upload their own picture.

“Yeah, shouldn’t be a problem…” I say, recalling the File Upload control on Rational Application Developer’s JSF palette…famous last thoughts.

IBM, in their wisdom and glory, have shipped some JSF components that don’t work with their Portal solution.  They’re available for use in a Portal project, they just don’t work… (bonus points to me for looking it up in the documentation rather than bugging the local IBM on-site consultant).  I guess that makes sense…

This means a trip to Apache and a chance to try the Commons File Upload component (apparently it works with Portal…I won’t get into why I find this entire thing so hilarious).

EJPPG0003E: ServletContext lookup for /.CreditCounterPartyReviewLog returned the portal context. It has to be a different one.

I’m working on a Portlet project right now. It helps a group over at TransAlta keep their financial obligations and exposures in check. I like the application…it has great business value, terrific customer participation…a great project.

A second developer was introduced to the project recently. He brought the portlets down from CVS and tried running them on his workstation. The received the following error:

2006.08.23 13:37:49.064 E com.ibm.wps.pe.om.definition.impl.WebApplicationDefinitionImpl getServletContext
EJPPG0003E: ServletContext lookup for /.CreditCounterPartyReviewLog returned the portal context. It has to be a different one.

hmmm, what does that mean? He created an EAR file to associate the project with…ahh, but wait! When Rational Application Developer associates Web Modules with an EAR, it doesn’t give it a context root. It tries using the context root for the Portal itself (uh oh) and then throws the exception found above. Fixing it, as my good friend from IBM Thomas Young discovered, is quite simple. Open the EAR, find the module reference and click ‘Refesh’ located beside the Context Root field.

ReDeploy and run…Right Side, not cropped


My wife and I took the kids out to Nipika for a four day weekend. It’s a wonderful place, I’d highly recommend it to anyone looking to get away from the hustle and bustle of city life for a while.

The last thing I did before leaving was export a .war file for release to my client’s Test Environment. I’m starting to learn the last thing you do prior to holidays is rarely the thing that causes the biggest upset while you’re gone. The second last thing you do prior to holidays…now that’s a different story.

As I prepared to export the .war and send it through the deployment process, I noticed something. I noticed a package within the code base with the following name: “org.transalta.creditservices.managedbeantests”.

I like to maintain two projects for every stream of production code, one for the code and one for the tests. That should explain why a package in my deployment release with ‘managedbeantests’ in its name seemed out of place. It’s not uncommon, it usually means I forgot to change the package name at the time of the classes creation. Since I typically create a class from within the context of my ‘Test’ project, it stands to reason why this happened.

No big deal.

So just before exporting, I refactor the package by changing its name to match the other managedbeans, “org.transalta.creditservices.managedbeans”…done. Export .war, send to Tommy and it’s a 4 day weekend.

I return Monday morning to find a note from Tommy, the deployment administrator. To summarize the content of the note, “Jamie, your deployment didn’t work”.

What?!?! Impossible. It worked when I left, I remember deploying it to my development environment right before packaging it up and sending it to Tommy, he must be mistaken. A thread of emails later, he’s right. It’s not working in either Project Dev or Test. I fire up my development environment to prove that I’m not nuts, that it worked just before I left.

It didn’t work.

again, What?!?!?

I spend 5 minutes thinking about the deployment and what may have gone wrong. I focus on the last thing I did before leaving (packaging the .war). A quick look at the code and I find an empty package, “”org.transalta.creditservices.managedbeantests”. Ahhhhh…a clue.
I moved the class but didn’t delete the package (lucky much?). That was enough to trigger my memory, a path to what may have happened lay ahead…. The class I moved is a JSF managed bean. These are beans used within JSF and registered with the JSF context. That means, you guessed it, an explicit reference to it within the faces-config.xml file (bloody xml!?!?!).
Oh, and by the way, nice exception logging JSF, “cannot instantiate ReviewLogManagedBean” (not even the bean in question, just the first referenced bean in the faces-config.xml file.  Almost as useful as Portal’s ‘AssertionFailed’ exception in the log…thanks guys.

I pop open faces-config.xml and there it is, a reference to the old package location. How foolish could I have been? I changed the reference to the new locations, ran it in Dev (it worked), deployed it to Tommy (it worked) and informed the customer (it worked).

So rather than learn a lesson over and over, I thought I’d jot down my lessons learned on this little adventure.

1) Never make a change between final test and deployment, no matter how trivial you think it is. Make the change, rerun your local tests and deploy (Comp. Sci 101, I know, I know)

2) Refactoring tools within Eclipse 3.02 are good, just not good enough to know about references within an XML file. 3.02, I know, is old but it’s what IBM use for Rational Application Developer (tool of choice here).

3) When a container driven exception is thrown and you’re working with JSF, take a look at the faces-config.xml file. It’s worth a shot and really, that’s the heart of the framework.

4) Never make a change between final test and deployment, no matter how trivial you think it is. Make the change, rerun your local tests and deploy (Comp. Sci 101, I know, I know) [worth a second mention]

5) Don’t release anything within 2 hours of a vacation and leave yourself a note.

6) Don’t fry bacon in a cast iron frying pan over a bbq in the mountains if you don’t want to smell like  bacon for the rest of the day.

A Project of Problems

My friend and colleague Iwona and I were talking this afternoon about our current project. It’s a complex integration exercise, joining 4 very different systems while surfacing a new interface through Portal. Iwona is an excellent team member constructing a data model that is both durable and dynamic.

The conversation came around to how we’ve been tackling the problems as they come. Her preference would have been more upfront analysis and less refactoring. It came out that she believes we’ve been ‘designing the system to solve the next problem’.  I bristled at the suggestion….but only for a moment (and the moment’s gone)

I thought about it and realized that’s exactly what we’re doing and I don’t think I’d have it any other way. I’m not saying upfront analysis is a bad thing. Lightweight design meetings are a great way to start a project. They introduce everyone to the Domain, get lots of foundation knowledge on the table. I love that part of a project. I love getting to know a new Domain, form a common Domain language and figure out where the wins are. Conversations beyond that start returning diminished value.

Under a certain light, projects can be viewed as nothing more than a series of problems needing solved. Isn’t that why we got into this in the first place, to solve problems? I know that’s where the draw was on my 1983 Apple II clone, solving the riddles that made the bloody thing work (I was 12 and it the machine rarely worked without some coaxing…).

You often hear team members  describe a pre-production problem as “Murphy’s Law strikes again” and yeah, I guess that’s one way of looking at it. To me, it means a problem wasn’t ready to appear. Now I know that sounds a bit too, I don’t know, abstract or philosophical to have any meaning. What I mean to say is some problems are revealed only through the solving of others. You’ll never solve them all, you just need to solve enough to provide value to those who feel the problem’s pain the hardest.

So whether you spend the time designing the holes in which the fence post will be placed or drawing a rough idea and putting the shovel into the ground…there are rocks, they weigh a lot and it feels amazing once they’re out.


I was having lunch with Jeff and Ian at Café Mauro when the subject of JSR168 portlets came up. It seems the architectural strategy at Jeff’s current client is to build all portlets in strict accordance to the specification (JSR168).

A blanket statement like all pieces of software are to be written as absolute deriviates of a specification makes no sense to me. I see it as architectural idealism; a pattern that hinders the movement to build better software. And here’s why.

Specifications have authors and guess where those authors work? They work for the large software vendors of the world. They work at SAP, they work at IBM, they work at Oracle…you get the idea. They co-author these specifications because they want to standardize ideas or approaches to building products. Once the specification is published, they release their implementation of the specification and customers buy it. It makes sense. They add functionality to the published version; some companies do a really good job, some fail miserably. That’s their problem (and their customer’s I suppose).

Let’s use Portal as an example. Here are three reasons why I will never insist my team build onlyJSR 168 portlets:

  1. It prevents them from leveraging what they own- They paid for a swack of work done by the diligent developers from their vendors labs…they should probably use it.
  2. It slows the software development cycle – Spending my time hand crafting something that has already been built means I’m not hand crafting the stuff that hasn’t been built
  3. It severs their support channel – “Ummm, IBM, Hi, it’s Jamie McIlroy calling. Yeah, I’m having some trouble with my real time awareness application within WebSphere…what’s that? Sametime? No, no…we wrote our own to comply with JSR 168…ummm, hello?!”

I can’t wait to sit in a meeting and here someone tell a client they can’t have functionality they need because: a. It’s not part of a rather generic specification or b. It would take too long to rebuild it to comply with the specification. Yeah, I’d love to support my colleague on that one…While I’m at it, I should probably ask the client to stop taking their medication (Drug Companies are corrupt) or writing to their mother. It’s not my place.

WebSphere Portal and it’s proprietary portlet specification (WPI) have loads of good things we’re delivering to the business. Sametime awareness (not in the specification — never will be), Click2Action (c2a, not portlet messaging: not in the specification — never will be) are two examples of helpful function points I have no problem getting out to the business.

This idealism is like asking your home builder not to use any manufactured parts in your new house. Asking them to mill every bannister spindle, baseboard and door jam. While the idea may seem appealing, imagine what it would cost? Imagine how little you’d care about those hand crafted baseboards once you moved in. I imagine telling my wife how the obscene budget overruns are attributed to the hand blown glass windows I had the builder make. Your boss at work is like my boss at home. They don’t care about where it comes from. — they don’t want any surprises. They care that it works and you did your homework before deciding to use it.

*This assumes I’m working for a customer and that customer isn’t in the business of writing JSR168 portlets.

Remembering Memory Management with CORBA

Java is a wonderful language, especially when compared to a container native language like LotusScript. There are many more options, frameworks, design patterns you can play with. The tools for writing Java agents make the days of writing LotusScript agents seem like forever ago. Have I discovered the silver bullet in the Domino world? Is this my valhalla?


Not by a long shot. Remember memory management? Yeah, it’s back. I tried writing a simple agent that processed a Domino view containing a little more than 20,000 records. The agent uses the POI framework to convert the view into an excel workbook. This is done on a nightly basis. Here’s the thing. Domino’s default heap size is 64mb. My agent was running out of memory. A simple increase in heap size got me around the issue but raised the concern that memory management is something I now need to keep my eye on when writing these Java agents. I know, I know, any (every) developer should always be thinking about memory management but Domino’s LotusScript lulled me away from the concern.

That being said, I still believe this is the way I’ll continue to write my Domino agents from this day forward. My main reason? I can write junit tests for them. A topic for another day…