I use the JetSpeed Brigde, simply because it's more egalitarian, but the steps are practically the same for JBoss or GridSphere or Vignette or the Cocoon portal - you just have to plug in the appropriate portlet bridge from apache.
So, you really just need to know the basic rules for Struts development, be careful with your struts forwards and stuff, cuz there are certain rules for struts portlets, and use the appropriate bridge.
By the way, it seems to me that the real direction from Sun, IBM, and the people that work on the Portlet API is to integrate JSF with the Portlet spec, as opposed to Struts. I love Struts, and have always been a big fan, but you have to be aware of where the industry is moving, and I am now recommending to all of my clients, which are very heavy on the WebSphere Portal Server side, to embrace the JSF framework, and minimize their exposure to Struts within a portlet framework.
I agree with Cameron. The JSF direction seems to be more prominent than Struts.
Speaking as a former IBM portal developer, who's worked on WebSphere Portal using Struts and JSF, I have to say it's more 'enjoyable' as a programmer to use JSF in Portal. Also in WebSphere Portal's case in particular, the Portal Software Group had to re-write parts of the Struts source code in order to do the integration, and to do certain subtle things required knowledge of how this deep integration worked.
On the other hand, the JSF integration seemed very smooth and straightforward. In fact, I believe for IBM, the WebSphere Portal integration with JSF was actually written by the Rational Application Developer people. Every time I had a Portal Struts issue, I got routed to Portal Tech Support, but every time I had a Portal JSF issue, I got routed to Rational Tech Support.
By the way, if you do end up using JSF in Portal, remember: PHASE LISTENERS. Very useful on portal page refreshes for real-time data, and all sorts of other things. Resist the urge to 'hack' the portlet class when you can just use a PhaseListener.