Category Archives: ruby

org.apache.bsf.BSFException: unable to load language

I’m jazzed about creating a JRuby DSL for message manipulation in SonicMQ/Sonic ESB.  No time to go into the details right now, but I ran into a problem that I couldn’t find an answer for.  Maybe this will help the next poor soul…

I was able to run this service on my laptop without any problem, but when I tried to distribute it to others, it wouldn’t work.  So I went back and tried to deploy my XAR to a clean VM, and I kept getting org.apache.bsf.BSFException: unable to load language: ruby.  It didn’t make any sense, because it ran on one copy of Sonic, why not the other?

Well, after a lot of Googling and head-scratching, I came to the realization that I was running my laptop container on Java 5, while the clean install on the VM was, by default, using Java 1.4.2.  Once I changed the VM container to Java 5, the problem went away.

One of the coolest things I’ve ever seen in code. Ever.

I went to the Atlanta Java Users Group (AJUG) meeting on Tuesday night. The speaker was Jeff Brown of Object Computing, and the topic was Groovy.

I’ve been dabbling with Ruby, Groovy, and JRuby, for quite some time now. (Among other things, I’ve created Ruby and Groovy services for Sonic ESB.) I’ve never been a fan of Java as a language, but I’ve always thought it was a great platform. These dynamic languages take me back to the days when C and C++ allowed for great creativity and real power in software. I’m starting to feel excited about the ability to innovate in software, once again. Java is so tedious and restrictive in comparison. Great things have been done with it, but that’s mostly in spite of it, not because of it. And the complexity of all the frameworks is a result of the tight leash the language puts on you.

Not unlike Java, Groovy has not had the greatest smell to me, nor to Steve Yegge. I prefer the Ruby syntax, the Ruby style, and the Ruby community. (Yes, for me, why is a large part of the appeal of Ruby. The guy is brilliant.) Groovy is poorly documented, pretty dry, and seems like a bad derivative of Ruby. Just as Java is a dumbed-down C++, Groovy feels the same to me, with regards to Ruby.

However, I have to give kudos to Jeff Brown for doing a great job of showing Groovy in a great light last night. As much as I’ve read about and tinkered with Groovy, Jeff was able to demonstrate some very powerful constructs that I was not aware of. (Hence my poor documentation comment.)

One of the most amazing things I’ve ever seen done in software, something only a geek can appreciate, was Jeff’s demonstration of Groovy stubs. He set up the demonstration this way:

Suppose you have a class that checks for the existence of a file on the file system, and you need to isolate that test for a unit test. The problem with this class is that it was written such that you pass in a String, which is the full path and filename of the file, and the file’s existence is tested within the class under test. This is a problem for unit testing, because the Class Under Test (CUT) has a built-in dependency on the file system, and therefore, so does the test. You cannot test the class without setting up the filesystem to support the test. It’s complex, unwieldy, and not very portable.

As Jeff presented this problem, I couldn’t see how Groovy was going to be able to help. It seemed pretty insurmountable. I mean, the call to File.exists is sitting within the Java class. All you’re passing in is the String that identifies the file. As George Costanza would say, you’ve got no hand! How are you going to get hand?!

Well, I’ve already given the answer away: Groovy stubs. But, still, what does that mean, and how does it give you hand?

What you do is tell the stub how you want it to react to the method calls coming from the Java class under test. Still, you’re wondering, what does that accomplish? It’s not calling my stub for File.exists, it’s calling the File class for that!

What you do is wrap the invocation of the unchanged class under test in the stub, so that the stub can intercept the call to File.exists and respond the way you want it to, rather than the way it actually would if it were called. I don’t have the exact syntax (see, more documentation shortcomings), but it looks something like this:


// WARNING - pseudocode -- will not work
// create a stub for the class under test
def myStub = new StubFor(ProblemClass)
//define what you want the result to be
myStub.demand.exists { return true; }
//then call the method under test
myStub.use {
assert true == ProblemClass.updateFile()
}

When you run this test, the stub actually intercepts the call to File.exists and responds the way you told it to, without ever making the call to the File.exists method. File system dependency neutralized.

How often do you see software that acts that much like real magic? You’ve got to admit, that is beyond your expectations, really clean, and very cool.

Now, I realize that Groovy is making use of proxies, and that JRuby could certainly do the same thing. But you’ve got to give props to the Groovy team for something really slick and powerful.

More importantly, I found this to be an eye-opener, an exciting indication of what’s possible with these new dynamic languages. Whichever language you choose, a whole new world of power and creativity have made themselves available. I used to do very cool things with C function pointers and the C++ preprocessor. Now, I can see that there is once again the opportunity to work magic. The long, dark winter of Java is coming to an end.

What an accomplishment!

Who ever would have thought that moving a blog could be such a major endeavor?!

For about three years, I’ve been running my blog on Pebble, a Java-based web app, running in Tomcat. For some reason, though, Pebble sort of lost its mind many months ago. I’ve been unable to post, or I could post and it would then vanish. My catalina.log file is loaded with stack traces from Pebble. Sometimes they come every few seconds. You can imagine how that adds up over months.

So, temporarily, I started blogging at another site, http://urlinone.com/blog, running WordPress. And in my Pebble template, I put a big header that said my blog had moved. Ugly.

Over the last couple of months, I’ve been slowly dealing with this issue. The first problem was moving all the Pebble posts to a new instance of WordPress. Unfortunately, they have completely different URL schemes, so, even if I could move all the posts, all the links out there in the world would now point to pages that WordPress couldn’t serve. Enter Ruby.

I used Ruby to spider my own site, creating directories and HTML pages to mirror my Pebble blog. This was complicated by the fact that, as I mentioned, Pebble had lost its mind. So, many pages that should have had content actually did not. And the links were, therefore, missing, as well. So my spidering effort ended up being a multi-step process of spidering a bunch of smaller, disconnected webs, rather than one big one. I also took this opportunity to zap all the spam comments, so they didn’t end up in my legacy blog.

At last, I uploaded all these now static blog pages up to my web host, so that all the old URLs will still find a page present (albeit static). Unfortunately, I forgot to remove the “This blog has moved” header from all the static pages, so I’ll have to go back and take care of that.

Next, I had to do an export from the temporary blog at http://www.urlinone.com/blog, so that I could import it into the soon-to-be new WordPress blog for http://www.leegrey.com/hmm. That, I’m happy to say, went very smoothly. One interesting note… My first export was done before deleting all the comments that Akismet had caught. It was 237KB. Then I deleted all the spam comments and did another export. 38KB. Sheesh! If only I was as prolific as the spammers.

Now came the real fun. I had to figure out how to modify the DNS zone file for the web host where Pebble is running, so that I could essentially split my domain. I only wanted to move my blog to the other web host running WordPress. All my other subdomains and my email, FTP, SSH, and such needed to stay put. I had never tried to do anything quite this sophisticated in a zone file before, but I spent some time learning about DNS, and it turned out to be pretty easy. The key was discovering that CNAMEs are basically aliases for A records.

All I had to do was create a couple of new A records for leegrey.com. and www.leegrey.com., pointing to the IP address of the server hosting WordPress. Everything else was using a CNAME that didn’t seem to be affected by my changes. The most confusing part was the fact that there was a record identified as @, which, in this case, represented leegrey.com. I was afraid that everything was going to break when I changed that to point to the foreign web host. It seemed like moving the root of a directory tree, so that everything below it would also be moved. Fortunately, I was able to simply comment out the A record for the @, explicitly define the two new A records, and the rest stayed as is. So far, it all looks okay. My only concern is the propagation delay with DNS changes. I’m not sure if I’m seeing cached info that will break in a couple of days. I’m most worried about my MX records being hosed and my email suddenly going silent.

All I can say is, it was fun using Pebble for a while. And I’m so happy to be on WordPress now! It’ll be a long, long time before I change blog software again.