tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <>
Subject Re: Some JK2 ideas v.3
Date Tue, 20 Jul 2004 04:09:04 GMT
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 ).


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message