Greetings Programs

Spring Python 1.1.1, 1.2.1, and 1.3.0.RC1 are released

2011-12-21T19:44:00.000-06:00

See my official blog entry at http://blog.springsource.org/2011/12/20/spring-python-1-1-1-1-2-1-and-1-3-0-rc1-are-released/.

Sorry Planet Python

2011-07-13T07:42:00.001-05:00

I just moved all the blogs I wrote about Spring Python over here, and asked Michael Foord to update Planet Python's feed to point hear instead. I forgot that it would probably repost everything. Well I guess it's kind of like an extra media blitz.

Just so you are up to date:
- Spring Python is at release 1.2.0.Final
- We support Python 2.6+ (but not 3+ yet)
- Visit Packt Publishing's website and you can order a copy of my book, Spring Python 1.1, of which probably everything works. It just doesn't show the newer features.

For more project details, forums, or documentation, visit http://springpython.webfactional.com.

Spring Python 1.1.0 released

2010-05-11T04:35:00.000-05:00

The final release of Spring Python 1.1.0 is out. Spring Python takes the concepts of Spring and applies them to the Python. This includes functionality like dependency injection, aspect oriented programming, data access, transaction management, security, remoting, and even python-to-java-to-python communication through JMS.

Spring Python has been growing since 2006 and was the first Spring Extension to go live. The project thrives with community involvement. The biggest thanks go to our fellow committers: Dariusz Suchojad and Sven Wilhelm. You can also follow postings at http://twitter.com/springpython.

There is also a Spring Python 1.1 book to help both Java and Python coders alike come to grips with the functionality offered by Spring Python. It covers all the major functional pieces of Spring Python (except the JMS part which is very new) and includes two case studies with lots of code and high level diagrams.

The following is a list of issues worked during this major release:

Bug

[SESPRINGPYTHONPY-99] - PyroServiceExporter daemon shutting down abruptly in Python 2.6

[SESPRINGPYTHONPY-100] - SpringWiki's non-XML configuration doesn't match the XML app context

[SESPRINGPYTHONPY-107] - Iterating over set configurations in the container not handled properly.

[SESPRINGPYTHONPY-113] - Break dependency of ApplicationContext on Pyro

[SESPRINGPYTHONPY-129] - Add springpython.jms to setup.py's list of packages

[SESPRINGPYTHONPY-130] - Discovered that trying to access SecurityContextHolder information was broken inside

[SESPRINGPYTHONPY-101] - Incorrect imports and a password typo in "Data Access" docs CherryPy app

Improvement

[SESPRINGPYTHONPY-98] - Migrate modules based on amara to ElementTree

[SESPRINGPYTHONPY-106] - Add TRACE logging level

[SESPRINGPYTHONPY-111] - Move InitializingObject from springpython.factory to springpython.

[SESPRINGPYTHONPY-114] - Move amara import statement inside XML-based parsers, move pyyaml inside YamlConfig

[SESPRINGPYTHONPY-119] - List all external dependencies in the ref docs

[SESPRINGPYTHONPY-126] - Update the documentation to use v. 1.1 XMLConfig XSD schema

[SESPRINGPYTHONPY-133] - Add support for SSL JMS w/ WebSphereMQ

[SESPRINGPYTHONPY-136] - Stop using Amazon's S3 browse site, and replace it with SpringSource's

[SESPRINGPYTHONPY-102] - Patch to make top-level build.py OS-independent

[SESPRINGPYTHONPY-136] - Stop using Amazon's S3 browse site, and replace it with SpringSource's

New Feature

[SESPRINGPYTHONPY-12] - Investigate creating JmsTemplate

[SESPRINGPYTHONPY-97] - Create a YAML-based IoC configuration parser

[SESPRINGPYTHONPY-105] - Add DisposableObject

[SESPRINGPYTHONPY-108] - Add lazy_init as option to @Object

[SESPRINGPYTHONPY-121] - Add LDAP support to security module (CPython)

[SESPRINGPYTHONPY-127] - Implement abstract objects

[SESPRINGPYTHONPY-132] - Add JMS SimpleMessageListenerContainer

[SESPRINGPYTHONPY-95] - Add dictionary support to DatabaseTemplate queries

[SESPRINGPYTHONPY-103] - SQLServerConnectionFactory

Refactoring

[SESPRINGPYTHONPY-128] - Cleanup CherryPy-specific classes, dependencies and overall hierarchy

[SESPRINGPYTHONPY-137] - get_last_traceback duplicates existing functionality

There is no better time write than now

2010-04-23T10:12:00.002-05:00

I just handed our keys and garage door opener to the title company. Doing this while writing a book highlights how easy it is in this day and Internet age to really work from a laptop. As stressful as these last couple of days have been, I'm glad I decided to write. If you want to write, I encourage you to do the same!

Posted via web from Spring Python Book

Spring Python 1.1.0.RC1 released

2010-04-07T06:17:00.000-05:00

See http://www.springsource.org/node/2490 for the official notice.

Spring Python takes the concepts of the Spring Framework and applies them to Python. This includes features like dependency injection, aop, remoting, data access, transactions, and security, all with a non-invasiveness style.

This is the first release candidate for version 1.1. We are quickly approaching final release. You can read more detail with the online documentation (see official notice for more links, as well as the sidebars of this blog). You can also pre-order your copy of the Spring Python 1.1 from Packt Publishing, due for release in June 2010.

Improvement

[SESPRINGPYTHONPY-136] - Stop using Amazon's S3 browse site, and replace it with SpringSource's

Spring Python 1.1.0.M2 is released

2010-04-02T04:51:00.000-05:00

See http://www.springsource.org/node/2489 for the official notice.

Spring Python takes the concepts of the Spring Framework and applies them to Python. This includes features like dependency injection, aop, remoting, data access, transactions, and security, all with a non-invasiveness style.

This is the last planned milestone for version 1.1. We are quickly approaching final release. You can read more detail with the online documentation (see official notice for more links, as well as the sidebars of this blog). You can also pre-order your copy of the Spring Python 1.1 from Packt Publishing, due for release in June 2010.

Release Notes

Bug

[SESPRINGPYTHONPY-99] - PyroServiceExporter daemon shutting down abruptly in Python 2.6

[SESPRINGPYTHONPY-100] - SpringWiki's non-XML configuration doesn't match the XML app context

[SESPRINGPYTHONPY-107] - Iterating over set configurations in the container not handled properly.

[SESPRINGPYTHONPY-113] - Break dependency of ApplicationContext on Pyro

[SESPRINGPYTHONPY-129] - Add springpython.jms to setup.py's list of packages

[SESPRINGPYTHONPY-130] - Discovered that trying to access SecurityContextHolder information was broken inside CherryPy app

Improvement

[SESPRINGPYTHONPY-98] - Migrate modules based on amara to ElementTree

[SESPRINGPYTHONPY-106] - Add TRACE logging level

[SESPRINGPYTHONPY-111] - Move InitializingObject from springpython.factory to springpython.

[SESPRINGPYTHONPY-114] - Move amara import statement inside XML-based parsers, move pyyaml inside YamlConfig

[SESPRINGPYTHONPY-119] - List all external dependencies in the ref docs

[SESPRINGPYTHONPY-126] - Update the documentation to use v. 1.1 XMLConfig XSD schema

[SESPRINGPYTHONPY-133] - Add support for SSL JMS w/ WebSphereMQ

[SESPRINGPYTHONPY-136] - Disable attempts to access s3browse since it no longer exists

New Feature

[SESPRINGPYTHONPY-12] - Investigate creating JmsTemplate

[SESPRINGPYTHONPY-97] - Create a YAML-based IoC configuration parser

[SESPRINGPYTHONPY-105] - Add DisposableObject

[SESPRINGPYTHONPY-108] - Add lazy_init as option to @Object

[SESPRINGPYTHONPY-121] - Add LDAP support to security module (CPython)

[SESPRINGPYTHONPY-127] - Implement abstract objects

[SESPRINGPYTHONPY-132] - Add JMS SimpleMessageListenerContainer

Refactoring

[SESPRINGPYTHONPY-128] - Cleanup CherryPy-specific classes, dependencies and overall hierarchy

[SESPRINGPYTHONPY-137] - get_last_traceback duplicates existing functionality

Pre-order your copy of Spring Python 1.1 book today!

2010-02-03T10:04:00.000-06:00

Pre-order your copy of the Spring Python book!

"Create powerful and versatile Spring Python applications using pragmatic libraries and useful abstractions

Maximize the use of Spring features in Python and develop impressive Spring Python applications

Explore the versatility of Spring Python by integrating it with frameworks, libraries, and tools

Discover the non-intrusive Spring way of wiring together Python components

Packed with hands-on-examples, case studies, and clear explanations for better understanding"

Visit the Packt Publishing site for more details.

Spring Python 1.1.0.M1 Released

2010-01-22T08:15:00.000-06:00

See http://www.springsource.org/node/2282 for the official announcement.

I chatted with Mark Pollack earlier this week and asked if we wouldn't mind me taking over. He said no problem, and I was able to get keys later to push releases up to SpringSource's S3 site.

This release is first milestone in our new 1.1 baseline. More features, improvements, and enhancements will be coming out with the next milestone, as we work towards getting this released.

I'm going to work for SpringSource

2009-12-12T07:05:00.000-06:00

Starting January 11th, I'm going to be working for SpringSource. I told my daughter and look what she had to say!

I'm glad she approves.

No, they didn't hire me to work on Spring Python. That is still in my spare time. Hopefully, I can become sponsor and not have to bug Mark Pollack.

Anyway, my first assignment will involve working on integration between tcServer and some of SpringSource's management products. I can't wait!

See how Spring Python works with Jython

2009-10-15T08:59:00.000-05:00

I recently completed a patch that replaces the amara library with python's default elementTree library. As much as I like amara's API, its C-extension basis was unacceptable. I just merged the patch into the trunk, and verified it works with Jython 2.5.1.FINAL. When Spring Python's 1.1.0.M2 release comes out, we will be Jython-compatible.

With this change, there were only a couple of tweaks to the rest of Spring Python.

What does this mean? How about looking at some code to see how we can start with a Java app, and migrate things over to Python. To kick this off, let's start with an uber-contrived example Java app: a wiki engine. The wiki engine calls into a data access layer in order to look up some statistics on the site.

public interface DataAccess {

        public void statistics();

}
public class MySqlDataAccess implements DataAccess {

        public void statistics() {
                System.out.println("MySQL: You are calling for some statistics.");
        }

}
public class WikiService {

        private DataAccess dataAccess;

        public DataAccess getDataAccess() {
                return this.dataAccess;
        }

        public void setDataAccess(DataAccess dataAccess) {
                this.dataAccess = dataAccess;
        }

        public void calculateWikiStats() {
                System.out.println("You are passing through a pure Java WikiService...");
                dataAccess.statistics();
        }

}

Let's assume this is a Spring app. That means we need an XML application context. Let's create one and call it javaBeans.xml.



       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://www.springframework.org/schema/beans
           http://www.springframework.org/schema/beans/spring-beans-2.5.xsd">

We can start up our pure java app along with its context by writing jython script javabeans.py. It uses Spring Python's SpringJavaConfig parser.

if __name__ == "__main__":
    from springpython.context import ApplicationContext
    from springpython.config import SpringJavaConfig
    ctx = ApplicationContext(SpringJavaConfig("javaBeans.xml"))
    service = ctx.get_object("wikiService")
    service.calculateWikiStats()

We just need to compile the java code, and then run our script using jython.

gregturn@startrek:~$ javac *.java
gregturn@startrek:~$ jython javabeans.py
You are passing through a pure Java WikiService...
MySQL: You are calling for some statistics.
gregturn@startrek:~$

Okay, we're off to a good start. We have tapped a running java system. For our next step, let's write a pure python version of the data access code and put it into Py.py.

import DataAccess

class MySqlDataAccess(DataAccess):
    def statistics(self):
        print "PyMySQL: You are calling for some statistics."

class StubDataAccess(DataAccess):
    def statistics(self):
        print "PyStub: You are calling for some statistics."

Now, to really crank things up a bit, let's migrate from the Spring Java XML configuration over to Spring Python's pure Python container.

from springpython.config import PythonConfig, Object
from Py import MySqlDataAccess
import WikiService

class WikiProductionAppConfig(PythonConfig):
    def __init__(self):
        PythonConfig.__init__(self)

    @Object
    def data_access(self):
        return MySqlDataAccess()

    @Object
    def wiki_service(self):
        results = WikiService()
        results.dataAccess = self.data_access()
        return results

if __name__ == "__main__":
    from springpython.context import ApplicationContext
    ctx = ApplicationContext(WikiProductionAppConfig())
    service = ctx.get_object("wiki_service")
    service.calculateWikiStats()

The top half of our mixed.py script contains an IoC container, except there is no XML whatsoever. Instead, its raw python. You can see how we are also using our python version of MySqlDataAccess.

gregturn@startrek:~$ jython mixed.py
You are passing through a pure Java WikiService...
PyMySQL: You are calling for some statistics.
gregturn@startrek:~$

This shows that we are still using the pure java WikiService class, and it calls into our pure python MySqlDataAccess.

Another useful feature that Spring Python provides is easy access to Pyro, the Python Remote Objects library. This library is for making RPC calls from Python-to-Python. Spring Python makes it easy to link clients and services together with Pyro.

First, let's take our wiki service, and export it with a server script.


from springpython.config import PythonConfig, Object
from springpython.remoting.pyro import *

from Py import MySqlDataAccess
import WikiService

class WikiProductionAppConfig(PythonConfig):
    def __init__(self):
        PythonConfig.__init__(self)

    @Object
    def data_access(self):
        return MySqlDataAccess()

    @Object
    def wiki_service(self):
        results = WikiService()
        results.dataAccess = self.data_access()
        return results

    @Object
    def exported_wiki_service(self):
        return PyroServiceExporter(service=self.wiki_service(), service_name="wiki", service_port=9000)

if __name__ == "__main__":
    from springpython.context import ApplicationContext
    print "Starting up exported WikiService..."
    ctx = ApplicationContext(WikiProductionAppConfig())

We made some slight tweaks to the IoC container by adding exported_wiki_service. It targets wiki_service, and links it with a name and port to expose it as a Pyro service. Spring Python by default will instantiate every object, so in this case, it creates the PyroProxyExporter. Because this isn't the caller, we don't need to fetch anything from the context.

Next, let's code a client to call our service.


from springpython.config import PythonConfig, Object
from springpython.remoting.pyro import *

class WikiProductionAppConfig(PythonConfig):
    def __init__(self):
        PythonConfig.__init__(self)

    @Object
    def wiki_service(self):
        results = PyroProxyFactory()
        results.service_url="PYROLOC://localhost:9000/wiki"
        return results

if __name__ == "__main__":
    from springpython.context import ApplicationContext
    ctx = ApplicationContext(WikiProductionAppConfig())
    service = ctx.get_object("wiki_service")
    service.calculateWikiStats()

Now, let's start up the server.


gregturn@startrek:~$ jython mixed_with_pyro_server.py &
[1] 4953
Starting up exported WikiService...

The script is backgrounded, because it is running a Pyro daemon advertising our service. Now, let's launch the client script.


gregturn@startrek:~$ jython mixed_with_pyro_client.py
You are passing through a pure Java WikiService...
PyMySQL: You are calling for some statistics.
gregturn@startrek:~$

As you can see, our client makes remote to the exported WikiService, which happens to be a pure java service. The java service then calls our python version of MySqlDataAccess to do its statistics call. This goes to show how easy Spring Python makes it mix and match Java and Python.

Welcome Sven Wilhelm!

2009-09-24T03:22:00.000-05:00

I wanted to introduce another team member: Sven Wilhelm. We just granted him commit privileges this week. Sven has been using Spring Python as a core piece of his team's system. He has been doing a bit of work on making Spring Python work with Jython (which I'm VERY interested in!), as well as working on a Spring Python Ldap module. With Sven on the team, we will be able to make these parts available to you as well.

Sven, thanks for joining the Spring Python team!

Welcome Dariusz Suchojad

2009-09-15T11:29:00.000-05:00

I want to welcome our newest team member: Dariusz Suchojad. He has coded several patches in the past, including support for SQLServer. You will notice his name in the credits at the top of the reference docs (http://springpython.webfactional.com/1.1.x/reference/html/index.html). I submitted a request today that he be given commit rights to Spring Python's code base.

He is working on some new Spring Python features as well. Dariusz, thanks for joining Spring Python!

Spring Python's website gets a major upgrade

2009-08-18T04:05:00.000-05:00

I recently upgraded Spring Python's project page from being a statically generated maven-based website to a dynamic drupal-based CMS.

VMware set to buy SpringSource

2009-08-10T11:34:00.000-05:00

Rod Johnson posted a blog entry today that is also sweeping the twitterverse, indicating that they "have signed a definitive agreement with VMware, who will acquire SpringSource". It says that the Spring Framework software will remain as free as ever. That should be the case, and I haven't seen reason to doubt SpringSource would do anything differently.

Considering SpringSource has been at play using venture capital to grow its business and enter markets, this should definitely be a sign of success. A lot of startup companies get venture capital, but die off through the fact that no bigger company seeks them. This is definitely the opposite. The way I see it, SpringSource has succeeded by getting acquired by a well known company. One thing is keen in the article: both SpringSource and VMware have their eyes on the cloud computing market. And given their successful record, I think they can do pretty well.

I don't know what VMware thinks about python, but I sure will keep me ears open. This project isn't slowing down!

UPDATE: Acquisition is complete. Read all about it at http://www.vmware.com/company/news/releases/springsource-close.html.

Ever seen two robots discuss AOP in python?

2009-07-02T16:17:00.000-05:00

I couldn't resist using this website to put together a little movie. What is better than a couple of robots discussing aspect oriented programming in python? (This was based on my earlier post The Case forAOP in Python)

Okay, maybe its a little stiff, but you have to admit that putting this together on a web page is pretty cool!

Spring Python makes final 1.0.0 release

2009-07-01T16:33:00.000-05:00

Please read the official press release from SpringSource about this historic release of Spring Python. Please visit http://www.springsource.com/download/community in order to download a copy. NOTE: Spring Python has now been relocated to the top level, instead of being inside EXT.

It's the first Spring Extension to reach live status and also progress to a stable 1.0.0 final release.

The trunk has been updated to allow work on next major release 1.1 to begin. This means we aren't through, but just getting started.

Another branch has been created to support backporting critical fixes into the 1.0 baseline, meaning it will have the same type of strong support as other SpringSource projects.

This demonstrates that Spring Python has a nicely honed development process, committed to providing stable APIs, while also focusing on new and innovative changes. While we have worked hard since the start of this project back in 2006, we still lots of ideas and have plenty more work to do.

I wish to thank Mark Pollack, the current sponsor of Spring Python and code geek that developed Spring .NET, for coming on board quickly, and supporting me in every way possible to get this release wrapped up and pushed out for everyone to use. I also want to thank Russ Miles, former SpringSource consultant, who has supported me for over the past year with encouragement and feedback. I also thank the community for its valuable comments, questions, and suggestions that has helped steer this project in a positive direction.

Key changes used to this release include:

Improvement

[SESPRINGPYTHONPY-96] - When making builds, use "." as separator between version and tag; support python 2.4/2.5/2.6

Task

[SESPRINGPYTHONPY-56] - Assess impact of python's deprecation of md5 and sha modules to spring python's security segment

Is Spring Python a framework or a library?

2009-06-11T04:10:00.000-05:00

I was tracking some comments, and recently noticed a thread of discussion (in English) on a python mailing list. This is a follow-up to someone else posting about his discovery of Spring Python through the news announcement from SpringSource. (I appreciated that the person also caught on to my article defending the usage of AOP in python.)

They concluded their response by indicating:

Aunque para convencerme de usarlo todavía le falta compararse con otros frameworks de python.

(Run this through Google Translate if you need to.) Apparently, this person, while slightly impressed that I wasn't coding in horrible java paradigms, didn't see enough to use this instead of other python frameworks. I knew that he was comparing it to other python web frameworks.

History Lesson

I started thinking about the basis of all this, and realized a little bit of a history lesson is in order. Anybody who has ever heard of Spring, knows it by its full name, The Spring Framework. This should help illuminate why Spring is referred to as a framework, and why Spring Python is often thought of as a framework itself.

Starting around 1999, the first EJB spec came out. This was the technology everyone in the java industry started using, and people were throwing together any and all java web apps using EJBs. It caused a resurgance in the value of java, and arguably catapulted java into the enterprise space. EJBs promised much. The application servers that would run your EJB-based app had many features, like transactions, security, failover, messaging, and web services to name a few. All you had to do was extend a few interfaces, write a few configuration files, and do a little configuration to the app server.

Well, that was how it was supposed to be, right? The truth was, EJB apps required lots of XML file configuration. Each container had deviations, so your app tended to be container-specific. People usually had too many services turned on, and unit testing was next to impossible. You couldn't test your app outside the container, so turn around time to see your changes was a nightmare. That is what generated the flurry of frameworks, like Struts, to help make EJB app development simpler. By extending these framework's classes, you had a little bit less to extend, less to write, and less to configure. But you still had to do it anyway. And that turn around time to test your app? No better. And you had to make your WHOLE app do this. There was no such thing as, "Part of my app is using Struts, another part is using Wicket."

Then in 2002, Rod Johnson, a java software consultant, wrote a book Expert One-on-One J2EE Development without EJB. When Rod's book hit the shelves, the message he was sending was completely unorthodox. He showed tactics of code development that quickly made these container-based services obsolete. You didn't have to extend anyone's classes. And...you didn't have to adopt any framework lock-stock-and-barrel. Instead, your app could be 99% based on POJOs. The code he was writing for examples in the book was very pragmatic, and was just like the other frameworks, only it was a framework based on POJOs. Another consultant approached Rod about releasing that software as an open source project, and thus was born The Spring Framework.

This code, while acting similar in output as other frameworks, had a peculiar difference: it did not require actually extending anybody's classes. In fact, you could write your code 99% framework-free, and Rod & Co. encouraged this.

"So...is Spring a framework or a library?"

I argue: both!

Considering that a library is a set of functions and classes you download and install in your software development toolbox, Spring fits this perfectly. It was inspired by the need to overcome the lethargic development process of the EJB spec. Not only did they improve over EJB's way of doing things, they also enhanced JDBC, JDNI, JMX, and other things.

Ben Alex decided to develop a Security library based on the pragmatic concepts behind Spring, which has since become the most widely adopted security solution for java.

Mark Pollack was also watching Spring cut through the java industry and coded a similar solution for C#/.NET and called it Spring .NET.

...and the list goes on of other widely adopted libraries/tools developed for the java industry based on Spring's approach to solving problems

So, yes, Spring is a library. But it is ALSO a framework, in that its original intention was to faciliate building enterprise-grade web applications inside EJB containers. They simply showed that the servlet container was enough. In fact, many shops started fresh adopted the concept of using Apache Tomcat or Jetty as the servlet container, which has been challening the commerical app server market. Combined with the fact that your app could run inside and outside an EJB container, and also be easily JUnit-tested without the slow make-deploy cycle made it a hit.

And...its NOT a framework!

"But, you just SAID Spring is a framework!"

Yeah, I know I did, but many people interpret framework as code meant to be extended. Spring doesn't require this. It may accomplish the same end result as these other EJB frameworks, but through simpler means. I know this first hand, because I have developed thick Java client apps using Swing. No EJB container to be found! And yet, I have found Spring provided much leverage and functionality. I didn't have to extend anything. Okay...I had a unique situation involving security where I needed to extend a Spring Security interface, but 99% of my code doesn't do that. And that's the point.

"Enough Java already! I thought this was a Python blog!"

Okay, if you're still reading, it means you are really a cross technology buff. Or maybe you just read blogs instead of sword fighting while waiting while waiting for your code to compile. Otherwise, you freaked that I spent so much time talking about Java, XML, EJBS, and fled the scene. Well, I'm a polyglot programmer. I use all kinds of stuff: C/C++, Java, Python, Tcl/Tk/Expect, PERL, bash/csh, jython, scala, groovy, clojure, anything! Actually, I had never heard the term until I saw Russ's Skills Matter presentation where he presented himself as an "self professed, unapologetic, polyglot programmer". But I immediately connected with it.

Anyway, the point I'm trying to make is that the concepts Rod presented are of incredible value. Its not the fact that he was working in Java, but instead the idea that pragmatism is valuable. Instead of always resting comfortably against specs, we need to always be on the lookout for places and paradigms where we are wasting countless cycles in coding and re-coding the same thing. I contend that repetition is one of the top ranking source of bugs, if not the highest.

I believe Spring Python is a library

My first entry into the world of Spring was through their fabulous JdbcTemplate. Writing SQL queries without leaking cursors and connections was of high important to me. When I decided to code a carputer application, I picked Python because reading Dive Into Python had sold me on the beauty of it. However, I quickly realized I was missing my lean-and-mean JdbcTemplate. I started coding a DatabaseTemplate to help me, and realized I was starting to do something just like Rod. Well, I decided then and there to share my library with anyone who was interested. Hope it helps you like it has helped me.

I think, and it's not a mockery, that the Java world is rather a framework type of environment which leads usually to have as many frameworks as you have developers for the very reason I described above. Python has also its share of frameworks but the language is flexible enough to encourage libraries. I *strongly* believe that Python Spring[sic] has both functionalities that could be attractive to many developers while having the chance of doing so as a library rather than a framework. --Sylvain while commenting about Spring Python w/CherryPy 3

And that's why I call it Spring Python. It takes the cool concepts of Spring, and write them in a slick-and-quick, pythonic library. And yes, it is a library.

Is Spring Python notable enough to keep its wikipedia article?

2009-06-04T04:20:00.000-05:00

Spring Python has had a wikipedia article for some time. I know, I wrote it. Today, someone has proposed deleting the article, citing that the it doesn't establish its notability. I encourage anyone interested to put in their $0.02. However, please do NOT go rabid. Whether you think this fits wikipedia's criteria for an individual article or not, please put in your opinion backed up by links to resources, while following wikipedia's guide for article deletion (as show on the site).

Please vote your conscience. What am I trying to say? If you think Spring Python is good, but doesn't fit their criteria of an article, go ahead and vote it down. If you think this project has something unique and distinct, then vote it up. (Can anyone say unobtrusive AOP?) A key factor is that there is about 7 days before they will make a decision of which way to go, so if you're going to vote, please vote soon.

Personally, I would like to keep the article. But it's not the end of the world if its deleted, because this blog, the official website, and our source code repository are the heart and sole of this project. Whatever your opinion is, if you only express it here on this blog, it won't influence the vote on whether or not to delete this article.

Thanks everyone,

Greg Turnquist, Spring Python project lead

UPDATE:

The wikipedia article has been deleted.

00:05, 18 June 2009 Cirt (talk | contribs) deleted "Spring Python" ‎ (Wikipedia:Articles for deletion/Spring Python)

Spring Python 1.0.0 (RC2) is released

2009-06-03T08:44:00.000-05:00

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. You can visit Spring Python's official web page, or skip right to the downloads.

You're Late!

Yes, we're a tad late. Okay, we're really late, but in case you fell off the planet, SpringSource lost a valuable member of its team, Russ Miles, who was also the sponsor for this project. There were other high priority things happening, so considering this is an extension, it took a little longer than usual to get to making a release. Which brings me to my next point. I want to welcome Mark Pollack as the new sponsor for this extension. He is the code geek that developed Spring .NET. I have had the benefit of meeting him at least year's SpringOne Americas conference and attending his presentation, and we have also corresponded over email and IM.

So what's in this release?

You can scroll down to see the release notes. There actually isn't much change in the code. We are trying to freeze things into a stable API. However, one thing not listed was a key problem we had to solve with coily. coily is the command-line tool that let's you download Spring Python plugins. Coily was having trouble handling data hosted on the S3 servers used to stage these downloads, so I had to fix it. It now offers you the correct name.

When you query this version to see what plugins are available, you should see this:

$ ./coily --list-available-plugins
Coily v1.0.0 - the command-line management tool for Spring Python
===============================================================================
Copyright 2006-2008 SpringSource (http://springsource.com), All Rights Reserved
Licensed under the Apache License, Version 2.0

Available plugins:
        gen-cherrypy-app        springpython-plugin-gen-cherrypy-app-1.0.0-RC1.tar.gz   2009-01-22 18:08
        gen-cherrypy-app        springpython-plugin-gen-cherrypy-app-1.0.0-RC2.tar.gz   2009-06-03 18:23

You may be seeing two copies listed here, but when you try to install, it will grab RC2's version.

Release Notes

Release Notes - SX Spring Python - Version 1.0.0-RC2

Improvement

[SESPRINGPYTHONPY-92] - Show more examples of using pure python IoC configuration

Task

[SESPRINGPYTHONPY-90] - Update trove categorization from Beta to Production/Stable

[SESPRINGPYTHONPY-91] - Create minimal documentation for Hessian remoting

What is coming next?

Well, I have been in contact with a company in Germany that is using Spring Python as a key piece of their software solution. They have even granted me access to view their code base. It is exciting seeing them in action, especially since they are writing some extensions to Spring Python and also experimenting with using it inside Jython.

What does this boil down to? Community feedback is a key ingredient to finding out what features need to be added, modified and improved. Through IM and email, we have already identified some mods to DatabaseTemplate supporting convention-over-configuration, and have already coded a SimpleRowMapper. If your POPO's attributes match the column names of a query, you don't need to create a custom RowMapper. Instead, plug-in this one, and it will link them together, without requiring you to extend any of Spring Python's classes.

self.databaseTemplate.query(
                            "select name, category from animal",
                            rowhandler=SimpleRowMapper(testSupportClasses.Animal))

SimpleRowMapper only needs a class name. It will instantiate one of these classes for each row, and then populates the name and category attributes with the results of the query.

There is also a DictionaryRowMapper, which returns a list of dictionaries, instead of tuples. The key point is that convention-over-configuration has become an accepted way to rapidly write essential code without getting caught up the details, and Spring Python embraces this concept.

There is just one wrinkle to make this work: the API used in RowMapper has a slight change (we added metadata as an optional attribute). Since 1.0 is a frozen API, and we are trying to get to a final release, Sven and I agreed to put this change into Spring Python v1.1, so for now, you can only get it from our source repository. Stay tuned for updates!

SpringOne Europe - Wish I Could Be There

2009-04-28T02:13:00.000-05:00

Well, I was able to make it to the SpringOne Americas conference back in December 2008. And I knew I would hunger to be at the SpringOne Europe conference this year. This time, though, since I got into twitter, I have been able to keep my thumb on the pulse by watching twitter on the #springone channel.

It makes me feel almost like I'm there.

So far, I have been tracking Ben Alex's Spring ROO framework.

Oracle = "A tax on old Java technology" - Rod Johnson (overheard on twitter)

SpringSource Tool Suite will be free for all developers.

Okay, I'm not going to give you everything (and I don't KNOW everything). If you can make it to a SpringOne conference, trust me...it's awesome. However, if not, then at least follow along twitter for some of the bits.

The case for AOP in Python

2009-03-23T05:20:00.000-05:00

There are many articles out there about AOP and python, and consequently, several AOP solutions for python are offered. The spectrum is broad, ranging from "python doesn't need AOP" to "python has enough language features to do AOP without framework code" to "AOP works great with python" to "AOP is just another thing built for static languages someone is trying to bolt onto python".

Someone made a good point back in 2004 on a python mailing list that AOP is a paradigm, not a specific framework, and that if we are going to argue against AOP in python, then it opens the door to arguing over OOP, and in turn, probably every paradigm that we know. Are you ready to throw out python classes and do everything functionally?

When Jim Moore gave his SpringSource presentation at my company a few weeks ago, he gave an excellent description of AOP: its a way to get the computer to help you drop in functionality where its needed, with minimal effort on your part.

Way back in the stone ages, we wrote programs based on how the CPU thinks: one line of code translates directly to one line of CPU instruction. As programs got bigger and bigger, we exceeded the ability to track a whole program. We needed to trim things down into smaller bites, so we could focus on one piece of logic at a time. Someone came up with the idea of combining a class of functionality based on data, and thus OOP was born. New programming paradigm; however, the CPUs are still pretty much the same. Did we worry about this? Of course! There were scores of debates on the merit of OOP. We had the compilers able to translate OOP into sequences of instructions, and just built OOP-aware tools to give us the right visibility. When the next generation of developers arrived, OOP was nothing new, and it has become a part of history.

AOP is another way to avoid DRY (don't repeat yourself). As we write more sophisticated applications, we still find areas where the same riff of code needs to be sprinkled in several places. If we needed to update the code, we don't want to edit it in 95 different places, and unfortunately, OOP can't solve everything, considering its vertical-nature. We have already built compilers than can convert our OOP/AOP/structural programs into a sequence of steps for the CPU to execute. We just need the tools to help us maintain the right perspective. And...we need to wait for the next generation of developers to arrive to cement it into history. In my opinion, writing off AOP as "only needed by java developers" is akin to burying your head in the sand.

It is true that different languages have differing levels on how easily they can support the AOP paradigm. I agree that python is very adept, which is part of the reason that it took less time for me to implement an AOP solution than it possibly took to implement the Java-based one. I would generalize that other dynamic languages are probably quick as well for that.

Python has shown in many articles, that metaclass programming, using decorators, and some of the new python 2.5/2.6/3.0 constructs help as well. It depends on what you are doing. If you are in complete control of all source code, you have more options. Metaclass programming is possible, as are decorators.

Sometimes, you don't control all the parts. You can read a whole thread, where a Spring Python newbie wanted to add a simple interceptor to an existing library, and trace a certain operation. Spring Python's AOP module makes this very easy, because it works after the fact. Metaclass programming and usage of decorators would be very hard, unless you were willing to touch the library's actual code. One key aspect that Spring Python seeks is to be non-obtrusive. Some of the other AOP libraries for python tend to require edits to the code itself.

Regardless of which library you use, the ability to easily intercept code and in turn add functionality based on a controlled pattern is nothing new. We needed OOP to accomplish this in some areas. We need AOP in others. And knowing how to utilize the full extension of a language sums it up. We need the ability to apply functionality at the right time, in the right place, without repeating ourselves.

http://en.wikipedia.org/wiki/Aspect-oriented_programming

http://springpython.webfactional.com/reference/html/aop.html

https://fisheye.springframework.org/browse/se-springpython-py/trunk/springpython/src/springpython/aop

Spring Python's blog site moved to Wordpress

2009-02-09T03:10:00.000-06:00

I was enjoying running the blog site with b2evolution, but decided to spend the last few days switching over to wordpress. It has been pretty much smooth sailing. I was really happy to find that someone had already ported the theme to wordpress. Basically, the only thing I sacrificed were the user comments. It was just too much effort, and not enough talk threads to manage. I have been digging through plugins, and already have OpenID working. :)

Why use Spring Python and not just plain python?

2009-02-01T02:17:00.000-06:00

I have bumped into articles and forum postings, blog entries, other blog entries, and yet more blog entries. In fact, while writing this blog entry, someone posed the question "what is the aim of Spring Python?" (Click and see my answer.) There are a diverse range of view points, and many in disagreement about the viability of DI in python.

Many of these opinions raise a good question. Why do you need some complicated thing like Spring Python when you could be using pure python to do your job? I was very impressed with Jamis' article LEGOs, Play-Doh, and Programming. The core question is, why use complicated Java idioms that can be easily and dynamically expressed in pure ruby? I value this article because it encourages me to recheck my assumptions and ideas. It doesn't matter how good your solution is. If you built it on a platform of invalid, unwise, or ridiculous assumptions, you probably aren't going anywhere fast.

So, what ARE my assumptions?

Being able to apply extra services to my code without touching the code is good.

Being able to inject test dummies into my code without editing my code is good.

Simplifying and reducing code volume is good.

Using fancy tricks that are hard to read the next day is bad.

Using Problem A's solution for Problem B without analysis is dumb.

I want to compare this against what some people may think my assumptions are.

XML is the way to configure everything.

Java's solutions are perfect for Python.

Dependency Injection should be used for every problem.

Let's look at this in closer detail. Hopefully, I can show some insight into places where I think Spring Python can help, and other places it would be overkill to use it. Nothing works everywhere, right?

Being able to apply extra services to my code without touching the code is good - True

The first couple of things I can think of are transactions and security. These are functions, that when you implement them by hand, are a pain in the neck! You keep writing the same boilerplate plumbing code wrapping logical blocks, and you have to do it right every time, or you may find yourself in a big hole.

Sure, any part of your code not working correctly is an issue. But this isn't YOUR code we are talking about. This is simply a layer of protection you are trying to wrap around code to make it safe. There isn't a whole lot of logic in transactions or security, just simple, copy-and-pasted stuff you need. And we know what risk we are at when copy-and-paste starts happening.

That is the definite code smell that AOP is needed. Spring Python provides an AOP solution. You can write any type of advice you need. But considering how prevalant transactions and security are, we went ahead and coded a flexible, pythonic way to do it.

But don't forget. The premise is that this is applied without modifying your working code or your calling code. If only we could have something that sat between the business code and the "main" function that calls the code, which managed instantiation of dependencies, and which we could modify with no impact.....you mean, like an IoC container?

I know what you're thinking. "Oh no! Not that XML stuff! I want to stick to python." Who said you have to use XML? You can code your transactions simply using python decorators and a pure python container. XML is only provided to help people coming from Java-land migrate to Python. Some people like XML. Some people don't. Its a choice, not a requirement.

I know there is something else to consider. If I'm using TDD and I am spotting the places where I need to make changes, why can't I just make the changes right then and there? If there is only one time and one place where you are injecting your AOP advice, you are probably right. It is when you need to apply one piece of advice in multiple places where you start doing the copy-and-paste routine. And when you need to add more advice, and repeat this whole process over again where things get costly. Instead, one refactoring to expose that service as an injection point, and you can easily adjust things in the future.

Being able to inject test dummies into my code without editing my code is good - True

Testability of dynamic code is key. We preach that dynamic typing works, provided you adequately test your code. If you remember anything from your computer engineering courses in college, the more components you have, the greater the number of permutations of state. Being able to isolate functionality is the way to increase confidence in test cases, and that means we need to be able to replace production dependencies with test doubles.

It is easy to get caught up in the "I want to inject everything" hype. Don't! Instead, only inject key things. TDD will expose what test doubles you want to inject, and thus what parts need to be wired by IoC. If your application is small enough, you may not need any at all. And that's alright! Perhaps you start off, and all you need to inject is a database test double. Assuming you have defined MyApp and DataAccess, your container definition can be as simple as:

class MyAppContext(PythonConfig):
    def __init__(self):
        super(MyAppContext, self).__init__()

    @Object
    def my_app(self):
        return MyApp(self.data_access())

    @Object
    def data_access(self):
        return MyDataAccess()

For your test case, you just need an alternative:

class MyTestableAppContext(MyAppContext):
    def __init__(self):
        super(MyTestableAppContext, self).__init__()

    @Object
    def data_access(self):
        return DataAccessStub()

How hard was that? You just extend your existing container, overriding a key injection point, and poof! You're there with a nicely isolated, testable version of your code! I don't know about you, but that is arguably a DSL, written in pure python.

Simplifying and reducing code volume is good - True

I mentioned transactions earlier. Let's look at an ugly example of some code with transactions:

class Bank:
    def __init__(self):
        self.factory = factory.MySQLConnectionFactory("springpython", "springpython", "localhost", "springpython")
        self.dt = DatabaseTemplate(self.factory)

    def balance(self, account_num):
        results = self.dt.query_for_list("select BALANCE from ACCOUNT where ACCOUNT_NUM = %s", (account_num,))
        if len(results) != 1:
            raise InvalidBankAccount("There were %s accounts that matched %s." % (len(results), account_num))
        return results[0][0]

    def withdraw(self, amount, source_account_num):
        if self.balance(source_account_num) < amount:
            raise InsufficientFunds("Account %s did not have enough funds to transfer %s" % (source_account_num, amount))
        self.dt.execute("update ACCOUNT set BALANCE = BALANCE - %s where ACCOUNT_NUM = %s", (amount, source_account_num))

    def deposit(self, amount, target_account_num):
        self.balance(target_account_num) # Implicitly testing for valid account number
        self.dt.execute("update ACCOUNT set BALANCE = BALANCE + %s where ACCOUNT_NUM = %s", (amount, target_account_num))

    def transfer(self, transfer_amount, source_account_num, target_account_num):
        try:
            cursor = self.factory.getConnection().cursor() # DB-2.0 API spec says that creating a cursor implicitly starts a transaction
            self.withdraw(transfer_amount, source_account_num)
            self.deposit(transfer_amount, target_account_num)
            self.factory.getConnection().commit()
            cursor.close() # There wasn't anything in this cursor, but it is good to close an opened cursor
        except InvalidBankAccount, InsufficientFunds:
            self.factory.getConnection().rollback()

If you can rip out that plumbing code, your code becomes cleaner, easier to read, and easier to maintain. The following shows the code where you don't have to explicitly manage the transaction. Instead, it is declared using a python decorator.

class Bank:
    def __init__(self):
        self.factory = factory.MySQLConnectionFactory("springpython", "springpython", "localhost", "springpython")
        self.dt = DatabaseTemplate(self.factory)

    def balance(self, account_num):
        results = self.dt.query_for_list("select BALANCE from ACCOUNT where ACCOUNT_NUM = %s", (account_num,))
        if len(results) != 1:
            raise InvalidBankAccount("There were %s accounts that matched %s." % (len(results), account_num))
        return results[0][0]

    def withdraw(self, amount, source_account_num):
        if self.balance(source_account_num) < amount:
            raise InsufficientFunds("Account %s did not have enough funds to transfer %s" % (source_account_num, amount))
        self.dt.execute("update ACCOUNT set BALANCE = BALANCE - %s where ACCOUNT_NUM = %s", (amount, source_account_num))

    def deposit(self, amount, target_account_num):
        self.balance(target_account_num) # Implicitly testing for valid account number
        self.dt.execute("update ACCOUNT set BALANCE = BALANCE + %s where ACCOUNT_NUM = %s", (amount, target_account_num))

    @transactional(["PROPAGATION_REQUIRED"])
    def transfer(self, transfer_amount, source_account_num, target_account_num):
        self.withdraw(transfer_amount, source_account_num)
        self.deposit(transfer_amount, target_account_num)

If you focus your attention on the transfer method, you should notice an improvement in readability. At first, maybe it doesn't like much. But try to visualize cleaning up a whole slew of transactional blocks of code you have to maintain, and the benefits starts to add up.

Also, I don't know if you noticed, but the withdraw and deposit operations aren't safe enough to be part of the public API. They need to be transactional as well. So why aren't they? Well, I wanted this to be an apples-to-apples comparison. You can't just blindly wrap the first sample of deposit with a transaction, because the transfer function may have already started a transaction. You need to test to see if you are already part of a transactions.

Guess what: @transactional handles this for you. The second example is easy. Just put @transactional in front of withdraw and deposit and you are done. The PROPAGATION_REQUIRED tag indicates a transaction will be started if one doesn't already exist. Doing this with the first example would have required hand-written code to track whether you were in or out of transactions.

class Bank:
    def __init__(self):
        self.factory = factory.MySQLConnectionFactory("springpython", "springpython", "localhost", "springpython")
        self.dt = DatabaseTemplate(self.factory)

    def balance(self, account_num):
        results = self.dt.query_for_list("select BALANCE from ACCOUNT where ACCOUNT_NUM = %s", (account_num,))
        if len(results) != 1:
            raise InvalidBankAccount("There were %s accounts that matched %s." % (len(results), account_num))
        return results[0][0]

    @transactional(["PROPAGATION_REQUIRED"])
    def withdraw(self, amount, source_account_num):
        if self.balance(source_account_num) < amount:
            raise InsufficientFunds("Account %s did not have enough funds to transfer %s" % (source_account_num, amount))
        self.dt.execute("update ACCOUNT set BALANCE = BALANCE - %s where ACCOUNT_NUM = %s", (amount, source_account_num))

    @transactional(["PROPAGATION_REQUIRED"])
    def deposit(self, amount, target_account_num):
        self.balance(target_account_num) # Implicitly testing for valid account number
        self.dt.execute("update ACCOUNT set BALANCE = BALANCE + %s where ACCOUNT_NUM = %s", (amount, target_account_num))

    @transactional(["PROPAGATION_REQUIRED"])
    def transfer(self, transfer_amount, source_account_num, target_account_num):
        self.withdraw(transfer_amount, source_account_num)
        self.deposit(transfer_amount, target_account_num)

To tell you the truth, writing functional code I can maintain is my #1 goal in software development. I have inherited many projects that were impossible to read. They worked, but because they were so poorly done, I couldn't enhance or improve them, and thus began the refactor/rewrite.

Using fancy tricks that are hard to read the next day is bad - True

Only use Spring Python if you need it. And only use what you need. If you really need to mark up transactions in your code, this is perfect. But if your tool doesn't need that protection, forget about it! If your tool needs rigorous testing, utilize the IoC container to inject test doubles. But if you are writing a simple admin tool, then perhaps you don't need any IoC at all. Same goes for all the features.

If you need IoC and you are used to reading XML-configured app contexts (perhaps because you used to write Java code a lot), then you can easily utilize the functionality of Spring Python. But if you have been a pythonista since day one, forget about it! Use the pure python, decorator based container, and don't waste one minute on XML.

Using Problem A's solution for Problem B without analysis is dumb - True

Just because an AOP transactional interceptor was what you needed for Problem A, doesn't mean you need it for Problem B. And don't assume that your strategy of IoC injection points for Problem A will map cleanly to Problem B. Again, TDD should help you expose the injection points. I can't possibly predict where you need to inject dependencies. That is what software analysis is for.

Anyone can pick up and use a library. But using it for your needs (and not mine) is where judgment calls come in. Your experience in using tools to solve problems is needed to figure out what parts of Spring Python will serve your needs.

XML is the way to configure everything - False

This is a false assumption, and unfortunately an oft repeated one. Notice that there was no XML to be found in my samples? I stuck with pure python, using what I argue is similar to a DSL. Consider writing your code to have some fluent APIs, and the pure python IoC container can easily and efficiently wire your application together as needed. I have also done my best to update documentation to show configuring things either way. Whether or not the documentation is up-to-date, please remember, you can ALWAYS stick with pure python.

Java's solutions are perfect for Python - False

I already wrote how Spring Python is not just a simple port. The idea is to grab higher level concepts that transcend languages, and see where they apply. Some perceive this as grabbing Java's solutions and dropping them into Python. It's not. I know a dozen or so computer languages (C, C++, Tcl, tk, expect, PERL, java, python, csh, bash, Forte 4GL, and more), and some problems I find occur no matter where I go. Some carry a similar solution, some don't. The key factor is, many of these problems need a solution that looks similar from 10,000 feet, but when you look deeper, the details are very different. That is what Spring Python strives for: solving some of the same high level concepts, where the high level perspective looks similar, but the details use the power and idioms of python. If you perceive one of my ideas as being out-of-whack, please drop me a comment, and I will be happy to discuss it.

Dependency Injection should be used for every problem - False

You need look no further than at coily, our command line tool, to see that some solutions don't require any Spring Python. Instead, good ole' raw python does the trick. Use Spring Python sparingly, and when it improves your efficiency, NOT just for the sake of using. This is the type of critical judgment you should apply to any library you utilize. Use what you need to solve your TDD test cases, and when they pass STOP! Move away from the keyboard. You are done.

Conclusion

I will say I have presented at least a minimal case that I'm not really using Java idioms, but instead solving higher level problems. People may assume I am reusing the idioms considering my library was inspired by one written in Java. But you really need to peel back the layers and see what is happening. This is true for any library you use. Look at the documentation we provide and inspect the source code, and see if you can spot any anonymous inner classes, or getter & setters. You won't find them. Instead, you find anonymous functions, python iterators, usage of standard python libraries, etc, and what I consider a slim-and-trim library of functionality. And on top of that, lots of documentation on how to use it along with a solid forum of support. Makes it more than just a random recipe posted somewhere, and subject to discovery by google.

Spring Python 1.0.0 (RC1) is finally here!

2009-01-22T00:27:00.000-06:00

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 http://springpython.webfactional.com, 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?

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 (http://springsource.com), 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 plugincoily 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!

Missed SpringOne Americas conference?

2009-01-21T22:00:00.000-06:00

Intro_to_Spring_Python_Turnquist

In case you missed my presentation Introduction to Spring Python, here is the slide show I presented.