Creation of beans.xml from pre-populated object graph...

[alopecoid]

Hi,

I'd like to use Spring's "beans.xml" file almost as a configuration file that instantiates, populates, and "wires together" beans for later use within an application. This is easily done. However, I also need the ability to do the INVERSE of this. Within an application, a graph of objects is created though some means, and I would like to save the state of this object graph as a "beans.xml" file, so that at some other time, I could recreate the graph, with the possibility of "by hand" modifying some values in the xml.

I know this sounds similar to an xml marshalling/unmarshalling framework (XStream, XMLBeans, etc.), but really it's more powerful... for the same reason we choose to "wire" objects via Spring over "unmarshalling" via some other framework.

I would say the idea is more similar to the way Apache Ant tasks work... a graph of objects is created, so that an application can later execute a given task, which is all setup and ready to go. However, Ant doesn't offer the ability to do the inverse either.

Now, before Spring came out (or became popular), I wrote a framework that would do what I need. I have been using it for years, and it works great. The problem is, I finally found the need to revisit some things in order to implement a few new features. However, Spring as a whole, offers so much more than my framework does, and unfortunately the xml is incompatible. So I find myself in the situation where I want to CLONE the way Spring wires together objects, and then implement the "inverse" as well. I feel like that this is replicating a lot of work, and furthermore, would require me to "upkeep" the framework to ensure Spring compatibility in the future.

I hate to make such a request, but I feel that the developers of the Spring framework could implement this quicker than I could because they are already familiar with the internals of the code. The pattern is really just to inverse the way the object graph is populated from the xml. The only thing to really worry about is when objects aren't instantiated using a "default" no-argument constructor, but this is something that could be solved very nicely using Spring AOP... by creating a MethodInterceptor that keeps track of objects that are instantiated via non-default constructors, or static/non-static bean factories.

I think this would also tie in very nicely with the [hopefully] up and coming feature of hot-deployment. Imagine being able to write out an already existing object graph, edit a few values that were perhaps erroneous or needed to be modified for testing purposes, and then having the changes in the graph occur... all during runtime!

Do any of the current Spring developers think that this could be a possibility in the future?

Thank you.

[irbouho]

Please log a request on JIRA.