BEA Weblogic Portal 8.x Tips & Tricks, Page 2
Dude, Where's My Portlet?
Portals that are built well (or are well funded despite not having been done right the first time) will grow. If the growth of your portal requires no security restrictions on your new portlets and you manager all of your portal layouts through Workshop, you will never know that there are some quirks to how portlets are associated to a portal in the portal administration application. For the rest of us, here's a couple of things to consider if it is early enough, and how to deal with them if it is too late.
Properties about your portal are stored in the database when you deploy it to your server. From what I can guess (I'm too lazy to look it up, so please don't send me a flood of comments that this is documented somewhere), the portal was designed to be run from a managed server with plenty of horsepower. This makes sense, considering that useful portals will require a fair amount of resources and have a large enough base of users to require a server farm. What this means to those of us who manage portals in the wild is that time spent documenting and following a proper deployment plan will save hours (or days) of work dealing with future changes.
When deploying your portal, you first want to deploy it to your admin server before deploying to managed servers. This approach will allow the server to handle LDAP propagation automatically for you, so that new users are added to the full server farm instead of the first server you deploy to. At the time of this first deployment, your portal assets are catalogued into the database for management. If you deploy to a managed server first, the assets become frozen and future deployments will not update your portal administration application with new portlets and/or page. With this in mind, even if you will not be initially deploying to a server farm it is still a wise strategy to create a managed server environment anyway and follow the above plan.
If you are already in production and didn't plan for this, all hope is not lost. The best approach would be to re-build your environment with a deployment plan, eliminating extra steps in the future. That said, I have seen situations where this was not practical (generally based on political rather than technical challenges). In which case, the next approach to gain access to your assets is to do the following:
First, if you have an admin server and haven't already deployed your portal to it, do so now. If you have resource constraints, you can always remove it once you have updated your database.
Next, in the portal admin console, create a new desktop and then assign your current portal to it. The new desktop should contain your new pages and portlets because the new desktop will generate the necessary database entries. Depending on the service pack you have installed, you may need to re-start the server to add these assets to your original desktop. Now, you can manage your new assets.
Another important thing to remember about your initial deployment planning is that, in a clustered environment, you must deploy your LDAP to Admin only, so that it replicates properly across all servers. Otherwise, you frequently will run into user profile issues. In the managed server environment, you will want to use your Admin deployment to make updates because all the neat stuff is there, where you have to search or type group names to find them in managed server admin consoles.
Are We There Yet?
Some portals are small, some are big, and some are gigantic. I'm not talking about users, and not necessarily functionality, but total code involved. Code bases get huge, especially if there have been upgrades or (gasp!) migrations from one platform to another. From SP 3 up, loading Workshop and running builds can seem to take forevvvvvvver as all the paths are validated and the code assists are updated. It's the old story of do you want it easy to use or fast (pick one). The answer from everyone is: both! That's okay. It was evolution that got you to this point and one more step will get you past it and back to fast(er) builds. The two-step trick is first to find all the legacy stuff that you aren't using and then get rid of it. Of course, most of us don't have the time to do that, but the second step will help in that case, too. Step two is to find all the legacy stuff (preferably only what you still use) that has not changed in eons and JAR it up. JARs get stored more efficiently and only need to be referenced the very first time the environment is created. This will cut your build times anywhere from 10–80%, depending on how thorough you are and how honest you are.
When Java Calls for a Coffee Break
Portals are often used to consolidate disparate data sources into a single view, especially with the growing popularity and need for Business Intelligence Dashboards. With many of these views being composites of separate sources and/or accessing web services, sometimes the data for a portlet takes a long time to load. Despite the modularity of a portlets at design time, at run time it all is distilled into a single Web page, and a Web page doesn't load until the last line of HTML as been generated and sent to the browser. When one or more of your portlets takes too long to load, you could be inundated with complaints about your portal's performance, even after having done everything programmatically possible to streamline your back-end calls. How do you provide the users with what they want while not gaining a reputation for causing a traffic jam at the coffee pot? Use the old iFrame trick (aka the new AJAX trick): iFrames for portlets.
Note: Version 9 has built-in functionality to handle this issue and it is strongly recommended that, if you used this work-around in version 8 to re-write your portal, you should use the out-of-the-box features available in version 9).
Faster Start Up in Development
One complaint I hear from developers is about how long it takes the application to start when developing. The default memory settings are low to be respectful of slower developer machines. It is easy to change these settings by updating your setDomainEnv.cmd file to use your memory more efficiently. The basic setting is MEM_ARGS=-Xms96m -Xmx256m. Change this to MEM_ARGS=-Xms786m -Xmx768m and the full memory will be allocated immediately rather than growing as you need it (which is usually during start up). Keep in mind that, if you have less than 1Gb RAM installed, this won't work, but then if you do have less, you need more to do any serious development. I consider 1.5 to be the minimum to be productive as a developer.
Once you are up and running, you may run into out-of-memory errors. Although this is a good way to convince the boss to buy you an upgrade (as I did before I found the real problem), the real issue is with a bug in the older 8.x servers. After around three deployments, the server starts throwing the error. Earlier versions did it less often because each re-deploy was done manually. Later versions automatically re-deploy your changes. Although this saves keystrokes, if you are having a tough time with a bug and save frequent changes, you will run into the error more often. Just get in the habit of bouncing the server every fourth deployment and you should be much happier. This is also true of production deployments. I recommend that rather than try to track how many deployments it has been to always bounce production with each new release. This may take more planning, but planning is a good thing.
About the Author
Scott Nelson began writing this article as the Northeast Regional Consulting Manger for Keane Architecture Services Global Sourcing, where he discovered the tips listed in this article as a Principal Consultant. He has recently returned to acting as a Principal Consultant and completed the article as an employee of BEA. All of the concepts and opinions in this article are solely those of the author based on his experience before being employed by BEA. Scott can be reached at email@example.com.