This is mostly a reminder of the previous discussion, and an update wrt. the java side, now based on coyote.
We agreed ( I hope :-) that mod_jk ( C ) needs a better config, and we agreed that the new config must support both user-editable and runtime changes ( like discovery, etc - where the ajp14 API will push new apps or workers and mod_jk will persist those ). We also agreed on a format for the C side - basically extended properties, as used in ini and other files. The java side of jk2 was designed to work closeley with the C, it has similar architecture and config. In particular, it can use a properties file that is similar in semantics and use ( now it's just plain properties ). Also on java side we support other options - like the web.xml file, interceptors.xml, server.xml. The first 2 are now removed ( since we use Coyote ). The problem is that jk2 has more configuration than what we cleanly express in server.xml. It supports a variable number of 'workers', different channels with different properties, different protocols. We can create some 'hardcoded' configs with the options used in Ajp13, but that wouldn't cover JNI or unix sockets or future versions. My preference is to keep the jk2 config separated and in a properties file. We'll default to a sane behavior ( ajp13 ) if this is not present. If users want to customize Jk2, they'll use the properties file or a tool. The main benefit of moving the jk config outside of server.xml ( and the 3.x and 4.x specifics ) and into a properties file is that it'll make it much easier to support JMX or dynamic configuration. As in the C side, the connector will 'control' the config repository and will save it. Another benefit ( for future ) is that we might be able to support ( in both C and Java ) a pluggable config repository. I already added the 'interfaces' in C, and java is simple ( but not a priority ) - we could store in a platform-specific repository ( via 1.4 preferences or jndi ), etc. Things like win registry or LDAP/NDS. So my proposal is to make jk2.properties the 'official' config for jk2 connector. The coyote Connector will just pass minimal information, i.e. the location of the jk2.properties ( or catalina.base/tomcat.base ). Short term will have the pain of configuring a different file with a different ( and non-xml) syntax ( but that's required anyway - for the native code ). Long term we'll have nice support for JMX and other important things. Craig may tell us a bit about the 'fun' of adding JMX and supporting server.xml :-) Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
