So there — Iñtërnâtiônàlizætiøn.

I’ll leave the RTL test to someone braver.

wob, bow

The javascript in the buttons will walk all the elements in the page and set the foreground and background, reset link colors for normal and visited links and should be cross-browser, but I only really use ff, so ymmv.

The issue is that sometimes the ruby context is being duplicated. So we get this type of behavior:

=> i=5
5
=> i=6
6
=> i
6
=> i
5

Now it I have finally figured out that all of this takes place with one instance of emissary.scripting.RubyConsole (my object that adapts into Jruby and sets up theglobals I want the user to have access to), one instance of org.jruby.javasupport.bsf.JRubyEngine that gets set up through the BSFManager code, one instance of org.jruby.Ruby naturally since there is one private instance of it inside JRubyEngine.

Once I started looking at the code in org.jruby.Ruby and seeing ThreadLocal and ThreadContext type of things, a little light bulb went off somewhere in the North East corner of south west North Dakota. So I changed all of my log4j output formatters to add the %t directive which is the thread name. I am serving up access to the JRuby console over an AJAX enabled web-page using my own high-performance MVC code run by Jetty. As soon as the thread name comes out, here is what we are getting:

31 Dec 14:27:23 DEBUG JettyListenerPool-10 – – eval(’i=5′) => 5 [java.lang.Long]
31 Dec 14:27:45 DEBUG JettyListenerPool-11 – – eval(’i=6′) => 6 [java.lang.Long]
31 Dec 14:27:56 DEBUG JettyListenerPool-11 – – eval(’i') => 6 [java.lang.Long]
31 Dec 14:27:57 DEBUG JettyListenerPool-10 – – eval(’i') => 5 [java.lang.Long]

The highlighted item is the thread name. The order is not important. The number of different values I can get assigned to a variable named “i” is not important either. It all depends on how busy the Jetty server is and how many threads it decides to use in answering the HTTP AJAX requests coming in. As many threads as there are is how many different values for “i” that can be stored and retrieved.

Something is amiss in thread-local land.

I’m finding this code a little hard to follow. I’ve read several of Charles’s posts from 2006 on the performance considerations and looking up the context. I am continuing to hunt for the underlying reason for the several contexts and what actual object is being created on each thread. Without a fix for this I really cannot see how the JRuby console idea through BSF can be adapted to the web server environment.

Update: Here is a comment from ThreadService that looks interesting:
// Must be called from main thread (it is currently, but this bothers me)
mainThread = Thread.currentThread();

Hmm. I guess that bother’s me too. Since the first time I call it, the call is coming from any one of my Jetty listener threads, and there is nothing special about it. I can’t see any other way around this at the moment. But it’s comforting to know it might bother someone besides me.

But there is a small problem that is driving me bonkers.

Sometimes, more often while debugging something and doing a Shift-Reload on the JRuby Console web page, but sometimes without that — I get TWO JRuby environments and the interactions using AJAX alternate between them. Like this:

=> i=5
5
=> i=6
6
=> i
5
=> i
6

This doesn’t happen all the time and I really don’t know what is going on. There could very well be some fundamental thing about the Bean Scripting Framework’s BSFManager that I just don’t grok. In fact, after looking into the BSFManager a little, I’m worried about the multi-threaded nature of running that inside the emissary node. We could have multiple users each creating a JRuby console which could be living on separate HttpSessions. Should be ok as far as all of my code goes, but that BSFManager factory/singleton is starting to look suspiciously like an anti-pattern I once knew.

Today I dropped bsf.jar and jruby.jar (1.1b1) into the Emissary P2P Workflow project’s lib directory. I wrote a few dozen lines of java to set up jruby as my ruby scripting language in the framework, create a context to run ruby in. I wrote few more line to hook all of this into our custom high-performance MVC system and now we have a Ruby scripting console served up by Jetty, protected by our normal J2EE security mechanisms. The initial context gets a load of all the important objects inside an emissary node via BSFManager.declareBean. This makes them available as globals in jruby (duh, once you remember to put the “$” in front on the ruby side).

While adding the important object from the Emissary namespace into the JRuby context, some of the object names we were binding things with turned out to be not-so-great for use in Ruby. So here is the little regex that we ended up using to clean up the names and make them nice.

key = key.replaceAll("[-'\"?><{\\\[\\]&$!@#^*()+=]","");

A little css, some MochiKit and how I have an Ajax-enabled JRuby window into running Emissary code served up by our own embedded Jetty. The power this is going to unleash is hard to fathom at the moment but the ideas are coming fast and furious.

So we had a discussion (he’s not a software developer at all) about unit testing, codebase confidence, code coverage, test-first, and so forth. Nice. But it took him about 4 seconds to look over at the Clover chart and say “You’re not doing so well, huh?” I came up with some medium-lame explanations about how things in that initial view are divided up into components (java packages) and that I know some of the packages are more important than others. After bringing the codebase from basically no tests coverage to 45% coverage in the last year, it was a snap back to reality. 45% code coverage is not bad, really. I’ve been snooping at some large OSS projects that use Clover and we are up there with the big boys. But there’s a long way to go. And face the facts man: if you exercise some code but don’t assert the right stuff, you might as well not be doing anything at all.

So I explained a little more about code coverage to the boy and showed him how Clover allows me to drill down to the class and see where I need to write more tests. I showed him how the counts on the left show how many times each line was executed and that the red background means it didn’t get tested. It took him 1.8 seconds to notice an “if” statement that had an execution count greater than one but was red. So we had to have a discussion about execution paths.

Pretty sharp kid.

Here is some pretty straightforward, unobtrusive javascript that you can include
in your page that will intercept shift-clicks and make them work. If you click
the first item in a list the shift click some item farther down the list, everything
in between is filled in for you. You don’t have to do anything except include the
javascript file in the head section of your page. All checkboxes on the page
in groups of more than one are automatically taken care of.

When javascript isn’t enabled or the browser doesn’t support what we are
trying to do here, the checkboxes should all work just as they normally do.

Here’a an example with two groups of checkboxes.

Get the source

One or two caveats about this. When checkboxes are filled in automatically no other
javascript handlers are called. This situation might be detectable and fixed, but that’s
not clear at the moment. Also, if your checkboxes already have onclick handlers for
something they are going to be wiped out and replace. That could use some work
as well.

To use this feature you have to

• Give your table an id and add exptable to its classes.
• Use thead and tbody to separate headers from content
• Declare one column in the header row to be of class expcontrol
• Grab the javascript, css, and two images and include them in your page

Here is a little table to fool around with to get an idea of how it works.
The onclick handlers in the header control column and on the summary
rows are all added dynamically, as are the image backgrounds for the
control cells, and the titles.

Comments welcome. It still has a few imperfections, one place where the
control column is hardcoded to be column 0. I may fix that later on.

The principle of unobtrusive javascript has been around for a while, and the old sortable html table thing has been used all over the place. This version has been updated to

• work with tables that use thead and tbody to separate header rows from content rows,
• works with tables that use odd/even styling for the data rows,
• it has a fix for Safari browsers,
• and it can use different sort types instead of the built in Javascript sort. Notably, the merge sort is
  a stable sort that is pretty fast.

So, cut to the chase, I hear you saying. Alright. Here is a table to play with.

The reqiurements for using this are:

1. Give your table an id attribute
2. Give your table a class sortable
3. Use thead and tbody in your table for header and body rows
4. Include the sorttable.js javascript in the head of your document
5. Optinally grab the sorttable.css and include it as a starting point for your stuff.

What, you were expecting more steps? Well you can set the sort type, change the
arrows, add odd-even styling to the rows and more. UTSL for that, man.

This page also includes a nice little trick to do logging when in a sort of debug mode.
To turn on the logging, you just include a textarea on your page with an id of logarea.
Like this:

When the textarea is present, log messages will be added to it. When it’s not there,
nothing happens to the log messages.

Thanks, ssf, for the nice image in the header. It’s Lake Powell, Arizona with the water level 80 to 90 feet down from when I visited there as a teenager in 1978.