NavigationSelectionModel navModel = // see http://publib.boulder.ibm.com/infocenter/wpdoc/v6r1/index.jsp?topic=/com.ibm.wp.ent.doc_v6101/dev/dgn_modelxmp.html on how to get the NavigationSelectionModel
            NavigationNode navNode = (NavigationNode) navModel.getSelectedNode();
            if (navNode != null) {
                ContentNode contentNode = navNode.getContentNode();
                if (contentNode != null) {
                    pageId = contentNode.getObjectID();
                }
            }

The Servlet Request can be accessed via com.ibm.wsspi.portletcontainer.portlet.PortletUtils.getHttpServletRequest(javax.portlet.PortletRequest).

Here is a summary How-to:

There are two additional prerequisites your wedav server needs to fulfill though, in order to be able to use the web dav server as mapped network drive with the default webdav client (called Mini-Redirector) on windows XP:

• it can only use the standard http ports (80/443)
• the first path segment after the server name is expected to be the webdav root folder, e.g. http://server.name/root-webdav-folder can be embedded as network drive, but not http://server.name/path/to/my/root-webdav-folder.

On your Windows XP desktop, perform two simple steps to make webdav a fully featured network drive for your Win XP workstation (supposing your webdav server uses http basic authentication):

1) edit the windows registry (run > regedit) and add this setting
(or place these two lines in a *.reg file and double-click):

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WebClient\Parameters]
"UseBasicAuth"=dword:00000001

2) from the command line issue:

net use x: "http://my.server.com/subfolder/" myPassword /User:myUser /persistent:yes

regsvr32 /u zipfldr.dll

But running the command above is not enough to permanently disable this feature. The zipped files are no longer listed as folders in Windows Explorer folder tree when expanded, but sometimes the settings get reverted, especially when users double-click on any .ZIP file. To avoid this problem, and ensure that built-in ZIP support is totally and permanently disabled in XP, continue with the steps below after running unregistration command above.

* Run Registry Editor (RegEdit.exe in Run command), and search for Zipfldr.dll in the registry. Delete all instances of Zipfldr.dll found. There should be only one instance of it after unregistering.

* Reboot the computer system to unload the DLL from memory, in case it still persists.

* Delete or rename Zipfldr.dll file from \Windows\System32\DLLCache\ folder.

* Delete or rename Zipfldr.dll file from \Windows\System32\ folder. When prompted by WFP (Windows File Protection) saying that system stability may be affected, answer “No” or click “OK” on the dialog window pop up.

* Install your favorite ZIP program, e.g. 7-Zip, which is my preferred choice. Ensure that .ZIP extension is associated with the program.

(adapted from: http://forums.techarena.in/tips-tweaks/934175.htm => it worked well for me)

Trigger a process and let it run while you’re logging out again (see also here):
nohup <command> &
or, for being able to reattach later, start with

1. type screen and submit
2. trigger your longer-running process
3. detach with the sequence ctrl + a and ctrl + d
4. logout
5. later, when logging in again, you can reattach to that console session with:
   screen -r

for the latter, see also this tip.

Symbolic links (see also here):

• Creation: ln -s target link_name
• Removal: simply delete it using e.g. rm. It is a file of its own and deletion will not affect the target it is pointing at.

• Here’s an easy solution for setting up client-side SSL. Instead of doing the usual javax.net.ssl key store declarations and more, you can simply set one single system property com.ibm.SSL.ConfigURL to point to the ssl.client.props in the %WSADMIN_HOME%/properties folder

I have learned about this in another forum post - and after that I also found the corresponding official documentation.

It worked fine in my case and I find it an elegant solution…

• In the code sample, the MBeans are retrieved via an AdminClient using a soap connection, whereas
• if the portlets you want to query about reside on the same server, you can access them more directly via the AdminServiceFactory as described e.g. in the info center

• Container runtime options, except for javax.portlet.actionScopedRequestAttributes
• Setting of html head section elements via the MimeResponse.MARKUP_HEAD_ELEMENT property
• Custom Portlet Modes and Custom Window States
• Portlet-managed modes
• RenderResponse.setNextPossiblePortletModes(Collection)
• Set dynamic portlet titles via RenderResponse.setTitle(String)
• Support for aliases in public render parameters
• Support for aliases and wildcards in eventing
• Expiration and validation based caching

Moreover, it should be noted that some typical portal features based on the 286 portlets are emphasized to be out of scope of the specification:

• the actual wiring between portlet events, and
• the aggregation of portlets into a portal page

/**
   * Returns the current portlet session or, if there is no current session
   * and the given flag is true, creates one and returns
   * the new session.
   *
   * If the given flag is false and there is no current
   * portlet session, this method returns null.
   *
   * Creating a new portlet session will result in creating
   * a new HttpSession on which the portlet session is based on.
   *
   * @param create
   *               true to create a new session, 

   *               false to return null if there
   *               is no current session
   * @return the portlet session
   *
   */

  public PortletSession getPortletSession (boolean create);

So, in short, since when a new PortletSession is created also a new HttpSession is created, it should also hold true that if there is an existing HttpSession, the PortletSession should also already exist. This is correct as long as all portlets live in the same web application as the main portal servlet. In this case, request.getPortletSession(false) will always return a non-null value.

But consider that standard portlets usually live in multiple web applications. And each web application has its own scope for HttpSessions. In the latter case, you can only be sure that a logged-in user has an active HttpSession in the web application where the main portal servlet resides, but not necessarily in other web apps where your portlets reside. So in summary: request.getPortletSession(false) can, in fact, return null, even if the portlet can only be used by logged-in users.

It has been introduced with Java 1.5 and can also be used with the Websphere Appserver. Sander Hautvast has proposed a configuration based on a Service integration Bus.

Below, I shall outline a simpler way that also works:
1. Create a file named /my/path/management.properties with the following contents:

com.sun.management.jmxremote.port=9999
com.sun.management.jmxremote.authenticate=false
com.sun.management.jmxremote.ssl=false

2. Next, you need to edit the Generic JVM arguments of your server (via the administrative console: Application servers > server1 > Process definition > Java Virtual Machine) :
-Djavax.management.builder.initial= -Dcom.sun.management.jmxremote -Dcom.sun.management.config.file=/my/path/management.properties

3. Start jconsole from your WAS_HOME/java/bin directory and login with localhost:9999, as defined in your management.properties file (Note: not recommended for production use, since security is disabled for that port).

4. You’re done. Have a look at the threads, the memory consumption, the mbeans etc.

Normally you would think, well first you install the app and then you start it. Well, not quite right with wsadmin. If you have a large app or many apps in one bigger app (EAR), the application(s) may not have been completely extracted, when you issue your start application request.

But there is help - use the isAppReady command in between:

def installApplication (serverName, nodeName, appName, appPath):
   global AdminControl
   global AdminApp
   global AdminConfig

   print AdminApp.install(appPath)
   AdminConfig.save( )
   # important: wait for the installation to be completed ...
   AdminApp.isAppReady(appName)
   # ... before starting the app
   appManager = AdminControl.queryNames("type=ApplicationManager,process="+ serverName +",node="+nodeName+",*" )
   AdminControl.invoke(appManager, "startApplication", appName )
#endDef

The use of isAppReady may surprise as well, because normally you would check the return value in an if-clause or similar. But since this method always returns 0 (zero) you should avoid doing so. The method isAppReady basically holds back the response until the app is completely installed and that’s all we need.