Category Archives: plugins

Spring Python 1.0.0 (RC1) is finally here!

This is an exciting day. The first, production-ready version of Spring Python is finally here. Version 1.0.0-RC1 is out. You can download from the official site, but if you are having trouble, you can go directly to S3, and grab 1.0.0-RC1. Please visit the official website at, where you will find links to up-to-date documentation, support options, and anything else you might need. Please click here to check for any dependencies you may be missing, so you can in turn download and install them.

Be sure to grab:

  • springpython-1.0.0-RC1.tar.gz
  • springpython-samples-1.0.0-RC1.tar.gz

You DON’T have to install the springpython-gen-cherrypy-plugins!!! See later section for the reason why.

What is Spring Python?

For those of you new to this project, Spring Python takes the concepts implemented by the Spring Framework (Java), and applies them to Python. This provides a powerful library of functionality to help you get back to writing the code that makes you money.

A little history

I have been working since October 2006 on this project, and it feels good to make this release. What do we mean by “production-ready?” The APIs are frozen until the next major release, so you have a stable platform to work against. This is a Release Candidate, meaning if there are critical errors, please report them so we can fix and release, until we reach general availability (GA).

I want to personally thank the many people who have helped make this release possible, including: Russ Miles, Sylvain Hellegouarch, and Dennis Mendelson. Also, a big thanks to SpringSource for hosting this project. And I also want to thank the Spring Python community that has posted questions, comments, patches, and ideas. BTW, Uche, your amara toolkit really saved the day in XML parsing!

Release Notes

Release Notes – Spring Python – Version 1.0.0-RC1

** Bug
* [SESPRINGPYTHONPY-87] – Fix object.html documentation to use proper import for ApplicationContext
* [SESPRINGPYTHONPY-88] – Fix PyroServiceExporter so that it has configurable host/port settings (w/defaults)

** Improvement

* [SESPRINGPYTHONPY-62] – Add XML configuration documentation to reference documents.
* [SESPRINGPYTHONPY-84] – Generate digital signatures for uploaded items automatically
* [SESPRINGPYTHONPY-89] – Repair springpython.context.ObjectPostProcessor to work more like BeanPostProcessor

** New Feature
* [SESPRINGPYTHONPY-83] – Create a command-line utility with a plug-in system that can perform useful tasks

Spring Python has a command-line tool with plugins!

While we have been working on many key features over the life cycle of this project, the biggest feature in this release is our command-line/plug-in system. During the SpringOne Americas conference, I was blown away by Graeme Rocher’s demo of Grails, where he built a twitter clone app in 40 minutes. A key part was his command-line grails tool.

Before I left that presentation, my mind was already racing in how to build a similar tool to help Spring Python developers. I realized I needed a pluggable solution, so that many different plugins could be created, whether by me or the community. During a few of the other presentations I attended, I was coding a simple solution that would support version control of plugins, being able to download and install from an official source, having some command-line help, and being able to install/uninstall/reinstall. To go along with this, I cooked up one plugin, gen-cherrpy-app, that creates a skeleton CherryPy web application with an IoC container configured with basic components, including security.

To use this tool, just download and install the main Spring Python package. After installing, you should find coily installed on your path. To get started, see what coily has to offer.

% coily --help

You should get something like this:

Coily - the command-line management tool for Spring Python
Copyright 2006-2008 SpringSource (, All Rights Reserved
Licensed under the Apache License, Version 2.0

Usage: coily [command]

--help print this help message
--list-installed-plugins list currently installed plugins
--list-available-plugins list plugins available for download
--install-plugin [name] install coily plugin
--uninstall-plugin [name] uninstall coily plugin

--reinstall-plugin [name] reinstall coily plugin

coily will create a local ~/.springpython directory, which contains all installed plugins, on a per-user basis. Currently, there is one official plugin which is used to help you create a CherryPy application. However, the opportunities are endless. Grails has plugins to create apps, modify existing apps, and so on. We can grow in a similar fashion.

Remember when I said you don’t have to install springpython-gen-cherrypy-app? Guess what. coily will grab it for you. You don’t have to install all the plugins. You can pick and choose what you want. At this stage, we don’t have an upgrade feature. But if you reinstall, it should do the trick.

Plugin Explosion

One issue Grails is having to deal with is their explosion of plugins. They have a lot, and only a subset are managed by the core Grails team. Others were developed by the community. This is definitely a good thing, because it reflects widespread adoption of Grails. However, anyone new to the project cannot discern the status of each plugin, and be able to decipher the stable ones from the bleeding edge ones. This is where Spring Extensions comes into play!

Spring Extensions is the official incubator process SpringSource has developed to manage new software development. Each extension has its own life cycle, forum, and tracked issues. Spring Python is an extension, and currently it contains one plugin. New plugins can fit into one of three possibilities:

  • Become an official part of Spring Python, meaning it is managed by the Spring Python team.
  • Become a separate, official Spring Extension, meaning it is not part of the official Spring Python release, but instead, has its own life cycle of releases, and potentially different leader and team.
  • Be managed outside the entire SpringSource system.

All three of these choices are good. They each offer a way to extend Spring Python in a usable way. Maybe you want to start an extension, but want to tip toe a little before diving in. Great! That is how lots of open source projects start. Later on, perhaps your plugin is becoming popular, and you would like to make it more official. A Spring Extension gets branded as officially supported by SpringSource. The amount of support varies, meaning as a minimum you get access to tools and some web space. Perhaps someday, if it becomes really popular, it can potentially join the SpringSource software portfolio. Or…not. No promises are made!

What else have you got?

Enough about plugins. What else is there, you ask?

  • Inversion of Control – a container which supports several formats, allows you to wire your python application together simply and effectively.
  • Aspect Oriented Programming – add extra services to existing code without changing APIs.
  • Data Access – DatabaseTemplate is a very useful abstraction to make writing database calls easier. This isn’t an ORM, but makes it easy to write pure SQL operations.
  • Transaction Management – while database calls are useful for any small, medium, or large application, transactions are the bread and butter of enterprise apps. This makes it easy to wrap business logic in transactions, whether or not it is the data access layer.
  • Security – using AOP, this is another powerful layer to add on. It is based on the architecture of Spring Security, meaning it is just as flexible and powerful, whether you are building a web app or a desktop client.
  • Remoting – RPCs are the building blocks for distributed apps. Most enterprise apps need to grow beyond the limits of a single server at some stage.

Each of these features, when orchestrated together, makes it easy to build enterprise-grade applications. IoC provides the indirection that allows you to convert a simple, one-machine, client-server app into a multi-node, security layered, scaled application with transactional protection. And everything is POPO-based.

What are POPOs?

Spring Java works hard to make sure it support POJO-based solutions. POJOs are plain old java objects. The idea is you don’t have to extend the frameworks classes. Instead, you can retool code you already wrote with minimal effort. Spring Python takes this same concept to Python by using POPOs, or plain old Python objects.

There are useful utility classes you can extend, but you don’t have to in order to use this collection of libraries. And that’s the point! You only use what you need, when you need it. The choice is yours.

Join us at LinkedIn

Please come and join us at the Spring Python group on LinkedIn.

What else is coming?

Whew! It has been some hard work to get to here. But by no means are we done. There is plenty more to do to make Spring Python better. A lot of the work done has been foundational.

Spring Python’s security module has a strong architecture in place. Now, we can start coding authentication providers to support things like LDAP, X.509, SecurId, two-factor authentication. Plenty of places to go there!

Remoting currently supports Pyro (Python Remote Objects) and some basic Hesssian. But there are many other remoting protocols. We have the foundation in place to code more service exporters in order to integrate with other technologies.

There are plenty of places to go from here. And we aren’t slowing down!

SpringOne – Day 3 and Spring Python plugins

Day 3 – Writing a Spring Python plugin manager
Yesterday, I visited three sessions: RESTful Web Applications with Spring 3.0, Terracotta, and The Dojo Toolkit. I admit that my mind was wandering during the web-based ones. That was because I wanted to work on my command-line, plug-in based tool. So I planted myself in the back of the room for the first and third presentation, plugged into some power, and worked on a plugin.

I managed to get a basic one completed called gen-cherrypy-app. Right now, you can only find it on one of my sandbox branches at In that directory is a command line python tool called coily. If you need help, type:

./coily –help

Currently, it will load plugins found in the current directory. In this case, you can see two in subversion: gen-cherrypy-app as I mentioned before, and noop as a test plugin that takes no arguments. In the future, it would be useful to have official plugins living on SpringSource’s download site, perhaps split into officially supported ones, and others going through the Spring Extensions life cycle.

Back to coily. If you run:

./coily –install-plugin gen-cherrypy-app

…it creates a .springpython folder in your home directory, copies the entire directory of gen-cherrypy-app there, and then next time you run coily –help, it will list it as a viable command-line option.

What does this plugin do? The idea for this plugin was inspired by Graeme’s presentation on Grails where he built a twitter-like site in 40 minutes.

./coily –gen-cherrypy-app twitter

That will generate a directory called twitter, which contains a Spring Python-based CherrypPy skeleton app called plus some support files. Several toolsets are proving the value of auto-skeleton apps: RoR, Grails, and Turbogears to name a few. Spring Python can use that too.

Spring Python hasn’t yet made it safe for the fairies, so I think users deserve all the help they can get wiring up spring python security.

But more than anything, this helps set the stage for other useful plugins that the community can identify as useful for adoption of Spring Python. I hope I have whetted your appetite. Now…time to get ready for a couple of presentations!

SpringOne – Days 1 and 2

I finally found some time to post updates. Whew! It has been busy!

Day 1
On Monday, I hooked up with the SpringSource guys. It seems everyone had something to work on. I wanted to get 0.9.0 completed and working before giving my demo of PetClinic on Thursday. Just about anyone I spoke to was polishing up their slides. It is truly fantastic to be chatting with the guys at SpringSource.

Rod Johnson gave the keynote addresss, focusing on the target goal of SpringSource in reducing the complexity of application development. Complexity means more development, more risk, and in turn, more cost. SpringSource’s overarching goal of reducing complexity must be working, because he had several metrics showing how much has been adopted in some degree by the industry.

After the keynote, I was finally able to meet up with Keith Donald. We have been playing email tag for some time, and I was surprised to find out his office is probably 10 minutes away from mine. Hopefully we can get together soon after the conference. It was also great to meet Mark Pollack, Chris Beams, Ben Alex, and of course, Rod Johnson himself. While I enjoy reading their blog entries and source code, there is no substitute for meeting the real person.

Day 2
In the morning, I attended the Grail presentation. That was awesome. Graeme demonstrated building a twitter-like site using Grails in 40 minutes. Okay, he promised 40 minutes, and took 45 minutes, but only because he started adding extra functionality not found at the actual twitter site. In the process, I was realizing the value Grails places on plugins. Grails is good at creating a skeleton application, and then letting you flesh it out. I was starting to get the idea that Spring Python could use a command line utility with plugins to generate a skeleton CherryPy app, Django app, or anything else developed by a plugin. Well, I went to the next session, “Intro to Spring Security 2.5”, opened my laptop, and started coding. I managed to write a static skeleton app, and then began working on a command-line utility to dynamically generate this. That is still in progress.

I admit I was only listening with one ear to Ben’s presentation. Sorry Ben! 1) I am already somewhat familiar with Spring Security, 2) most of it is geared towards web apps which I don’t write, and 3) I was really stoked at the idea of a command-line tool that download Spring Python plugins from a network location. I did catch his question, “who here is NOT writing web apps?” I was the only person in the room who raised a hand to that. When asked what I was using, I answered “Swing desktop apps.” That plugged Ben’s point that Spring Security uses the same tactics.

After lunch, I attend two sessions about Spring Integration. This is channel based messaging, which is sort of like JMS on steroids in my book. They interface with JMS, but also with other things like file-based systems, web services, RMI, anything. And it is easy to plug in your non-message based service to a chain of processing. This is wiring your app in a different, more decoupled way. I sure could have used this about five years ago.

Later that evening, Russ and I got together to work on his Spring Extensions presentation. Russ is planning to talk about the process Spring has set up to better manage new code, and wanted to compare the process with real life, and Spring Python is his choice target. If you are at SpringOne and can read this before Thursday, I highly suggest you attend that presentation. It will definitely be entertaining (shameless plug).