WLP Sessions and Porlets in Shared Libraries

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

If you found this interesting, please share.

Good Article on WebLogic Deployment Plans

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

If you found this interesting, please share.

FastSwap Feature of WebLogic Server 10.3

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.

If you found this interesting, please share.

Patch for WLS 10.0 ORA-00001 Error Messages in Logs

While the message does not impact functionality, if you have to read the logs it becomes tedious to scroll past the following over and over:

<BEA-403302> <An unexpected SQL exception occured java.sql.SQLException: ORA-00001:
unique constraint (PORTAL.PK_LEASE) violated.
java.sql.SQLException: ORA-00001: unique constraint (PORTAL.PK_LEASE) violated
at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:112)
at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:331)

Not to mention how the fun of having every person who hasn’t looked at your application before reporting it as a problem or insisting it is the root of a bug you are chasing (it isn’t).

If you have a support account, you can surpress this with the following WLP 10.2 patch:

VZGR | 9AS6D7D9

If you found this interesting, please share.