Only four scripting languages are available out-of-the-box in Mule and Spring. It's a good design and support decision: all four have large user bases, good documentation, and popularity across many problem domains. There may be cases, however, where a non-supported language is desired because: * The implementers want to leverage an existing code base; or * Problem domain expertise is available in a different language (e.g. Scheme) that the app server developers lack; or * There is a definite time-to-market advantage when using a language that isn't available in Mule/Spring This need to deploy a new, different scripting language in the app server requires understanding all the nuances of JSR-223 and 3rd-party language integration. Just dropping the new language run-time in the class path isn't enough. This guide shows what to do and what to avoid using SISC Scheme as an extreme integration example. Though the article examples are from Mule and MuleStudio, the content applies to Spring 3 (the foundation under Mule) and any other non-trivial Java app container.