[EMAIL PROTECTED] wrote:
I just commited a big chunk of config changes to support
dynamic configuration of jk2.
I'm pretty happy with the new model - many new things
will become possible.
As you know, I'm usually a bit extreme regarding backward
compatibility. Preserving it is still
If the file is handled by program it does not need to be nice:
for me the
property format is enough.
And -0 for using xerces C to do that... I want to run mod_jk
on EBCDIC machines
and porting xerces C is some work.
What about parsing the xml file in Java? ;-)
Hi Jf,
Did you have expat
I just commited a big chunk of config changes to support
dynamic configuration of jk2.
I'm pretty happy with the new model - many new things
will become possible.
As you know, I'm usually a bit extreme regarding backward
compatibility. Preserving it is still possible - but
I'm now convinced it
[EMAIL PROTECTED] wrote:
On Tue, 12 Mar 2002, jean-frederic clere wrote:
myworker1=
Would be the same as:
myworker1=ajp13://localhost:8009?lbfactor=0debug=ERROR
(no load balancing and only log error messages).
How to describe AF_UNIX or shared memory (as transport but not
[EMAIL PROTECTED] wrote:
On Tue, 12 Mar 2002, jean-frederic clere wrote:
What to do when myvhost is www.apache.org for example...
uri.www.apache.org:/examples.worker? Using ':' instead of '.' does not
solve the problem.
Sounds good.
If we use a hierarchical name we also solve
On Tue, 12 Mar 2002, jean-frederic clere wrote:
myworker1=
Would be the same as:
myworker1=ajp13://localhost:8009?lbfactor=0debug=ERROR
(no load balancing and only log error messages).
How to describe AF_UNIX or shared memory (as transport but not protocol)?
Even more extreme - use full uri, with query strings. We're in a http
server, we should know how to parse this kind of stuff :-)
Location /examples
JkUriSet worker
ajp13://tomcat_host.my.com:8009?lbfactor=10debug=INFO
/Location
Good, but Apache oriented
And another idea for
[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:
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
On Tue, 12 Mar 2002, GOMEZ Henri wrote:
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 )
setProperty, yes.
The current impl ( not checked in ) adds a new struct,
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
JkSet LogFile/var/log/httpd/mod_jk.log
I would use logFile, logLevel - current options in
workers.properties start will small caps, and this
can go in either w.properties and httpd.conf.
ok for logfile, logLevel instead of Logfile/LogLevel.
BTW, may be good to UsE aNY CaSE ?
I'm thinking about:
1. JkSet NAME VALUE
Will have exactly the same behavior as NAME=VALUE in a
workers.properties file.
All settings that you can do in workers.properties today
could be done by JkSet, in httpd.conf. Or all settings
could be done in workers.properties.
For example JkLogLevel
On Mon, 25 Feb 2002, GOMEZ Henri wrote:
JkSet LogFile /var/log/httpd/mod_jk.log
I would use logFile, logLevel - current options in
workers.properties start will small caps, and this
can go in either w.properties and httpd.conf.
The forward options : ?
JkSet Forward SSLKeySize
I'm understandably fond of ApacheConfig, but I realize that we can do
better. For the rest, see inline.
- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, February 22, 2002 11:02 PM
Subject: Jk2 config
I'm going to do few more changes to jk2 config
1. JkSet NAME VALUE
Will have exactly the same behavior as NAME=VALUE in a
workers.properties file.
All settings that you can do in workers.properties today
could be done by JkSet, in httpd.conf. Or all settings
could be done in workers.properties.
For example JkLogLevel DEBUG will
On Sat, 23 Feb 2002, Bill Barker wrote:
Instead of renaming all config directives with Jk2, I would
like to just _remove_ them all. If the old directives are
used in a config, mod_jk1 will do what's expected.
From what I've read, I'd still like a 'compatibility mode', to allow for
I'm going to do few more changes to jk2 config ( unless anyone has a
better idea ).
Instead of renaming all config directives with Jk2, I would
like to just _remove_ them all. If the old directives are
used in a config, mod_jk1 will do what's expected.
I would like to minimze the number
18 matches
Mail list logo
