geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Blevins <>
Subject Re: Deployment architecture
Date Mon, 03 Jan 2005 20:23:56 GMT
On Mon, Jan 03, 2005 at 11:04:25AM -0800, David Jencks wrote:
> On Jan 3, 2005, at 9:28 AM, David Blevins wrote:
> >Any ideas on how we would dictate the order of the deployment chain?
> Either writing a little class like the ejb interceptor builders or by 
> some kind of deployment descriptor.  If each element is a gbean, 
> linking them into a chain is pretty easy with our current xml based 
> gbean deployment system.
> >
> >-David
> On Jan 3, 2005, at 9:49 AM, Dain Sundstrom wrote:
> >>1. a chain of  builders with only one method, "build"
> >
> >Do you really mean a chain?  The word chain implies an order to me, so 
> >is there an order you are thing of?  If not, how about "set" or "bag".
> Definitely an ordered chain of "interceptors".  All deployments would 
> happen by feeding stuff into the single topmost interceptor.

It seems that if you took our existing deployment code which is very ping-pong-like, e.g.
builders bouncing data back and forth from each other in the four phases of deployment, and
tried to make it linear, e.g. a chain, you would end up with very macro-level interceptors
at the top passing very complex work objects to increasingly micro-level (finer-grained) interceptors
toward the bottom which are very dependent on parts of those complex work objects.  

In essence, what you are thinking about is like XSLT stylesheets; a number of overloaded build
methods or "templates" processing work objects a tree of "nodes".  In that world you definitely
get what i described, a few templates which start out fairly abstract and multiply rapidly
into several small templates to process the more specific parts of the tree.

I dunno if that is good or bad.  The clear thing is that we wouldn't end up with a one-phase
deployment system, just the four-phases spread out through the chain with strong coupling
between producers and consumers of work objects.

Again, still rolling this one around in my head.


View raw message