I am looking into the same issue, and think that this parent/child context seems like a work around (albeit feasible in the short term), not a long term solution to the problem.
In my configuration context file for a IMAP/AMQP connector I have a number of "routes in". Each one has an inbound IMAP adapter, a filter bean, a transformer bean, and and outbound AMQP adapter. There are some channels and some Rabbit Infrastructure also defined for each route in.
I would like to be able to start and stop, and restart the "routes in" independent of one another. I see the ClassPathXmlApplicationContext and I understand what you are saying in theory, The idea is to put the inbound adapter for each "route in" into its own separate child context using ClassPathApplicationContext.
The child context can be created or destroyed, which would be the start/stop mechanism. Am I understanding correctly? What would be the mechanism for sending start and stop commands? a std-in adapter?
I have some experience with Integration Engines in healthcare. The Open source Mirth is a java based one. These engines have similar functionality to SI when it comes to channels, adapters, transformers, filters, etc, but they add a UI. The UI has WSWYG editor for the configurations, and it has a management console (threads, start, stop). The engines also have logging and queuing of messages is also built in. Given AMQP provides a generic queuing prtocol and Rabbit provides persistent queues detached from the integration piece, it is probably superior to the tightly coupled queuing strategy deployed in other integration engines I have seen.
It seems SI could also be the generic integration engine if it had the UI and management piece found in other products on the market.
We are interested in exploring this option in further detail.