Using wadm in Sun Java System Web Server 7.0 (part I)
By blue on Jun 25, 2006
As you may have noticed, the Sun Java System Web Server 7.0 came out with a revamped command-line interface that incorporates a scripting
This scripting framework is based on JACL a java-vm implementation of the TCL language. During the start of 7.0 effort, multiple
languages were evaluated to provide the scripting solution that we wanted. The Application server even had their own home grown
solution called asadmin that provided a very skeletal interface to command invocation (I wouldn't call that a language yet.)
We were looking for the following features so as to make the use of our scripting interface painless for the users.
- We needed to provide the same kind of interface both as stand-alone command
line and also asexposed to scripting with in the language environment. This
meant that the language needed to be as close to the shell scripting syntax
the shell scripting environment than with any other language.
2. Most of our enterprise customers have home-grown solutions that rely on configuration files and shell scripts to achieve large scale clustering.
Attention was paid to the mouldability of the language to emulate these systems so that the barrier of entry would be low for our
3. We needed a powerful system that ran on top of JVM, (did not have the resources to create or adapt any new language
to the jvm platform)
4. A system that would allow us to hammer out simple scripts for simple tasks, and also keep its cool on complex tasks was felt to be
the need of the hour (especially because our largest customers had to write very complex solutions to maintain their farms) We also
wanted to support only a single language since having multiple languages would fragment the users and the community using the wadm.
We evaluated the following based on these guiding principles.
Languages we looked at\* scheme (jscheme)
\* python (jython)
\* ruby (jruby)
\* shell (various _sh)
The first one we looked at was asadmin, one because we had lots of in-house expertise on it, and second, it was already being used in
one of the sister products. Sadly it fell far short of most of the requirements.
The various shells like bash,zsh,ksh,csh started out as favorites because they had the shell syntax (well, they are the shells). but did not
make it due to the unavailability of a jvm implementation.
The same was true of perl.
python was a hot favorite of AppServer folks but did not make the grade because it made exchange of simple scripts needlessly difficult
(the indentations have a way of getting lost when you copy/paste your scripts to or from emails or web pages). Its strict philosophy was
also a slight turn off.
groovy was very interesting since it took the pain out of using the java libraries but that very same feature worked against it. While it may
be very comfortable to pick up for developers who are used to the java syntax and API, we were not very sure that the sysadmins were
going to do like it. If possible we wanted to hide the jvm underneath at least for common tasks.
The same was true of beanshell too.
'discover the features as you use' feel to it. It was obviously well suited for doing smaller scripts. Looking at its large scale features to
It had a very open prototype based inheritance which was much easier to use than many other languages, Allowed
all the features of dynamic languages including redefining the methods and classes at run time, It is very clean, and easy to maintain.
like co-routines, interesting uses of objects and iterators, mixins etc.
It also has a very clean and consistent syntax. Stitching up small languages for use in configurations and other server farm administration
tasks are also pretty easy in this ruby.
jscheme was also ruled out as it was markedly different from the shell/perl world that our end users are in currently.
Then we evaluated jacl (TCL), some of the things that we immediately attracted us were,
1) It had the closest to the shell syntax that we can find on top of a jvm.
2) Language with the fewest number of rules (right there with scheme) It has a simple primitive, the command. no special cases
any where, and another simple data structure the list.
3) Very high redesign capabilities (You can create your own language with it) Macros if you need them, create your own
primitives, redefine syntax etc.
4) Interesting and few primitives (even lower than scheme) means you can pick it up in half an hour.
5) max late binding to be found any where.
6) Availability of an existing vm based language so that we can utilize java api's in a pinch.
7) an existing event driven model that may come in handy
8) clean code with consistent interface.
(as far as we were concerned) were
1) Richness of syntax.
for the audience we were targeting.
2) No built in OO, but this could be rectified the same way it is done in CommonLisp/Scheme if necessary, since the language
allows itself to be extended quite heavily (incrTcl being an example).
3) Absence of interesting things like closures, continuations etc. (These cant be done in tcl even by extending it, while both ruby
Considering all the three, the main deficiency was 3, but considering other advantages, we decided to go for TCL
(or jacl - its jvm implementation.) the clinching argument was that the command lines would look exactly same in a stand alone
mode and within the jacl environment.