Hi all,
In the past few weeks i have been working on a new set of scripting modules based on jsr 223 and the javax.script api. I know there has been interest around this from many parties so i wanted to share what i have been working on. Eventually I would like to dd it as a community module/extension but for now i think i prefer to just work in git.
The idea is that his new module would eventually take over the scripting modules we currently have , namely:
community/
python
scriptlet
The way I have things structured currently is a core module, and then a module for each language. It breaks down like:
communtity/
script/
core/
bsh/
groovy/
js/
py/
rb/
The new module is designed much like the existing python scripting module that revolves around the idea of providing “scripting hooks” for various extension points. Currently i have only implemented the following hooks:
- wps process
- filter functions
I plan to continue to port from the old python module and add additional scripting hooks:
- output formats (GetMap, GetFeatureInfo, GetFeature, etc…)
- datastores
- etc…
The idea is that most of the code to handle a hook will live in the core module leaving nothing to do for a specific language other than adding the language jar (and script engine jar in cases where it is not included in the core language jar).
However the idea is also to support specific customizations for those languages that can support it. For example geoscript. Since python, groovy, and javascript have geoscript bindings they would want to utilize them say for instance when invoking a process hook. Instead of passing in a raw geotools feature the idea would be to wrap it in a geoscript feature before calling the process.
There is also a rest api that allows for various functionality. The first is to invoke a simple script over http so you can do something like this:
curl -G “http://localhost:8080/geoserver/script/foo.py”
The interface to the script is a simple one, define a function named “run” and have it accept a request/response object. For example, with beanshell:
foo.bsh:
run(request,response) {
response.setEntity(“Hello World!”)
}
However, this would be the default interface, each language would have the ability to customize this. For instance, with python there is already the WSGI standard for an interface for web applications. So in that module we would want to customize and support that:
foo.py:
def application(environ, start_response):
start_response(‘200 OK’, [(‘Content-Type’, ‘text/plain’)])
return [‘Hello World!’]
Also there is an api for creating and persisting “sessions” on the server, that is script engine instance that will persist state across different calls. The idea here is to be able to interact with scripts on the server via remote clients. For example, for the python extension I have written a client based on this session api that i can invoke from my terminal. The client mimics the regular python shell, but is actually executing on the server side. ( Obviously all of this would be secured by default and only available to the administrator 
)
Let me know what you think, the code is in a branch called “scripting” in my github repo:
https://github.com/jdeolive/geoserver/tree/scripting/src/community/script
-Justin
–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
) to dig into the datadir and delete some XML when I botch a REST request and have GeoServer telling me that I can’t create a layergroup because it already exists, but can’t delete it because it doesn’t exist, I think that we are asking for trouble by encouraging scripting against the catalog while the catalog’s validation is at its current level of completeness. Remember, by enabling scripting we are basically asking for developers to start developing against GeoServer who have no idea how to use a Java debugger or read a stack trace.