The current view from my desk
This is a room with a view
[video:youtube:tcliR8kAbzc]
Got an email from Linkedin saying:
Rune, congratulations! You have one of the top 10% most viewed LinkedIn profiles for 2012.
They have 200 million profiles so I my first reaction is “yeah, rrriiighht!” And then they want me to share the below text on Twitter, FB and such:
Hurray! I have one of the top 10% most viewed @LinkedIn profiles for 2012. http://www.linkedin.com/pub/profile/0/70b/01b
Confusing, first time I tried the url I got this profile http://uk.linkedin.com/pub/odi-nanka-bruce/0/70b/1, but now it is pointing to my own profile. So maybe it is true, and then either
After having successfully installed Workplace XT v 1.1.5.0 applying FP1 of Workplace XT, version 1.1.5.1 fails. The error message showing in the Install Shield is plain and simple, that is meaningless: null. In the log file I found “JVM_HOME = null”.
Reported this as a PMR which helped me solve the problem. Simply just uninstalled v 1.1.5, then installed 1.1.5.1 since it is a cumulative fix. Info from IBM:
The Workplace XT 1.1.5.1-WPXT-FP001 fix pack installs a new, complete Workplace XT 1.1.5.1 system, or upgrades an existing Workplace XT system. Workplace XT fix packs are cumulative; each fix pack contains the base release and content from all previously released fix packs.
So seen, it would be possible just to scrap the existing installation including the registry path and install Workplace XT 1.1.5.1 directly.
Had an issue today after having installed the application engine and then the latest fixpack. WebSphere reported that the application started just fine, but when accessing http://my_server/Workplace it failed with a NullPointerException. Part of the stacktrace
[07.02.13 18:10:45:986 CET] 0000002e SystemOut O Loading logging config: null
This was in test, in the dev environment where it is working SystemOut.log reported
[2/7/13 18:39:24:274 CET] 00000043 SystemOut O Loading logging config: D:\\AEShare\\FileNet\\Config\\AE\log4j.properties
After a lot of cursing it turned out that the problem was caused by Windows and access to the share where the log4j-file was located. As a wild guess I granted access to “Everyone” and voila…it worked…Windows shares…simply hate it. WebSphere running as local system account, did not cause any problems in the dev environment, but test…don’t know why yet.