lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From peter royal <pro...@apache.org>
Subject Re: ThirdParty Jars in GData
Date Thu, 09 Nov 2006 15:48:38 GMT
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




-- 
proyal@apache.org - http://fotap.org/~osi




Mime
View raw message