Category Archives: development

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.

Free trial of Maileable

For years now, I’ve been managing my email, fighting spam, and spotting phishing emails through the use of an email routing system that I developed.  The problem with today’s email system is that anyone can put email into your inbox without anything more than your email address.  Yes, you can put things like filters, whitelists, and such into the mix, but they are, in my opinion, poor substitutes for a real solution to the problem.

My email routing system has to do with putting a configurable router in between all email senders and your inbox, so that no one has free, direct access to your inbox.  The key is to give different email addresses to different email senders.  As untenable as that may sound, it works extremely well and *is* absolutely manageable.  I’ve been doing it since a trip down the Colorado River in 2003 had me panicked about missing important emails because my 10MB mailbox was going to fill up with spam.

At that time, I devised what has evolved into today’s Maileable system.  Maileable is a turn-key email routing system that anyone can use to easily route emails from different sources to different destinations including the bit bucket.  And it can’t be spoofed.

Unlike email filters that try to ascertain an email’s legitimacy based on its content and other metadata (every bit of which can be fabricated), Maileable works on the To address of an email, the one and only thing you can count on to be correct.  If it’s coming to you, you know the email address it was sent to.  And that’s the only thing you need to know with Maileable.

This is the only system that works within today’s SMTP protocol and doesn’t rely on hope.  Filters make you hope that they catch the bad stuff and let the good stuff through.  Validation systems make you hope that the people and automated systems that send you email will go through the trouble of validating themselves to get past them.  Maileable is a solid system that puts the power in the email recipient’s hands, which is a place where it has never been before with SMTP.

The Maileable beta is now available for anyone to try.

The functionality is about 95% complete, but there are a few cosmetic improvements to be made.  Things will get prettier.  New and powerful features will be forthcoming, as well.

To understand what Maileable is and how it works, read the free Getting Started guide from https://www.maileable.com/GettingStartedWithMaileable.pdf.  It will walk you through the entire process in detail with dozens of screenshots.

If you’re a Windows user, you can download the free installer from http://maileable.com/prog/maileable-installer.exe.

If you use another operating system, I’m going to have to do some more research and coding before your version is available.  It would help me to know what operating system you use, so that I can prioritize my efforts.  If you want to weigh in on this, please send an email to Maileable support with your platform preferences.

I am eager to make this system widely available, so please feel free to tell others about the free beta.  I sincerely believe this is an important tool for protecting your identity, making your email work for you, and keeping you efficient.  It has certainly been all of that and more for me.

When it comes time to pay for this service, around late June, I will be offering irresistable pricing to beta testers, so please try this out and help me confirm that it works for you.  Stay in touch if things go wrong by emailing Maileable support.  And I’d like to hear your feedback, good or bad, so that I can tweak and adjust to make this the best possible product.

Symlinks for Windows

One of the handiest things I learned at No Fluff Just Stuff this weekend was from Neal Ford, who showed a way to set up soft links (symbolic links, symlinks, it’s all the same idea) in Windows. This allows you to install different versions of JDKs, Tomcat, Groovy, Grails, JRuby, whatever, and use the latest version without having to change anything but your symlink.

For example, you can install Groovy 1.0 into c:\sw\groovy-1.0. Then create a symlink at c:\sw\groovy that points to c:\sw\groovy-1.0. Set up your GROOVY_HOME and your Path to also point to this symlink. Now, when Groovy 1.1 comes out, you install it in c:\sw\groovy-1.1. Then, simply change your symlink to point to c:\sw\groovy-1.1, and you’ve got an instant, machine-wide upgrade! If anything goes wrong, you can easily change the symlink back to the 1.0 version, and everything goes back to the way it was before.

This is the kind of thing that Unix, Linux, and Mac users have been doing for years. The one drawback to the Windows version is that you can only symlink to directories, not to individual files. Not the end of the world, but a limitation to be aware of.

You can download the free utility from the great SysInternals site, where you can find dozens of other brilliant, free utilities. The symlink utility is called Junction and can be downloaded here.

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.

Delphi for PHP

I remember when Delphi 1.0 came out.  It was what I had been looking for for several years.  At last, I could build Windows apps without all the pain.

And now, there’s Delphi for PHP.  It’s what I’ve been looking for for several years.  At last, I can build web apps without all the pain.

Since Turbo Pascal 1.0 in 1983, I’ve been using Borland products to be a more productive software developer.  I love you, Borland!