BEA Weblogic Portal 8.x Tips & Tricks
As documentation goes, BEA is in my top five vendor list. It can be hard to find documentation for older versions (it's all still there, but the links are buried), but once you find the product documentation page you'll have a well indexed reference for most of what you need. Still, there are always those wonderful little gotchas that you will run across where the answer either came after the documentation or is something that you can do to make your life easier that the product reference team didn't think of (or, in some cases, they thought of it but didn't give the best answer).
In this article, I want to share a few solutions I have discovered outside of the standard documentation. Some you can find on BEA's Dev2Dev (though it might take a long time), some came from trial and error, and one came from days of pain following the recommended path to later try almost the total opposite approach and cut my work time by two-thirds. And, I am sure there are dozens (if not hundreds) of other little helpful hints, but these are the ones that I remember the most in almost three years of building many BEA Portal solutions.
You Can Get There from Here
The most cherished word to any vendor is also the most dreaded to an IT department: Upgrade. This is very near the top of my mind with BEA showcasing Aqualogic as a growing technology stack. I know that as soon as they have the Aqualogic Portal (or whatever name they are going to give it), I will have a lot of upgrades to do (and as a professional services consultant, I personally look forward to it). Based on the many job postings from BEA lately, my guess is that it will be heavily based on the Plumtree portal they bought last year. You may think I digress speaking of future upgrades in an article about the current version, but it all ties in.
The first BEA portal upgrade I dealt with was from version 7.x (really .x in this case, because I don't recall the exact release) to version 8. Being a self-appointed member of the semantics police, I recall complaining that the project name for this process included the word migration rather than upgrade. When the dust finally settled, I retreated from my position on the project title. Version 7 is nothing like version 8 (which was the point of mentioning the likelihood of the next version being based on an entirely different product).
Being the astute engineers that professional services expects, the migration team went directly to the BEA site for a hint on how to handle this project. As I said in the beginning, BEA has pretty good documentation available and we immediately found a very detailed set of instructions for upgrading. I'm not going to make a big deal of what I thought about the instructions because I'm still a fan of BEA products. What I will state is that I am really, really glad that I had to migrate multiple portals or else I wouldn't have this topic to write about.
If you ever need to move from version 7 to version 8 (and there are plenty of version 7 applications still out there), ignore the upgrade documentation. Instead, inventory your existing application and separate it into webflow portlets and non-webflow portlets. By doing this, you will save yourself hours (days or weeks, depending on the size of your application). Do read the online instructions for working with version 8 if you're not familiar with it. Then create a brand new portal in 8 with all of the pages in Workshop. Once you have a nice, blank portal, import your non-webflow portlets one at a time. With each import, run a build. Each time you do this you'll get a stack of errors for the methods that have changed. Take the advice of the Hitchhikers Guide to the Galaxy and Don't Panic. Track down the compile errors and look up what that method did for you in version 7 and change it to use the version 8 method. This will get easier with each portlet, especially if you have a consistent development process because before you are done you'll start to anticipate errors and correct them before you build. This may sound tedious, but it is a heck of a lot easier than following the proscribed path and tracking down both compile errors and functional bugs.
Now, according to all the documentation, you can port your webflows to pageflows with minimal fuss. This reminds me of the question asked by every mother all over the world: "If you're friend jumped off a bridge, would you do it too?" Instead, create a new pageflow, fire up your old webflow editor, and re-write it in pageflow format. This will get rid of the many limitations imposed on version 8 webflow support and prevent the harried calls from whomever inherits your applications asking how the heck to make a change to that monster. Again, no matter how tedious this sounds, it will be worth it in the time saved. Additionally, version 9 has no support for webflows, so following this track will leave you ready for a future upgrade. In fact, many of the work-arounds described in this article have been solved as a standard feature in version 9 (which I had not investigated prior to starting this article).
Upgrading from one version 8 Service Pack (SP) to another is not nearly as difficult, yet some caution should still be exercised. The whole versioning naming convention is misleading. Sometimes they are referred to as .release, sometimes as service pack releases. This would make you think that they made some enhancements that are major changes, and you would be thinking correctly. However, it would also lead you to believe that methods and classes may be added or improved that require no effort on your part to upgrade, and there you have the gotcha. Sometimes they replace classes and methods. Although the changes are covered in the release notes, who wants to read through all of that to find the two or three things that are specific to your application?
I have found that most of the big changes take place in the framework implementations. The easiest way to a smooth upgrade is to import everything into a new portal except your portlet and framework JSPs. Those you want to leave behind, then create new JSPs in your new portal and copy-paste all of your custom code from your original application. Workshop will color code the stuff that no longer works right away for you. Once you have hand-moved your JSPs into your new portal, run your build and track down the little changes. Then regression test and find the other quirks that may have popped up. One that occurred from one SP to the next is the relative path used for page tab icons. The quickest way to figure out where to move your reference to is to let the icon fail to show up and the view the page source to see where it is looking for it. The relative path changed from the framework to application. While this was a wise approach (especially for clustered environments) it can be daunting to figure out without knowing that a change occurred and it isn't some bug in your port.
Write Once, Run in Any Project
All right, this is just a quick note on a quirk of Workshop that can be annoying for those who frequently use either their own legacy code or purchase code. I'm sure most folks who have done any extensive work with Workshop have already discovered that a BEA control project has no option for adding classpaths. While I'm sure there was some good reason behind this, it's tough to use your existing code base throughout your portal project if you can't reference it when you need it. To get around this limitation, just make sure that what you need is in the classpath of another plain old Java project. Then, set your build order so that the project with your legacy code reference is built before your control project.
This isn't a perfect fix because you will still need to keep your various portal projects in sync if there are cross dependencies. You will also need to document this dependency in case your control project later becomes legacy code. Still, this is far more maintainable of a solution than duplicating your legacy code into your control project.