64-bit RAD 8.0.4 console and debug mode problems while running WebSphere Application Server v6.1

Question

I am running the 64-bit install of IBM Rational Application Developer (RAD) 8.0.4 on Windows 7. I have WebSphere Application Server (WAS) v6.1 running within it. To be honest, I'm not completely sure if the WAS server is 32- or 64-bit. My problems are:

1. Except for a few useless lines of logging at WAS startup, I get no logging in the RAD console at all. Not even when there's an exception thrown-- no strack trace, nothing. I cannot find the SystemOut.log file in the place that the WebSphere Properties dialog claims that it is. However, there is one in C:\Users\myUser\AppData\Local\VirtualStore\Program Files\IBM\SDP\runtimes\base_v61\profiles\was61profile1\logs\server1\SystemOut.log, but I do not know how to configure RAD/Eclipse to see it.

   I do see an Access is Denied message as the first line of what I can see in the Console. But RAD is not clear about what or whom is being denied access, and in all other ways the server works just fine, except...

2. I cannot seem to get the WAS instance to run in Debug mode. If I "Restart in Debug...", RAD complies, but the server in the Servers panel of Eclipse does not show "Degugging, Synchronized"-- it simply shows "Started, Synchronized"-- just like it would if started normally. The Debug panel in Eclipse shows the server there, and claims that the debugger is listening on Port 8001. But the application will not stop on any breakpoints.

My colleagues are running identical Windows 7 machines, but have the 32-bit RAD 8.0.4, and don't seem to have this problem. I'm not ready to concede and re-install RAD down to 32-bit, nor do I have the time. There's got to be some other solution.

Answer 1

I was able to resolve the logging by giving the LOCAL_MACHINE/Users group more permission on the file-system tree where RAD is installed (C:\Program Files\IBM\SDP\). I have found that when I run RAD "as administrator" in Windows 7, the logging problem I had went away.

Perhaps I should have done more granular analysis to figure out precisely which directory at a lower level might've needed different/more permissions, rather than changing it for all of the RAD install tree; but this works for me at the moment.

---

UPDATE 11.22.2013

I think the ultimate culprit was Windows 7 UAC. Apparently, applications installed within the default "Program Files" or "Program Files (x86)" directories receive extra security constraints when UAC is fully enabled. Running the server in Debug and the Console logging seem to need permission to modify things that Windows 7 feels like shouldn't be modified without elevated privileges. By either NOT installing RAD in the default Program Files or Program Files (x86) directories, OR completely disabling UAC, the problem is resolved. Disabling UAC could be considered risky, so the solution for me was to reinstall RAD outside of the default Program Files locations.

Answer 2

Work with the admin console and turn on the debug flag.

Start the server from the command line (not from within RAD) and the server would start in the debug mode.

Now try and debug a remote application (like you would any remote application within Eclipse) to attach RAD to this application Server.

Try and see if it works this way.

I would also try and see if the server is running in a debug mode (by looking for a netstat on the port 7777 which is the default debugging port)

HTH