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.
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).
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.