Quieter Console for WLP 9.2.x Domains

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.

© Scott S. Nelson

WSRP over HTTPS in WLP

Ever run across a problem that sounds real familiar, but you don’t remember all the details of the solution? Recently someone was telling me an issue they were having with WSRP where the WSDL when accessed over the HTTPS port still showed the HTTP end point.  That is when I experience De Ja Vue (I’v seen this before).

When using HTTPS with WSRP in WLP you must edit the wsrp-producer-config.xml in the producer application:

<!– This element describes the capabilities of this producer. Set the secure attribute to “true” if you require this producer offer any port over SSL. –>
<service-config>
<registration required=”true” secure=”true“/>
<service-description secure=”true“/>
<!– Set accepts-mime to true to more efficiently process uploaded files when the consumer is a WebLogic Portal. –>
<markup secure=”false” rewrite-urls=”true” transport=”string” accepts-mime=”false”/>
<portlet-management required=”true” secure=”true“/>
</service-config>

The bold is where the default value has been changed to true. My conclusion from this is that with WLP your WSRP portlets are either available over HTTP or HTTPS, but not both. I haven’t tested this theroy, however, as I have not yet worked on a WSRP project that was not over HTTPS.

If you found this interesting, please share.

© Scott S. Nelson

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.

© Scott S. Nelson

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.

© Scott S. Nelson