Remy Maucherat wrote:
Monitoring and controlling the native code from java is IMO quite usefull and important by itself. Even Apache supports limited monitoring ( SNMP, mod_status, etc ).
Ok. We'll see if I'm more convinced when you show your code ;) For now, I'm siding with Henri and his proposed solution.
Which proposed solution ? To drop "dynamic monitoring and reconfiguration" from requirements ?
So far I haven't even seen a final list of requirements for this new connector, and no design. We only have some ideas - most of them mapping to the drop of some requirements ( which is fine ). It is also clear we don't have any clear decision on how to solve the conflicting requirements. Henri is talking about some "discovery" requirement, and some other people talked about "discovery" for the cluster - how does this interact with the other requirement of "use httpd.conf and play nice with other modules" ?
Regarding "show me code" - I don't have to write a complex pice of code to prove my point. KDE DCOP ( and to a lesser extent, Gnome ) are good example of components that allow control from outside. We don't need something as complex ( well, dcop is not very complex, only the qt-depenent dispatching ).
I can understand the jk2 "object oriented C" is considered too complex. 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.
Seriously - if you take away the JMX and support for other servers - why not just use mod_jserv ? 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.
In any case - I haven't been very active lately, and my current interest is on the java side, so I can't vote -1. But it would really be bad if this will start without even having an agreed list of requirements, and
a design that is based on the requirements and takes into account the future ( "simple" is a nice word, but if it is not based on a sound design it's just a matter of time until it becomes unmaintainable complex ).
Costin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
