Glyn, How exactly is notification in 5 should be done? Should it be done at all? Engine builds the pipeline dynamically when request comes. It does not seem to cache handlers in any way (unless I missed something). That is it'll ask EngineCongiguration everytime, and so, if the information was updated in the configuration provider, it'll be used right there. Why notify the enhine then?
My biggest concern is (and was for a while) consistency of the pipeline when deployment and request processing are done at the same time. For example, a request is a half way through the chains and then an independent thread is redeploying something. The other half of the chains can already be processed with the updated deployment info which obviously may not be consistent with the processed first half. :) This may become quite a problem in a production system that cannot be brought down for redeployment. I thought that we should change the AxisEngine to provide a momentary locking capability based on a resource sync. -- Igor Sedukhin .. ([EMAIL PROTECTED]) -- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11788 -----Original Message----- From: Glyn Normington [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 24, 2002 4:51 AM To: [EMAIL PROTECTED] Subject: Subsystem responsibilities: WSDD Glen Daniels and I are working to improve the modularity of Axis's "configuration" subsystem and are collecting together the WSDD-related responsibilities and removing them from the non-config. parts of Axis such as AxisEngine. We discussed this on the 'phone yesterday and put some sandbox code in a 'config-work' cvs branch which we aim to improve and merge into the main trunk in the next few days. Here are some points we discussed: 1. The configuration, e.g. as defined in WSDD, defines factory classes, options, and scopes for various handler types. 2. The configuration from an engine's perspective consists of a handler 'registry' (i.e. a collection of factories) and some 'global' options. We should introduce an EngineConfiguration interface to provide access to this configuration information by an engine. 3. Three is a fairly close relationship between configuration providers and the registry. Both are really part of the "configuration" subsystem. The engine should ideally not be aware of the distinction between configuration providers and registries so long as it has access to the EngineConfiguration that it needs. 4. The engine should not be directly involved in the details of how the configuration is constructed or modified as that tends to pull in types which are specific to particular configuration mechanisms such as WSDD. 5. An engine's configuration should be modified by getting hold of its EngineConfiguration, modifying that, and then notifying the engine so it can refresh its global options (and potentially other information). Glyn
