June 2007 Archives

We talked about trace.axd as a debugging solution, but often it's even easier to step through your code as it runs. When doing regular .NET application development, the browser connects directly to the .NET application and allows you to step through the code in real time, watching variables, etc. The problem is, when you're doing portlet development, the browser connects to the portal, and the portal connects to your application. You can't avoid this in most cases because the portal is sending context information to the portlet running your code via HTTP headers. When your code is running this way, Visual Studio won't stop at the breakpoints specified unless you attach the debugger to the .NET process by selecting "Debug: Processes", then choosing the .NET worker process:

Click through for some more tips...

There are lots of ways to debug .NET applications, from tunneling tools to stepping through code. Another neat way to keep track of requests to your application is to use Application-Level Trace Logging. Once turned on, you can view a list of requests and other trace information by going to the URL http://iisserver/webservicepath/Trace.axd, and getting the following:

The "View Details" link brings back a huge amount of information about the request headers and other important .NET information, including trace messages written into your code, which can be instrumental in diagnosing problems with your portlet.

We mentioned some problems with the WS Server after database restarts a little while ago, and have another tip for you from our friends Sri Potharaju and Omoruyi Evbuoma, who we've worked with on a joint project. For those of you that develop using the PRC, you no doubt have used the login token sent to a portlet to create a remote session:

    IRemoteSession session = RemoteSessionFactory.GetTokenContext(
        req.GetRemoteAPIEndpoint(), req.GetLoginToken());

One thing that you may not have run into is an exception about an invalid token when everything seems to be OK (you've checked the option to send the login token to the portlet, etc.):

    com.plumtree.server.marshalers.PTException: -2147024809 -
    Error in function PTSession.Reconnect
    (strToken == '7330|1179848758|pww0VlUyQzOmNllByGZcfrEwj6A='): -2147024809 -
    InternalSession.Reconnect():  Invalid token.  
    com.plumtree.remote.prc.search.SearchException:   
    com.plumtree.server.marshalers.PTException: -2147024809 -   
    Error in function PTSession.Reconnect    
    (strToken == '7330|1179848758|pww0VlUyQzOmNllByGZcfrEwj6A='): -2147024809 -  
    InternalSession.Reconnect():  Invalid token.  
        at com.plumtree.remote.prc.search.SearchRequestWrapper.execute(SearchRequestWrapper.java:48)
        at com.pt.search.PlumtreeSearch.DoSearch(PlumtreeSearch.java:304) 
        at com.pt.search.BasicSearch.(BasicSearch.java:143) 

Solution: Make sure the time and date of the servers are synchronized. Since the login token expires after a set amount of time, it has the expiration time built into it. So if the times aren't synched, it's likely the token will already be "expired" by the time it arrives at the WS Server!

You're probably aware that you can customize the portal appearance via style sheets, but perhaps you haven't looked into it too much. Or maybe you think that you can't get the level of customization you need with just style sheets. Whatever the situation, this post gives you a quick CSS summary and shows a couple of the items you can configure in a just portlet. The first thing to understand about styles is that there are IDs, CLASSes, and TAGs, and when you're specifying a style you can apply that style to any combination of them to be as specific or general as you'd like.

• IDs apply to a single item on a page (such as a single portlet), and are identified in a style sheet with the '#' character.
• CLASSes can apply to multiple items (such as all portlets), and are identified with the '.' character.
• TAGs are just simple HTML tags that you're no doubt familiar with.

If there's one thing you should remember about portal customization via CSS, it's that virtually every item on your standard portal page has a CLASS and/or ID associated with it, and therefore can be customized via CSS.

Here's an interesting and little known Activity Space: The Memory Debug page. You need to be an administrator to get to it, but go to /portal/server.pt?space=MemoryDebug in your portal, and you'll see a bunch of interesting (albeit not incredibly useful for actual debugging) information. If you're building an app that uses reloadable var packs, though, you actually can use this page to reload them on demand (if you specify that the varpack can be dynamically reloaded in the code):