On Thu, 7 Mar 2002, GOMEZ Henri wrote: > >In future versions we can add anything - the code is now > >much more modular and easier to extend. > > Yes, and we had all to relearn it :-)
You already know me, as long as nobody complains ( and -1 ) I move on until I'm happy enough with the design. Jk was already 'object oriented C', I just enhanced that and tried to clean up a bit. > >For refresh - again, I would prefer an explicit control, maybe > >using the status worker ( or a config worker ) - you can deploy a > >new app on a dozen of workers, and then refresh the apache config. > > Arg, you'll see we'll have to create a nice WEB interface for this. > IBM does a superb job in their AS/400 implementation with a cool > UI creating workers/in-process/out-process tomcats, something I'd like > to see in jk2 and may be via a new jkconfig worker.... The best UI for configuration is xemacs ( or vi ) :-) Seriously - the properties file doesn't have to be visible to the user, it's just a format that is easy to parse on the C side and easy to generate/edit from java ( by a GUI, deploy tool, etc). KDE, Gnome, etc are using this kind of stuff without problems. The win registry is much worse, but still has a similar model - a hierarchical-named key/value. I love XML, and I could probably write expat code - but I don't think it's a complexity we need. A much better/simpler solution would be to have a XML config file and a simple xsl ( or just java xmlmapper/digester ) to generate the properties. I also think the _best_ solution to generate urimap.properties is not what we use in 3.3 ( the interceptor extracting info from inside tomcat), but a standalone tool ( eventually ant-scriptable ) that transforms web.xml directly ( == a deploy tool independent of tomcat ). Ant is obviously an excelent driver for this, but needs some work. Let's try to wrap up the first release of jk2 with minimal additional features ( i.e. don't let me change too much more :-) I still want to finish the setProperty() changes and allow the channel to be configured independently of worker ( it's cleaner, simpler - and similar with what we do in the java side of jk ). And I'll start to run end-to-end watchdog tests to make sure jk2/java is fine. My proposal is to first release jk2/java, as a replacement for the current jk connector/jk interceptor ( using mod_jk1 ). Then we can release mod_jk2 for apache2.0/1.3, and maybe finish the iis/nes updates. We are pretty close, the 'core' stuff is in a decent shape, and all extra features can be refined and updated in future releases. > >I think Apache has some time() function called ( so it can log the > >total time ). We can use it, and call the system if we want to > >tune our stuff ( but not in the default config, only if enabled > >and maybe per uri ) > > I was thinking about a faster time() alternative, there was hacks I think for now it is enough to have an option on the uri to enable counting, and use the system time. It's not an essential feature or something that should be enabled in production mode for all pages, it's maingly for tuning. Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
