On 12.11.19 11:58, Kerridge, Jon wrote:
[...]
The problem is that the Groovy version when run as three separate
processes creates the error
org.codehaus.groovy.tools.RootLoader cannot be cast to
jcsp.net2.mobile.DynamicClassLoader.
This error comes from deep in the jcsp library. DynamicClassLoader uses
the Java(8) SystemClassLoader.
The code is derived from a part of jcsp which deals with class loading
in a parallel system run on multiple nodes on separate workstations.
The idea, which works, is that if a node discovers that it does not have
the required class it can go back down the chain of nodes looking for
the class file which will be automatically transferred to the node, if
it is found.
[...]
RootLoader is supposed to be used when starting Groovy in the console to
provide a stable class loading setup to it. RootLoader is not supposed
to be used in other means, because it actually violates class loading
constraints in that it prefers loading jars from a given directory over
the system/plattform loader.
What seems to happen, according to your description is that the jcsp
library expects a setup with DynamicClassLoaders, so it can identify and
transfer the required classes. Instead it finds a RootLoader and cannot
handle it. When you start Groovy in an IDE the IDE usually takes care of
setting up the classloaders, thus there is no RootLoader involved.
You can use GroovyMain to start a script and take care of the
classloader setup yourself. For example you can just add Groovy and all
the required libraries to the normal classpath and start using the Java
command through GroovyMain. Not as convenient as just starting the
scripts using the groovy command of course
bye blackdrag
