geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <dsundst...@gluecode.com>
Subject Re: Deployment architecture
Date Mon, 03 Jan 2005 22:38:22 GMT
On Jan 3, 2005, at 1:30 PM, David Jencks wrote:

>
> On Jan 3, 2005, at 11:53 AM, Dain Sundstrom wrote:
>
>> On Jan 3, 2005, at 11:04 AM, David Jencks wrote:
>>
>> I'm not sure I like that also.  My thoughts have revolved around 
>> having a single builder responsible for a module type and child 
>> builders that can add stuff the deployment but are not the main 
>> builder.  For example, wars are currently handled by the JettyBuilder 
>> which means that it is this builder that is responsible for coping 
>> the files from the war archive into the deployment context, setting 
>> up the bulk of the class path, and the module GBeans.  Then if we had 
>> a portlet builder, it would get a chance to add to the classpath and 
>> add additional gbeans to the the deployment.  I envision this being 
>> implemented by the web module builder having a collection reference 
>> to child web module builders, and iteration over the set in each 
>> build method.  Is there something I'm missing that makes this 
>> complex?
>
> Well, right now the ear builder has references to a bunch of other 
> builders that it has to explicitly delegate various work to.  Your 
> proposal for the web builder is similar, in that it will have a set of 
> sub-builders that at various times it explicitly calls.

I think you are implying much coupling then I am.  I really mean that 
the child deployers, are just a set of deployers that only (for 
example) see 3 of the 4 deployment phases.  The just get a crack at the 
deployment unit after the main deployer has done its work.

> With an interceptor chain, you wouldn't need these references at all: 
> the ear builder would simply decompose ears into a bunch of modules, 
> and the other builders would find and work on them.  The web builder 
> would just work on the web.xml, and the portlet builder would just add 
> stuff to the context.  One way of looking at this is that with the 
> interceptors we are building a high level domain specific language for 
> deployment, and setting up the interceptor chain is programming 
> deployment in that language.  Instead of java code maintaining and 
> using references from one builder to another, we set up the 
> interceptor order to do the same work for us.   Of course the current 
> reference-based deployment system can also be regarded as a domain 
> specific language.  I think it might be harder to understand since it 
> has many more references and can't be written down linearly.  I'm by 
> no means convinced that my idea is good, but every time I've switched 
> to an interceptor based architecture it has really improved the power 
> and simplicity of the system.

I believe I understand what you are suggesting, I just don't think it 
is simpler.  I actually think this will be much more complex.  When 
deployment breaks, we will have to complex problems, missing 
"down-chain calls" and spurious "down-chain calls".

As a separate issue, I'm a bit skeptical that a chain metaphor will 
work.  My guess it that it is more like a tree, or valve.

>> My gut says, this is way complex and will be hard to debug.  The is 
>> mainly since there is no way to know who is responsible for a piece 
>> of data.  At the end, you have an extra piece of data, and you don't 
>> know if it was optional, if it is bad data, or it was good data and 
>> the expected builder was not online.  Just my gut.
>
> You could well be right, but I'm not sure it is any different from 
> what we have now.

It is definitely different.  The question is is it better? :)

-dain


Mime
View raw message