Posts Tagged ‘WLS’

Creating a Local WLS 10.3.2 Domain

Friday, March 12th, 2010
No Gravatar

While setting up a new project this morning I was reminded of a somewhat counter-intuitive sequence when setting up a local environment (even with the simple Pointbase install). When you get to this screen:

Clicking Next will give you this warning:

Just click OK. The database isn’t running at this time.

And, for those who haven’t upgraded in a while and don’t read the manual, you will want to click Run Scripts when you see this screen:

After the wizard completes, look for the create_db.cmd in the domain root and run it before starting the server. The first start, the server will have problems starting. Let it run until nothing is spit into the console anymore, then kill it and start it again. This time it should come up.

ClassNotFoundException for PageFlowContextListener

Wednesday, March 10th, 2010
No Gravatar

I was a bit surprised to run across this issue for the first time in a 10.3.0 installation.  According to a post on OTN, it is caused by the actual Beehive library not added correctly in config.xml. However, when I ran across it, it was a different library (the sample projects) that were missing, but the same error occurred.

Go figure.

If the WLS 8.x Left Navigation Missing

Thursday, October 1st, 2009
No Gravatar

This usually happens after an older JRE is installed or machines with an older version of IE. You need to check Internet Options – Advanced Java to see which version is installed.

This can happen frequently in shops that use older versions of Documentum WebPublisher, which requires an older JRE to work.

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

Thursday, September 3rd, 2009
No Gravatar

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]\samples\server\medrec\console-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:

\workspace\console-extension\framework\markup

\workspace\console-extension\common

All in \workspace\console-extension\framework\skins\xray EXCEPT the following:

css

images

skin.properties

All in \workspace\console-extension\framework\skins\xray\images

All in \workspace\console-extension\framework\skins\xray\css

All in \workspace\console-extension\framework\skeletons\xray

All in \workspace\console-extension\images

Now we want to add some files for our use. First, create a skeleton.properties file in  \workspace\console-extension\framework\skeletons\xray and add the following:

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

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

[WEBLOGIC_HOME]\server\lib\consoleapp\webapp\framework\skins\default\images to /console-extension/framework/skeletons/xray/images

[WEBLOGIC_HOME]\server\lib\consoleapp\webapp\images to /console-extension/images

[WEBLOGIC_HOME]\server\lib\consoleapp\webapp\framework\skins\default\css\ to \workspace\console-extension\framework\skins\xray\css

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

Quieter Console for WLP 9.2.x Domains

Monday, August 31st, 2009
No Gravatar

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.

Annotation Overrides in a Cluster

Saturday, August 29th, 2009
No Gravatar

The original blog I referenced in my original blog (I recall someone  laughing at the term “Legacy Web Application” back in 2000) is sadly gone. So, for those who may run into the following error:

“javax.enterprise.deploy.model.exceptions.DDBeanCreateException: [J2EE Deployment SPI:260142]The descriptor at ‘META-INF/annotation-manifest.xml’ in module

Here is the closest reference still available to help you out: http://blogs.oracle.com/jamesbayer/2007/08/changing_weblogic_annotations.html

WLP Sessions and Porlets in Shared Libraries

Thursday, June 11th, 2009
No Gravatar

Awhile back, I ran into an issue where session data was being lost between requests in a WebLogic Portal project. As it only occurred in a clustered environment, it was obvious that the value was not being persisted, even though persistence was set properly with

<wls:session-descriptor>
<wls:persistent-store-type>replicated_if_clustered</wls:persistent-store-type>
</wls:session-descriptor>

After much frustration, someone on the team ran across an additional setting for the session-descriptor node: sharing-enabled. In the case where a portlet is from a shared library, the persistence does not work unless sharing-enabled is set to true.

<wls:session-descriptor>
<wls:persistent-store-type>replicated_if_clustered</wls:persistent-store-type>
<wls:sharing-enabled>true</wls:sharing-enabled>
</wls:session-descriptor>

In hindsight, this behavior makes some sense, in that most portlets that are distributed as shared libraries by vendors do not require session values. However, in the case where a shared library is created by an application team to reuse portlets across portals where WSRP is not practical, the need to share sessions may arise, and now you know how to fix it.

For other deployment descriptor options, see http://download.oracle.com/docs/cd/E12840_01/wls/docs103/webapp/weblogic_xml.html

Latest Developer.com Article

Monday, June 1st, 2009
No Gravatar

When my articles appear on Developer.com, they have 120 days exclusive rights. Rather than have readers wait four months,  I post a link to the article here (when I remember to).

The latest is 10 Things You Should Know About WebLogic Server 10.3, handy if you are considering a move to the latest version of WLS.

Good Article on WebLogic Deployment Plans

Tuesday, May 26th, 2009
No Gravatar

In WLS, deployment plans let you change the values in deployment descriptors at deployment time. This is really handy when you want to move your deployment archives from one environment to the next (i.e., from Staging to Production) and need different settings based on the environment. Maxence Button blogged an excellent how-to at http://m-button.blogspot.com/2008/08/how-to-use-deployment-plan.html

FastSwap Feature of WebLogic Server 10.3

Wednesday, May 6th, 2009
No Gravatar

I’m the first to admit that if you are looking for breaking news, I am not the source. Broken news, maybe…

Anyway, I just noticed the FastSwap feature for WLS 10.3. This allows for updating classes in a running instance without having to do a full redeploy. If you have spent anytime developing WebLogic Portal applications, you know what a boon this is.  Two of the major productivity killers in building  WLP solutions is the time it takes to redeploy the whole portal to test every little change, and eventual Out of Memory errors that will occur with repeated redeployment of the same application.

Turning on the feature is a simple matter of updating weblogic.xml and weblogic-application.xml (see the documentation for the specifics).

One note of caution: This is for development use only. If your deployment processes do not include either deployment plans or environment-specific deployment descriptors, you will need to maintain a local copy outside of your normal source control.