groovy and ruby required when using namespaces?

[Dan Owens]

I've recently updated from Spring 2.0 to Spring 2.0.3. I'm using these
namespace declarations in my Spring Context files

<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:tx="http://www.springframework.org/schema/tx"
xmlns:aop="http://www.springframework.org/schema/aop"
xmlns:jee="http://www.springframework.org/schema/jee"
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schem...-beans-2.0.xsd
http://www.springframework.org/schema/jee
http://www.springframework.org/schem...ng-jee-2.0.xsd
http://www.springframework.org/schema/aop
http://www.springframework.org/schem...ng-aop-2.0.xsd
http://www.springframework.org/schema/tx
http://www.springframework.org/schema/tx/spring-tx-2.0.xsd">

I am now getting the stack trace below when I run my test application.
It looks like a change was made in 2.0.3 to the
org.springframework.scripting.config.LangNamespace Handler class such
that Groovy, Ruby and Bsh are required when using the namespaces above.
In 2.0 this was a conditional requirement. Am I now required to bring
in these dependencies when using namespaces or is this a bug?

(i'm running under JDK1.4 on Solaris)

DEBUG - Loaded mappings
[{http://www.springframework.org/schem...ork.beans.fact
ory.xml.SimplePropertyNamespaceHandler,
http://www.springframework.org/schem...work.scripting
.config.LangNamespaceHandler,
http://www.springframework.org/schem...ork.ejb.config
.JeeNamespaceandler,
http://www.springframework.org/schem...ork.aop.config
.AopNamespaceHandler,
http://www.springframework.org/schem...work.beans.fac
tory.xml.UtilNamespaceHandler,
http://www.springframework.org/schem...rk.transaction
.config.TxNamespaceHandler}]
DEBUG - Ignoring handler
[org.springframework.scripting.config.LangNamespace Handler]: problem
with class file or dependent class
java.lang.NoClassDefFoundError:
org/codehaus/groovy/control/CompilationFailedException
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:141)
at
org.springframework.scripting.config.LangNamespace Handler.class$(LangNam
espaceHandler.java:45)
at
org.springframework.scripting.config.LangNamespace Handler.init(LangNames
paceHandler.java:45)
at
org.springframework.beans.factory.xml.DefaultNames paceHandlerResolver.in
itHandlerMappings(DefaultNamespaceHandlerResolver. java:123)
at
org.springframework.beans.factory.xml.DefaultNames paceHandlerResolver.<i
nit>(DefaultNamespaceHandlerResolver.java:96)
at
org.springframework.beans.factory.xml.DefaultNames paceHandlerResolver.<i
nit>(DefaultNamespaceHandlerResolver.java:82)
at
org.springframework.beans.factory.xml.XmlBeanDefin itionReader.createDefa
ultNamespaceHandlerResolver(XmlBeanDefinitionReade r.java:489)
at
org.springframework.beans.factory.xml.XmlBeanDefin itionReader.createRead
erContext(XmlBeanDefinitionReader.java:478)
at
org.springframework.beans.factory.xml.XmlBeanDefin itionReader.registerBe
anDefinitions(XmlBeanDefinitionReader.java:458)
at
org.springframework.beans.factory.xml.XmlBeanDefin itionReader.doLoadBean
Definitions(XmlBeanDefinitionReader.java:353)
at
org.springframework.beans.factory.xml.XmlBeanDefin itionReader.loadBeanDe
finitions(XmlBeanDefinitionReader.java:303)
at
org.springframework.beans.factory.xml.XmlBeanDefin itionReader.loadBeanDe
finitions(XmlBeanDefinitionReader.java:280)
at
org.springframework.beans.factory.support.Abstract BeanDefinitionReader.l
oadBeanDefinitions(AbstractBeanDefinitionReader.ja va:131)


--

[lloyd.mcclendon]

yeah that is bullcrap, those exceptions should be swallowed and a simple "groovy not installed" message should be logged. whenever i have the log turned up to debug i am obviously looking for something. seeing all those stacktraces everytime always makes me think something is not right, even though it is benign.

[Dave Syer]

It *is* just a DEBUG message, so the dependency is still optional. Anyway there was already a fix 2.0.x to change this behaviour to something less alarming. Why did you upgrade to 2.0.3? Why not use 2.0.5?

[Dan Owens]

Glad to hear this is fixed in 2.0.5. We are upgrading to 2.0.3 because at the time the decision to upgrade was made, 2.0.3 was the latest version.

Having the stack trace appear is not a problem when everything is working correctly. However when trying to troubleshoot some problem which may or may not having anything to do with this, the stack trace is misleading. Especially when it did not show up in a previous version.