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]>
