Return-Path: Delivered-To: apmail-xml-axis-dev-archive@xml.apache.org Received: (qmail 83457 invoked by uid 500); 5 Feb 2002 17:12:08 -0000 Mailing-List: contact axis-dev-help@xml.apache.org; run by ezmlm Precedence: bulk Reply-To: axis-dev@xml.apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list axis-dev@xml.apache.org Received: (qmail 83440 invoked from network); 5 Feb 2002 17:12:07 -0000 Message-ID: <849C1D32E4C7924F854D8A0356C72A9E015726E5@usilms08.ca.com> From: "Sedukhin, Igor" To: axis-dev@xml.apache.org Subject: RE: Heads up - engine configuration clean-up Date: Tue, 5 Feb 2002 11:52:48 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Glyn, That's right we can discuss it after you make changes. Basically if we want to support dynamic reconfig with versioning, passing factory as a parameter to the Engine constructor may be a good architectural simplification. Yes, we'll have one config factory instance per engine instance, but then the factory would be managing config versions, so it makes sense. The config factory implementor would then have polymorphic constructors with desired signatures (AxisEngine won't care). Safe dynamic reconfig is a nice feature. Worth spending some cycles... :) -- Igor Sedukhin .. (Igor.Sedukhin@ca.com) -- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11788 -----Original Message----- From: Glyn Normington [mailto:glyn_normington@uk.ibm.com] Sent: Tuesday, February 05, 2002 8:31 AM To: axis-dev@xml.apache.org Subject: RE: Heads up - engine configuration clean-up Igor, You wrote: >Will EngineConfigurationFactory be a parameter to AxisEngine >constructor? I had to think hard about this, but my intuition is that it would be better to pass an EngineConfiguration. Perhaps we should revisit this after I've made my changes as I think the trade-offs will be more visible. My current reasons for not passing a factory are: 1. I want to allow a variety of constructor signatures for concrete EngineConfigurations without forcing multiple factory instances (which would be necessary if the factory was passed as a parameter to the engine). 2. The lifecycles of engines and EngineConfigurations are more closely related than those of engines and EngineConfigurationFactories, so it would appear to make the engine more reusable to pass an EngineConfiguration instance than a factory. Glyn