Yes, it's happening again... I feel I'm really close to what I want - so please send feedback !
The goal - improve mod_jk2 configuration. Subgoals: - make it more intuitive / simpler / cleaner - allow runtime changes ( and query ) The proposed solution: Same config model that is used in Java beans. All jk components will have a setProperty() and the config will be 'pushed' by a config module. A component can react at runtime to some config changes ( most don't - but that can change in time, it's the model that matter ). That means no code in mod_jk2 will use things like: jk_map_getStringProperty("worker.ajp13.port" ), but the config module will locate 'worker.ajp13' and call setProperty("port", "8009" ). The config module can be pluggable itself - it can read the config from the properties file or from registry, XML, wire protocol ( ajp14 or something else ), LDAP, NDS, whatever :-) Most likely properties file for the first release, of course. Again, we'll deal with named components and properties - I'll not call it jk_mbean, but it'll be close. The syntax for the properties file will be slightly changed ( again ). There are 2 ways to do it: [property]:[object_name]=value [object_name].[property]=value The first property for each object must be 'type' ( with a special exception for URIs ). The type will be used to construct the object, like className in java side. ( I can eliminate this requirement, but later, I want to keep first version simpler ). It is possible ( probably not in the first release ) to get a message if a property name is not recognized ( right now this is siltenly ignored in jk1), or if the value is wrong ( and stop ). The first form is usefull for URIs or names that are 'stranger', the second is good for backward compat. Each object will be created and registered in the jk_env. A getProperty will allow read access to various properties, including dynamically-constructed. Comments please, after I'm done with that I would like to freeze and prepare for an alpha/beta, and it will be harder to change too much. Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>