geoff2k

So I rebooted my laptop, and it was way slower than usual, and the only way I could get any sort of UI at all is Ctrl-Alt-Del > Task Manger > File > New Task. The Event viewer was full of Event ID 10010 messages with various GUIDs, and I came *this* close to re-installing XP when I found a MSDN blog post that describes the situation exactly, gives you a fix, but says:

At this point, we haven't got a chance to determine the root cause of this problem. In other words, we don't know what particular action ends up removing the USERS group from the HKCR\CLSID registry key and we need your help in determining root cause. If you are able to reproduce this issue at your end, we will like to know the steps you took to reproduce this issue to figure out what CAUSES this and try to avoid it from occurring in the first place. Please feel free to post your comments at the end of this blog to let us know if you have a successful repro of this situation.

It's nice to have a fix, but WTF???

From the documenting-things-I-keep-having-to-relearn-department...

For whatever reason, whenever I install a JDK under FreeBSD I always forget to install the certificates, which leads me to errors such as these when I try to use Java apps that depend on those certificates, for example, the Amazon EC2 command line tools:

% ec2-describe-images -x all
Unexpected error:
javax.net.ssl.SSLException:
 java.lang.RuntimeException:
  Unexpected error:
   java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty

The easiest way I've found of getting around the problem is:

1. download the latest version of the debian package "ca-certificates-java" (e.g. ca-certificates-java_20081028_all.deb)


2. extract the contents of ca-certificates-java_20081028_all.deb using 'ar xf'


3. extract the file 'cacerts' from 'data.tar.gz'


4. copy 'cacerts' to your JDK's 'jre/lib/security' directory (backing up the existing one of course)

Once upon a time, I would only consider OpenBSD for any Unix-y server task (NSA's internal and external DNS servers were OpenBSD-based back in the day), and grew very comfortable with the BSD environment. Some data corruption issues led me to believe that ZFS was the way to go (esp since I insist on using cheap consumer-grade equipment for my home server builds), so our two home fileservers (shigure and oogway) are both running FreeBSD 7.0 with ZFS mirrors. I'd like to use them for running "intranet" apps such as the comic release date tracker I wrote as my play-with-Rails app, but I'd also like to try some of the new scripting languages that are taking over the JVM since FreeBSD also has awesome up-to-date JVMs, hence my interest in JRuby.

Long story short, getting the then latest JRuby (1.1.3) up, running and working took a bit of work, so I submitted a patch to the port, and it was accepted.

Now to update it to JRuby 1.1.4...

I installed a bunch of IntelliJ IDEA plugins today in anticipation of the Ruby study group meeting on my new laptop (an ASUS m70vm-X1), and was trying to write some ruby scripts to follow along with the presenter. I was mainly interested in the code-completion abilities of the Ruby plugin, but could NOT get them to work... we were talking about IO.readlines, so dutifully in my new Test.rb script, I typed:

    IO.

followed by control-space.

Nothing happened.

I then started noticing strange character selectors for glyphs that I wasn't familiar with when I tried to use other keyboard functions, and it took me a full 10 minutes before realizing that the "language bar" on the vista task bar was changing every time that I hit control-space... further investigation showed that the laptop had simplified Chinese and control-space was setup as the hotkey for switching to simplified Chinese.

keywords: ctrl-space ctrl-spacebar control-spacebar

We've started a project using ICEfaces at work, and I recently ran into some warnings deploying our app to Tomcat 6.0.18:

Aug 21, 2008 3:02:48 PM org.apache.catalina.core.StandardContext
addApplicationListener
INFO: The listener "com.sun.faces.config.ConfigureListener" is already
configured for this context. The duplicate definition has been ignored.
Aug 21, 2008 3:02:48 PM org.apache.catalina.core.StandardContext
addApplicationListener
INFO: The listener "com.icesoft.faces.util.event.servlet.ContextEventRepeater"
is already configured for this context. The duplicate definition has been
ignored.

Checking our web.xml, we were most certainly defining the listeners in question only once, so what's going on?

After researching the problem, and initially assuming it was a bug (discussed under 6.0.16 here: http://www.mail-archive.com/dev@tomcat.apache.org/msg23391.html), it turns out that the warning is being generated because listeners may be defined in *both* the web.xml as well as within *.tld files. As it turns out, within our specific app, we include jsf-impl.jar (which defines com.sun.faces.config.ConfigureListener in jsf_core.tld) as well as icefaces.jar (which defines com.icesoft.faces.util.event.servlet.ContextEventRepeater in include.tld).

So even though the listeners in question are only defined in the web.xml once, because they are defined in the tld files, Tomcat issues the warning.