>> 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.
And that's fine :) >Jk was already 'object oriented C', I just enhanced that >and tried to clean up a bit. And it works well, better design and working implementation >> >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 ) :-) May be for experienced users/admins, but this kind of tools are one of the reason IT managers choose products like websphere because they fill it will be easier to manage. >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. Agree >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. Yes >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 ). Good idea >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 :-) +1 >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 ). ok >Then we can release mod_jk2 for apache2.0/1.3, and maybe >finish the iis/nes updates. what's the status of iis/nes/domino ? >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. Exact, it will be used only on LOGREQUEST mode. Which make me think that we could have this one in a + mode. JkLogLevel info + request instead of JkLogLevel request -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
