Return-Path: Delivered-To: apmail-xml-axis-dev-archive@xml.apache.org Received: (qmail 15126 invoked by uid 500); 4 Feb 2002 15:39:40 -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 15102 invoked from network); 4 Feb 2002 15:39:39 -0000 Subject: RE: Subsystem responsibilities: WSDD To: axis-dev@xml.apache.org X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Glyn Normington" Date: Mon, 4 Feb 2002 15:43:00 +0000 X-MIMETrack: Serialize by Router on d06ml007/06/M/IBM(Release 5.0.8 |June 18, 2001) at 04/02/2002 15:39:20 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Igor, I'm a bit concerned that the engine would be using an interfaces which gives the impression of delivering a particular version of a configuration when the current configuration providers would not support this behaviour and would ignore the version stamp. Wouldn't it be better to build versioning into the current configuration providers for consistency? Also, I'm confused by your statement:: >Engine calls getConfig() like right now since AxisEngine doesn't call getConfig(). The EngineConfiguration is passed as a parameter on the constructor and later the engine asks for specific Handlers etc. from the EngineConfiguration. Your scheme would, I think, require the version stamp to be passed in on each of these methods. A better approach may be to supply a 'frozen' engine configuration instead of a version stamp. The 'frozen' version would be an EngineConfiguration which could, for example, keep a reference to the original and use some kind of copy on modification scheme (or alternatively clone when the 'frozen' version is created, but that would burn pathlength in the normal case of an infrequently-changing configuration). Glyn