A Groovy shell embedded inside the CAS server overlay.
This is an instance of the Groovy interactive console that is embedded inside a CAS server overlay. The shell is fully aware of the CAS application context and API and is also able to load custom groovy scripts which may want to peek inside the CAS configuration, invoke its API and perhaps report back various bits of configuration about CAS.
There are no hard dependencies on the CAS server. The shell may be extracted to be used with any Java web application.
<cas.version>3.5.2</cas.version>
<groovy.version>2.1.7</groovy.version>
- Execute
mvn clean package
at the root project directory. Copy thetarget\cas.war
over to the server container, and also copy the contents of theetc
directory over to/etc/cas
.
or...
- Review the
build.xml
file for environment settings, and then simply executeant deploy
which will entirely automate the build/deployment process.
...and start the container.
The shell is simply a wrapper around the Groovysh
tool that is able to respond to client requests by
launching a separate thread for each. In the groovyShellContext.xml
file by default, the groovy shell
service listener component on the server side launches on startup and binds on the port 6789
:
<bean id="groovyShellService" class="com.iterative.groovy.service.GroovyShellService"
parent="groovyService">
<property name="socket" value="${groovy.shell.socket.port:6789}" />
<property name="launchAtStart" value="${groovy.shell.launch.startup:true}" />
<property name="customScriptsLocation" value="${groovy.shell.scripts.path:/etc/cas/scripts/" />
</bean>
..which means that in order to connect, you could:
- Use Telnet:
telnet localhost 6789
(You may have to turn off local echos) - Use Putty with the following configuration:
- Connect to
localhost
and6789
- Connection Type:
Telnet
- Close Window on Exit:
Never
- Telnet Negotiation Mode:
Passive
- Session Logging:
All Session Output
- Connect to
Successful connection attempts should present the groovy shell prompt, that is:
Groovy Shell (2.1.7, JVM: 1.7.0_25)
Type 'help' or '\h' for help.
--------------------------------------------------------------------------------------
groovy:000>
By default custom groovy scripts are loaded from /etc/cas/scripts/
. You can change this of course by the customScriptsLocation
setting as is shown above.
The following variables are available to the shell automatically:
- All beans that are registered with the application context. In other words, every bean that is registered with CAS application context inside its XML files is available to the console, except of course those that cannot be instantiated, such as abstract beans.
- The output stream
out
variable. - The application context
ctx
variable
Extra bindings may also be provided in the groovyShellContext.xml
file, such as:
<bean id="groovyService" abstract="true" init-method="initialize" destroy-method="destroy">
<property name="bindings">
<map>
<entry key="variableName" value-ref="refToSomeOtherBeanId" />
...
</map>
</property>
</bean>
-
Use
help
to learn groovy shell commands. In particularshow classes
,display
,history
andload <groovy-file
are extra helpful. -
Directly interact with the bindings. For instance you may inspect the
ticketRegistry
bean:
groovy:000> ticketRegistry
===> org.jasig.cas.ticket.registry.DefaultTicketRegistry@bc1fe6
All beans and their public APIs may be used by the shell to interact with the application context.
The shell by default will compile and load all groovy scripts that are found at the customScriptsLocation
path.
Scripts are loaded by their class name and added to the shell binding collection. A sample CasVersion
is provided
that shows how a groovy script, with access to the application context may report back results about the webapp:
groovy:000> CasVersion.run(ctx)
CasVersion.run(ctx)
===> CAS version: 3.5.2
Ticket registry instance: DefaultTicketRegistry
groovy:000>