[EMAIL PROTECTED] wrote:
> 
> 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.

I prefer the form [object_name].[property]=value.
That way the file could be handled in Java via ExtendedProperties.

> 
> Costin
> 
> --
> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to