Friday Oct 12, 2012

Establishing WebLogic Server HTTPS Trust of IIS Using a Microsoft Local Certificate Authority

Everyone agrees that self-signed and demo certificates for SSL and HTTPS should never be used in production and preferred not to be used elsewhere. Most self-signed and demo certificates are provided by vendors with the intention that they are used only to integrate within the same environment. In a vendor’s perfect world all application servers in a given enterprise are from the same vendor, which makes this lack of interoperability in a non-production environment an advantage. For us working in the real world, where not only do we not use a single vendor everywhere but have to make do with self-signed certificates for all but production, testing HTTPS between an IIS ASP.NET service provider and a WebLogic J2EE consumer application can be very frustrating to set up. It was for me, especially having found many blogs and discussion threads where various solutions were described but did not quite work and were all mostly similar but just a little bit different. To save both you and my future (who always seems to forget the hardest-won lessons) all of the pain and suffering, I am recording the steps that finally worked here for reference and sanity.

How You Know You Need This

The first cold clutches of dread that tells you it is going to be a long day is when you attempt to a WSDL published by IIS in WebLogic over HTTPS and you see the following:

<Jul 30, 2012 2:51:31 PM EDT> <Warning> <Security> <BEA-090477> <Certificate chain received from - 10.555.55.123 was not trusted causing SSL handshake failure.>

weblogic.wsee.wsdl.WsdlException: Failed to read wsdl file from url due to -- [Security:090477]Certificate chain received from - 10.555.55.123 was not trusted
causing SSL handshake failure

The above is what started a three day sojourn into searching for a solution. Even people who had solved it before would tell me how they did, and then shrug when I demonstrated that the steps did not end in the success they claimed I would experience. Rather than torture you with the details of everything I did that did not work, here is what finally did work.

Export the Certificates from IE

First, take the offending WSDL URL and paste it into IE (if you have an internal Microsoft CA, you have IE, even if you don’t use it in favor of some other browser). To state the semi-obvious, if you received the error above there is a certificate configured for the IIS host of the service and the SSL port has been configured properly. Otherwise there would be a different error, usually about the site not found or connection failed.

Once the WSDL loads, to the right of the address bar there will be a lock icon. Click the lock and then click View Certificates in the resulting dialog (if you do not have a lock icon but do have a Certificate Error message, see for steps to install the certificate then you can continue from the point of finding the lock icon).

Figure 1: View Certificates in IE
Figure 1: View Certificates in IE

Next, select the Details tab in the resulting dialog

Figure 2: Use Certificate Details to Export Certificate
Figure 2: Use Certificate Details to Export Certificate

Click Copy to File, then Next, then select the Base-64 encoded option for the format

Figure 3: Select the Base-64 encoded option for the format
Figure 3: Select the Base-64 encoded option for the format

For the sake of simplicity, I choose to save this to the root of the WebLogic domain. It will work from anywhere, but later you will need to type in the full path rather than just the certificate name if you save it elsewhere.

Figure 4: Browse to Save Location
Figure 4: Browse to Save Location

Figure 5: Save the Certificate to the Domain Root for Convenience
Figure 5: Save the Certificate to the Domain Root for Convenience

This is the point where I ran into some confusion. Some articles mentioned exporting the entire chain of certificates. This supposedly works for some types of certificates, or if you have a few other tools and the time to learn them. For the SSL experts out there, they already have these tools, know how to use them well, and should not be wasting their time reading this article meant for folks who just want to get things wired up and back to unit testing and development. For the rest of us, the easiest way to make sure things will work is to just export all the links in the chain individually and let WebLogic Server worry about re-assembling them into a chain (which it does quite nicely). While perhaps not the most elegant solution, the multi-step process is easy to repeat and uses only tools that are immediately available and require no learning curve. So…

Next, go to Tools then Internet Options then the Content tab and click Certificates. Go to the Trust Root Certificate Authorities tab and find the certificate root for your Microsoft CA cert (look for the Issuer of the certificate you exported earlier).

Figure 6: Trusted Root Certification Authorities Tab

Export this one the same way as before, with a different name

Figure 7: Use a Unique Name for Each Certificate
Figure 7: Use a Unique Name for Each Certificate

Repeat this once more for the Intermediate Certificate tab.

Import the Certificates to the WebLogic Domain

Now, open an command prompt, navigate to [WEBLOGIC_DOMAIN_ROOT]\bin and execute setDomainEnv. You should then be in the root of the domain. If not, CD to the domain root.

Assuming you saved the certificate in the domain root, execute the following:

keytool -importcert -alias [ALIAS-1] -trustcacerts -file [FULL PATH TO .CER 1] -keystore truststore.jks -storepass [PASSWORD]

An example with the variables filled in is:

keytool -importcert -alias IIS-1 -trustcacerts -file microsftcert.cer -keystore truststore.jks -storepass password

After several lines out output you will be prompted with:

Trust this certificate? [no]:

The correct answer is ‘yes’ (minus the quotes, of course). You’ll you know you were successful if the response is:

Certificate was added to keystore

If not, check your typing, as that is generally the source of an error at this point.

this for all three of the certificates you exported, changing the
[ALIAS-1] and [FULL PATH TO .CER 1] value each time. For example:

keytool -importcert -alias IIS-1 -trustcacerts -file microsftcert.cer -keystore truststore.jks -storepass password

keytool -importcert -alias IIS-2 -trustcacerts -file microsftcertRoot.cer -keystore truststore.jks -storepass password

keytool -importcert -alias IIS-3 -trustcacerts -file microsftcertIntermediate.cer -keystore truststore.jks -storepass password

In the above we created a new JKS key store. You can re-use an existing one by changing the name of the JKS file to one you already have and change the password to the one that matches that JKS file. For the DemoTrust.jks  that is included with WebLogic the password is DemoTrustKeyStorePassPhrase. An example here would be:

keytool -importcert -alias IIS-1 -trustcacerts -file microsoft.cer -keystore DemoTrust.jks -storepass DemoTrustKeyStorePassPhrase

keytool -importcert -alias IIS-2 -trustcacerts -file microsoftRoot.cer -keystore DemoTrust.jks -storepass DemoTrustKeyStorePassPhrase

keytool -importcert -alias IIS-2 -trustcacerts -file microsoftInter.cer -keystore DemoTrust.jks -storepass DemoTrustKeyStorePassPhrase

Whichever keystore you use, you can check your work with:

keytool -list -keystore truststore.jks -storepass password

Where “truststore.jks” and “password” can be replaced appropriately if necessary. The output will look something like this:

Figure 8: Output from keytool -list -keystore
Figure 8: Output from keytool -list -keystore

Update the WebLogic Keystore Configuration

If you used an existing keystore rather than creating a new one, you can restart your WebLogic Server and skip the rest of this section. For those of us who created a new one because that is the instructions we found online…

Next, we need to tell WebLogic to use the JKS file (truststore.jks) we just created. Log in to the WebLogic Server Administration Console and navigate to Servers > AdminServer > Configuration > Keystores. Scroll down to “Custom Trust Keystore:” and change the value to “truststore.jks” and the value of “Custom Trust Keystore Passphrase:” and “Confirm Custom Trust Keystore Passphrase:” to the password you used when earlier, then save your changes. You will get a nice message similar to the following:

Figure 9: To Be Safe, Restart Anyways
Figure 9: To Be Safe, Restart Anyways

The “No restarts are necessary” is somewhat of an exaggeration. If you want to be able to use the keystore you may need restart the server(s). To save myself aggravation, I always do. Your mileage may vary.


That should get you there. If there are some erroneous steps included for your situation in particular, I will offer up a semi-apology as the process described above does not take long at all and if there is one step that could be dropped from it, is still much faster than trying to figure this out from other sources.

Wednesday Sep 05, 2012

Tips on Migrating from AquaLogic .NET Accelerator to WebCenter WSRP Producer for .NET

This year I embarked on a journey to migrate a group of ASP.NET web applications developed to integrate with WebLogic Portal 9.2 via the AquaLogic® Interaction .NET Application Accelerator 1.0 to instead use the Oracle WebCenter WSRP Producer for .NET and integrated with WebLogic Portal 10.3.4. It has been a very winding path and this blog entry is intended to share both the lessons learned and relevant approaches that led to those learnings. Like most journeys of discovery, it was not a direct path, and there are notes to let you know when it is practical to skip a section if you are in a hurry to get from here to there.

For the Curious

From the perspective of necessity, this section would be better at the end. If it were there, though, it would probably be read by far fewer people, including those that are actually interested in these types of sections. Those in a hurry may skip past and be none the worst for it in dealing with the hands-on bits of performing a migration from .NET Accelerator to WSRP Producer. For others who want to talk about why they did what they did after they did it, or just want to know for themselves, enjoy.

A Brief (and edited) History of the WSRP for .NET Technologies (as Relevant to the this Post)

Note: This section is for those who are curious about why the migration path is not as simple as many other Oracle technologies. You can skip this section in its entirety and still be just as competent in performing a migration as if you had read it.

The currently deployed architecture that was to be migrated and upgraded achieved initial integration between .NET and J2EE over the WSRP protocol through the use of The AquaLogic Interaction .NET Application Accelerator. The .NET Accelerator allowed the applications that were written in ASP.NET and deployed on a Microsoft Internet Information Server (IIS) to interact with a WebLogic Portal application deployed on a WebLogic (J2EE application) Server (both version 9.2, the state of the art at the time of its creation). At the time this architectural decision for the application was made, both the AquaLogic and WebLogic brands were owned by BEA Systems. The AquaLogic brand included products acquired by BEA through the acquisition of Plumtree, whose flagship product was a portal platform available in both J2EE and .NET versions. As part of this dual technology support an adaptor was created to facilitate the use of WSRP as a communication protocol where customers wished to integrate components from both versions of the Plumtree portal. The adapter evolved over several product generations to include a broad array of both standard and proprietary WSRP integration capabilities.

Later, BEA Systems was acquired by Oracle. Over the course of several years Oracle has acquired a large number of portal applications and has taken the strategic direction to migrate users of these myriad (and formerly competitive) products to the Oracle WebCenter technology stack. As part of Oracle’s strategic technology roadmap, older portal products are being schedule for end of life, including the portal products that were part of the BEA acquisition.

The .NET Accelerator has been modified over a very long period of time with features driven by users of that product and developed under three different vendors (each a direct competitor in the same solution space prior to merger).

The Oracle WebCenter WSRP Producer for .NET was introduced much more recently with the key objective to specifically address the needs of the WebCenter customers developing solutions accessible through both J2EE and .NET platforms utilizing the WSRP specifications.

The Oracle Product Development Team also provides these insights on the drivers for developing the WSRP Producer:


  1. Support for ASP.NET AJAX. Controls using the ASP.NET AJAX script manager do not function properly in the Application Accelerator for .NET.
  2. Support 2 way SSL in WLP. This was not possible with the proxy/bridge set up in the existing Application Accelerator for .NET.
  3. Allow developers to code portlets (Web Parts) using the .NET framework rather than a proprietary framework. Developers had to use the Application Accelerator for .NET plug-ins to Visual Studio to manage preferences and profile data. This is now replaced with the .NET Framework Personalization (for preferences) and Profile providers.

The WSRP Producer for .NET was created as a new way of developing .NET portlets. It was never designed to be an upgrade path for the Application Accelerator for .NET. .NET developers would create new .NET portlets with the WSRP Producer for .NET and leave any existing .NET portlets running in the Application Accelerator for .NET.


The advantage to creating a new solution for WSRP is a product that is far easier for Oracle to maintain and support which in turn improves quality, reliability and maintainability for their customers. No changes to J2EE applications consuming the WSRP portlets previously rendered by the.NET Accelerator is required to migrate from the Aqualogic WSRP solution. For some customers using the .NET Accelerator the challenge is adapting their current .NET applications to work with the WSRP Producer (or any other WSRP adapter as they are proprietary by nature). Part of this adaptation is the need to deploy the .NET applications as a child to the WSRP producer web application as root.

Differences between .NET Accelerator and WSRP Producer

Note: This section is for those who are curious about why the migration is not as pluggable as something such as changing security providers in WebLogic Server. You can skip this section in its entirety and still be just as competent in performing a migration as if you had read it.

The basic terminology used to describe the participating applications in a WSRP environment are the same when applied to either the .NET Accelerator or the WSRP Producer: Producer and Consumer. In both cases the .NET application serves as what is referred to as a WSRP environment as the Producer.

The difference lies in how the two adapters create the WSRP translation of the .NET application. The .NET Accelerator, as the name implies, is meant to serve as a quick way of adding WSRP capability to a .NET application. As such, at a high level, the .NET Accelerator behaves as a proxy for requests between the .NET application and the WSRP Consumer. A WSRP request is sent from the consumer to the .NET Accelerator, the.NET Accelerator transforms this request into an ASP.NET request, receives the response, then transforms the response into a WSRP response. The .NET Accelerator is deployed as a stand-alone application on IIS.

The WSRP Producer is deployed as a parent application on IIS and all ASP.NET modules that will be made available over WSRP are deployed as children of the WSRP Producer application. In this manner, the WSRP Producer acts more as a Request Filter than a proxy in the WSRP transactions between Producer and Consumer.

Highly Recommended

Enabling Logging

Note: You can skip this section now, but you will most likely want to come back to it later, so why not just read it now?

Logging is very helpful in tracking down the causes of any anomalies during testing of migrated portlets. To enable the WSRP Producer logging, update the Application_Start method in the Global.asax.cs for your .NET application by adding


IIS logs will usually (in a standard configuration) be in a sub folder under C:\WINDOWS\system32\LogFiles\W3SVC.

WSRP Producer logs will be found at C:\Oracle\Middleware\WSRPProducerForDotNet\wsrpdefault\Logs\WSRPProducer.log

InputTrace.webinfo and OutputTrace.webinfo are located under C:\Oracle\Middleware\WSRPProducerForDotNet\wsrpdefault and can be useful in debugging issues related to markup transformations.

Things You Must Do

Merge Web.Config

Note: If you have been skipping all the sections that you can, now is the time to stop and pay attention J

Because the existing .NET application will become a sub-application to the WSRP Producer, you will want to merge required settings from the existing Web.Config to the one in the WSRP Producer.

Use the WSRP Producer Master Page

The Master Page installed for the WSRP Producer provides common, hiddenform fields and JavaScripts to facilitate portlet instance management and display configuration when the child page is being rendered over WSRP. You add the Master Page by including it in the <@ Page declaration with MasterPageFile="~/portlets/Resources/MasterPages/WSRP.Master" . You then replace:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" >




<asp:Content ID="ContentHead1" ContentPlaceHolderID="wsrphead" Runat="Server">




<form id="theForm" method="post" runat="server">



<asp:Content ID="ContentBody1" ContentPlaceHolderID="Main" Runat="Server">

And finally






In the event you already use Master Pages, adapt your existing Master Pages to be sub masters. See Nested ASP.NET Master Pages for a detailed reference of how to do this.

It Happened to Me, It Might Happen to You…Or Not

Watch for Use of Session or Request in OnInit

In the event the .NET application being modified has pages developed to assume the user has been authenticated in an earlier page request there may be direct or indirect references in the OnInit method to request or session objects that may not have been created yet. This will vary from application to application, so the recommended approach is to test first. If there is an issue with a page running as a WSRP portlet then check for potential references in the OnInit method (including references by methods called within OnInit) to session or request objects. If there are, the simplest solution is to create a new method and then call that method once the necessary object(s) is fully available. I find doing this at the start of the Page_Load method to be the simplest solution.

Case Sensitivity

.NET languages are not case sensitive, but Java is. This means it is possible to have many variations of SRC= and src= or .JPG and .jpg. The preferred solution is to make these mark up instances all lower case in your .NET application. This will allow the default Rewriter rules in wsrp-producer.xml to work as is. If this is not practical, then make duplicates of any rules where an issue is occurring due to upper or mixed case usage in the .NET application markup and match the case in use with the duplicate rule. For example:







May need to be duplicated as:







While it is possible to write a regular expression that will handle mixed case usage, it would be long and strenous to test and maintain, so the recommendation is to use duplicate rules.

Is it Still Relative?

Some .NET applications base relative paths with a fixed root location. With the introduction of the WSRP Producer, the root has moved up one level. References to ~/ will need to be updated to ~/portlets and many ../ paths will need another ../ in front.

I Can See You But I Can’t Find You

This issue was first discovered while debugging modules with code that referenced the form on a page from the code-behind by name and/or id. The initial error presented itself as run-time error that was difficult to interpret over WSRP but seemed clear when run as straight ASP.NET as it indicated that the object with the form name did not exist.

Since the form name was no longer valid after implementing the WSRP Master Page, the likely fix seemed to simply update the references in the code. However, as the WSRP Master Page is external to the code, a compile time error resulted:

Error      155         The name 'form1' does not exist in the current context                C:\Oracle\Middleware\WSRPProducerForDotNet\wsrpdefault\portlets\legacywebsite\module\Screens \Reporting.aspx.cs                51           52           legacywebsite.module

Much hair-pulling research later it was discovered that it was the use of the FindControl method causing the issue. FindControl doesn’t work quite as expected once a Master Page has been introduced as the controls become embedded in controls, require a recursion to find them that is not part of the FindControl method.

In code where the page form is referenced by name, there are two steps to the solution. First, the form needs to be referenced in code generically with Page.Form. For example, this:

ToggleControl ctrl = new ToggleControl(frmManualEntry, FunctionLibrary.ParseArrayLst(userObj.Roles));

Becomes this:

ToggleControl ctrl = new ToggleControl(Page.Form, FunctionLibrary.ParseArrayLst(userObj.Roles));

Generally the form id is referenced in most ASP.NET applications as a path to a control on the form. To reach the control once a MasterPage has been added requires an additional method to recurse through the controls collections within the form and find the control ID. The following method (found at Rick Strahl's Web Log) corrects this very nicely:

public static Control FindControlRecursive(Control Root, string Id)


if (Root.ID == Id)

return Root;

foreach (Control Ctl in Root.Controls)


Control FoundCtl = FindControlRecursive(Ctl, Id);

if (FoundCtl != null)

return FoundCtl;


return null;


Where the form name is not referenced, simply using the FindControlRecursive method in place of FindControl will be all that is necessary. Following the second part of the example referenced earlier, the method called with Page.Form changes its value extraction code block from this:

Label lblErrMsg = (Label)frmRef.FindControl("lblBRMsg";);

To this:

Label lblErrMsg = (Label) FunctionLibrary.FindControlRecursive(frmRef, "lblBRMsg";);

The Master That Won’t Step Aside

In most migrations it is preferable to make as few changes as possible. In one case I ran across an existing Master Page that would not function as a sub-Master Page. While it would probably have been educational to trace down why, the expedient process of updating it to take the place of the WSRP Master Page is the route I took. The changes are highlighted below:

<asp:ContentPlaceHolder ID="wsrphead" runat="server"></asp:ContentPlaceHolder>


<body leftMargin="0" topMargin="0">

<form id="TheForm" runat="server">

<input type="hidden" name="key" id="key" value="" />

<input type="hidden" name="formactionurl" id="formactionurl" value="" />

<input type="hidden" name="handle" id="handle" value="" />

<asp:ScriptManager ID="ScriptManager1" runat="server" EnablePartialRendering="true" >


This approach did not work for all existing Master Pages, but fortunately all of the other existing Master Pages I have run across worked fine as a sub-Master to the WSRP Master Page.

Moving On

In Enterprise Portals, even after you get everything working, the work is not finished. Next you need to get it where everyone will work with it.

Migration Planning

Providing that the server where IIS is running is adequately sized, it is possible to run both the .NET Accelerator and the WSRP Producer on the same server during the upgrade process. The upgrade can be performed incrementally, i.e., one portlet at a time, if server administration processes support it. Those processes would include the ability to manage a second producer in the consuming portal and to change over individual portlet instances from one provider to the other. If processes or requirements demand that all portlets be cut over at the same time, it needs to be determined if this cut over should include a new producer, updating all of the portlets in the consumer, or if the WSRP Producer portlet configuration must maintain the naming conventions used by the .NET Accelerator and simply change the WSRP end point configured in the consumer.

In some enterprises it may even be necessary to maintain the same WSDL end point, at which point the IIS configuration will be where the updates occur. The downside to such a requirement is that it makes rolling back very difficult, should the need arise.

Location, Location, Location

Not everyone wants the web application to have the descriptively obvious wsrpdefault location, or needs to create a second WSRP site on the same server. The instructions below are from the product team and, while targeted towards making a second site, will work for creating a site with a different name and then remove the old site. You can also change just the name in IIS.

Manually Creating a WSRP Producer Site

Instructions (NOTE: all executables used are the same ones used by the installer and “wsrpdev” will be the name of the new instance):

1. Copy C:\Oracle\Middleware\WSRPProducerForDotNet\wsrpdefault to C:\Oracle\Middleware\WSRPProducerForDotNet\wsrpdev.

2. Bring up a command window as an administrator

3. Run

C:\Oracle\Middleware\WSRPProducerForDotNet\uninstall_resources\IISAppAccelSiteCreator.exe install WSRPProducers wsrpdev "C:\Oracle\Middleware\WSRPProducerForDotNet\wsrpdev" 8678 2.0.50727

4. Run

C:\Oracle\Middleware\WSRPProducerForDotNet\uninstall_resources\PermManage.exe add FileSystem C:\Oracle\Middleware\WSRPProducerForDotNet\wsrpdev "NETWORK SERVICE" 3 1

5. Run

C:\Oracle\Middleware\WSRPProducerForDotNet\uninstall_resources\PermManage.exe add FileSystem C:\Oracle\Middleware\WSRPProducerForDotNet\wsrpdev EVERYONE 1 1

6. Open up C:\Oracle\Middleware\WSRPProducerForDotNet\wsdl\1.0\WSRPService.wsdl and replace wsrpdefault with wsrpdev

7. Open up C:\Oracle\Middleware\WSRPProducerForDotNet\wsdl\2.0\WSRPService.wsdl and replace wsrpdefault with wsrpdev


1. Bring up a browser on the host itself and go to http://localhost:8678/wsrpdev/wsdl/1.0/WSRPService.wsdl and make sure that the URLs in the XML returned include the wsrpdev changes you made in step 6.

2. Bring up a browser on the host itself and see if the default sample comes up: http://localhost:8678/wsrpdev/portlets/ASPNET_AJAX_sample/default.aspx

3. Register the producer in WLP and test the portlet.

Changing the Port used by WSRP Producer

The pre-configured port for the WSRP Producer is 8678. You can change this port by updating both the IIS configuration and C:\Oracle\Middleware\WSRPProducerForDotNet\[WSRP_APP_NAME]\wsdl\1.0\WSRPService.wsdl.

Do You Need to Migrate?

Oracle Premier Support ended in November of 2010 for AquaLogic Interaction .NET Application Accelerator 1.x and Extended Support ends in November 2012 (see for other related dates). This means that integration with products released after November of 2010 is not supported. If having such support is the policy within your enterprise, you do indeed need to migrate. If changes in your enterprise cause your current solution with the .NET Accelerator to no longer function properly, you may need to migrate. Migration is a choice, and if the goals of your enterprise are to take full advantage of newer technologies then migration is certainly one activity you should be planning for.

Wednesday Aug 15, 2012

The Hitchhiker's Guide to WLP 10.3.4 Domain Creation

When creating a new WLP domain at the stage where you run the scripts
to create the tables, at completion of the script run you may see:

CFGFWK-60839:  Database Load Failed!

Don’t Panic! :)

It seems that sometimes the scripts don’t run in the proper order.
Simply run them again after receiving the error and the second time
should be fine.

Tuesday May 29, 2012

Running a WebLogic Portal (WLP) 10.3.4 Domain as a Windows Service

To start a WLP server as a Windows service it is simplest to make your own script based on the provided standard script located at WL_HOME\server\bin\installSvc.cmd. The standard script works fine for a plain WLS domain, but lacks some classpath and options necessary for WLP.

Start by making a copy of the installSvc.cmd script and naming it something specific to your domain.

Next, just under SETLOCAL you will find where WL_HOME is defined. Here you will add the definitions you would normally add in a script that later calls installSvc.cmd (as per the standard documentation).

set DOMAIN_NAME=gnma_test_domain
set USERDOMAIN_HOME=D:\my_test_domain
set SERVER_NAME=AdminServer
set WLS_USER=weblogic
set WLS_PW=gnmaAdmin01
set MEM_ARGS=-Xms512m –Xmx512m
set MW_HOME=C:\Oracle\Middleware

Note: I had heard of people using this approach who had issues with the length of the command line. This may be due to their use of the default domain path. In the example above, I use a shorter path.

At this point, edit the DOMAIN_HOME\bin\startWebLogic.cmd and set it to echo both the classpath and the options. Then start the domain and capture the output of those echoes, then shut the domain back down. Now REM out the existing CLASSPATH definition, then use the outputs you captured earlier to set the CLASSPATH and JAVA_OPTIONS like this:

REM set CLASSPATH=%WEBLOGIC_CLASSPATH%;%CLASSPATH%; C:\Oracle\Middleware\wlportal_10.3\portal\lib\security\wsrp-security-providers.jar

set CLASSPATH=%MW_HOME%\patch_wls1034\profiles\default\sys_manifest_classpath\weblogic_patch.jar;%MW_HOME%\patch_wlp1034\profiles\default\sys_manifest_classpath\weblogic_patch.jar;%MW_HOME%\patch_oepe1111\profiles\default\sys_manifest_classpath\weblogic_patch.jar;%MW_HOME%\patch_ocm1033\profiles\default\sys_manifest_classpath\weblogic_patch.jar;%MW_HOME%\JROCKI~1.1-3\lib\tools.jar;%WL_HOME%\server\lib\weblogic_sp.jar;%WL_HOME%\server\lib\weblogic.jar;%MW_HOME%\modules\features\weblogic.server.modules_10.3.4.0.jar;%WL_HOME%\server\lib\webservices.jar;%MW_HOME%\modules\ORGAPA~1.1/lib/ant-all.jar;%MW_HOME%\modules\NETSFA~1.0_1/lib/ant-contrib.jar;%WL_HOME%\common\derby\lib\derbyclient.jar;%WL_HOME%\server\lib\xqrl.jar;%WL_HOME%\server\lib\xquery.jar;%WL_HOME%\server\lib\binxml.jar
set JAVA_OPTIONS= -Xverify:none -ea -da:com.bea... -da:javelin... -da:weblogic... -ea:com.bea.wli... -ea:com.bea.sbconsole... -Dplatform.home=%WL_HOME% -Dwls.home=%WL_HOME%\server -Dweblogic.home=%WL_HOME%\server -Dweblogic.wsee.bind.suppressDeployErrorMessage=true -Dweblogic.wsee.skip.async.response=true -Dwlw.iterativeDev=true -Dwlw.testConsole=true -Dwlw.logErrorsToConsole=true -Dweblogic.ext.dirs=%MW_HOME%\patch_wls1034\profiles\default\sysext_manifest_classpath;%MW_HOME%\patch_wlp1034\profiles\default\sysext_manifest_classpath;%MW_HOME%\patch_oepe1111\profiles\default\sysext_manifest_classpath;%MW_HOME%\patch_ocm1033\profiles\default\sysext_manifest_classpath;%MW_HOME%\wlportal_10.3\p13n\lib\system;%MW_HOME%\wlportal_10.3\light-portal\lib\system;%MW_HOME%\wlportal_10.3\portal\lib\system;%MW_HOME%\wlportal_10.3\info-mgmt\lib\system;%MW_HOME%\wlportal_10.3\analytics\lib\system;%MW_HOME%\wlportal_10.3\apps\lib\system;%MW_HOME%\wlportal_10.3\info-mgmt\deprecated\lib\system;%MW_HOME%\wlportal_10.3\content-mgmt\lib\system -Dweblogic.alternateTypesDirectory=%MW_HOME%\wlportal_10.3\portal\lib\security

And that's it. Looks really simple, but it took me quite some time to gather all the necessary pieces in order to make it work. Hopefully you find this before you went through half as much research.

The example here uses a domain with only the Admin server and no managed servers. For a variety of reasons I only want the Admin server to be run as a service. The standard documentation along with the example above should allow you to expand this to include managed servers should you feel the need.

Tuesday May 15, 2012

Changing the Port used by the WebCenter WSRP Producer for .NET

As part of a recent POC effort it was desirable to use a different port from the pre-configured 8678 default. This was achieved by first changing the configured port for the web site in IIS, then updating C:\Oracle\Middleware\WSRPProducerForDotNet\[WSRP_APP_NAME]\wsdl\1.0\WSRPService.wsdl.

Tuesday Mar 13, 2012

Quicktime Killjoy for WLS

Installed the latest QuickTime recently as required for WebEx, then
today I could not start a new WebLogic domain. To save you all the
searching I went through, it turns out that the QuickTime adds
.;C:\Program Files (x86)\Java\jre6\lib\ext\ to the classpath,
which causes the following error starting WLS: was unexpected at this time

the classpath entry and the QTJAVA entry from your environment
variables if you have the same issue. If you are starting WebLogic from a
console you will need a new console session. If from an IDE, you will
need to restart the IDE afterward for the update to take effect.

Friday Mar 02, 2012

JRockit on Solaris

While JRockit is generally the preferred JDK for WebLogic Server, I ran across an environment that had poor performance for no discernible reason recently. I could make this post long by boring you with the details of how I decided to try switching to the Sun JDK, but instead I will just mention that it was WLS 10.3.4 on Solaris 10U6 with JRockit 6U28 and that switch to Sun JDK 6U24 resulted in a significant improvement.

There may be other factors involved in this (I have requested that a Solaris SME look at the environment), but wanted to add this as a debugging option for those who may run into a similar issue where none of the usual suspects of poor performance are present and it happens to be JRockit on Solaris. 

As someone commented, I did leave out the hardware, which was SPARC.

Tuesday Dec 27, 2011

WLS 10.3.x Silent Install Gotcha

I ran into an issue where I couldn't figure out why I was getting the
following error when running a WebLogic Server 10.3.2 upgrade in silent
mode pert the documentation:

weblogic.Upgrade -mode silent -type domain

Calling Wizard
framework for upgrade: args2: [-mode=silent,

-log=stdout, -p:plugin:plugin.executionPlan.file=weblogic/upgrade/domain/execplan.xml,


12:12:25,926 ERROR [inputAdapter_silent]
com.bea.plateng.wizard.WizardController - Uncaught Exception



  at com.bea.plateng.wizard.plugin.silent.tasks.InputAdapterSilentTask.execute(



A fatal error has
occurred.  This application will terminate.
I thought I had followed the example from perfectly:

Example E-3 Sample Silent-Mode XML Script for Upgrading a Domain

<?xml version="1.0" encoding="UTF-8"?>


<group name="DomainSelectionGroup">
<plugin name="SelectWebLogicVersionPlugIn">
<input-adapter name="ChoiceIA">
<bind-property name="selectedChoiceIds">
<plugin name="DomainDirectorySelectionPlugIn">
<input-adapter name="IA">
<bind-property name="selectedFile">
<group name="PostDirSelectionGroup">
<plugin name="AdminServerSelectionPlugIn">
<input-adapter name="IA">
<bind-property name="selectedChoiceIds">
<plugin name="NodeManagerCredentialsPlugIn">
<input-adapter name="UsernameIA">
<bind-property name="value">
<input-adapter name="PasswordIA">
<bind-property name="value">
<input-adapter name="PasswordConfirmIA">
<bind-property name="value">
<plugin name="OptionalGroupsSelectionPlugIn">
<input-adapter name="IA">
<bind-property name="selectedChoiceIds">
<value> . . . </value>
<group name="PostDirSelectionPost81Group">
<plugin name="AdminServerSelectionPlugIn">
<input-adapter name="IA">
<bind-property name="selectedChoiceIds">
<plugin name="OptionalGroupsSelectionPlugIn">
<input-adapter name="IA">
<bind-property name="selectedChoiceIds">
<value> . . . </value>
<group name="DomainBackupGroup">
<plugin name="DomainDirectoryBackupPlugIn">
<input-adapter name="FileSelectionIA">
<bind-property name="selectedFileNames">
<input-adapter name="TextIA">
<bind-property name="value">


But, as it turns out, where I wanted to be literal on the  SelectWebLogicVersionPlugIn value with 10.2, the correct format is to be a bit broader, with:

<plugin name="SelectWebLogicVersionPlugIn">

<input-adapter name="ChoiceIA">

  <bind-property name="selectedChoiceIds">

    <value>9.0 or higher</value>




I hope this saves some folks the time I spent figuring it out :)

Thursday Sep 01, 2011

Handy Deployment Plan for WLP Propagation

Most people will face the issue with file size limits in propagation uploads early on. Some of us also want verbose logging with the commit task so that we have a record of what was propagated. The following propagation plan will fix the first issue up to 90 MB (if your inventory is larger use the uploadRemote tasks instead) and the latter to the best of the ability of the propagation servlet:

<deployment-plan xmlns="" xmlns:xsi="">
            <value>90000000</value><!-- 90 MB -->
        <module-descriptor external="false">
        <module-descriptor external="false">

Wednesday Aug 17, 2011

Steps to use OBIEE JSR168 Portlets in WebLogic Portal

Someone told me they were having trouble getting the OBIEE JSR 168 portlets to run in WLP. Since WebLogic Portal has excellent support for all published portal standards, I figured that the best thing to do is provide illustrated,  step-by-step instructions.

Deploy the JSR168 WAR to the WebLogic Server

Add the JSR168 WAR as a Shared Library to the Application Workspace

Figure 1: Add the JSR168 WAR as a shared library to the application Workspace Step 1

Figure 1: Add the JSR168 WAR as a shared library to the application Workspace Step 1

Figure 2: Add the JSR168 WAR as a shared library to the application Workspace Step 2

Figure 2: Add the JSR168 WAR as a shared library to the application Workspace Step 2

Figure 3: Add the JSR168 WAR as a shared library to the application Workspace Step 3

Figure 3: Add the JSR168 WAR as a shared library to the application Workspace Step 3

Add Shared Library To Portal Project

Figure 4: Add shared library to Portal project Step 1Figure 4: Add shared library to Portal project Step 1

Figure 5: Add shared library to Portal project Step 2

Figure 5: Add shared library to Portal project Step 2

Figure 6: Add shared library to Portal project Step 3

Figure 6: Add shared library to Portal project Step 3

Figure 7: Add shared library to Portal project Step 4

Figure 7: Add shared library to Portal project Step 4

Figure 8: : Add shared library to Portal project Step 5 (Check Allow newer versions unless need explicit version control)

Figure 8: : Add shared library to Portal project Step 5 (Check Allow newer versions unless need explicit version control)

Add Library Reference To Weblogic.Xml In The Portal WEB Project




Add <wls:specification-version> and <wls:exact-match> nodes if required.

Un-check Build Automatically, Clean The Workspace Without A Build And Exit Workshop

Figure 9: Uncheck Build Automatically; Clean The Workspace Without A Build And Exit Workshop Step 1

Figure 9: Uncheck Build Automatically; Clean The Workspace Without A Build And Exit Workshop Step 1

Figure 10: Uncheck Build Automatically; Clean The Workspace Without A Build And Exit Workshop Step 2

Figure 10: Uncheck Build Automatically; Clean The Workspace Without A Build And Exit Workshop Step 2

Restart workshop, build, deploy.

Log-in To Portal Admin Console

Go to Portal\Portal Management. The portlet will be listed for use on streaming portals.



Monday Aug 15, 2011

Programmatically Managing WLP Enterprise Scope Roles

Recently I was working on code to manage roles in WLP. WLP roles can
be at the global, enterprise application, or web application scope and I
needed it at the enterprise application scope because these roles were
for use with the content repository.  However, I could only find
examples for the web application scope, which generally looked like

RolePolicyManager rpm = new RolePolicyManager();

RolePolicyItem rpi = new RolePolicyItem();





ArrayList a = new ArrayList();




From that example, I would assume that changing




would be sufficient. Alas, it wasn't. The role was still created at the web application level. So, being clever, I removed


had an interesting result. The role was created at the Enterprise
Application scope, but only in the RDBMS, not in LDAP and, consequently,
not in the Portal Admin Console. For someone in a hurry this might be
acceptable as the role could be managed from code. And, while in a
hurry, I had the long view that these roles would also need to be
managed from Portal Admin Console, so don't ask me if the role actually
worked for entitling when out of sync as I never tested it.

make a long story short (probably too late for some), I contacted
support, who in turn opened a bug. The response from engineering was
that the WebAppName had to remain, and that one more piece was required:


that did the trick. I looked up the documentation for
com.bea.p13n.entitlements.policy.RolePolicyItem and found the
setPolicyUser method listed in the parent class, though found no
reference as to its value, nor did I find a getter for the attribute, so
I don't believe it was something I missed, just one of those
undocumented features that are handy to know about.




« August 2016