Custom telnet Groovy shells – version with shared context

A follow-up to the previous postcustom Telnet shared Groovy shells. This time having shared context for all shells, i.e. shared variables!

The trick was to get Binding object from current Groovy shell Interpreter and pass it in constructor to Groovy shells that we instantiate programmatically on socket connections. Not sure if it’s thread safe BTW (this isn’t production ready (-: ).

The code is based on Groovy Shell internals a bit, so should probably be run only from Groovy shell. (And just in case – I’m using version 1.8.4 of Groovy).

In any case, here’s again some demo video:

UPD: Also there’s the thread-safe version.
In it each shell will have it’s own Binding object, i.e. separate variables context.
But on creating shell we’ll inject two variables into that context:
sharedConcurrentMap – an instance of ConcurrentHashMap which will serve as thread-safe shared context for all shells, and is pre-populated with “server” and “sockets” (the latter are also made thread-safe);
thisShellSocket – a socket that is used for this child shell.

See source code at the end of the post.

As usual, a little demo video:

The source code Continue reading


Checking out Groovy…

It’s a quite typical architecture for Java webapp to have Apache Velocity as templating engine that handles the View part of your MVC.

Well, having worked for a while with it and checking out Groovy now I immediately felt it’s be very interesting to have Groovy there instead of Velocity.

Velocity is sensibly weak in working with arrays and lists. But Groovy on contrary adds more power and convenience in this aspect. And doesn’t seem to be lacking in any other.

It seems someone in 2007 already though about this:

And even more – Grails, the Groovy framework, is actually based on Spring MVC, although this is a bit too much compared to just having Groovy scripts as “views” in Spring MVC.

All in all, it sounds like a good ting to try out.