Mladen Turk wrote:
Costin Manolache wrote
I can understand the jk2 "object oriented C" is considered too complex.
True.
But I certainly can't agree on a design that is not modular and doesn't support this basic requirement. We already have mod_jserv and mod_webapp
- and a long history of "rewrite from scratch to make it simpler" turning into far more complex code.
But we don't wish to write something modular and unlimitedly extendable.
Just the load-balancing-ajp13+ over tcp/ip connector, for Apache2.
Having that in mind, we have APR, and 'almost' a finite set of requirements,
without the need to 'think modular' or 'think cross-webserver'.
Lot of the code would be reusable, but it would mean that making a mod_jni
connector would mean to make a completely different project without some
common directory holding shareable code.
Also making any additional 'features' to the connector (like 'discovery'
etc.) would have to be made as such, and enabled during compile time, so
that the basic functionality remains as is. This means that we don't compile
everything and then use the config to either enable or disable features, but
rather make something like 'mpm concept' selectable at compile time.
Seriously - if you take away the JMX and support for other servers - why not just use mod_jserv ?
No one prevents you of making mod_jmx that will allow entire Apache2 to be
maintainable trough JMX console, not only our module :).
A great idea, but probably something which should be a whole new module,
mod_jmx or mod_cmx (C Management Extension). I'm sure the HTTPD team will be more than pleased to discuss this.
Regarding other servers you meant IIS (other are less then couple of
percent) probably (apache13 users can use jk). I would like to make the
'real' IIS6 filter that will go in the NT kernel's http.sys, have dynamic
thread pool and MMC snap-in, but that is something completely different. Few
things like config tree, ajp protocol and transport can be reused cause now
we have the APR that generalizes the OS layer. If you wish to write a good Apache2 module or IIS filter, they have to be
different projects. Also being usable from admins point of view requires
that the apache module is configurable trough httpd.conf, and IIS trough
GUI. None of them uses JMX to configure the webserver thought.
I have on my dash-board for a long time a project that will make a TC as a main web server, having Apache as a 'slave' for additional PHP and Perl support, but that also is something completely different and questionably usable.
After all mod_jk and jk2 got complex because of additional requirements and features that we wanted to implement - if we drop them then we can just go back and use mod_jserv.
Think that the main problem is that we don't understand the JK2 code any more, and that the modularity combined with crosswebserver became an obstacle rather then a feature.
Yes, that's a perfect resume of the current situation.
I don't have problem with writing clean C to make something JMX/CMXizable but it appears to add some complexity.
Just take a look at the actual code in jk2 :(
...
int JK_METHOD jk2_channel_setAttribute(jk_env_t *env,
jk_bean_t *mbean,
char *name, void *valueP)
{
jk_channel_t *ch = (jk_channel_t *)mbean->object;
char *value = valueP; if (strcmp("debug", name) == 0) {
ch->mbean->debug = atoi(value);
}
else if (strcmp("disabled", name) == 0) {
ch->mbean->disabled = atoi(value);
if (ch->worker != NULL)
ch->worker->mbean->disabled = ch->mbean->disabled;
}
else {
if (ch->worker != NULL) {
return ch->worker->mbean->setAttribute(env, ch->worker->mbean,
name, valueP);
}
return JK_ERR;
}
return JK_OK;
}...
The problem with C is there is no introspection helper so we have to do many things by hand and it tend to 'offuscate' the real code.
I'd rather like simple C way:
int ajp_channel_setDebug(jk_channel_t * channel, int debuglevel); int ajp_channel_setState(jk_channel_t * channel, int state);
int ajp_channel_open(jk_channel_t * channel); int ajp_channel_close(jk_channel_t * channel); int ajp_channel_read(jk_channel_t * channel, apr_pool_t * buf); int ajp_channel_write(jk_channel_t * channel, apr_pool_t * buf); int ajp_channel_hasInput(jk_channel_t * channel);
That's one of the reason I suggested a specific Apache 2.x module, to follow the HTTPD dev team habbits which are still plain C.
May be a pre-requisite to go farther will be to discuss with them what should be a CBean ?
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
