>Yes, it's happening again... I feel I'm really close to
>what I want - so please send feedback !
Let's go
>The goal - improve mod_jk2 configuration.
>Subgoals:
>- make it more intuitive / simpler / cleaner
>- allow runtime changes ( and query )
good
>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.
ok
>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 ).
ok
>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" ).
You mean
the config module will locate 'worker.ajp13'
call getProperty("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.
ok
>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
[object_name].[property]=value will help make blocks
>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 agree, let's go
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
