A simple Spring challenge

I got some comments on my Biggus Dickus article in its own comments section as well as on programming.reddit. Many people defended Spring on grounds of its usability, whereas others identified the author of this lines as completely clueless. I don’t want to argue against the latter and they are certainly right that Spring is the way enterprise software shall be written to eliminate Java complexity.

SpringSource made just the mistake of supporting dynamic languages but omitted Jython which wasn’t hip for a while and now countless amateurs, Java mavericks and inevitable crackpots feel attracted by Spring and seek their luck. Once you open the door to this folks they want to feel comfortable in their own way which means they want to get rid of XML configuration files and enable self-management for dynamic languages.

The problem description

It is not much effort to use Springs dependency injection (DI) machinery. The Spring user can follow a Bean creation protocol which looks cumbersome on the first sight but one gets used to it very soon.

Spring defines a BeanReaderInterface implemented by the PropertyBeanDefinitionReader and XmlBeanDefinitionReader classes. So what about adding a JythonBeanDefinitionReader along with a JythonBeanFactory replacing the DefaultListableBeanFactory or another factory of this kind which is typically used? The following protocol shows how to tangle both types and how to create new bean instances without letting the application know anything about configuration logics:

JythonBeanFactory factory = new JythonBeanFactory();
JythonBeanDefinitionReader reader = new JythonBeanDefinitionReader(factory);
SomeBean obj = (SomeBean)factory.getBean(name);

How can JythonBeanFactory and JythonBeanDefinitionReader possibly work ? In a simple case the Reader uses the Jython API and imports a Python module which defines parameter-less functions like the following:

def source():
    # creates SomeBean object and returns it

Calling factory.getBean(“source”) will invoke the source() function which returns a SomeBean object. Eventually the object has been cached but at this stage I do not want to complicate the design if it can be avoided.

Both classes can be implemented on an elementary level as a simple exercise of embedding Jython in Java and using the Jython API.

The Challenge

Now try to write both classes s.t. they do fit into the Spring framework. As I said above it is a basic exercise to write them but side stepping the Spring interface hierarchy would just mean to create another DI framework which is off topic here. They shall implement Spring interfaces and they shall replace existing bean readers and factories. This is not hackish and Spring itself has foreseen such extensions as use cases of the framework.

  1. Dave says:

    Interesting stuff! I have a couple of questions…

    • Why a JythonBeanDefinitionReader? The problem is that this part of Spring’s internals is assuming you’re loading in BeanDefinitions, not instantiated beans. Once that’s done, the internals will take care of wiring up the dependencies and instantiating the BeanDefinitions (with an instantiation strategy). What you’d end up with is a config file that happens to look like Jython source but that is really parsed in the same way as the XML config files are – unless you have source that returns instances of BeanDefinition…?

    • Are you trying to have a jython source file that knows how to instantiate all the beans and wire up all the dependencies itself – without spring knowing anything about the wiring – and then make those jython beans available in a BeanFactory? If so, are you essentially running a script that populates a StaticListableBeanFactory?

    • If you’re trying to mix Jython beans with Java beans, are you able to use the ScriptFactory support to create scripted bean instances within the standard XML config? Or is the whole point to ditch the XML, the autowiring, all that stuff entirely?

  2. Dave says:

    Well, I stuffed that formatting up! :D

  3. kay says:

    Thanks for your reply, Dave.

    My request covers essentially the second case. I just wonder if StaticListableBeanFactory isn’t somewhat limited in functionality as a singleton provider? I’d have expected a composition of a simple bean factory ( “JythonBeanFactory” ) which creates new object instances on every call of a factory function – this is essentially the part of the Jython module which implements the wiring – and an upstream factory which is parametrized by the role or “scope” of the Bean ( which is the proper Spring term AFAIK ) and controls the life cycle of a Bean and requests new Beans on demand from the JythonBeanFactory.

    I’m not sure if this is possible in Spring or if it is a request for a different, pluggable architecture?

  1. There are no trackbacks for this post yet.

Leave a Reply