Glyn, That is right engine does not call getConfig, although it does config.getHandler() for instance, so that can be easily replaced with getConfig(versionStamp).getHandler().
I was thinking to establish an EngineConfigurationProvider interface that would define getConfig(), getConfig(versionStamp) and getCurrentVersionStamp() methods. All config providers would implement it in addition to EngineConfiguration as necessary (i.e. if no versioning, then simply implement both by the same class). You're right, because of internal engine/handler dependencies we won't get away by simply enhancing the config provider/engine relationships. We'd have to add a version stamp parameter to getService, get... Methods of the AxisEngine, and also provide getConfigVersionStamp and setConfigVersionStamp on the MessageContext. That way no one will be misguided and won't make mistakes by getting head version all the time from the Engine. Note that this concerns only Engine, if one calls getService, etc. on the EngineConfiguration, then it's all good: version has already been resolved by the getConfig call. Actually the point is to get that version stamp just when the request arrives and then it's all good performance- and resource-wise... Another important element is to allow config providers to implement or not to implement versioning. Let's say we do it in Axis code and won't let config providers take control, then how can we make sure it's the best versioning implementation for any Db or any directory? That'll be hard. We can provide some default implementation for FileProvider over WSDDDeployment. That'll give it a good example on how to plug such feature in. We can leave SimpleProvider without versioning for that sake. -- Igor Sedukhin .. ([EMAIL PROTECTED]) -- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11788 -----Original Message----- From: Glyn Normington [mailto:[EMAIL PROTECTED]] Sent: Monday, February 04, 2002 10:43 AM To: [EMAIL PROTECTED] Subject: RE: Subsystem responsibilities: WSDD 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
