.NET Portlets using PRC Need Extra Love after 6.5 or 10g Upgrade

| | Comments (2)

The title tells me this is going to be boring to some readers, but I guarantee those who arrive from Google searches will be glad for it--especially since an early discussion of this that used to be on forums.bea.com is now gone.

A funny problem arises when you take certain portlets written in .NET and load them into ALUI 6.5 or Oracle 10gR3 portals. The portlets at issue use the EDK/IDK's PRC library. Even though these portlets work fine when loaded into ALUI 6.1 portals, they suddenly fail with this deceptive message:

The underlying connection was closed: The server committed an HTTP protocol violation. at com.plumtree.remote.prc.soap.QueryInterfaceProcedures.GetVersionInfo() in e:\latestbuild\Release\devkit\5.4.x\prc\src\dotnet\portalprocedures\QueryInterfaceProcedures.cs:line 35 at com.plumtree.remote.prc.xp.XPRemoteSession.getAPIVersion() in e:\latestbuild\Release\devkit\5.4.x\prc\src\xpj2c\portalclient\com\plumtree\remote\prc\xp\XPRemoteSession.cs:line 352 at Plumtree.Remote.PRC.RemoteSessionWrapper.GetAPIVersion() in e:\latestbuild\Release\devkit\5.4.x\prc\src\dotnet\portalclient\RemoteSessionWrapper.cs:line 144 at apicheck.WebForm1.PageLoad(Object sender, EventArgs e) in d:\www\api-check\portlet.aspx.cs:line 60


The real problem though is that the application's web.config file needs an extra setting block dropped in just beneath system.web:

<system.net>
<settings>
<servicePointManager expect100Continue="false" />
</settings>
</system.net>


You'll have to do this with your custom portlets, but it's may also necessary with portlets that come from Oracle/BEA. I've encountered it with the SharePoint Console, for example.

Enjoy (no hugs though),

Bill

2 Comments

Thanks for the tip!
Does this have to do with the upgraded .NET framework that 6.5 requires? I believe pre 6.5 it was 1.1 and 6.5 and up uses 2.0?

Hi Geoff:

It's not clear to me why this behavior occurs. While it is true that a system running the portal on .NET will change their version of .NET during the upgrade, it is not the case that the portlet's remote server need to change its version of .NET. The portlet server however is where the modification is made. Thus, the problem looks to be related to a change in how the HTTP request comes in from the portal.

I do not have a Java portal up right now. If I did, then it would be an interesting experiment to see what happens when a changing version of .NET is no longer part of the equation. Would the remote server still with .NET still need its web.config changed?

Bill

Leave a comment