Support for shared GroovyClassLoader in GroovyScriptFactory

Exposes setClassLoader method in ConfigurableApplicationContext interface as obvious first-class configuration option.

Closes gh-25177
This commit is contained in:
Juergen Hoeller
2020-06-06 13:21:20 +02:00
parent ad5710c1d1
commit 196bb6fe32
3 changed files with 27 additions and 9 deletions

View File

@@ -159,9 +159,8 @@ The steps involved in using dynamic-language-backed beans are as follows:
element in the XML configuration (you can define such beans programmatically by
using the Spring API, although you will have to consult the source code for
directions on how to do this, as this chapter does not cover this type of advanced configuration).
Note that this is an iterative step. You need at least one bean
definition for each dynamic language source file (although multiple bean definitions can reference the same dynamic language source
file).
Note that this is an iterative step. You need at least one bean definition for each dynamic
language source file (although multiple bean definitions can reference the same source file).
The first two steps (testing and writing your dynamic language source files) are beyond
the scope of this chapter. See the language specification and reference manual
@@ -578,9 +577,12 @@ If you do not use the Spring namespace support, you can still use the
<bean class="org.springframework.scripting.support.ScriptFactoryPostProcessor"/>
----
NOTE: As of Spring Framework 4.3.3, you may also specify a Groovy `CompilationCustomizer`
(such as an `ImportCustomizer`) or even a full Groovy `CompilerConfiguration` object
in the same place as Spring's `GroovyObjectCustomizer`.
NOTE: You may also specify a Groovy `CompilationCustomizer` (such as an `ImportCustomizer`)
or even a full Groovy `CompilerConfiguration` object in the same place as Spring's
`GroovyObjectCustomizer`. Furthermore, you may set a common `GroovyClassLoader` with custom
configuration for your beans at the `ConfigurableApplicationContext.setClassLoader` level;
this also leads to shared `GroovyClassLoader` usage and is therefore recommendable in case of
a large number of scripted beans (avoiding an isolated `GroovyClassLoader` instance per bean).