Web conferencing is fun. One-to-many web conferencing is even more fun, as you can concentrate on performing (taking the role of an instructor) or watching that single speaker (if your participating as a kind of “student”). That is – *if* you can concentrate on the speaker and everything is working. But to get there is not always as easy.
Blackboard Collaborate is a widely used platform for i.e. web-based education, and if you’ve booked SuSE/Novell online courses before, you’ve most probably had to deal with their “Blackboard Collaborate” solution. Unfortunately, Blackboard doesn’t support SUSE Linux out of the box – be it SLED or openSUSE. So when you hit their test page, you’ll be greeted with that nasty red indicator: Your OS could not be detected and is unsupported. On the other hand, having installed OpenJDK makes that same page tell you that you’re running a supported version of Java WebStart (1.7.0_51, in our case). So why not go on and try?
Your browser will download the starter file (meeting.jnlp) and prompt you to open it using the OpenJDK webstart application. (Of course, if you’ve turned off the option to get asked every time, it’ll run “javaws” directly.) You’ll see OpenJDK display it’s logo, download the required files from the web and start the actual “Collaborate” application. If your system is configured (and permitted) to access the Internet directly, everything will be fine from here on.
But in our case, corporate policies require all traffic to go through a controlling proxy system – based on Squid 2.7.STABLE5, as it comes with SLES11SP3. We’ve so far didn’t have any serious trouble with it, and it doesn’t even require an individual authentication – nevertheless, initial connectivity tests run by the “Blackboard Collaborate” Java applications failed and no obvious problems could be found in any logs.
Looking through the configuration settings of the application, we noticed that there are several different ways to set up proxy support (“launcher-based”, “direct connection”, “SOCKS4/5”, “https proxy”, “http proxy”, “http proxy (half duplex)”, “http direct” and “http direct (half duplex)”). No matter how we set it up to access our internal proxy – either we received time-out errors (https proxy) or “broken pipe” errors (http proxy). Drilling a hole through the firewall and permitting direct access to the Blackboard servers did immediately help, though. So it could not be the JRE, could it?
After much tracing, fuzzing around and looking for advice on the Internet without getting anywhere, a fellow user mentioned that he’d seen some problems using OpenJDK with Elluminate and thus having switched to Oracle’s Java implementation.
Guess what? After downloading and installing the latest JRE from Oracle, everything worked like a charm. We did have to select “https proxy” mode though, which does sound a bit strange (since our proxy URL explicitly specifies HTTP).
I cannot tell if it’s a problem caused by some strange implementation in OpenJDK or if it’s actually some weird coding done inside the Blackboard application – but I suggest that if your Java application fails with similar symptoms, give the Oracle JRE at try.