On Nov 9, 2006, at 12:29 AM, Simon Willnauer wrote:
So except of the meta data work people would have to do it is just a replacement e.g reimplementation of a single method.Instead of Registry.getService() it would be ApplicationContext.getBean()is it that what you are alluding to?
kinda, but at a level one below that..You have all of these services/beans that live in the container. I'd make them one logical module in the project. They have zero dependencies on any specific container. Call it gdata-core
Then, you have another module, gdata-hivemind. This takes the components from gdata-core, and wires them up in a usable fashion with hivemind, puts them into the servlets, does the soap/etc exporting.
Now, say someone comes along and wants to integrate the gdata work into their spring container.. they have two choices. They can just take the core components from gdata-core, and drop them into their existing spring container. Or, perhaps someone wants to make a gdata- spring module, since they want to use some whizzy feature spring may have over hivemind. It may make sense to share some details of the wiring/etc with gdata-hivemind, or it may not. But they still share the same underlying components via gdata-core.
Or, to try to put it succinctly worded in another way... I'm advocating a separation of concerns: 1) The "work" components that do all of the heavily lifting. (gdata-core) 2) The assembly of said components into a functional application. (gdata-hivemind)
Given #1, you can make multiple versions of #2, using various assembly styles.
-pete -- [EMAIL PROTECTED] - http://fotap.org/~osi
smime.p7s
Description: S/MIME cryptographic signature
