For example, the documentation at Using the WebLogic Server JMX Timer Service gives a very straight-forward and standards-compliant example of how to run a task at intervals.  I used this example almost in its entirety to create a module to poll a database for a specific change every 2o minutes. I then noticed that the timer would stop for no apparent reason at no obvious interval.

After many hours of digging through logs looking for some cause, I was ready to give in and post a plea for help on a mailing list. It just so happened used a text editor to grab the code to post, and noticed in the text editor that there was one place where unregister would be called on the bean: under contextDestroyed in the servlet to at registered the timer.  In the clarity of hind-sight I realized that the timer was stopping more often in environments that were accessed less often because the efficient WebLogic Server was garbage collecting the unused servlet handle, resulting in contextDestroyed being invoked, thus killing my timer. As it normally should, except in the case where the timer should continue running as long as the server was running.

Lesson learned: Think it all the way through between copy and past.

For those who like links and confessions:  There is an example of using a timer in my JavaBoutique article that contains precisely the same flaw in logic.

I’ve had on my to-do list for awhile now to post about a recent investigation into a WLS  stuck thread issue I fixed. And I still will, as the way I got there is probably more useful to some than the end result. But, someone sent me a question that led straight to the solution today, so I thought I would post the email thread here to benefit my reader:

Q: Can we configure a cluster of WLS that is behind a F5 to use jdbc based persistence without the server affinity defined by load balancer?

A: By persistence, I would assume you mean user session. The limitation is on the applications deployed rather than WLS itself. All objects in session must be serializeable in order for WLS to properly manage persistence, regardless of whether it is database or file or in-memory persistence.

If your client has an issue where session data is lost unless server affinity is maintained it is because persistence has been manually turned off for the application. This is almost always done be developers or vendors when their application does not support serialization.

I’ve run across this situation twice this year. The first time was a sloppy, dishonest vendor (they clearly stated both that their product supported serialization and that they had never tested it…so I did, and it did not) that did not make their session objects serializable. The second time they had issues with a third party application that serialized PDF reports that were generated for a request and they had to turn off persistence to keep the disks from filling up every quarter.

One of those things I ran across recently that I always forget between projects so I thought I would share here:

1 Set the Oracle Home

export ORACLE_HOME=/usr/lib/oracle/xe/app/oracle/product/10.2.0/server/

2 SQL Plus – Idle Instance $ORACLE_HOME/bin/sqlplus /nolog

3 Connect as SYS User

connect sys/welcome1@xe as sysdba;

4 Create the WEBLOGIC_PORTAL

User CREATE USER WEBLOGIC_PORTAL IDENTIFIED BY WEBLOGIC1;

5 Grant Roles and Permissions

GRANT CONNECT, RESOURCE,DBA TO WEBLOGIC_PORTAL;

6 The WLS install seems to expect a table named SYSTABLES, so you will need to create it:

CREATE TABLE SYSTABLES (TEMP NUMBER);

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.

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.

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.

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

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.

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

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