Developing Software in a Sauna

Scott S NelsonLeave a comment

There are cynics amongst us (if you are reading this, you should know that by now) who say that the most pleasurable part of a sauna is getting out of it and being relieved from the heat.

Developing software is like that, sometimes. You will always run across a bug in your software, or poor documentation, or an upgrade or language shift where all the things you expect to be there aren’t. So you bang your head against the wall until a solution falls out of it (hopefully out of your head… though the wall has contributed on occasion). And then you stop banging your head and give it a final slap as you solve the problem. Then it feels good. So good, you wind up banging your head again in a few months/days/hours over another problem.

Of course, just like in the sauna, there’s always that one person who claims to love the heat—the developer who insists they thrive on chaos, who grins at a stack trace like it’s a Sudoku puzzle. Don’t trust them. They’re probably the same people who say they enjoy cold showers and anchovies on pizza. For the rest of us, the cycle is familiar: you dive into the code, confident and optimistic, only to find yourself sweating bullets as you try to decipher what “SyntaxError: Unexpected Token” actually means this time.

Eventually, after spilling enough sweat and coffee onto your keyboard to be justify the $10 spent on a silicone keyboard cover, you emerge victorious. The bug is fixed, the unit tests pass, your CD pipeline deploys to staging, and you feel a rush of euphoria that’s almost worth the ordeal. You promise yourself you’ll document everything this time, or maybe even write better tests next time. But let’s be honest, you’ll be back in the sauna soon enough—sweating, swearing, and secretly loving the moment when you finally get to step out into the cool air of a solved problem.

If you found this interesting, please share.

How to Customize the Color Scheme for the BEA WebLogic Server 9.x Administration Console

Scott S NelsonLeave a comment

Originally published at developer.com

At last year’s BEA World many portal developers were excited to hear that the WLS Administration Console is now portal-based. As developers, we all know that what excites us doesn’t always excite those who hold the purse strings, and customizing an application that is only used by IT generally falls pretty close to the bottom of the budget approval list. At least until there is a really good reason for it. So, my first foray into customizing the WLS Administration Console didn’t come about until 9.2, and was limited to changing color schemes.

A Business Case for Customizing the Console

For those of you looking for approval to customize your console, the driver for the project this article is based on came from a case where multiple BEA domains were running installed on the same physical machine. When the maintenance team would log in to the various consoles they would occasionally make an update to the wrong domain. Doh! For those who have done support, this comes as no big surprise. Many service activities are scheduled in off hours. Off hours are defined as when most users are off the applications and most IT folks are off their par because it is too late at night. The only visual cue as to which console you are logged into is some subtle text showing the user name and domain name.

The solution for this was to color-code the header in each Administration Console. While this sounds fairly straight-forward to the average portal developer, there are a few things that made it a bit of a challenge. First, the Administration Console application is compiled (as it should be), so cracking it open was a bad option as this could have upgrade implications. Second, even if one were to crack open the Administration Console portal (we’ve all made a similar call and regretted it at the next upgrade), the application under WEBLOGIC_HOME affects all domains rather than individual domains. Finally, the steps described at http://e-docs.bea.com/wls/docs92/console_ext/rebrand.html leave out a couple of minor pieces that are only obvious to portal developers. To make a long story short (which is only ever said when it is already too late) I came up with the following steps that worked for this effort.

(If you don’t already have a portal development environment, download the latest from http://www.bea.com/framework.jsp?CNT=index.htm&FP=/content/products/weblogic/portal/.)

Steps to Changing the Header Colors

Create a new workspace for Eclipse for your customization project. For old-time Eclipse developers, this may sound odd. I thought it odd that the BEA best practice is a new workspace for each related group of projects and at first stuck to my old ways of one workspace for all projects. Then I made a change to the wrong project and stopped being so obstinate. Since there are similar types of projects from one group to the next, it is an easy mistake to make and thus the smart recommendation not to. Long story etc.

In your new workspace, create a new Java project named console-extension. While it doesn’t matter what you name your project, this name makes it easier to remember what it is for and to reference documentation related to console customization. Next, import [WEBLOGIC_HOME]samplesservermedrecconsole-extension into your new project. If you are unfamiliar with Eclipse imports, this is done with the File System option in the Import dialog. Once we have this tree in, we want to trim the branches that we don’t want to change by deleting the following:

workspaceconsole-extensionframeworkmarkup

workspaceconsole-extensioncommon

All in workspaceconsole-extensionframeworkskinsxray EXCEPT the following:

css

images

skin.properties

All in workspaceconsole-extensionframeworkskinsxrayimages

All in workspaceconsole-extensionframeworkskinsxraycss

All in workspaceconsole-extensionframeworkskeletonsxray

All in workspaceconsole-extensionimages

Now we want to add some files for our use. First, create a skeleton.properties file in  workspaceconsole-extensionframeworkskeletonsxray and add the following:

jsp.search.path:  ., ../default

Then do the following imports (all files in the path for each):

[WEBLOGIC_HOME]serverlibconsoleappwebappframeworkskinsdefaultimages to /console-extension/framework/skeletons/xray/images

[WEBLOGIC_HOME]serverlibconsoleappwebappimages to /console-extension/images

[WEBLOGIC_HOME]serverlibconsoleappwebappframeworkskinsdefaultcss to workspaceconsole-extensionframeworkskinsxraycss

Next, open /console-extension/framework/skins/xray/skin.properties and delete the following (spread in groups through the file):

theme.plain.search.path: plain/images, images

theme.alert.search.path: alert/images, images

theme.wlsmodules.search.path: wlsmodules/images, images

theme.wlstoolbar.search.path: wlstoolbar/images, images

theme.wlsbreadcrumbs.search.path: wlsbreadcrumbs/images, images

theme.wlschangemgmt.search.path: wlschangemgmt/images, images

theme.wlsworkspace.search.path: wlsworkspace/images, images

theme.wlsnavtree.search.path: wlsnavtree/images, images

theme.wlsmessages.search.path: wlsmessages/images, images

theme.wlsstatus.search.path: wlsstatus/images, images

theme.wlsquicklinks.search.path: wlsquicklinks/images, images

link.window-plain.href:       plain/css/window-plain.css

link.window-plain.rel:        stylesheet

link.window-plain.type:       text/css

link.window-alert.href:       alert/css/window-alert.css

link.window-alert.rel:        stylesheet

link.window-alert.type:       text/css

link.window-wlsmodules.href:       wlsmodules/css/window-wlsmodules.css

link.window-wlsmodules.rel:        stylesheet

link.window-wlsmodules.type:       text/css

link.window-wlstoolbar.href:       wlstoolbar/css/window-wlstoolbar.css

link.window-wlstoolbar.rel:        stylesheet

link.window-wlstoolbar.type:       text/css

link.window-wlsbreadcrumbs.href:       wlsbreadcrumbs/css/window-wlsbreadcrumbs.css

link.window-wlsbreadcrumbs.rel:        stylesheet

link.window-wlsbreadcrumbs.type:       text/css

link.window-wlschangemgmt.href:       wlschangemgmt/css/window-wlschangemgmt.css

link.window-wlschangemgmt.rel:        stylesheet

link.window-wlschangemgmt.type:       text/css

link.button-wlschangemgmt.href:       wlschangemgmt/css/button-wlschangemgmt.css

link.button-wlschangemgmt.rel:        stylesheet

link.button-wlschangemgmt.type:       text/css

link.window-wlsworkspace.href:      wlsworkspace/css/window-wlsworkspace.css

link.window-wlsworkspace.rel: stylesheet

link.window-wlsworkspace.type:      text/css

link.book-wlsworkspace.href:  wlsworkspace/css/book-wlsworkspace.css

link.book-wlsworkspace.rel:   stylesheet

link.book-wlsworkspace.type:  text/css

link.window-wlsnavtree.href:  wlsnavtree/css/window-wlsnavtree.css

link.window-wlsnavtree.rel:   stylesheet

link.window-wlsnavtree.type:  text/css

link.window-wlsmessages.href: wlsmessages/css/window-wlsmessages.css

link.window-wlsmessages.rel:  stylesheet

link.window-wlsmessages.type: text/css

link.window-wlsstatus.href:   wlsstatus/css/window-wlsstatus.css

link.window-wlsstatus.rel:    stylesheet

link.window-wlsstatus.type:   text/css

link.window-wlsquicklinks.href:     wlsquicklinks/css/window-wlsquicklinks.css

link.window-wlsquicklinks.rel:      stylesheet

link.window-wlsquicklinks.type:     text/css

script.skin.src:    skin.js

script.skin.type:   text/javascript

script.menu.src:    menu.js

script.menu.type:   text/javascript

script.util.src:    util.js

script.util.type:   text/javascript

script.delete.src:  delete.js

script.delete.type: text/javascript

script.float.src:   float.js

script.float.type:  text/javascript

script.menufx.src:  menufx.js

script.menufx.type: text/javascript

(note that if you want to customize any of the above UI elements for your own application leave the ones you need).

Open netuix-extension.xml and delete the following: default-window-icon=”window-icon.gif” and default-window-icon-path=”/console/images/”

To change our header appearance we need to change two files. First, open /console-extension/framework/skins/xray/css/body.css and change the value of background-color: for .bea-portal-body-header; Then, grab an image editor and change the color in /console-extension/framework/skins/xray/images/banner_bg.gif to the same value. For ascetics, you may wish to edit /console-extension/framework/skins/xray/images/banner_logo.gif as well.

Deploying Your Updates

Finally, save everything, then right-click on the console-extension project and select Export. Export as a JAR file to domain-dir/console-ext directory (or to a handy local location to later be uploaded to the domain-dir/console-ext directory). If you made any of your changes in the file system rather than in Eclipse, be sure to refresh your project before exporting or you will get errors.

The example below uses the color value of FFCC33 to replace the default:

While there may be some simpler paths to achieving this, this particular approach was the fastest solution that should have little or no impact to future upgrades within the 9.x WebLogic Server series. If most of these steps seem daunting, you can grab the workspace from here (PLEASE CREATE LINK TO workspace.zip) and find the values you want to change.

Scott Nelson is a Professional Services Principal Portal Consultant by day and a blogger with a sense of humor by night. This article illustrates the former. To confirm the latter for yourself, visit http://humor.fywservices.com/.

If you found this interesting, please share.

Can I Told You So Be Retroactive?

Scott S NelsonLeave a comment

I was part of the team at my former employer bidding for the re-work of the MBTA web site. Lo and behold (whatever that means), I get around to reading /. for the first time since then and I run across this little item that talks about how the new-and-improved site didn’t support Opera and has been rolled back to it’s earlier version.

So, if they had gone with my former company and if I had stayed, they wouldn’t be having these issues. But, then, I probably wouldn’t have time to read about them 🙂

If you found this interesting, please share.

Quieter Console for WLP 9.2.x Domains

Scott S NelsonLeave a comment

In the server console window when starting WLP 9.2.x there is a lot of logging that is both useless and slows down the start of your unit tests when developing. Here is how to get rid of that:

Go into your WebLogic Administration Console.

Under Environment on the left hand side navigation there is a node called Work Managers. Click on that and add a new Work Manager for the name:

weblogic.wsee.mdb.DispatchPolicy

Be sure to check the target server on the Next screen after adding the name.

Note: This tip came from Dev2Dev, which is sadly no longer.

If you found this interesting, please share.

Whether to Use Open Source or Windows Development Platform

Scott S NelsonLeave a comment

The following questions was on LinkedIn today:

How to decide whether to use Open Source or Windows development platform.  we are working on creating a SAAS model for a payroll and HR software. The debate we currently having is to on what software to develop Open Source or Windows. Need some help to decide the parameters on which to compare so as to come up with a logical decision rather than the decision based on gut.

Here is my response:

I started typing a couple of different responses, and then stopped as it occurred to me that the world of the operating system has turned upside in the last ten years, because your choice for OS is literally Mircrosoft or Open Source. All of the other vendors have either gone open source or are too small to consider as real choices anymore.

So from the OS point of view, it is a choice of who your support vendor is now.

Once you choose your operating system, then you need to choose your software packages. This is where in-house skill is a big part of the equation, because if you don’t have people that will take complete ownership of both the framework and custom code, your open source options narrow. You have to look at which projects have the most solid team that will still be updating the product n years from now. Currently, those are products that either have vendor sponsorship (and you expect the vendor to be around n years from now) or are so wildly popular for so long that even if the current group gets rich and bored someone else will step in.

And, back to the Windows or something else question: For a web-based application, if software doesn’t run on both (at least a version that runs on both), I wouldn’t consider it.

But (as Dennis Miller used to say every week), that’s just  my opinion. I could be wrong.

If you found this interesting, please share.