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
